Pixel-is-Area vs Pixel-is-Point #2261
Replies: 12 comments 18 replies
-
Have a look at https://grasswiki.osgeo.org/wiki/GRASS_raster_semantics, I think the answer is there in Cell Locations section |
Beta Was this translation helpful? Give feedback.
-
In the slope module (r.slope.aspect) I use a Copernicus DEM as the input. It has the pixel-is-point flag (Geotiff key 1025) correctly sect. GRASS changes the grid to pixel-is-area, but does not set Geotiff key 1025 for the output. Software using the resulting grid is left to guess at the pixel-is-??. GDAL does the same thing (and gets identical results for the slope grid), but other software winds up with a half pixel offset for the slope grids. |
Beta Was this translation helpful? Give feedback.
-
|
Beta Was this translation helpful? Give feedback.
-
extent dem input
extent slope output
|
Beta Was this translation helpful? Give feedback.
-
at least gdalinfo reports the same extent of input DEM tif and output slope tif, |
Beta Was this translation helpful? Give feedback.
-
and now gdalinfo from the provided slope tif
|
Beta Was this translation helpful? Give feedback.
-
|
Beta Was this translation helpful? Give feedback.
-
according to gdalinfo, the GIS relevant tool, the extend is the same for input and output |
Beta Was this translation helpful? Give feedback.
-
gdalinfo gives correctly the same GIS extent for input and outpout; AFAIU tiffinfo gives the raw information of the tiffs. |
Beta Was this translation helpful? Give feedback.
-
Thanks everyone for looking at this. With some tweaks to my code, and assuming that a Geotiff without the key set will be Pixel-is-area, I can now get the two grids to have identical extent. I have only access to the raw information in the tiffs, and would really like to see GDAL code the pixel representation in the output files. |
Beta Was this translation helpful? Give feedback.
-
As far as I know GDAL does set the Pixel-is-area metadata and in GeoTIFF version 1.1 it is mandatory.
|
Beta Was this translation helpful? Give feedback.
-
Thanks. I downloaded a new release of OSGEO4W, which had the same GDAL but a newer GRASS, but it was doing the same thing. I got listgeo, and found that the Geotiff key was in both the new and old output from GRASS/GDAL. It was not being parsed correctly in the two readers I will using; I have fixed mine, and will report the problem to the author of the other. It's another example of the complexity of Geotiff. |
Beta Was this translation helpful? Give feedback.
-
Hi
Just to confirm, which model does GRASS uses? Pixel-is-Area or Pixel-is-Point?
The definitions are in the GeoTiff standard: http://docs.opengeospatial.org/is/19-008r4/19-008r4.html#_pixelisarea_raster_space
"PixelIsArea" Raster Space
The "PixelIsArea" raster grid space R, which is the default, uses coordinates I and J, with (0,0) denoting the upper-left corner of the image, and increasing I to the right, increasing J down. The first pixel-value fills the square grid cell with the bounds:
top-left = (0,0), bottom-right = (1,1)
and so on; by extension this one-by-one grid cell is also referred to as a pixel. An N by M pixel image covers an area with the mathematically defined bounds (0,0), (N,M).
The location of the area pixel is referenced at the upper left of the pixel (pixelCorner convention).
"PixelIsPoint" Raster Space
The PixelIsPoint raster grid space R uses the same coordinate axis names as used in PixelIsArea Raster space, with increasing I to the right, increasing J down. The first pixel-value however, is realized as a point value located at (0,0). An N by M pixel image consists of points which fill the mathematically defined bounds (0,0), (N-1,M-1).
The location of the pixel is referenced at the point pixel (pixelCenter convention).
If a point-pixel image were to be displayed on a display device with pixel cells having the same size as the raster spacing, then the upper-left corner of the displayed image would be located in raster space at (-0.5, -0.5).
Thanks
Beta Was this translation helpful? Give feedback.
All reactions