search

ceos-org / ceos-ard

Repository for CEOS Analysis Ready Data (CEOS-ARD), including Product Family Specifications (PFSs)
9 stars 1 forks source link

EPSG codes #14

Open mattsymbios opened 6 months ago

mattsymbios commented 6 months ago

Projections/Coordinate systems in the various metadata products - is it possible to ensure the EPSG code(s) is included (this stops any confusion about the Projection/Coordinate system being used, especially UTM ones)

Suggestion: Consider in next major revisions of PFS. Should include consideration of further increasing consistency between SR 1.6 and SAR 1.7.11 for example.

Proposed by Peter Harrison.

strobpr commented 6 months ago

just a word of warning: not all projections have an EPSG code. EPSG reserves the right to grant or not respective codes to projections proposed by applicants. In case of EQUI7 for exampe it took almost 10 years before the respective codes were assigned.

It might however make sense to use at least a standard format such as WKT

m-mohr commented 6 months ago

It can't be just the EPSG code, there must be an alternative option such as WKT2 or PROJJSON. Having an EPSG code in addition would be nice though.

akerosenqvist commented 6 months ago

Example from the SAR PSF:
1.7.11 Product Coordinate Reference System The metadata lists the map projection (or geographical coordinates, if applicable) that was used and any relevant parameters required to geolocate data in that map projection, expressed in a standardised format (e.g., WKT). Indicate EPSG code, if defined for the CRS.

strobpr commented 6 months ago

The issue with WKT(2), PROJJSON, and many other forms of CRS (projected and not) encodings is that they sometimes at least partly build on EPSG for Ellipsoid, Datum, Projection, and related identifiers, but in addition allow manual encoding of parameters like major and semi-major axis, CRS orientation, projection type, offsets, etc. In theory (and sometimes also in practice) these declarations can be inconsistent and the CRS interpreted from them might depend on what is given preference (manual settings or EPSG codes). In essence: Is it still ARD if a user needs to worry about such detail? And these are just the CRSs, we haven't yet disussed the grids with issues such as types (point vs. area), reference points (corner vs. center), offsets, gridspacings (regular and irregular on each axis) etc. How much variety in grids can be regarded still 'ARD'? Considering the massive implications that resampling might have (e.g. between 'LatLon' and 'UTM' at higher latitudes) I'd rather go with the motto: "Choice is the enemy of interoperability!"

sjskhalsa commented 6 months ago

Agree. For a concrete example, NSIDC maintains a table of "Grid mapping variables" we encounter in netCDF file. The table includes columns noting the "synonyms" for CF, OGC, and proj4 parameter terms which may show up. We tell users it's ok if the grid mapping variable comprises a mix of terms from CF and OGC WKT as long as it contains all of the parameters necessary and the values they define are correct for the EPSG code: https://docs.google.com/spreadsheets/d/1HAQqyvEX3Rs7M0ZwfvhkTr9GZ14Yfbvhf_C8ndAzOqo/edit#gid=0 (assuming it's not password protected. I can export if it is and someone wants to see it)