[Schema] Update `.coordinate_system` to recommend either EPSG or ESRI codes

[odscjen]

One of the draft examples takes the coodinate system from https://ghsl.jrc.ec.europa.eu/download.php?ds=bu which only appears to offer data in a coordinate system that is defined in ESRI but not EPSG (something the source itself appears to have wrong). Should we simply update the description of Resource.coordinate_system from "The reference co-ordinate system of this resource, using the EPSG codelist." to "The reference co-ordinate system of this resource, using the EPSG or ESRI codes."

I'm not particularly fond of this solution as having a single code source is best but when even the EC's Joint Research Centre are getting confused between EPSG and ESRI maybe we need to include the possibility of both?

[matamadio]

I had no idea that Mollweide was an ESRI specific either... it is one of the most used projection for global data, thus we should definitely allow both EPSG and ESRI.

[odscjen]

https://epsg.io/ seems to include both EPSG and ESRI codes as a recommended source for codes. We should probably specify how to structure the codes to make it clear if it's EPSG or ESRI, i.e. so it look like "ESRI: 54009" rather than just "54009".

So update to:

"The reference co-ordinate system of this resource, using the EPSG or ESRI codes from https://epsg.io/. Provide both the scheme and the code, e.g. EPSG:4326"

[duncandewhurst]

Seems like there are other CRS identifier authorities besides EPSG and ERSI, e.g. OGC and IGNF, and some CRSs which are not registered with any authority, e.g. ZANGI:HBKNO15.

Other standards (e.g. PROJJSON, which is based on WKT's Identifier definition) model CRS identifiers as at least two separate fields: one for the authority and one for the identifier.

I suggest that we do the same here, e.g.

{
  "coordinate_reference_system": {
    "authority": "ERSI",
    "id": "54009"
}

We can then have an open crs_authority codelist with codes for at least EPSG, ERSI, OGC and IGNF.

[matamadio]

Imho this is going too deep into particular cases. I would stick to EPSG and ESRI standards from https://epsg.io This is coherent with data preparation guidelines where we are suggesting to convert rarely-used CRS to commonly-used CRS.

I'd stick to one field attribute with both authority and ID (e.g. "EPSG:4326"; "ESRI:54009"). Open crs codelist.

[stufraser1]

I'd stick to one field attribute with both authority and ID (e.g. "EPSG:4326"; "ESRI:54009").

Agreed with this to be explicit. It's usual to include the scheme and code separated by colon in say QGS lookups for selecting spatial references. Then we also don't need a crs codelist as it is in the field.

[duncandewhurst]

Using a single field gives a bit less flexibility for validation. There are a few options:

1. Only validate the type of the field, i.e. any string value will pass validation
2. Use a regex to require that the string begins with either 'EPSG:' or 'ERSI:', i.e. disallow any other authorities
3. Use a regex to require that the string begins with any four capital letter characters followed by a colon, i.e. allow any four-letter authority code

If we choose either of the regex options, it will need to be explained in the field description.

[stufraser1]

Prefer 2. Use a regex to require that the string begins with either 'EPSG:' or 'ESRI:', i.e. disallow any other authorities But if it is best to have them in separate fields then let's do that.

[matamadio]

Agree on 2. Please note it is "ESRI".