gdalinfo incorrect AREA_OR_POINT for CDED

[jonny2vests]

gdalinfo incorrectly reports 'Point' instead of 'Area' for Canadian Digital Elevation Data.

The CDED product description attached does not explicitly say one way or the other, but the area convention is implied in the data structure.

​http://www.geobase.ca/doc/specs/pdf/GeoBase_product_specs_CDED1_3_0.pdf

[Jukka Rahkonen]

Hi,

Could you save us some time and tell which chapter or page we should read?

[jonny2vests]

Section 3.3:

Each profile has one point of overlap with the cell above it (to the north) and one with the cell below it (to the south). The first profile of the CDED cell coincides with the last profile of the adjacent CDED cell.

If CDED were point (pixel centre) convention, then this data structure would not be possible.

Also, each tile is 1201x1201, and because each pixel is 0.75 arc seconds, which represents an area of 15 arc minutes, therefore there is an extra sample indicating area (top left of top left pixel) convention.

Jon

[Jukka Rahkonen]

Sketch about CDED profile model

[Jukka Rahkonen]

I think I agree with you. Does the sketch I draw with 4+1 sized tiles look correct?

[Even Rouault]

I believe the behaviour of the driver is correct. It is at least consistant with the DTED and SRTMHGT drivers that also expose GDALMD_AOP_POINT and have 1201x1201 grids with 1 pixel overlap with neighbour tiles. According to ​http://www.gdal.org/gdal_datamodel.html,

"AREA_OR_POINT: May be either "Area" (the default) or "Point". Indicates whether a pixel value should be assumed to represent a sampling over the region of the pixel or a point sample at the center of the pixel. This is not intended to influence interpretation of georeferencing which remains area oriented. "

and in http://trac.osgeo.org/gdal/wiki/rfc33_gtiff_pixelispoint :

"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. "

In our case the georeferencing is correct and the information of a DEM is traditionnally thought as a sampling point.

[jonny2vests]

Replying to jratike80:

I think I agree with you. Does the sketch I draw with 4+1 sized tiles look correct?

Yes. Nice sketch.

[jonny2vests]

Replying to rouault:

Your two references are at odds with one another. The first seems to say that AREA_OR_POINT will have no effect on georeferencing and it's merely a means of describing how the data was sampled. Your second reference (rfc33) refutes that in the paragraph after the one you quoted.

[Even Rouault]

RFC33 is mostly about geotiff support for RasterPixelIsArea vs RasterPixelIsPoint. In GeoTIFF world, this implies a half-pixel shift in georeferencing, that must be corrected when going to GDAL data model where Area vs Point doesn't influence the georeferencing (it follows the Area convention)

[Jukka Rahkonen]

Even believed 10 months ago that driver was behaving right. Trusting him and closing the ticket as invalid.