Closed jerstlouis closed 5 months ago
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 https://github.com/opengeospatial/NamingAuthority/issues/170).
That particular problem has been resolved.
This Issue duplicates and possibly specialises the one at https://github.com/opengeospatial/NamingAuthority/issues/124
Closing this issue because it duplicates https://github.com/opengeospatial/NamingAuthority/issues/124
@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 https://github.com/opengeospatial/NamingAuthority/issues/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.
@avillar @ghobona
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
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:
/tms/2.0
, however that should not be relevant because:See also #109 about actually returning the definition as a 200 rather than a re-direction.
See also #124 about content negotiation.