[gdal-dev] Geolocation Arrays ??

[Brian Case]

the forward transform is pretty strait forwards, however the reverse is
not, it creates back-mask (a geo-referenced image that contains the x/y locations
in the source image). the points that the warper tries to transform to
figure out the target extent are no-data in the back-mask.

Brian

On Sun, 2012-02-12 at 12:25 -0200, Etienne Tourigny wrote:
> 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
> >
> >