Pixel-Is-Point or Pixel-Is-Area

The GeoTIFF specification includes a data item, GTRasterTypeGeoKey (#1025), which may be set to either RasterPixelIsArea (maybe the default, but not clear in 7.2.1), or RasterPixelIsPoint.

• The GTRasterTypeGeoKey value SHALL be:

  • * 0 to indicate that the Raster type is undefined or unknown; or

  • * 1 to indicate that the Raster type is PixelIsArea; or

  • * 2 to indicate that the Raster type is PixelIsPoint; or

  • * 32767 to indicate that the Raster type is user-defined.

• Recommendation: the use of 0 (undefined) or 32767 (user-defined) is not recommended

 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.

This is a real world issue with Key Global Regional DEMs.  For these, some follow the

• Pixel-is-point standard with DTED, where a 3" data set has 1201x1201points.  The edge columns and rows are shared with the neighboring cells.
• Pixel-is-area standard, where a 3" data set has 1200x1200points and no points are shared with neighboring cells. The point coordinates are the corner of each cell, so the center, where most computations are assigned, has a 1/2 pixel offset in both directions.

In "Arc-speak" these are

• punctual spatial support where the pixel represents the value of elevation at the center of the cell
• spatial support equal to the pixel size where the value of the pixel represents the mean value of the elevation inside the pixel

View of the grid for a 1" geographic grid in Alaska, where the spacing is about 15 m x 30 m.  The black star represents the geographic position of a pixel.

• In the pixel-is-point interpretation on the left, the elevation represents the elevation of a single point.  If the sensor that created the DEM had to sample an area on the ground, that area would be the size of the pixel, and centered on the coordinates of the pixel, giving the green box.
• In the pixel-is-point interpretation on the right, the elevation represents the elevations within the pixel (mean, median, min, or max, for instance).  The convention is that this is the SW corner of the pixel.  If a single point is desired for display or computaions, it should be the center of the pixel, shown with the yellow start.  This is offset from the nominal coordinates by a half pixel in each direction.

A number of programs (e.g. GDAL, GRASS) turn all DEMs into Pixel-Is-Area, transforming all coordinates by a half pixel.

References:

• https://grasswiki.osgeo.org/wiki/GRASS_raster_semantics
• https://github.com/opengeospatial/ogcapi-coverages/issues/92
• https://www.ngdc.noaa.gov/mgg/global/gridregistration.html
• https://github.com/opengeospatial/coverage-implementation-schema/issues/6

• http://srtm.csi.cgiar.org/faq/  has diagram at the bottom of the page
• https://www.usgs.gov/land-resources/eros/topochange/science/srtm-ned-vertical-differencing?qt-science_center_objects=0#qt-science_center_objects how to match SRTM and NED
• https://www.researchgate.net/publication/222420565_The_impact_of_misregistration_on_SRTM_and_DEM_image_differences

Much older references

• https://lists.osgeo.org/pipermail/gdal-dev/2009-April/020520.html  GDAL take, old
• https://trac.osgeo.org/gdal/wiki/rfc33_gtiff_pixelispoint (this is old, and GDAL has apparently been handling correctly for over a decade)

Last revision 5/29/2022