iho-ohi / S-102-Product-Specification

It is opened to develop S-102 Bathymetric Surface Product Specification. The contents of this repository are not offical publication in force, therefore please check the final version on the IHO website.
Other
26 stars 10 forks source link

Grid origin #83

Closed tfilppula closed 1 month ago

tfilppula commented 5 months ago

In S-102PT16 we agreed to create new issues from any pending comments in the pull request #73. The pull request was commented by @avautour as follows:

So, coverages usually have two conventions, pixel-is-point and pixel-is-area. S-102 was based on BAG, which is pixel-is-point, and if I understand this pull request correctly, this is to change S-102 to pixel-is-area.

For pixel-is-point, the origin is usually a corner node (centre of the cell), while for pixel-is-area, the origin is usually the corner of a cell. As far as I can tell, line 771 of this file still states the the origin is at the centre of the cell, is that intentional? In other words, is the plan to use a pixel-is-point convention for the origin, and a pixel-is-area convention for the bounding box, because I would find that very weird.

For instance, see GeoTIFF, that has both conventions: https://docs.ogc.org/is/19-008r4/19-008r4.html#RasterSpace

In other words, these two statements seem to be at odds:

This practice has the effect that gridOriginLongitude and gridOriginLatitude are identical to westBoundLongitude and southBoundLatitude.

The gridOriginLongitude and gridOriginLatitude are the cell center of the cell.

If the bounding box is pixel-is-area (corners of cell), and the origin is pixel-is-point (centre of cell), by definition, gridOriginLongitude would not be the westBoundLongitude, and gridOriginLatitude would not be the southBoundLatitude.

tfilppula commented 5 months ago

As I commented in the S-102PT16, I don't see a problem here:

avautour commented 5 months ago

As I have previously stated, rasters using a pixel-is-area raster usually use the corner of the grid cell for the origin, not the centre. It seems to me like you are only taking part of a raster convention, but keeping other parts of it to the other convention, which I find very confusing.

Geopackage, which is pixel-is-area, uses the corner of the cell: https://www.geopackage.org/spec131/index.html#tiles:

Since GeoPackages use the upper left tile origin convention defined in clause Table Data Values below, the gpkg_tile_matrix_set (min_x, max_y) ordinate is the upper-left corner of tile (0,0) for all zoom levels in a table_name tile pyramid user data table.

A PixelIsArea GeoTIFF uses tie points that are the corner of the cells, which usually serves as the origin.

GDAL (https://gdal.org/tutorials/geotransforms_tut.html), which uses the pixel-is-area convention, uses the corner of the corner cell as the origin: GT(0) x-coordinate of the upper-left corner of the upper-left pixel. 'GT(3) y-coordinate of the upper-left corner of the upper-left pixel.'

This practice has the effect that gridOriginLongitude and gridOriginLatitude are identical to westBoundLongitude and southBoundLatitude.

The gridOriginLongitude and gridOriginLatitude are the cell center of the cell.

How are those two above statements not contradicting each other? If the origin is the centre of the cell, and the bounding box is now defined based on the corners of the cells, wouldn't they not be equal, but rather half a resolution off: gridOriginLongitude = westBoundLongitude + (xRes / 2.0) gridOriginLatitude = southBoundLatitude + (yRes / 2.0)

Am I missing something?

AnnaWall01 commented 1 month ago

This topic has been discussed further between members within the S-102 Project Team. The conclusion is that the original definition will be kept as it is, i.e. grid point based. This aligns with S-100 and the ISO19123 standard. A descriptive image has been added to describe the grid structure. During PT17 it was decided to merge PR#73.