listgeo reports incorrect corner coordinates if RasterPixelIsPoint is set about libgeotiff

[rouault]

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

[CaptainCarrot]

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.

[rouault]

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

[CaptainCarrot]

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.