[gdal-dev] Geolocation Arrays ??

[Etienne Tourigny]

Brian, thanks fot the info.

I have seen that on all tests I made (without -te option).  Sometimes
it fails completely, and sometimes it creates an extent that is too
large.

Would it make sense, if the geolocation SRS and target are SRS are the
same (e.g. WGS84), to calculate the target extents from the min/max of
the geolocation arrays?
Current extent detection code seems to try many transformations with
proj4, and either fails or creates an extent that is too large.

regards,
Etienne


On Tue, Feb 7, 2012 at 8:46 PM, Brian Case <rush at winkey.org> wrote:
> Etienne
> with the transformer the way it sits now, in most cases you will need to
> specify -te xmin ymin xmax ymax with gdalwarp to avoid that error
>
> Brian
>
>
> On Tue, 2012-02-07 at 19:22 -0200, Etienne Tourigny wrote:
>> Even, Frank,
>>
>> thanks for your answers.  I have run into a problem with using
>> gdalwarp with geoloc transform.
>>
>> In ticket #1895 there is an hdf file for which the HDF4 driver creates
>> GEOLOCATION metadata.
>>
>> Trying gdalwarp on it gives an error, and the result transform is
>> incorrect.  Am I doing something wrong, or is this a bug?
>>
>> command is : gdalwarp -geoloc -t_srs EPSG:4326
>> HDF4_SDS:UNKNOWN:"A2006005182000.L2_LAC_SST.x.hdf":13 tmp1.tif
>> more info below:
>>
>> $ gdalinfo HDF4_SDS:UNKNOWN:"A2006005182000.L2_LAC_SST.x.hdf":13
>> Driver: HDF4Image/HDF4 Dataset
>> Files: A2006005182000.L2_LAC_SST.x.hdf
>> Size is 389, 602
>> Coordinate System is `'
>> Metadata:
>> [...]
>> Geolocation:
>>   LINE_OFFSET=0
>>   LINE_STEP=1
>>   PIXEL_OFFSET=0
>>   PIXEL_STEP=1
>>   SRS=GEOGCS["WGS 84",DATUM["WGS_1984",SPHEROID["WGS
>> 84",6378137,298.257223563,AUTHORITY["EPSG","7030"]],TOWGS84[0,0,0,0,0,0,0],AUTHORITY["EPSG","6326"]],PRIMEM["Greenwich",0,AUTHORITY["EPSG","8901"]],UNIT["degree",0.0174532925199433,AUTHORITY["EPSG","9108"]],AUTHORITY["EPSG","4326"]]
>>   X_BAND=1
>>   X_DATASET=HDF4_SDS:UNKNOWN:"A2006005182000.L2_LAC_SST.x.hdf":11
>>   Y_BAND=1
>>   Y_DATASET=HDF4_SDS:UNKNOWN:"A2006005182000.L2_LAC_SST.x.hdf":12
>> Corner Coordinates:
>> [...]
>>
>> $ gdalwarp -geoloc -t_srs EPSG:4326
>> HDF4_SDS:UNKNOWN:"A2006005182000.L2_LAC_SST.x.hdf":13 tmp1.tif
>> Creating output file that is 31119P x 5864L.
>> Processing input file HDF4_SDS:UNKNOWN:A2006005182000.L2_LAC_SST.x.hdf:13.
>> ERROR 1: Too many points (441 out of 441) failed to transform,
>> unable to compute output bounds.
>> 0...10...20...30...40...50...60...70...80...90...100 - done.
>>
>> $ gdalinfo tmp1.tif
>> Driver: GTiff/GeoTIFF
>> Files: tmp1.tif
>> Size is 31119, 5864
>> Coordinate System is:
>> GEOGCS["WGS 84",
>>     DATUM["WGS_1984",
>>         SPHEROID["WGS 84",6378137,298.257223563,
>>             AUTHORITY["EPSG","7030"]],
>>         AUTHORITY["EPSG","6326"]],
>>     PRIMEM["Greenwich",0],
>>     UNIT["degree",0.0174532925199433],
>>     AUTHORITY["EPSG","4326"]]
>> Origin = (-90.198287963867188,90.300000000000011)
>> Pixel Size = (0.015398926739995,-0.015398926739995)
>> Metadata:
>>   AREA_OR_POINT=Area
>> Image Structure Metadata:
>>   INTERLEAVE=BAND
>> Corner Coordinates:
>> Upper Left  ( -90.1982880,  90.3000000) ( 90d11'53.84"W, 90d18' 0.00"N)
>> Lower Left  ( -90.1982880,   0.0006936) ( 90d11'53.84"W,  0d 0' 2.50"N)
>> Upper Right (     389.001,      90.300) (Invalid angle, 90d18' 0.00"N)
>> Lower Right (     389.001,       0.001) (Invalid angle,  0d 0' 2.50"N)
>> Center      ( 149.4013126,  45.1503468) (149d24' 4.73"E, 45d 9' 1.25"N)
>>
>>
>> Regards,
>> Etienne
>>
>>
>> On Tue, Feb 7, 2012 at 7:05 PM, Frank Warmerdam <warmerdam at pobox.com> wrote:
>> > On Tue, Feb 7, 2012 at 7:40 AM, Etienne Tourigny
>> > <etourigny.dev at gmail.com> wrote:
>> >> Hi all,
>> >>
>> >> I would like to have information on the status of geolocation array
>> >> support in GDAL.
>> >>
>> >> The relevant RFC4 (http://trac.osgeo.org/gdal/wiki/rfc4_geolocate)  is
>> >> still "under development", and the information there is that
>> >> GDALCreateGeoLocTransformer "is currently partially implemented".
>> >
>> > Etienne,
>> >
>> > I think the geoloc transformer received some fixes from someone
>> > other than myself and now is working reasonable well.  It would
>> > be desirable to freshen up the RFC and get it passed but it isn't
>> > particularly a priority of mine so I'm not likely to drive it in the
>> > very near future.
>> >
>> > Best regards,
>> >
>> > --
>> > ---------------------------------------+--------------------------------------
>> > I set the clouds in motion - turn up   | Frank Warmerdam, warmerdam at pobox.com
>> > light and sound - activate the windows | http://pobox.com/~warmerdam
>> > and watch the world go round - Rush    | Geospatial Software Developer
>> _______________________________________________
>> gdal-dev mailing list
>> gdal-dev at lists.osgeo.org
>> http://lists.osgeo.org/mailman/listinfo/gdal-dev
>
>