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 <[email protected]> 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 <[email protected]> > >> wrote: > >> > On Tue, Feb 7, 2012 at 7:40 AM, Etienne Tourigny > >> > <[email protected]> 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, > >> > [email protected] > >> > light and sound - activate the windows | http://pobox.com/~warmerdam > >> > and watch the world go round - Rush | Geospatial Software Developer > >> _______________________________________________ > >> gdal-dev mailing list > >> [email protected] > >> http://lists.osgeo.org/mailman/listinfo/gdal-dev > > > > _______________________________________________ gdal-dev mailing list [email protected] http://lists.osgeo.org/mailman/listinfo/gdal-dev
