search

opengeospatial / NamingAuthority

Primary repo for the OGC Naming Authority
6 stars 12 forks source link

Added clause on Shortened Names of CRS's #119

Closed ghobona closed 2 years ago

ghobona commented 3 years ago

Addresses https://github.com/opengeospatial/NamingAuthority/issues/92

RogerLott commented 3 years ago

When a shortened form of an identifier is used, the following shall apply:

[loweralpha] . The version segment of the URI is assumed to be equal to 0 . The definition-type segment shall be assumed to be equal to crs.

I suggest this should be: When a shortened form of an identifier is used, the following shall apply:

[loweralpha] . The version segment of the URI is assumed to be equal to 0 . The object-type segment shall be assumed to be equal to crs. . The definition segment shall be assumed to be equal to def.

ghobona commented 3 years ago

Thanks @RogerLott. I have just updated the list, adding the text about the def segment.

The Commit is https://github.com/opengeospatial/NamingAuthority/pull/119/commits/b4e8b8e83ba85c09777b2b7c0be65b7ec4bfb6a5.

cportele commented 2 years ago

I just had a look at the text and the current wording is unclear. It states:

A shortened form of the URI of a registered Coordinate Reference System (CRS) may be used as an alternative to the full URI by ...

This currently seems to imply that the shortened form could be used anywhere where a URI is expected. This, however, is not correct. The shortened form is not a URI and using it where ever only a URI is expected is syntactically incorrect and can lead to errors raised by libraries parsing the value.

My proposal would be a clean approach along the following lines:

That approach has limitations where we are using elements that are not controlled by OGC and URIs have to used in those cases, but I think we can cover many cases where we want to use a shorter string and the approach does not violate the rules of the IETF/W3C standards.

jerstlouis commented 2 years ago

Should it be ogc:rel instead of ogcrel, e.g. ogc:crs, ogc:tms?

cportele commented 2 years ago

That is not possible, a prefix is an NCName.

jerstlouis commented 2 years ago

@cportele OK, thanks.

Could CURIEs somehow also work for defining a CURIE actually compounding multiple CURIEs for #93 ?

e.g. [epsg:4979+ISO-8601:Gregorian_UTC] as a CURIE shorthand for

http://www.opengis.net/def/crs-compound?1=http://www.opengis.net/def/crs/EPSG/0/4979&2=http://www.opengis.net/def/crs/ISO-8601/0/Gregorian_UTC

where

[epsg:4979] is a CURIE for http://www.opengis.net/def/crs/EPSG/0/4979 and [ISO-8601:Gregorian_UTC] is a CURIE for http://www.opengis.net/def/crs/ISO-8601/0/Gregorian_UTC

assuming they all have an ogccrs default prefix.

ghobona commented 2 years ago

@cportele Could we modify your example prefix of "epsg" meaning http://www.opengis.net/def/crs/EPSG/0/ to be instead "epsg-crs" meaning http://www.opengis.net/def/crs/EPSG/0/

The modification would address the point raised by @RogerLott in Comment https://github.com/opengeospatial/NamingAuthority/issues/92#issuecomment-848971490

cportele commented 2 years ago

@ghobona - I would say "no", because the original issue is really about codifying the current practice that already uses "epsg" as a prefix for CRSs. So I think it has to be "epsg". But we could register, e.g. "epsg-uom" for EPSG UoM URIs etc.

@jerstlouis - Hmm, first of all, those http://www.opengis.net/def/crs-compound-URIs seem like a bad idea. http://www.opengis.net/def is for registered definitions, but this is a grammar to construct URIs, which is something entirely different. IMHO this should not have a base URI of http://www.opengis.net/def. So maybe that should be deprecated in the same step. What this really is, is a stop gap for an array of CRSs. So, where un-registered compound CRSs built from registered CRSs need to be supported, I would allow an array of CRSs, so the value in a query parameter would be [epsg:4979],[ISO-8601:Gregorian_UTC].

jerstlouis commented 2 years ago

@cportele The CIS domainset defines a single srsName field where a coverage has a single CRS, which may be compound (example).

I agree that defining an array of CRS and concatenating together in order all dimensions defined by each of them could really be equivalent to defining a compound CRS on the fly. The result can be seen as an integrated continuum of dimensions just as well. But it seems like we would need to make a breaking change to CIS to allow for this? Currently, CIS requires a single URI to define all dimensions. I had raised a related issue in https://github.com/opengeospatial/coverage-implementation-schema/issues/7.

Maybe we could update the schema so that srsName is a oneOf that could also accept an array?

cportele commented 2 years ago

Well, it would have to be a change in CIS anyhow since the value range would have to be extended from "URI" to "URI or OGC CURIE" or - in the original proposal - to "URI or some OGC-specific-string". The OGC NA cannot declare that something that is not a URI suddenly should be treated as a URI and can be used anywhere where a URI is required. What is a URI is controlled by IETF, not OGC.

Yes, srsName could be extended for such on-the-fly compound CRS and CURIEs. That would require a GML revision, if done properly. Or CIS just documents their convention for encoding CRS references in the srsName attribute, even, if it is not consistent with the XML schema. Based on the proposal in the original issue this seemed to be the idea anyhow. And it would likely work, because XML schema parsers do not throw errors for invalid URIs and non-URI values have frequently been used in the GML srsName attribute in the past.

dr-shorthair commented 2 years ago

Note that CURIEs are syntactically valid in some RDF representations - e.g. Turtle - provided the prefix has been declared.

ghobona commented 2 years ago

Closing this PR without Merging so that we can continue discuss on the Issue thread.

I'll copy over the proposal by @cportele .