Not possible to retrieve TileMatrixSet definitions from definitions server
Closed this issue · 12 comments
Currently it is not possible to retrieve TileMatrixSet definitions from definition server.
It is not possible programmatically:
Using an Accept: application/json header results in a SKOS JSON object which is not useful for clients or developers.
What is really needed is clients being able to retrieve the actual definition of a TileMatrixSet based on the schema defined by the 2D Tile Matrix Set and Tileset metadata 2.0 standard (schemas to be hosted at https://schemas.opengis.net/tms/2.0, but whose examples are not authoritative), for the registered TileMatrixSets maintained in the 2DTMS's GitHub repository registry directory, in either XML or JSON.
It is also not possible from to retrieve definitions manually from HTML representation of definition URI resource either, because of a 400 Input Error on the "see also" (see #170).
However, please note that:
- The schemas and 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, however that should not be relevant because: - The examples in the schemas/ folder and 2DTMS&TSMD standard are not the authoritative source for the TileMatrixSet definitions. Rather, the TileMatrixSet registry itself, as presented by the definition server, is.
- Because of this, it would seem more correct to call these links (accessed from the canonical URI of an entry in the TileMatrixSet register) "JSON representation" and "XML representation", or "definition", or "see also JSON/XML definition/representation" instead of "see also" implying that this is a different web resource.
- The TileMatrixSet registry can source its content from the registry directory of the GitHub TileMatrixSet repository (containing both the JSON and XML definitions). The definition server could make its own copy in a database or local directory for security or other reasons by cloning the copy, and sync by doing a pull/copy.
See also #109 about actually returning the definition as a 200 rather than a re-direction.
See also #124 about content negotiation.
It is also not possible from to retrieve definitions manually from HTML representation of definition URI resource either, because of a 400 Input Error on the "see also" (see #170).
That particular problem has been resolved.
@ghobona This issue may actually be different from "Content negotiation" discussed in #124.
There is actually already some support for "Content Negotiation" on the definition server.
Making this request:
curl -v -H "Accept: application/json" http://www.opengis.net/def/tilematrixset/OGC/1.0/GNOSISGlobalGrid
will return a 303 See other with a location header to a JSON document,
then requesting that location:
curl -v "http://defs.opengis.net/vocprez/object?uri=http://www.opengis.net/def/tilematrixset/OGC/1.0/GNOSISGlobalGrid&_mediatype=application/ld+json"
will return some JSON(-LD).
However, it is not the actual JSON definition of the TileMatrixSet which clients are interested in, it is a JSON representation of the SKOS concept.
So this issue was about returning the actual JSON definition of the TileMatrixSet instead of the JSON SKOS Concept,
and about returning the object directly instead of as a 303 See Other redirect (#109 was specifically about that latter aspect, but unfortunately it was closed, even though that is still a real usability issue for clients).
So unless #124 does include in its scope returning actual JSON definition rather than the JSON SKOS concept and returning things directly instead of as a 303 re-direct, I would suggest re-opening this issue and #109.
This issue should be closed once the following request:
curl -H "Accept: application/json" http://www.opengis.net/def/tilematrixset/OGC/1.0/GNOSISGlobalGrid
returns the content of the 2DTMS definition.
(cURL does not follow redirect by default "In curl's tradition of only doing the basics unless you tell it differently" unless the -L option is used. In my opinion, there is no reason why a "basic" request from the canonical URI of the 2DTMS definition resource should not just work).
@jerstlouis Thanks for the clarification. Let's keep the two issues separate because the discussion in #124 appears to be focused on the Turtle encoding.
@avillar I would suggest something like this.
import requests
import json
url = "http://www.opengis.net/def/tilematrixset/OGC/1.0/GNOSISGlobalGrid"
headers = {"Accept": "application/json"}
if ("http://www.opengis.net/def/tilematrixset/OGC/1.0/" in url) and (headers["Accept"] == "application/json"):
response = requests.get(url, headers=headers)
json = response.json()
for item in json[0]['http://www.w3.org/2000/01/rdf-schema#seeAlso']:
if "https://raw.githubusercontent.com/opengeospatial/2D-Tile-Matrix-Set/master/registry/json/" in item['@id']:
response2 = requests.get(str(item['@id']), headers=headers)
json2 = response2.json()
print(json2)The server has now been enabled to support this operation on tile matrix set definitions when the Accept header is set to application/json. All of the following have been checked and confirmed to work correctly.
curl -H "Accept: application/json" http://www.opengis.net/def/tilematrixset/OGC/1.0/CDB1GlobalGrid
curl -H "Accept: application/json" http://www.opengis.net/def/tilematrixset/OGC/1.0/CanadianNAD83_LCC
curl -H "Accept: application/json" http://www.opengis.net/def/tilematrixset/OGC/1.0/EuropeanETRS89_LAEAQuad
curl -H "Accept: application/json" http://www.opengis.net/def/tilematrixset/OGC/1.0/GNOSISGlobalGrid
curl -H "Accept: application/json" http://www.opengis.net/def/tilematrixset/OGC/1.0/UPSAntarcticWGS84Quad
curl -H "Accept: application/json" http://www.opengis.net/def/tilematrixset/OGC/1.0/UPSArcticWGS84Quad
curl -H "Accept: application/json" http://www.opengis.net/def/tilematrixset/OGC/1.0/UTM01WGS84Quad
...truncated...
curl -H "Accept: application/json" http://www.opengis.net/def/tilematrixset/OGC/1.0/UTM60WGS84Quad
curl -H "Accept: application/json" http://www.opengis.net/def/tilematrixset/OGC/1.0/WebMercatorQuad
curl -H "Accept: application/json" http://www.opengis.net/def/tilematrixset/OGC/1.0/WorldCRS84Quad
curl -H "Accept: application/json" http://www.opengis.net/def/tilematrixset/OGC/1.0/WorldMercatorWGS84Quad
Thanks @avillar, for implementing the solution.
Would it be possible to fix this to return the correct Content-Type: application/json response header ?
curl -v -H "Accept: application/json" http://www.opengis.net/def/tilematrixset/OGC/1.0/GNOSISGlobalGrid
...
< Content-Type: text/plain; charset=utf-8
This is the same issue why we cannot directly use the GitHub responses.
Additionally, it would be nice if the XML representation was supported as well:
curl -v -H "Accept: text/xml" http://www.opengis.net/def/tilematrixset/OGC/1.0/GNOSISGlobalGrid
A profile for the requested URI base exists but no rules match for the requested format
but we do also have those set up on the registry and in the definition server seeAlso:
@jerstlouis Can you check now?
ETA: I added the rules for the XML versions, too.
Thanks a lot @avillar !!! It is working!! \o/
Note that there is no charset parameter defined for application/json, so it might be best to omit
Note: No "charset" parameter is defined for this registration.
Adding one really has no effect on compliant recipients.
Verified using the following. The responses are below each command.
% curl -I -H "Accept: application/json" http://www.opengis.net/def/tilematrixset/OGC/1.0/WorldMercatorWGS84Quad | grep 'Content-Type'
% Total % Received % Xferd Average Speed Time Time Time Current
Dload Upload Total Spent Left Speed
0 7002 0 0 0 0 0 0 --:--:-- --:--:-- --:--:-- 0
Content-Type: application/json; charset=utf-8
X-Content-Type-Options: nosniff
Access-Control-Allow-Headers: x-requested-with, Content-Type, origin, authorization, accept, client-security-token
% curl -I -H "Accept: application/json" http://www.opengis.net/def/tilematrixset/OGC/1.0/CDB1GlobalGrid | grep 'Content-Type'
% Total % Received % Xferd Average Speed Time Time Time Current
Dload Upload Total Spent Left Speed
0 36115 0 0 0 0 0 0 --:--:-- --:--:-- --:--:-- 0
Content-Type: application/json; charset=utf-8
X-Content-Type-Options: nosniff
Access-Control-Allow-Headers: x-requested-with, Content-Type, origin, authorization, accept, client-security-token
@jerstlouis You got it, it's already gone