[gdal-dev] Geolocation arrays - location interpretation

[Agram, Piyush S (334D)]

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 <even.rouault at spatialys.com>
Date: Thursday, September 28, 2017 at 2:56 AM
To: "gdal-dev at lists.osgeo.org" <gdal-dev at lists.osgeo.org>
Cc: "Agram, Piyush S (334D)" <Piyush.Agram at jpl.nasa.gov>
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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/gdal-dev/attachments/20170928/e569f5da/attachment-0001.html>