Prefer epsg #90
Prefer epsg #90
Conversation
@letmaik I don't think that there is any mandate that says only one of these resources may be used. I am cautious about using the opengis identifiers for resources that are managed by EPSG. I know that there is not an EPSG resource equivalent to |
|
https://www.epsg-registry.org/export.htm?wkt=urn:ogc:def:crs:EPSG::4979 doesn't look like a long-term / stable URI to me. Just because it resolves to something that may or may not be a more preferred data format (WKT) it is not a reason for making this URI "the" new identifier. Identifiers, especially for things like CRSs are supposed to be stable forever, and it's up to standards bodies to define these, which the OGC has done. An improvement would be to come up with a media type for WKT and allow http://www.opengis.net/def/crs/EPSG/0/27700 to be resolved as WKT when requesting it (aka content negotiation). |
|
The format of the returned payload is not the critical factor here. The aim of this PR is to encourage the use of the EPSG registry as the point of truth for EPSG information, and not the opengis.net resources, which have other problems, with maintenance, versioning and consistency with the EPSG source. I don't think that requesting that opengis.net provide a WKT payload on content negotiation address these concerns. The use of URNs to define CRS references is a long standing aspect of OGC standards. The URN: As I understand it, it remains valid GML to directly use a URN of this form to identify a CRS and to recognise the EPSG authority. EPSG provide direct access to CRS definitions, using this URN pattern, and has a long standing service delivering this. |
|
The URN can be used as identifier alone, and I'm sure the OGC/ISO recommends that for certain standards/formats. For Linked Data it would be nice to use an actual URL instead, which also would be recommended by the OGC/ISO. And http://www.opengis.net/def/crs/EPSG/0/4979 is such. There are two separate issues here:
To answer 1., this has to come from some OGC/ISO document and shouldn't be decided ad-hoc just for CovJSON within this PR. And I don't think "https://www.epsg-registry.org/export.htm?wkt=..." is a recommended identifier prefix. But please correct me if that's the case actually. For 2, this is a nice-to-have but not essential, since if the identifier pattern is known, whether that's the URN pattern urn:ogc:def:crs... or the URI pattern http://www.opengis.net/def/crs/... then it is trivial to extract relevant metadata like the EPSG id and then either use a hard-coded lookup table or query some webservice for further information, and that could be https://www.epsg-registry.org. |
|
Hello @letmaik
I agree that a URL is preferred to identify a CRS within CovJSON There are active discussion about the ongoing problems with OGC repackaging of EPSG resources, the last two CRS domain working group meetings at OGC technical committee meetings have discussed numerous challenges with this provision that are not resolved. not least in this is the embedded version within these identifiers, There are extensive problems with how these resources are being managed to support GML by opengis.net. The authority for EPSG codes is the EPSG and they maintain their registry.
I believe that this is indeed a recommended identifier prefix, and preferable to opengis resources for many applications.
This is a long term stable URI. I have confirmation from the EPSG providers of the long term management of this URI pattern. This URN syntax is standardised in OGC 06-023r1 I have not yet found a document that explicitly provides an OGC recommendation for an identifier prefix. The only functional, in situ prefixes that I have found that provide a resolvable and well managed source from an authority, using the standardised URN, as the epsg-registry prefixes. I think this is a strong support for the use of the EPSG registry resources for CovJSON |
3 years later and the URL is broken :) In fact, the whole domain is changed to epsg.org. |
In the CovJSON specification there are numerous references to http://www.opengis.net/def/ where this OGC resource is being used to reference a EPSG published Coordinate Reference System definition.
The EPSG registry is responsible for publishing the EPSG referenced content, the OGC resource can only ever follow, and is unhelpfully inconsistent at times.
I think that the examples within CovJSON of referencing EPSG codes would be better directly referencing the source of these.
Additionally, the OGC resources publish GML encodings of CRS specifications. Whilst this can be seen as consistent for GML based applications, it is not well matched to a JSON encoding.
The Well Known Text encoding is much better suited to human and JSON clients, I believe.
In this change I propose using the http://epsg-registry.org resources and the WKT exports as identifying URIs for CRSs.
I have not proposed a mandate, this is not a compulsion, and it does not assume that EPSG meets all requirements.
This proposed change does recognise that publishing a CRS definition from the maintainers, not republished by a third party, and in a format more suitable for use directly within the encoding, may represent an improvement.