[gdal-dev] Geolocation Arrays ??
Etienne Tourigny
etourigny.dev at gmail.com
Sun Feb 12 10:17:37 EST 2012
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 <rush at winkey.org> 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 <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
>> >
>> >
>
>
More information about the gdal-dev
mailing list