Simplification of CRS references/2: allow shorthand notation in addition to URLs

[pebau]

For good reason OGC has established that URLs shall be used. However, manifold users have complained about the complexity of CRS references. To find a combination of derefenceability and user friendliness Coverages.SWG has made an option at the March 2021 TC meeting. This ticket addresses Part 1, predefined CRS shorthands:

Coverages.SWG recommends that the OGC-NA approve optional use of an additional syntax for CRSs in coverages, based on the following well-defined shorthand syntax (cf. GDAL, ArcGIS), based on #92:

{crs1}+{crs2} == http://www.opengis.net/def/crs-compound?1=crs1&2=crs2

Example: EPSG:4326+OGC:AnsiDate == http://www.opengis.net/def/crs-compound ? 1=http://www.opengis.net/def/crs/EPSG/0/4326 & 2=http://www.opengis.net/def/crs/OGC/0/AnsiDate

[rob-metalinkage]

Does this apply to short-hand in human readable documents or some machine readable form? If the latter then its an OGC/NA issue and examples of this in use is required - its not clear what resolver mechanism can be used for this short form if its intended to be machine readable. If human only - is it a OGC NA matter at all? Or a Doc team one?

[chris-little]

Speaking from a position of relative ignorance, I couldn't find any examples of this notation on the GDAL and ArcGIS sites. Perhaps someone could point me to the correct places? If this CRS1+CRS2 notification should be applicable across OGC rather than just the coverage standards, are there any implementation plans beyond the GDAL and ArcGIS examples mentioned? Does WKT2 support the notation?

[RogerLott]

There is an issue here in that Abstract Spec topic 2 defines several subtypes of CRS. One of these is compound. Using the N/A http URI string http://www.opengis.net/def/objectType/authority/version/code and the N/A objectType CRS will return any of these CRS subtypes, including compound. http://www.opengis.net/def/crs/EPSG/0/9518 will return a GML document for a compound CRS (WGS 84 latitude,longitude + EGM2008 height). http://www.opengis.net/def/crs/EPSG/0/9518/wkt will return the description for this compound CRS in WKT.

The objectType "crs-compound" is inconsistent with this use of objectType "crs". Consistency with the subtypes of CRS described in Topic 2 would lead to other subtypes of CRS also having their own objectType registered with N/A: crs-geodetic, crs-projected, crs-vertical, crs-temporal, crs-parametric.

Having "crs-compound" as an anomoly is useful in that it can be used to indicate that the compound CRS is being constructed 'on the fly' from component CRSs when there are registry entries for each of the components but not for the built-up compound CRS. This is a not unusual circumstance, so I support the utility of a mechanism to construct compound CRSs from registered components. It permits the component CRSs coming from different registries.

However Topic 2 includes rules for compound CRSs, designed to ensure that CRS definitions remain unambiguous. Amongst these rules is a requirement that compound CRSs cannot be nested. http://www.opengis.net/def/crs/EPSG/0/9518 + http://www.opengis.net/def/crs/OGC/0/AnsiDate would therefore be non-compliant because EPSG 9518 is already compound. But a concatenation of the components of 9518 would be compliant: http://www.opengis.net/def/crs/EPSG/0/4269 + http://www.opengis.net/def/crs/EPSG/0/5703 + http://www.opengis.net/def/crs/OGC/0/AnsiDate.

I see nothing in this proposal to require adherance to the compound CRS construct requirements of Topic 2. That needs to be addressed.

[RogerLott]

@chris-little, WKT (as in 18-010r8) includes a syntax for compound CRSs. Its definition in BNF is:

For example: COMPOUNDCRS["NAD83 + NAVD88 height", GEOGCRS["NAD83",DATUM["North American Datum 1983",ELLIPSOID["GRS 1980",6378137,298.2572221,LENGTHUNIT["metre",1]]]],CS[ellipsoidal,2],AXIS["Geodetic latitude (Lat)",north],AXIS["Geodetic longitude (Lon)",east],ANGLEUNIT["degree",0.0174532925199433]], VERTCRS["NAVD88 height",VDATUM["North American Vertical Datum 1988"],CS[vertical,1],AXIS["Gravity-related height (H)",up],LENGTHUNIT["metre",1]], ID["EPSG",5498]]

So there is support in WKT for compound CRSs, but not using the specific syntax in this request. WKT uses a comma and matching left/right delimitator counts as a seperator between the component CRSs.

I fully agree that if the proposed notation is to be considered, it should not be explicitly for coverages but for general application across OGC specifications.

I am not aware of the proposed notation for creating http URI strings for compound CRSs from several individual http URI strings of component CRS being supported anywhere other than coverage specifications. I am not sure if any registry services could respond to the concatenated URI string, althoug perhaps the SECORE resolver might do so. But I do wonder if the short-hand syntax proposed ({crs1}+{crs2} == http://www.opengis.net/def/crs-compound?1=crs1&2=crs2) is being built on unsound foundations. However if a definition shorthand as in #92 is agreed, then including the ability to construct compound CRSs from individual components would be sensible, at least for human readers.

[ghobona]

OGC-NA decision on 2021-06-17 to defer Issue 93 until Issue 92 is resolved.

[rob-metalinkage]

The documentation syntax is not an NA concern.

The use of parameterised URLs to access some content is more complex - are these identifiers or queries ? (URIs or URLs).

If the http://www.opengis.net/def URI root is used, then the identifiers fall under the NA governance regime - which implicitly means following ISO 19135 principles for "Item Registration".

An option is to have the root URI http://www.opengis.net/def/crs-compound be a "Concept" that is also a service endpoint for a CRS combination service that can resolve the various parameters that are provided.

This requires a request to the NA to set up a specific URI set of redirection rules for that URI (detecting a parameter pattern and calling the endpoint).

I think this is something we can prototype and send for wider review. IMHO this new behaviour requires a new policy to make sure we dont have many flavours of this, and to establish expectations about the behaviour, management and persistence of the services we will delegate to.

So I would actually think that a policy be drafted, then a bundle of all the resources needed to implement that policy provided. Thats a bit of work - so perhaps it should be canvassed with a wider group before the NA is asked to commit its (currently meagre) resources to support.

[pebau]

wait, this is all blowing up way too far. All that this motion suggests is a shorthand notation because (i) URLs are commonly considered unwieldy and as such hinder adoption and (ii) this notation is in common use already. So we discuss adoption of community practice.

• NO new concepts
• NOT the complete expressive power as URLs have

[dr-shorthair]

@pebau is your proposal essentially that the PREFIX EPSG: be consistently used for http://www.opengis.net/def/crs/EPSG/0/ ?

[pebau]

@dr-shorthair yes, indeed. Likewise for the parallel branches, like AUTO: and OGC: - the latter, with its time CRSs, will become particular important, and then we will want to add height/depth...that will be extremely unwieldy with fully sized URLs. (For those not so familiar: EPSG/0/ is equivalent to "latest version of EPSG", which is what normally is wanted.)

As mentioned earlier, future extension can be discussed (and added or not), this current proposal is a KISS, just to reflect current practice and enhance user experience.

[rob-metalinkage]

KISS for "essentially that the PREFIX EPSG: be consistently used for http://www.opengis.net/def/crs/EPSG/0/" is to use CURIES - no issue with using shorthand notation - but AFAICT this is issue #92.

The use of a syntax in a document to indicated a compound CRS is not a Naming Authority concern.

If compound CRS-s need to be assigned names in the forms of URIs (i.e. registration of the URIs after the syntax expansion) then this issue should be reworded to reflect that specific aspect.

It may be possible to define a "range of names" based on all possible CRS combinations, and use a service to perform the task of delivering the appropriate compound CRS definition. That wouldnt be handled by the Definition Server directly, so such a proposal would need to be backed by the existence of a stable service that performs this task - such names can't supported without additional infrastructure. The redirection to that infrastructure needs to be supported by some layer of the redirection service - in this case we'd need either Apache2 redirect rules or a custom redirection service that be proxied by the apache2 layer.

After determining exactly what the OGC NA role here is, happy to have the technical conversation with whoever is willing to either provide the necessary infrastructure or arrange the resourcing to have it built.

[pebau]

@rob-metalinkage the resolver service exists already for the URLs; the shorthand is not a URL.

We can define that notation specifically for coverages of course, but I though we see whether there is general interest as it is an overarching theme, so we brought it to OGC-NA. But if across our universes nobody else is interested we might pursue this for coverages only.

@ghobona WDYT?

[ghobona]

Let's resolve Issue https://github.com/opengeospatial/NamingAuthority/issues/92 first as was agreed last week during the OGC-NA session of the June 2021 OGC Member Meeting.

[ghobona]

OGC-NA discussed the issue on 2021-09-14 and agreed that:

• The service offered by the http://www.opengis.net/def/crs-compound URI is out of the scope of the OGC-NA's charter since it is not an identifiable or nameable resource. Therefore, the OGC-NA agreed to deprecate it and keep it running for sometime. The deprecated object would be annotated and a solution offered.
• OGC-NA recommended that the Architecture DWG or the Coverages DWG could work with the OGC Infrastructure Office to move the service to a new URI (outside of http://www.opengis.net/def/)

[jerstlouis]

@ghobona I think the second recommendation should be more about defining an alternative to crs-compound to define ad-hoc CRS combinations. (e.g. allowing an array of CRSes for srsName in CIS). GML SWG may need to be involved as well for GMLCOV.

[pebau]

hm, shouldn't we have a new, fully working solution FIRST and THEN start deprecating?

[jerstlouis]

@pebau Agreed, therefore I suggest we start discussing a solution as an agenda item for tomorrow's Coverage SWG (https://github.com/opengeospatial/coverage-implementation-schema/issues/18)

[pebau]

@ghobona I think the second recommendation should be more about defining an alternative to crs-compound to define ad-hoc CRS combinations. (e.g. allowing an array of CRSes for srsName in CIS). GML SWG may need to be involved as well for GMLCOV.

Just remembering that OGC-NA required (!) to have URLs, and the srsName type is anyURL AFAIK. Cannot see the fit here.

As this is a non-compatible change to CRS resolution by OGC -> new major release number? What is OGC-NA's take on the versioning rules of OGC?

[jerstlouis]

@pebau Could we perhaps simply allow multiplicity 1..* for srsName? That could work with GMLCOV, and in CIS JSON the schema would simply allow a oneOf where it can either be a single URI or an array of URIs.

Each of the CRSes being compounded would remain a URI/URL.

[ghobona]

Draft Policy revision sent to OGC-NA for review. This issue is addressed in Clause 6.8

[ghobona]

The revised policy has been published.