Closed CaptainCarrot closed 4 years ago
I'm not keen in changing listgeo behaviour. libgeotiff is a low level library, and it is good to see which raw numbers are actually written in the file. GDAL is higher level and thus abstracts (the 'A' in GDAL) those details and use a pixel-corner convention in all cases
The corner coordinates are not read from the file, they're computed from the coordinate system and the image extent. As they're currently wrong for PixelIsPoint and the corner coordinates are more of a guide anyways, I can't see any harm coming from fixing it for this case.
From a quick look into the source code, I figure this should be doable with minimal intrusion. Once I have figured out how to properly set it properly in a local environment, I'll happily open a Pull Request if you don't mind.
ah sorry, you were talking about the "Corner coordinates" section, not the raw tie points. Yes, could make sense to adjust like GDAL does. PR welcome
The issue is resolved, and I have seen that you made the GTIFGetKeySHORT/DOUBLE/ASCII functionality available in geotiff.h. There is nothing left to do here for me, so let me thank you for your assitance and close the issue.
listgeo currently treats all GeoTIFFs as if the RasterPixelIsArea is set, leading to incorrectly reported corner coordinates if RasterPixelIsPoint is set instead. It should report them as specified here.
Example:
I created a rasterized sample data in WGS 84, where the coordinates pixel center of the top left corner are exactly (-81.38, -0.04) and the ones of the bottom right pixel center are (-68.65, -18.45). listgeo reports the following:
The reported upper left coordinate is exactly the model tie point, and all the other corners are offset by one pixel.
For comparison, here the corners reported by gdalinfo:
Notes