EPSG code as string

[m-mohr]

This is one of the cases, where it seems the specification doesn't fully match what people expect. Also, implementations and examples did often also encourage the "wrong" way...
EPSG codes currently are provided as integers. We should probably also allow strings in 2.0 as this is what people seem to use quite a lot...

So the schema for it would change to something like:

{
  "title": "EPSG Code",
  "type": [
    "integer",
    "string"
  ],
  "subtype": "epsg-code",
  "oneOf": [
    {
      "type": "string",
      "pattern": "^(epsg|EPSG):\\d{4,}$"
    },
    {
      "type": "integer",
      "minimum": 1000
    }
  ],
  "examples": [
      3857,
      "EPSG:3857"
  ]
}

Thoughts?

[soxofaan]

In general I favor this, as the "EPSG:3857" notation seems to be very common in practical use. It's also more self-documenting than a raw integer 3857.

Counter argument: would users expect other prefixes are also allowed, e.g. something like "WGS:84"?

[LukeWeidenwalker]

For reference, we're using https://pyproj4.github.io/pyproj/stable/api/crs/crs.html#pyproj.crs.CRS.from_user_input to validate CRS fields now, so we're happy with both strings and integers!

[m-mohr]

Thanks. I don't think so as it clearly states EPSG code in the schema, also validation should reject it. If you dig down into other authorities it quickly gets messy...

[m-mohr]

I've tried to do this, but the schemas get very messy. I'm think we should only cater for the string vs. number issue in the clients. It seems like allowing it in the process spec makes it a work item for clients + backends while otherwise it makes it only to a work item in the clients.

In the Web Editor for example it's not an issue at all as it hidden from the user anyway.
The R client also already converts from string to integer if I understand it correctly.
So it's just a work item for the Python client: Open-EO/openeo-python-client#259