[gdal-dev] Geolocation Arrays ??

Wed Feb 8 08:19:05 EST 2012

Hi Etienne!

probably yes. At least that's what I got from an answer from Brian some 
time ago:

 > > EOS_SWATH has 2 geolocation arrays, you might try the -geoloc switch to
 >  > gdalwarp, otherwise it creates a handfull of gcps from the arrays, if
 >  > you get a error about points failing to transform, set the output 
extent
 >  > with the -te switch.
 >  >
 >  > also you could try the swath2grid application in
 >  > https://lpdaac.usgs.gov/tools/modis_reprojection_tool_swath
 >  >
 >  > Brian

Anton

On 02/08/2012 02:13 PM, Etienne Tourigny wrote:
> Thanks Anton,
>
> The latitudes of this dataset span from 26.77687 to 33.82318 , so
> nowhere near the poles!
>
> I tried your suggestion, using the extents from the hdf metadata:
>
> 		:Northernmost\ Latitude = 33.82318f ;
> 		:Southernmost\ Latitude = 26.77687f ;
> 		:Easternmost\ Longitude = -79.69389f ;
> 		:Westernmost\ Longitude = -90.15974f ;
>
>
> $ gdalwarp -geoloc -t_srs EPSG:4326 -te -90.15974 26.77687 -79.69389
> 33.82318f  --debug off
> HDF4_SDS:UNKNOWN:"A2006005182000.L2_LAC_SST.x.hdf":13 tmp1.tif
>
> And casual inspection shows that the value is correctly reprojected
> (the outlines of Florida are consistent).
>
> ==>  Does this mean that gdalwarp -geoloc should always be used with -te option?
>
> Etienne
>
> On Wed, Feb 8, 2012 at 6:21 AM, Anton Korosov<anton.korosov at nersc.no>  wrote:
>> Hello Etienne!
>>
>> I also got such error when trying to process MODIS L1B images taken near the
>> pole. Try to set some limited extent with the -te option for gdalwarp. It
>> helped me, at least.
>>
>> Best regards!
>> Anton
>>
>>
>> On 02/07/2012 10:22 PM, 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
>>
>> _______________________________________________
>> gdal-dev mailing list
>> gdal-dev at lists.osgeo.org
>> http://lists.osgeo.org/mailman/listinfo/gdal-dev