CRS Definitions in CovJSON

[marqh]

Summary:

• Prefer WKT to GML for CRSs
• Prefer http://epsg-registry.org to http://www.opengis.net/def/
• Prefer epsg #90
• Drop JSON like representation of WKT
• use text string for WKT-CRS #89
• Adopt WKT for Temporal CRSs
• clarify coordinates definitions to mandate matching to the CRS definition

Description:
There have been developments in the Coordinate Reference System definition domain that it would be beneficial to adopt within CovJSON

I would like to discuss some broad principles within this topic on this Issue, and then spawn PRs as appropriate to address particular issues.

It is worthy of note that ISO19111 has been revised, and is awaiting publishing by ISO and OGC.
This used to be titled
Spatial Referencing by Coordinates
but is now retitled
Referencing by Coordinates

The scope increase includes dynamic datum definitions, parametric coordinate reference systems (previously 19111-2) and temporal coordinate reference systems.

ISO19162, Well Known Text encodings for Coordinate reference systems, is also being updated and is at a comment and review stage as of late 2018.
The previous version is available from the OGC from
http://www.opengeospatial.org/standards/wkt-crs

The adoption of WKT-CRS as the preferred encoding for ISO19111 concepts is making its way into standards bodies and software implementations.

I think that there are changes to CovJSON that are non-destructive and which will better align it with spatio-temporal referencing capabilities and standardisation.

i will use this ticket as a focal point for proposed adaptions.

@jonblower please may I have a new label for this and associated tickets regarding CRS definitions?

many thanks
marqh

[jonblower]

Hi @marqh, many thanks for this. I've created a label for CRS issues. Just a question about "Drop JSON like representations of WKT" - are you suggesting that we should use WKT strings as-is in CovJSON documents (as string values), in preference to crafting a JSON encoding of the WKT information?

[marqh]

Hi @jonblower

Just a question about "Drop JSON like representations of WKT" - are you suggesting that we should use WKT strings as-is in CovJSON documents (as string values), in preference to crafting a JSON encoding of the WKT information?

I think that that is the first stage, yes.

I have spawned an issue on this, to aid further discussion on the appropriate path to take #89

[letmaik]

@marqh Regarding "Prefer http://epsg-registry.org to http://www.opengis.net/def/", is the former now the URI for CRSs? Where does it say so? Also, does the former include an equivalent for http://www.opengis.net/def/crs/OGC/1.3/CRS84 (lon-lat axis order)?

In general, it would be good to add direct links to the referenced standards/revisions, without having to register or pay. Can you add them? If that's not possible yet, then it's hard to comment on this topic and maybe it should be deferred to when the final version from OGC (since ISO won't be free) is published.

[marqh]

hello @letmaik

I have added a public domain link to the OGC WKT-CRS document management page, which is also ISO19162.
http://www.opengeospatial.org/standards/wkt-crs

I'll add more links as documents make it out of editing and into the public domain.

Much, if not all of this is available to OGC members via their document portal.

regarding

"Prefer http://epsg-registry.org to http://www.opengis.net/def/", is the former now the URI for CRSs? Where does it say so?

This is not a singular thing. I don't aim to propose that one and only one source of CRS URIs shall be used.

I have created a PR to develop this topic some more #90

[jonblower]

Revisiting this, it has been suggested to use PROJJSON for inline encoding of CRSs. This would need some analysis (it is not an OGC-approved spec and I have been told it doesn't fully implement WKT2) but may be a better alternative than the somewhat ad-hoc approach we currently have in the CovJSON spec.

This does not of course address the separate question of which URI scheme we should use for CRS ids.