Should PROJJSON be used rather than "text" WKT2 for CRS while awaiting an official JSON encoding from CRS SWG?

[jerstlouis]

In 2DTMS we have taken this approach and include the PROJJSON schema with a note that in the future this may be changed to whichever JSON encoding OGC comes up with per the CRS SWG work item on this topic.

See note in https://docs.opengeospatial.org/DRAFTS/17-083r4.html#tms-json-encoding :

NOTE: This Standard adopts the https://proj.org/specifications/projjson.html encoding, pending a resolution in the CRS group for adopting a possible future JSON encoding for WKT for CRS 2.0

Having part of the content all encoded in a (text WKT2) string makes it more difficult to parse the data and cannot be defined / validated with the overall schema, and would look odd and be difficult to use by people not familiar with WKT2.

[chris-little]

@jerstlouis Above, I corrected a link which was returning 404 because of spurious non-blank whitespace.

As PROJJSON claims (strict?) adherence to WKT2, it is more interesting than I thought!

How does having JSON objects instead of strings ameliorate the problem of people not familiar with WKT?

[jerstlouis]

As PROJJSON claims (strict?) adherence to WKT2, it is more interesting than I thought!

It does as per https://proj.org/specifications/projjson.html :

PROJJSON is a JSON encoding of WKT2:2019 / ISO-19162:2019, which itself implements the model of OGC Topic 2: Referencing by coordinates. Apart from the difference of encodings, the semantics is intended to be exactly the same as WKT2:2019.

However I think the CRS SWG found otherwise, but at least the intent is there, which is why we took that approach in 2DTMS.

How does having JSON objects instead of strings ameliorate the problem of people not familiar with WKT?

@chris-little Well the JSON Schema would embed or link to the PROJJSON schema (which can include description etc.), so developers would not require any special parsing and could easily access the individual pieces of it, as opposed to a big string with no idea how to parse it or what it means (and most would not try to dig up the WKT2CRS specification and try to read it to understand a small part of it that they care about).

[chris-little]

As the CRS specification in Candidate Standard is rather loose, it is probably a non-breaking , backward compatible change. I propose we slate it for V1.1 unitl the CRS SWG and others have clarified the truth of the statement PROJJSON is a JSON encoding of WKT2:2019 / ISO-19162:2019

[chris-little]

This has been discussed before, with a wider context, on the original CovJSON repo at covjson/specification#88

[chris-little]

@jonblower @letmaik @jerstlouis The OGC CRS SWG meeting on 16 Jun 2022 agreed to develop a full OGC standard to represent CRSs in JSON - CRSJSON. It will be based on the PROJJSON proposal from Even Roualt and be compatible with OGC CRS WKT2.

Also, CRS WKT1 will be deprecated, though not deleted!

So we can leave the tag V1.1 on this issue.

[chris-little]

At CoverageJSON Task Team 2022-07-27, agreed to tag V1.2, because of timescales, and to not delay other developments.