search

opengeospatial / NamingAuthority

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

Simplification of CRS references/1: allow shorthand notation in addition to URLs #92

Closed pebau closed 1 year ago

pebau commented 3 years ago

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):

{body}:{identifier} == http://www.opengis.net/def/crs/{body}/0/{identifier}

Example: EPSG:4326 == http://www.opengis.net/def/crs/EPSG/0/4326

pebau commented 3 years ago

This ticket needs to be seen in conjunction with #93, it has been split following request by OGC-NA.

cportele commented 3 years ago

Some comments:

ghobona commented 3 years ago

Noting that the WMS 1.3 Standard also allows for {body}:{identifier}.

pebau commented 3 years ago

@cportele thanks for commenting swiftly, good points.

* One idea behind the `EPSG:4326` notation was originally to register `epsg` as a URI scheme (`srsName` has always been a URI in the approved versions of the GML standard). This would have made `epsg:4326` a valid URI, but it never happened, and OGC decided to use first URNs and then http URIs. If this proposal goes forward, maybe that URI Scheme registration should be re-considered (probably by OGP as the owner of the EPSG register with support from OGC-NA)? Here is the link to the URI scheme register: https://www.iana.org/assignments/uri-schemes/uri-schemes.xhtml

sounds good to me! It carries less noise than a URN (or URL), and that's what people seem to want.

* `{body}:{identifier}` == `http://www.opengis.net/def/crs/{body}/0/{identifier}` works for the EPSG register, but not always for the OGC register. Example: `http://www.opengis.net/def/crs/OGC/1.3/CRS84`.

There is a convention with CRSs that a version 0 means "the latest version". That could be extended to a missing version. The above example then would be OGC:CRS84, translating to .../0/CRS84 being equivalent to .../1.3/CRS84.

* If the additional identifiers would be allowed, they should be allowed in general, not just for coverages.

yes, definitely (assuming it works for all situations, I have no overview). Just a thought: as we need to start somewhere and it might take time to complete stakeholders of all identifiers we might want to go for the low-hanging fruit first.

nicholascar commented 3 years ago

I have a long-standing Issue (#27) for the OGC-NA to make SKOS versions of the CRS information available. The relevance to this Issue is that with the new NA tooling for vocabularies, see http://defs.opengis.net/vocprez/, the NA could make many different sorts of information in many different formats for CRSes available including any number of several ways or relating either multiple URIs together or non-URI identifiers and URIs. So for each CRS, we could have multiple identifiers for use in particular domains listed, whether they have a declared URI Scheme or not.

We may see something like:

<http://www.opengis.net/def/crs/EPSG/0/4326>
    adms:identifier [
        skos:notation "EPSG:4326" ;
        METADATA...
    ] ,
    [
        skos:notation "other-scheme:epsg-xxx-4326"
        OTHER METADATA...
    ]
.

The above basically says that there is a primary identifier - the URI - but then there are these other identifiers for particular purpose. If any of those other identifiers were resolvable, they too could resolve back to a particular profile view the CRS' content via the same OGC NA vocab system.

pebau commented 3 years ago

@nicholascar great idea! Actually, from JSON side a similar request was expressed. Seems time is ripe for #92 and #93. We might find support to spice up the OGC resolver to host these representations.

How could we host different representations and keep them in sync? Not sure about automatic translation, but an awkward amount of work manually.

So maybe we start with this shorthand and then make our way forward.

rob-metalinkage commented 3 years ago

I think need to work out where resolution takes place - is this a naming policy issue, a JSON-LD issue or is it a document style issue?

pebau commented 3 years ago

@rob-metalinkage 2 options I can see:

rob-metalinkage commented 3 years ago

what is the Use Case scenario for "shortcut is passed as a parameter " ? - what is the client and how would it know to pass a parameter?

pebau commented 3 years ago

@rob-metalinkage use case is: human is curious or tool needs details on the CRS definition (eg, the COSMO rotated grid currently under discussion would require that the rotation angles get retrieved in case of reprojection). The URL would simply be a well-known base URL plus the CRS string on hand.

RogerLott commented 3 years ago

4326 is the EPSG code for the area Douglas County, Wisconsin, US.

It also happens to be the EPSG code for WGS 84 geographic 2D CRS. EPSG:4326 could apply to either or both of these. There are 9 different EPSG objects with code = 1035. How will EPSG:4326 uniquely identify a CRS?

Codes are unique only when the object type is also known.

Does this proposal need to be modified to crs:EPSG:4326 (retaining order of elements in the URN and URI definition strings defined by N/A in 09/048r5, i.e. http://www.opengis.net/def/objectType/authority/version/code)?

But if this is just for human readability, "EPSG CRS 4326" might be more meaningful.

pebau commented 3 years ago

@RogerLott thanks for sharing these (scary!) details - this prompts several questions:

RogerLott commented 3 years ago

@pebau said "all these are CRSs if I understand correctly".

You do not understand correctly. Douglas County, Wisconsin, US is a geographic extent, not a CRS. Referencing EPSG requires declaring the objectType and objectCode. With both of these attrbutes (plus the knowledge that the authority is EPSG) there is no ambiguity.

I have often seen EPSG:4326 quoted in written exchanges but I am not aware of any tools that support that syntax. I am aware that from time to time IOGP receives comments that EPSG:4326 is ambiguous.

pebau commented 3 years ago

@RogerLott ok, I see. Now, in the context of this discussion we know we are talking about CRSs. so objectType is a given. Doesn't that resolve ambiguity?

RogerLott commented 3 years ago

@pebau You might know you mean a CRS, but how will all recipients know this? If this is to be a context-sensative understanding, then the applicable context needs to be described.

RogerLott commented 3 years ago

In opening this issue, @pebau said "Coverages.SWG recommends that the OGC-NA approve optional use of an additional syntax for CRSs in coverages"

I am strongly of the view that if N/A approves a syntax, it should be applicable not just to coverages but be applicable more widely, ideally generally.

The N/A consideration should be broadened to include options for requesting definitions to be returned in a particular encoding. See issue #107

pebau commented 3 years ago

@RogerLott we may think practically - generalizing beyond practically known solutions will just be another way to kill the proposal. Without alternative. And problems will persist.

ghobona commented 3 years ago

OGC-NA discussion on 2021-06-17

RogerLott commented 3 years ago

@ghobana, re your second and third bullets fro the N/A discussion, those points were made as a means to resolve the problem of ambiguity of authority:code, but my recollection was that it was subsequently stated that a syntax that permitted objectType to be stated was [also] required, so that for example a coordinate operation method could be referenced.

rob-metalinkage commented 3 years ago

Here are my detailed comments and suggestions from the NA discussion..

the proposal cuts across 5 different concerns, and only some of these are a NA matter, however we might also note that the NA is becoming a de facto source of architectural review of HTTP based mechanisms :-)

  1. The syntax is a document writing policy thing, not a NA concern. That said I strongly recommend using the established CURIE pattern (prefix:term) without more complex URL templating. This addresses any issues of ambiguity as prefixes are bound (by some documentation convention) to namespace URIs. The OGC NA concern here is that such URIs should resolve to descriptive content.
  2. Resolution: there should not be any idiosyncratic URI resolution behaviours required. We already support flexibility via content negotiation on media (MIME) type and named profiles (with associated MIME types)
  3. Content: SWGs are responsible to provide canonical machine-readable content - either via providing a source document that can be mirrored in the NA repository or accessed via a stable external service
  4. The resolution of namespace prefixes in API parameters is not a NA concern - its an architecture issue. (The NA supports use of skos:notation properties to provide visibility of API-friendly tokens for URIs. alternatively APIs can define (in some way) assumed default namespaces or a means for clients and servers to establish common understanding of potentially ambiguous prefixes (e.g. EPSG:))
  5. Versioning (use of /0/ etc.) - another big issue but not one this one!
dr-shorthair commented 3 years ago

we might also note that the NA is becoming a de facto source of architectural review of HTTP based mechanisms :-)

Yes, that was my experience from about 9 years ago. OAB was de-facto governance board in OGC, and OGC-NA was architecture/quality control

pebau commented 3 years ago

@RogerLott there is no ambiguity, see the definition again: the shorthand notation always refers to the latest version, equivalent to 0 in OGC convention.

Extensions like adding versions are possible, the syntax does not prohibit it, but not the concern currently. Again, it is about accepting common community practice. Do we want to ignore what tools like GDAL and ArcGIS (and their users) find convenient since years?

ghobona commented 3 years ago

All, Pull Request https://github.com/opengeospatial/NamingAuthority/pull/119 has been created to address this issue.

cportele commented 3 years ago

Related to this: Can we also register http://www.opengis.net/def/crs/OGC/0/CRS84 as an alias for http://www.opengis.net/def/crs/OGC/1.3/CRS84 so that OGC:CRS84 can be used, too?

pebau commented 3 years ago

@cportele makes sense - more generally, we might ensure to have the proper versioning scheme implemented on all OGC/, AUTO/, etc. branches.

ghobona commented 3 years ago

The proposal to register http://www.opengis.net/def/crs/OGC/0/CRS84 as an alias for http://www.opengis.net/def/crs/OGC/1.3/CRS84 has been recorded at Issue https://github.com/opengeospatial/NamingAuthority/issues/120 so that it can have its own discussion thread.

pebau commented 3 years ago

(carrying over from original discussion) suggest to extend this systematically over all non-EPSG crs/ branches.

heidivanparys commented 3 years ago

I have often seen EPSG:4326 quoted in written exchanges but I am not aware of any tools that support that syntax. I am aware that from time to time IOGP receives comments that EPSG:4326 is ambiguous.

projinfo (@busstoptaktik, @kbevers) supports that syntax:

    [...] where {object_definition} or {srs_def} is one of the possibilities accepted
    by :c:func:`proj_create`

    - [...]
    - an object code (like "EPSG:4326", "urn:ogc:def:crs:EPSG::4326",
      "urn:ogc:def:coordinateOperation:EPSG::1671"),
    - [...]
.. option:: -k crs|operation|datum|ensemble|ellipsoid

    When used to query a single object with a AUTHORITY:CODE, determines the (k)ind of the object
    in case there are CRS, coordinate operations or ellipsoids with the same CODE.
    The default is crs.
C:\OSGeo4W>projinfo EPSG:1035
input string: parsing of user string failed: crs not found
C:\OSGeo4W>projinfo -k operation EPSG:1035
input string: parsing of user string failed: coordinate operation not found
C:\OSGeo4W>projinfo -k datum EPSG:1035
WKT2:2019 string:
DATUM["Red Geodesica de Canarias 1995",
    ELLIPSOID["GRS 1980",6378137,298.257222101,
        LENGTHUNIT["metre",1]],
    ID["EPSG",1035]]
ghobona commented 3 years ago

Thanks @heidivanparys, for checking projinfo.

On the Pull Request we tried to address the issue of different definition types by stating that...

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

Based on the findings from https://github.com/opengeospatial/NamingAuthority/issues/92#issuecomment-876571825, I think we should revise the second bullet to say:

Would the revision work?

ghobona commented 2 years ago

The following proposal is from @cportele . It was originally posted on the previous PR https://github.com/opengeospatial/NamingAuthority/pull/119#issuecomment-885577694 :

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.

ghobona commented 2 years ago

@RogerLott Does the CURIE-based proposal above address the scenario you described in https://github.com/opengeospatial/NamingAuthority/issues/92#issuecomment-848971490 ?

Specifically, the scenario that "4326 is the EPSG code for the area Douglas County, Wisconsin, US. It also happens to be the EPSG code for WGS 84 geographic 2D CRS."

pebau commented 2 years ago

I like the idea that we have some standards-based notation with clear guidance!

Looking at the syntax, is epsg:4326 really allowed? According to CURIE "4326" is a reference := irelative-ref (as defined in IRI) and IRI says that this starts with an irelative-path which in turn must have a prefix of // or /. That would mean epsg:/4326 - not exactly what we have in mind. Did I misread something?

RogerLott commented 2 years ago

@ghobona Depends upon what the Naming Authority does in the proposed OGC Prefix register. This issue was raised explicitly to support short cuts for CRSs. epsg:4326 will do this if in the prefix register "epsg:" is mapped to "http://www.opengis.net/def/crs/EPSG/0/".

Although CRSs are of much greater interest than other object types, IMHO the general mechanism being proposed should be made to be general enough to allow for any other entity type, so that if someone wanted to have a shortcut to http://www.opengis.net/def/area/EPSG/0/4326 or http://www.opengis.net/def/coordinateOperation/EPSG/0/1234 this could be done.

A general syntax something like "authority-objectType:" ::= "http://www.opengis.net/def/objectType/authority/0/" would achieve this. So "epsg-area:4326" would map to http://www.opengis.net/def/area/EPSG/0/4326.

But "epsg-crs:4326" is not as succinct as "epsg:4326". Because CRS is likely to be the most frequent use case, then as an addition to the general syntax I propose that if in the short cut the objectType is missing then it defaults to crs, so "epsg:4326" = "epsg-crs:4326" and both map to http://www.opengis.net/def/crs/EPSG/0/4326"

cportele commented 2 years ago

@RogerLott - +1, my proposal was in https://github.com/opengeospatial/NamingAuthority/pull/119#issuecomment-885599677 to use "epsg" for CRS and "epsg-xyz" for other types (e.g. "epsg-datum", "epsg-uom", etc.). If we follow the pattern you have proposed, my proposal would have to be amended to use "ogc-rel" instead of "ogcrel", which makes sense.

@pebau - "4326" is a valid reference. ipath-noscheme is also an option in the BNF rule of irelative-part (after the page break).

ghobona commented 2 years ago

@RogerLott @cportele Thank you for the responses. I think we are getting closer to a consensus solution that is based on the proposal by @cportele, and amended to use "ogc-rel" instead of "ogcrel".

@chris-little Could you please confirm that the proposal addresses your concerns?

chris-little commented 2 years ago

@ghobona Yes, it addresses my concerns:

  1. Uses W3C and IETF recognised mechanisms, not OGC specific;
  2. Extendable to other object types besides CRSs;
  3. Sensible defaults give compact notation;
  4. The NA software can be configured to do it sustainably.
RogerLott commented 2 years ago

@chris-little And generic so can be applied across the board, not just to coverages.

rob-metalinkage commented 2 years ago

Looks good.

one thing to remember is each context will require a way to define the binding of the prefix to the base URI for the CURIE. This is platform specific. The register has a point of truth but each place we use them will need to have an appropriate mechanism (e.g. table of prefixes in documents, JSON context documents etc, @prefix pragmas in RDF/turtle).

The OGC definitions server can help by managing a set of such resource fragments in the register and exposing it all as Linked Data to aid discovery and reuse (FAIR) - let me know what you want to include and I'll propose an information model to glue it together..

pebau commented 2 years ago

@rob-metalinkage we can gladly extend the CRS server to aid in that, a common model is most welcome.

pebau commented 2 years ago

all seems to converge nicely on this issue - however, this is just part of of the story; how would the CURIE-based concepts help with #93 ?

cportele commented 2 years ago

@pebau - Regarding ad-hoc definitions of compound CRS, see the discussion starting at https://github.com/opengeospatial/NamingAuthority/pull/119#issuecomment-885599677

ghobona commented 2 years ago

OGC-NA agreed on 2021-09-14 to apply the CURIE approach.

The approach includes the extension for the object type, as described during the telecon.

The CURIE approach will be reviewed in 2022 or 2023.

ghobona commented 2 years ago

The draft section on CURIE support, for the definitions policy, is in the fix-for-issue-92 branch at the following URL:

https://github.com/opengeospatial/NamingAuthority/blob/fix-for-issue-92/policyAndProcedures/OGCNANameTypeSpecificationForDefinitions/clause_6_1_CURIEs.adoc

The draft content for the CURIE register is at https://github.com/opengeospatial/NamingAuthority/blob/master/incubation/CURIEs/curie.csv

If there are any objections or requests for changes to the text, please post a comment in this Issue by 2021-12-31.

ghobona commented 2 years ago

There were no objections nor requests for changes to the text by the deadline of 2021-12-31. I will therefore proceed to submit a draft policy update to the OGC-NA for approval to recommend TC approval.

ghobona commented 2 years ago

The fix has been moved to the master branch.

An HTML version of the policy document will be generated once metanorma Issue 369 has been fixed.

ghobona commented 2 years ago

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

ghobona commented 1 year ago

The revised policy has been published.