Etienne the algorithm that finds the target extent is not in the transformer
Brian On Sun, 2012-02-12 at 13:17 -0200, Etienne Tourigny wrote: > Brian, > > I'm not sure I understand your point - I probably don't understand the > algorithm enough. Are both the forward and reverse transformations > necessary in all cases? > > My point is that, if (manually) adding the -te option to gdalwarp is > necessary in most cases, why not (automatically) setting the extents > from the min/max of the geolocation arrays instead of trying to > calculate them? > This could fix when the algorithm fails or generates an extent that is > too large. > > Etienne > > On Sun, Feb 12, 2012 at 12:38 PM, Brian Case <[email protected]> wrote: > > 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
