Consider use of PROJJSON for unenumerated CRSs?

[hobu]

PROJJSON is a faithful, if verbose, encoding of OGC WKTv2 in JSON by @rouault. It has a few things going for it that make it an interesting candidate for CRS definition description in OGC API:

• A JSON schema https://proj.org/schemas/v0.2/projjson.schema.json
• Same entity names as WKTv2
• Open source software that reads/writes/transforms it to WKTv2 using proj.org

I wrote a simple AWS Lambda endpoint that can be manipulated to return PROJJSON of enumerated CRSs. For example, this returns WGS84 geocentric + EGM2008 (everything in the definition node is PROJJSON, the other nodes are my bookkeeping):

https://henzuru.io/v1/crs/EPSG/4978+3855 <-- PROJJSON
https://henzuru.io/v1/crs/EPSG/4978+3855/WKT <-- WKTv2

Here's a couple of other examples:

https://henzuru.io/v1/crs/EPSG/4326 <-- The mother CRS
https://henzuru.io/v1/crs/ESRI/54028 <-- Cassini using ESRI code

I haven't been tracking the OGC API CRS efforts close enough to know about their expected intent, but as a downstream application consumer of the data, as currently specified, they still require me to dereference the definition from somewhere other than directly in my application. This can still work ok for well known enumerated CRSs, but for anything sufficiently interesting, we're kind of stuck slinging escaped WKT (of various flavors) around.

@cholmes said I should file a ticket asking about this, so the topic being brought up is his fault 😛

[cportele]

Many thanks, @hobu (and @cholmes).

The current scope for Part 2 is "Coordinate Reference Systems by Reference" (the bolding is mine). That is, we have kept full descriptions of CRSs out-of-scope (as most developers wouldn't know what to do with them anyhow) and just support CRS identifiers (URIs) - with the recommendation to use the OGC URIs.

There is no expectation in Part 2 that clients will dereference the URIs and parse a CRS description. As a result there is currently no discussion in the draft about dereferencing or formats. APIs can only express support for an enumerated list of CRSs. This is a conscious decision, but as the title of Part 2 implies, if there is enough demand for supporting full CRS descriptions, another extension could be developed. In that case, WKT2 as an OGC standard would probably be a supported format, but PROJJSON is indeed interesting in an API context, too.

[cholmes]

Cool, makes sense to limit scope initially. It does seem useful to have online JSON representations of the actual CRS information, but agree that it'd be good to see the desire in the market. And it doesn't feel like it'd be hard to integrate Howard's lambda endpoint with Features API, so hopefully we get some implementations and can standardize from there.

In STAC we are including PROJJSON as an option in the projection extension. This is for content, so items could choose to include a projjson if they want.

[jerstlouis]

We are also suggesting the use of PROJJSON in Coverages as well, and I hope the CRS SWG could standardize the PROJJSON encoding as an OGC standard for use in any JSON context where a full CRS definition is needed.