search

OSGeo / libgeotiff

Official repository of the libgeotiff project
180 stars 69 forks source link

listgeo reports incorrect corner coordinates if RasterPixelIsPoint is set #35

Closed CaptainCarrot closed 4 years ago

CaptainCarrot commented 4 years ago

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:

Geotiff_Information:
   Version: 1
   Key_Revision: 1.0
   Tagged_Information:
      ModelTiepointTag (2,3):
         0                 0                 0                
         -81.38            -0.04             0                
      ModelPixelScaleTag (1,3):
         0.0212520868113522 0.0307345575959933 0                
      End_Of_Tags.
   Keyed_Information:
      GTModelTypeGeoKey (Short,1): ModelTypeGeographic
      GTRasterTypeGeoKey (Short,1): RasterPixelIsPoint
      GeographicTypeGeoKey (Short,1): GCS_WGS_84
      GeogAngularUnitsGeoKey (Short,1): Angular_Degree
      End_Of_Keys.
   End_Of_Geotiff.

GCS: 4326/WGS 84
Datum: 6326/World Geodetic System 1984
Ellipsoid: 7030/WGS 84 (6378137.00,6356752.31)
Prime Meridian: 8901/Greenwich (0.000000/  0d 0' 0.00"E)
Projection Linear Units: User-Defined (1.000000m)

Corner Coordinates:
Upper Left    (-81.3800000,-0.0400000)
Lower Left    (-81.3800000,-18.4807346)
Upper Right   (-68.6287479,-0.0400000)
Lower Right   (-68.6287479,-18.4807346)
Center        (-75.0043740,-9.2603673)

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:

Corner Coordinates:
Upper Left  ( -81.3906260,  -0.0246327)
Lower Left  ( -81.3906260, -18.4653673)
Upper Right ( -68.6393740,  -0.0246327)
Lower Right ( -68.6393740, -18.4653673)
Center      ( -75.0150000,  -9.2450000)

Notes

rouault commented 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

CaptainCarrot commented 4 years ago

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 commented 4 years ago

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 commented 4 years ago

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.