Hi,
I have some NetCDF files tagged with this proj4 string:
proj4=+proj=ob_tran +o_proj=longlat +lon_0=-40 +o_lat_p=22 +R=6.371e+06 +no_defs
As ob_tran seems not supported, is there any way I can warp this onto
a regular (unrotated) lonlat-grid?
There is a long, 3 yr old discussion on
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 of
Hi,
I am having trouble to perform accurate warping of images with GCPs
(lon,lat) in the high Arctic (to +proj=stere +lat_0=90 +lon_0=0);
problems starting already around 80 degrees of latitude.
Thin Plate Spline (-tps) performs better than polynomial fits, but
output is often severely
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, but at cost of spatial accuracy.
Below some comments about
/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, but at cost of spatial
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 minutes without
On 12. des. 2012 14:16, Jan Hartmann wrote:
It's far too slow here too, so it's not your build.
I see that the warp itself doesn't start but after a very long time, so
the problem lies in the initial computation of the transformation
matrix. It must have something to do with the distribution
Dear list,
Warping datasets with geolocation arrays works fine if the arrays have
the same size as the other raster bands. However, if the geolocation
arrays are much smaller, the quality is very bad.
Say I have a 2000x2000 px dataset with 100x100 px sized geolocation
arrays. Then a warped
.
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
Hi,
From a time series of colocated images, I construct a VRT with one band
for each time step using gdalbuildvrt:
gdalbuildvrt -separate mtsat.vrt mtsat/*_IR*00.tif
Are there any tools that can be used to calculate some statistics (min,
max, mean, etc) versus time for each pixel of such a 3D
Even,
Your suggestion sounds plausible is and probably both correct and
necessary. But unfortunately it is still not working with your patch, so
I guess there must be an additional problem.
Regardless of using the patch or not, and adding --debug on or not,
the output from gdalinfo is:
Hi,
The GDAL AVHRR driver seems to work only for data from the older NOAA-9
- NOAA-17 satellites: http://gdal.org/frmt_l1b.html
Hence it does not work for my NOAA-19 AVHRR files in HRP-format (from
Eumetcast), which have filenames like avhrr_20120227_235800_noaa19.hrp
I have not able to
Hi group,
In searching for the reason for the bug reported in ticket #4442 [1], I
have made some tests with gdal.Transformer in Python:
A transformer defined generally as:
T = gdal.Transformer(src_ds, dst_ds, [''])
can be used to convert row/col from src-image to row/col of dst-image.
Behind
Hi,
For datasets with only GCPs for geolocation, is there any convenient and
efficient method to extract latitude and longitude values as arrays of
same size as the raster bands, using the Python API?
And similarly: is there an efficient method to return full arrays of the
azimuth
Hi,
Hróbjartur Þorsteinsson explained to me a near-hidden feature of GDAL,
namely to reproject one image onto the coverage of another.
Given two images:
imageA.tiff
imageB.tiff
Then an empty image can be created from image A with e.g.
$ gdal_translate -ot Float32 -scale 0 0 999 999 -a_nodata
Etienne,
My group is also very much in support of the suggested improvements, as
NetCDF/CF is becoming the most important standard for data
storage/exchange in our community (climate, meteorology, oceanography).
My group is not much into GDAL driver development (at least not yet),
but we are
Hi RSyaoxin and Antonio,
I share your interest in these metadata. In addition to the MPH and SPH
metadata in ASCII-format, Envisat files contain a lot of metadata in
binary form, e.g. for ASAR:
http://envisat.esa.int/handbooks/asar/CNTR6-6.htm#eph.asar.asardf.asarrec
It would probably be too
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
On 13/05/2011 12:07, Antonio Valentino wrote:
If you think it is useful I can attach the fake-driver code to the
#3367.
Thank you, that would be useful.
In the meantime I have tested this approach, nearly successful:
I copied one of your pixel-functions from #3367 and made a dynamic
library
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
Hi!
If I have two overlapping raster images, how can I interpolate one of
them to the exact coverage of the other image, so that they can be
compared pixel by pixel?
I primarily want to do this with Python API, but tips on how to do it
with commandline utilities are also welcome. The two
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, Apr 19, 2011 at 10:24 AM, Knut-Frode
Hi Even,
On 06.04.2011 20:21, Even Rouault wrote:
You can certainly write a (non-GDAL) reader in Python, but of course, you
won't be able to benefit from the GDAL API with the dataset returned by your
reader, or using them in software that use the GDAL API.
But if I use the GDAL API to create
Antonio,
On 06.04.2011 13:09, Antonio Valentino wrote:
I'm not sure to understand. GDAL reads data from the product. If the
product is not geo-referenced you will get data that are not
geo-referenced.
In this case you could use GDAL tools to interpolate data in a
geographic grid but you need
Even,
Thank you. That clarifies, and motivates use of the MEM format.
I gradually start to understand that GDAL is generally more
file-oriented than memory-oriented.
Then I have one last question for this thread:
As mentioned in another post, for some formats (e.g. Envisat) both the
image
Thank you for useful comments, Antonio.
I agree with you that the ideal thing would be to improve the support of
GDAL for our satellite data formats of interest. It would be great if we
could combine efforts and get some momentum on this.
Several formats (e.g. TerraSAR-X, Envisat ASAR, MERIS
26 matches
Mail list logo
