Hi Even,
I think I have figured out how the GeoLocTransformer works. Dumped out the
backmap and might have some changes.
1) Rounding up to the nearest integer is definitely the issue here.
2) I’m going to try this first – maybe a weighted approach will be
better. For now, if a pixel falls in the middle of square – I’m going to add it
to all of the 4 vertices. Then average all the data that went into a pixel of
the backmap.
3) For the regular grid tests, if this shows improvement (hopefully) – I
can share the implementation and we can possibly discuss about adding a
weighting scheme. I don’t want to increase the runtime too much by adding
complexity.
Piyush
From: Even Rouault <[email protected]>
Date: Thursday, September 28, 2017 at 2:56 AM
To: "[email protected]" <[email protected]>
Cc: "Agram, Piyush S (334D)" <[email protected]>
Subject: Re: [gdal-dev] Geolocation arrays - location interpretation
On jeudi 28 septembre 2017 02:14:53 CEST Agram, Piyush S (334D) wrote:
> Hi,
> I’m trying to track down systematic pixel shift effects observed with
> warping data using geolocation arrays:
> https://trac.osgeo.org/gdal/ticket/6959
>
> Essentially, the same data (image and location) provided as geolocation
> arrays is warped to a different output depending on how the arrays are laid
> out – WESN, WENS, EWSN, EWNS.
Gdalwarp produces least shift in warped data
> when the input arrays themselves are oriented WENS.
> Is there a definitive definition for interpretation of lat,lon,value when
> geolocation arrays – i.e, are the lat/lon representative of pixel center
> (which I think should be the intent)?
That's a good question. I would assume that center of pixel would be what is
expected in the gdalgeoloc code. I don't see anything explicitly said about
that in
https://trac.osgeo.org/gdal/wiki/rfc4_geolocate
During your examination of the code, could you find what was expected ?
I assume you are using geolocation transformer with one of the drivers that
support reporting geolocation arrays ? One possibility would be an
inconsistency in the convention this driver (or the datasource itself) reports
the lon,lat values with what the geolocation transformer expects.
Does GDAL by default assume that the
> geolocation value corresponds to the top/left of the pixel? Could this
> confusion result in the observed systematic shift?
> Alternately, could the input arrays be reoriented to WENS using VRTs instead
> of rewriting large raster files?
X_DATASET and Y_DATASET can point to any valid GDAL dataset, so a VRT should be
possible (and you'll need a VRT to modify the values of X_DATASET and Y_DATASET
;-))
Even
--
Spatialys - Geospatial professional services
http://www.spatialys.com
_______________________________________________
gdal-dev mailing list
[email protected]
https://lists.osgeo.org/mailman/listinfo/gdal-dev
