Changes between Version 3 and Version 4 of rfc33_gtiff_pixelispoint
- Timestamp:
- Nov 15, 2010, 5:36:50 PM (13 years ago)
Legend:
- Unmodified
- Added
- Removed
- Modified
-
rfc33_gtiff_pixelispoint
v3 v4 11 11 == Rationale == 12 12 13 The GeoTIFF specification includes a data item, GTRasterTypeGeoKey, which may be set to either !RasterPixelIsArea (the default), or !RasterPixelIsPoint. !RasterPixelIsArea defines that a pixel represents an area in the real world, while !RasterPixelIs Areadefines a pixel to represent a point in the real world. Often this is useful to distinguish the behavior of optical sensors that average light values over an area vs. raster data which is point oriented like an elevation sample at a point.13 The GeoTIFF specification includes a data item, GTRasterTypeGeoKey, which may be set to either !RasterPixelIsArea (the default), or !RasterPixelIsPoint. !RasterPixelIsArea defines that a pixel represents an area in the real world, while !RasterPixelIsPoint defines a pixel to represent a point in the real world. Often this is useful to distinguish the behavior of optical sensors that average light values over an area vs. raster data which is point oriented like an elevation sample at a point. 14 14 15 15 Traditionally GDAL has treated this flag as having no relevance to the georeferencing of the image despite disputes from a variety of other software developers and data producers. This was based on the authors interpretation of something said once by the GeoTIFF author. However, a recent review of section [[http://www.remotesensing.org/geotiff/spec/geotiff2.5.html#2.5.2.2 section 2.5.2.2]] of the GeoTIFF specificaiton has made it clear that GDAL behavior is incorrect and that !PixelIsPoint georeferencing needs to be offset by a half a pixel when transformed to the GDAL georeferencing model. This issue is documented in the following tickets including #3837, #3838, .... … … 17 17 This RFC attempts to manage this transition with a minimum of disruption for the users of GDAL/OGR. 18 18 19 == Planned Changes == 20 21 Interpretation of the raster space from the GeoTIFF tie points will be offset by half a pixel in the !PixelIsPoint case in gdal/frmts/gtiff/geotiff.cpp. This will impact the formation of the geotransform and the formation of GCPs when there are multiple tie points. geotransmatrix conversion to geotransform will also be affected. 22 23 Conversely if writing files with !PixelIsPoint (as driven by the "AREA_OR_PIXEL" metadata item being set to "POINT") the written raster space coordinates would be offset by half a pixel. 24 25 In trunk the above behavior may be disabled by setting the GTIFF_POINT_GEO_IGNORE configuration option to TRUE (it will default to FALSE). 26 27 In GDAL 1.7 and 1.6 branch the same changes will be applied, except the GTIFF_POINT_GEO_IGNORE configuration option will default to FALSE. 28 29 == Compatibility Issues == 30 31 This change will alter the apparent georeferencing of all GeoTIFF files with !PixelIsPoint set. It is not clear how large a proportion of GeoTIFF files this will apply to, but it is significant. This isn't too bad for files coming from non-GDAL sources as most other produces have made the correct interpretation of !PixelIsPoint for years. However, unfortunately, files produced in the past by GDAL with !PixelIsPoint will now be interpreted differently and the values will be off by half a pixel. 32 33 In practice it was not particularly convenient or well documented how to produce !PixelIsPoint GeoTIFF files with GDAL, so these files should be fairly rare. Thee easiest way to produce them was by copying from another !PixelIsPoint GeoTIFF file in which the error on write just undid the error when reading the source GeoTIFF file. 34 35 == Reporting Extents == 36 37 Folks have at various points in the past requested that we report the extents differently for files with an AREA_OR_PIXEL value of PIXEL, must as listgeo does for GeoTIFF files that have a !PixelIsPoint interpretation. I do *not* plan to do this, and for the purpose of GDAL the GCPs, RPCs and !GeoTransform will always be based on an area interpretation of pixels. The AREA_OR_PIXEL will *only* be used to control setting of the !PixelIsPoint value in GeoTIFF files, and as metadata about the physical interpretation of pixels. 38 19 39 == Test Suite == 40 41 The 1.6 and 1.7 branch test suites will not be altered. 42 43 The trunk branch test suite will be altered to check for the updated values and will be extended with a test to confirm that setting the config option GTIFF_POINT_GEO_IGNORE to TRUE suppresses the altered behavior. 44 20 45 == Documentation == 46 47 The situation will be noted in the 1.8.0, 1.7.4 and 1.6.4 release notes as well as in the GeoTIFF driver documentation in trunk. 48 49 The GeoTIFF web site GeoTIFF FAQ will be updated to clarify the interpretation of !PixelIsPoint and note that up to GDAL 1.8 it was improperly interpreted by GDAL. 50 21 51 == Implementation == 22 52 53 All code implementation will be by Frank Warmerdam in the next few weeks.
