this in [1], but the
conclusion is not clear to me.
[1] https://trac.osgeo.org/gdal/ticket/4285
Best regards from Knut-Frode
On 24. jan. 2013 20:43, Even Rouault wrote:
Did you try to do your suggestion at hand to actually check that your idea
leads to the expected result ? This is basically a matter of running :
1) gdaltransform -s_srs EPSG:4326 -t_srs "+proj=stere +lat_0=90 +lon_0=0" on
the coordinates of the GCPs o
P coordinates. A simpler and more pragmatic solution
could be to make a separate Python script gdal_translate_gcps.py?
Are there other suggestion to deal with these problems?
Best regards from Knut-Frode
___
gdal-dev mailing list
gdal-dev@list
(AutoCreateWarpedVRT), but it seems to have no option to use -tps (?) -
so therefore I have to call gdalwarp as system command.
Knut-Frode
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev
too close together. Are yours
evenly distributed? Can you do tests with subsets of control points?
On 12/12/2012 01:27 PM, Knut-Frode Dagestad wrote:
Hi Jan,
That sounds interesting and promising.
For the mentioned file it takes about 2 minutes with "-et 5" (low
accuracy), and 12
es running?
Jan
On 12/12/2012 01:12 PM, Knut-Frode Dagestad wrote:
Hi list,
When warping images with many GCPs, the -tps switch (Thin Plate
Spline) is found to be necessary to get decent accuracy. This makes
however warping very slow. The only method I found to increase speed
is the -et switch, bu
llowing file and command on Ubuntu:
http://dl.dropbox.com/u/15885758/testgcp.tif (3212 GCPs and 2048x2511
pixels covering Southern Europe)
time gdalwarp --debug on -et 5 -tps -t_srs '+proj=merc' testgcp.tif
out.tif (+ other swithces mentioned a
.
Thank you for looking into this.
Best regards from Knut-Frode
Den 26.11.2012 22:14, skrev Frank Warmerdam:
On 12-11-26 12:11 PM, Knut-Frode Dagestad wrote:
Dear list,
Warping datasets with geolocation arrays works fine if the arrays have
the same
size as the other raster bands. However, if the
a workaround I convert the
geolocation arrays to GCPs. This gives decent warping quality, but is a
bit awkward.
Is this the expected behavior of the present implementation of
geolocation arrays in GDAL?
Best regards from Knut-Frode
___
gdal-dev
h a 3D Dataset?
The rasters are large and timeseries long, so reading everything into a
Python NumPy cube is not a good solution.
Thanks,
Knut-Frode
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev
d not sure if
endianness is relevant at all? I could make available a sample file for
anyone interested to look at the problem.
Best regards from Knut-Frode
On 28. feb. 2012 17:06, Even Rouault wrote:
Knut-Frode,
I've skimmed quickly through the driver code and if you are lucky, it is
p
find any software to convert such images to a format
which can be read by GDAL.
Does anyone have some hints?
Best regards from Knut-Frode
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev
-image from row/col of the geotransform-image.
Can anyone explain why then the direct transformation does not work? I
suspect a small fix could possibly solve this problem?
Best regards from Knut-Frode
[1] http://trac.osgeo.org/gdal/ticket/4442
[2] http://www.gdal.org/gdal__alg_8h.html#767169
, e.g. defined as 0 for pixels where north is "up" (as
it would always be in a lon-lat or Mercator projection).
This angle is relevant e.g. when one want to know the sensor look
direction for satellite images.
Best regards from Knut-Frode
__
lg_8h.html#94cd172f78dbc41d6f407d662914f2e3
But there is no corresponding option to force use of GCP_POLYNOMIAL for
the *destination* dataset. I guess this is a bad sign?
Thank you for any help!
Knut-Frode
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.o
vertical axis) in GDAL
would be ideal, but that would probably be too much an effort for anyone
to develop.
Knut-Frode
Nansen Environmental and Remote Sensing Center
On 24/08/2011 22:37, Etienne Tourigny wrote:
Hi all,
I would like to start a discussion with those interested about fixing
software.
The incidence angles are stored in a small grid at the same size as the
GCP´s, (order of 100 elements), which does not fit very nicely into the
GDAL datamodel - it would probably have to be stored as a list of
metadata strings.
Best regards from Knut-Frode
On 15/05/2011 18:18
On 13/05/2011 19:07, Even Rouault wrote:
I had also a similar error on Linux, but it worked despite the error. I have
pushed a fix in trunk to silent that error. You can try to add a printf()
statement in your GDALRegisterMe function to check if it is loaded correctly.
You are right, it works
Any ideas what is wrong? OS is Mac OS X 10.6.7. I am not a C expert.
Best regards from Knut-Frode
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev
and inversions. I.e. things that are better done
in C than in Python.
Best regards from Knut-Frode
On 11/05/2011 21:05, Antonio Valentino wrote:
Hi Even, hi Knut-Frode,
Il 11/05/2011 20:08, Even Rouault ha scritto:
Le mercredi 11 mai 2011 11:53:55, Knut-Frode Dagestad a écrit :
Hi
not be used by command line
utilities (e.g. gdalwarp and gdal_translate) or from Python?
Best regards from Knut-Frode
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev
iting to file.
Best regards from Knut-Frode
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev
standard HDF4-libraries I have used. The "lib not found"
message from GDAL configure seems to be misleading.
Best regards from Knut-Frode
Den 20.04.2011 17:03, skrev Nikolaos Hatzopoulos:
when does the gcc
you must have: -L/Users/knutfd/Software/hdf-4.2.5/lib
in order to fi
d to use a "dev" version of HDF4, but I don't know
if that would solve this problem?
Best regards from Knut-Frode
On 19/04/2011 21:51, Nikolaos Hatzopoulos wrote:
hdf4 libraries not found that's what the log says :)
do a
locate libhdf4
to see where the library is
On Tue,
e (and also
http://trac.osgeo.org/gdal/wiki/BuildingOnUnix) suggests to try a
"hdf-dev" version. But where can I find such "dev-versions", in my case
for Mac OS X 10.6.7?
Would it be possible to update GDAL to work with standard HDF4 libr
ol and
lon/lat does not work since there are errors (contradictions) in the
list of GCP's (e.g.: http://trac.osgeo.org/gdal/ticket/3709).
Or is there another explanation?
Best regards from Knut-Frode
On 07.04.2011 13:31, Even Rouault wrote:
Selon Knut-Frode Dagestad:
Hi Even,
On 06
ops/WS%206/ESA%20SAR%20Products%20for%20Interferometry.pdf
Best regards from Knut-Frode
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev
ntonio has very similar needs and interests as our group.
Best regards from Knut-Frode
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev
APIs for additional
readers. But it is getting a bit messy to mix Python, C and Java in a
multi-platform environment (Linux, Mac and Windows).
Best regards from Knut-Frode
On 06.04.2011 10:13, Antonio Valentino wrote:
Hi Knut-Frode,
Il giorno Wed, 06 Apr 2011 09:51:42 +0200
Knut-Frode
?
Best regards from Knut-Frode
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev
30 matches
Mail list logo
