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.koro...@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<warmer...@pobox.com>
  wrote:

On Tue, Feb 7, 2012 at 7:40 AM, Etienne Tourigny
<etourigny....@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,
warmer...@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@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev

_______________________________________________
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev
_______________________________________________
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev

Reply via email to