[pdal] writers.gdal off by half a pixel?

[Jim Klassen]

On 3/19/19 11:38 AM, Howard Butler wrote:
>
>> On Mar 19, 2019, at 11:27 AM, Jim Klassen <klassen.js at gmail.com> wrote:
>>
>> I noticed when round tripping a DEM through readers.gdal to LAS (or CSV) and then back to writers.gdal that the output was shifted from the input by about half a pixel.
>>
>> I created a small 10x10 pixel test DEM and a simple pipelines to convert it to CSV via writers.text.  The X,Y coordinates in the CSV file match the center of the pixels of the source DEM as shown by QGIS, so I suspect that readers.gdal is correct.  I have another pipeline that is a readers.gdal into writers.gdal and QGIS shows the output DEM is shifted.
>>
>> I would be happy to share the 10x10 DEM and the pipelines if there is an appropriate place for them.
>>
>> I have attempted at a patch to writers.gdal that appears to fix this shift.
>>
>> https://github.com/klassenjs/PDAL/commit/c80963e938853ebd63aebe4e8a6ce7e1d5d53cbf
>>
>> I'm not sure I went about it the right way (vs redefining what m_offset means), but making the changes this way seemed like the least invasive way to make the code behave in a self consistent fashion.
>
> Jim,
>
> Are you sure it is the writer? Could it perhaps be the reader doing a pixel-is-area vs. pixel-is-point thing incorrectly?
>
> Howard

My evidence for readers.gdal being correct:

gdalinfo shows AREA_OR_POINT=AREA.  I'm not sure that PDAL takes this into account, but "area" seems to be the default.  The writers.gdal output also sets AREA_OR_POINT=AREA.  It might be that the writer should be setting AREA_OR_POINT=POINT, but personally I prefer to be able to round trip the DEMs losslessly.

Running readers.gdal -> writers.csv matches the coordinates output by gdal2xyz.py.

The values in the CSV match the center of the pixel coordinate as shown in QGIS (as I would expect for AREA_OR_POINT=AREA).