I've been trying to wrap my head around this field and the more I look at it, the bigger my headache. The bottomline is that this one field tries to capture two concepts in one attribute (and failing to do either satisfactorily):
- Where are the array elements located?
- What do the array elements represent?
Problems with NCEI and GMT
I understand that the current specification is based on the NOAA NCEI example that is linked to in the spec. For the grid/node option it says this:
Ranges refer to the centers of the cells on the outside border of the grid (Panel A), and the footprints of the cells extend 1/2 cell width outside the range
The two concepts I mentioned above are captured in this one label: "ranges" refer to the coordinate range of the outermost nodes on the grid, and the "cell" represents an area. GMT, another example linked to from the spec and possibly based on the NCEI example or the other way around, uses basically the same approach but using different terminology and adding the rather cumbersome construction of gridline registration requiring an extra element along each dimension (i.e. a shape of [3, 3] requires 4 elements along each dimension to properly describe it).
A grid-registered grid has one more row and one more column than a cell-registered version with an identical range.
Yes but so what? They have different bounding boxes, assuming that the bounding box is the outermost edge of the area represented by the data (as GDAL does it, for example). The example in the NCEI page that then follows basically says: "If you are ignorant and have no idea what you are doing with your DEM, then you may end up messing up your data." It has nothing whatsoever to do with coordinate space and data registration. Unfortunately, I see that general argument coming back in this convention under "Important considerations".
Both NCEI and GMT are fundamentally wrong and at odds with some other concepts in their own environment but also in the spatial: convention. For starters, "node" in this convention as based on NCEI is not equivalent to GeoTIFF's PixelIsPoint. NCEI and GMT do not recognize the different treatments necessary for point and area data, something which other tools do consider, such as GeoTIFF and GDAL with its AREA_OR_POINT metadata tag. The GMT -R option for the data domain is inconsistent with the general notion of a bounding box and the "spatial:bbox" field here. And lastly, there is a real risk of having inconsistencies with the "spatial:transform" field.
A proposal
I would propose to add a field that indicates the nature of each data element (what do they represent?). The GeoTIFF RasterType is inadequate because the term "raster" is not widely used in Zarr and "type" conveys no meaning. GDAL's GRID_CELL_ENCODING is similarly inadequate. I propose element, taken from the Zarr core spec, but any suggestions are welcome. The field "spatial:element" can take one of the values "point" and "area" (like GeoTIFF and GDAL). If a default value is to be defined, I would suggest "area" as most satellite imagery and general raster data fits that description.
The "spatial:registration" field should only refer to how coordinates map to elements. Allowable values would be "center" and "corner" (following the GDAL terminology in GRID_CELL_ENCODING). This field is required only if "spatial:element": "area" because in the "point" case the registration is always on exactly the point location.
The "spatial:bbox" field refers to the locations of the first and last element along each dimension in the "point" case and it is extended outwards by half a cell size in the "area" case.
I've been trying to wrap my head around this field and the more I look at it, the bigger my headache. The bottomline is that this one field tries to capture two concepts in one attribute (and failing to do either satisfactorily):
Problems with NCEI and GMT
I understand that the current specification is based on the NOAA NCEI example that is linked to in the spec. For the grid/node option it says this:
The two concepts I mentioned above are captured in this one label: "ranges" refer to the coordinate range of the outermost nodes on the grid, and the "cell" represents an area. GMT, another example linked to from the spec and possibly based on the NCEI example or the other way around, uses basically the same approach but using different terminology and adding the rather cumbersome construction of gridline registration requiring an extra element along each dimension (i.e. a shape of
[3, 3]requires 4 elements along each dimension to properly describe it).Yes but so what? They have different bounding boxes, assuming that the bounding box is the outermost edge of the area represented by the data (as GDAL does it, for example). The example in the NCEI page that then follows basically says: "If you are ignorant and have no idea what you are doing with your DEM, then you may end up messing up your data." It has nothing whatsoever to do with coordinate space and data registration. Unfortunately, I see that general argument coming back in this convention under "Important considerations".
Both NCEI and GMT are fundamentally wrong and at odds with some other concepts in their own environment but also in the
spatial:convention. For starters,"node"in this convention as based on NCEI is not equivalent to GeoTIFF'sPixelIsPoint. NCEI and GMT do not recognize the different treatments necessary for point and area data, something which other tools do consider, such as GeoTIFF and GDAL with itsAREA_OR_POINTmetadata tag. The GMT -R option for the data domain is inconsistent with the general notion of a bounding box and the"spatial:bbox"field here. And lastly, there is a real risk of having inconsistencies with the"spatial:transform"field.A proposal
I would propose to add a field that indicates the nature of each data element (what do they represent?). The GeoTIFF
RasterTypeis inadequate because the term "raster" is not widely used in Zarr and "type" conveys no meaning. GDAL'sGRID_CELL_ENCODINGis similarly inadequate. I proposeelement, taken from the Zarr core spec, but any suggestions are welcome. The field"spatial:element"can take one of the values"point"and"area"(like GeoTIFF and GDAL). If a default value is to be defined, I would suggest "area" as most satellite imagery and general raster data fits that description.The
"spatial:registration"field should only refer to how coordinates map to elements. Allowable values would be"center"and"corner"(following the GDAL terminology inGRID_CELL_ENCODING). This field is required only if"spatial:element": "area"because in the "point" case the registration is always on exactly the point location.The
"spatial:bbox"field refers to the locations of the first and last element along each dimension in the "point" case and it is extended outwards by half a cell size in the "area" case.