opengeospatial / NamingAuthority

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

Deprecate v1.0 tile matrix set examples #199

Closed ghobona closed 1 year ago

ghobona commented 1 year ago

The examples from schemas.opengis.net/tms/1.0 are deprecated. The data model has changed for 2DTMS&TSMD version 2.0. The new schemas will be deployed to /tms/2.0.

Reported by @jerstlouis

jerstlouis commented 1 year ago

Thank you @ghobona .

And as I clarified in #198:

jerstlouis commented 1 year ago

Thank you very much @avillar, @rob-metalinkage, everyone, for updating the TileMatrixSet definitions to point to the Tile Matrix Set definitions using 2DTMS version 2.0 from the registry.

Until #192 (multiple see also) is resolved, would it be possible to please link to (see also) the JSON definitions ( https://github.com/opengeospatial/2D-Tile-Matrix-Set/tree/master/registry/json ) rather than the XML ones?

The OGC API - Tiles TileSet conformance class (akin to a more useful "Core" than the minimalistic Core) explicitly requires support (requirement 8A) for the JSON definition, whereas the XML ones are for a separate conformance class. We expect much fewer implementations to implement and support the XML definition, which is only provided mostly for continuity with the WMTS legacy. Similar to how many more OGC API - Features implementations suport GeoJSON than GML.

This simple fix would greatly improve the immediate useability of the TileMatrixSet register for the use case of manually exploring it in a browser.

Also I noticed that UTM60WGS84Quad is missing from the list.

Thank you!

rob-metalinkage commented 1 year ago

@jerstlouis - yes happy to add these links - but if we link to github this way then the resource will not be given the correct MIME type - we are currently look at how best to link to multiple arbitrary locations and preserve correct mime-types - it may be a matter of a pipeline accessing them from the registered source and loading them into a proxy location we can expose with correct MIME types - or else ask providers to ensure they have a canonical location that uses correct MIME types.

We could use these links and expect systems navigating the machine readable content to make allowances but this is adding a layer of complexity in the wrong place - expecting consumers to predict and cope with non standard behaviours.

jerstlouis commented 1 year ago

@rob-metalinkage Thanks, my suggestion here was simply to use the JSON ones instead of the XML ones that are already there currently (linking to the GitHub).

I am not sure I understand the MIME type issue. Do you mean the Content-Type: that is returned by GitHub in HTTP response headers does not have the proper media type application/json? I do see that GitHub returns < content-type: text/plain; charset=utf-8.

it may be a matter of a pipeline accessing them from the registered source and loading them into a proxy location we can expose with correct MIME types

Yes, this is what we would hope for, that some sort of database or local file storage managed by OGC could serve that purpose, and pull from the GitHub registry when an update is needed (whether that is an automated or a manual process via issues here). Ideally, this would also support content negotiation (#124) and returning the actual definition (#109) at the definition server canonical URI itself (#198).

Thanks!

ghobona commented 1 year ago

@jerstlouis @rob-metalinkage Please note that the data that was ingested into the Definition Server already has links to both the JSON and XML representations. However, VocPrez does not appear to have been configured to display multiple seeAlso statements, so only one statement is currently being shown. It's the same issue as #192.

ghobona commented 1 year ago

The source file is at https://github.com/opengeospatial/NamingAuthority/blob/master/incubation/20220926_tile_matrix_set_register/tms.ttl

jerstlouis commented 1 year ago

@ghobona @rob-metalinkage @avillar Yes that is correct. My suggestion was a work-around for #192 considering the much greater importance of the JSON encoding for TileMatrixSets for OGC API - Tiles compared to XML. So does it just happen to keep the last see also entry? If so I could go through and submit a pull request that moves the .json to appear after the .xml in the .ttl file.

This temporary work around would greatly improve the immediate usability of the TileMatrixSet registry.

Thanks.

ghobona commented 1 year ago

Links to the v1.0 tile matrix set examples have now been removed.