search

BRGM / gml_application_schema_toolbox

GML Application Schema toolbox is a QGIS plugin allowing to manipulate OGC Complex Features
https://brgm.github.io/gml_application_schema_toolbox/
GNU General Public License v2.0
27 stars 18 forks source link

Future content negotiation #137

Open Guts opened 3 years ago

Guts commented 3 years ago

Purpose

Actually, resolve requests are using the application/xml mime-type: it's a feature, not a bug :wink:. Let's improve it! Goal: get a generic behavior to handle basic use cases and allow the end-user to fine tune it.

Different mime-types

Behavior

Mermaid syntax:

graph TD
    A[Feature instance description] -->|Resolve external| B(Request URI/L)
    B --> C{Content negotiation}
    C --> D[Profile settings]
    D --> C
    C -->|GET| E[application/ld+json]
    C -->|GET| F[application/gml+xml]
    C -->|GET| G[application/rdf+xml]
    C -->|GET| H[application/geo+json]
    E --> I{Response checker}
    F --> I
    G --> I
    H --> I
    I --> |KO| C
    I --> |OK| J{Response processor}
    J --> K([templating/rendering])

As image:

sgrellet commented 3 years ago

More content to anticipate future evolution on content negociation with services.

The exemple below is an attempt to show the various representations of the same feature (French aquifer of code 121AS01) available from the same URL

  {
    "schema:url": "https://data.geoscience.fr/id/hydrogeounit/121AS01",
    "@type": "foaf:Document",
    "primaryTopic": "gw:GW_Aquifer", 
    "format": [
      "application/gml+xml", "application/ld+json"
    ],
    "conformsTo": "https://www.opengis.net/def/gwml2",
    "provider": "https://data.geoscience.fr"
  },

Both approaches are not, yet, implemented on the server side so far.

=> Down to earth short term solution is to start "storing" just

"format": [
      "application/gml+xml", "application/ld+json"
    ],

with 

schema:url": "https://data.geoscience.fr/id/hydrogeounit/121AS01
or
"provider": "https://data.geoscience.fr/id/hydrogeounit/"

Keeping in mind this logic will evolve into a more matrix oriented content at some point

sgrellet commented 3 years ago

Quick note on the why 

schema:url": "https://data.geoscience.fr/id/hydrogeounit/121AS01
or
"provider": "https://data.geoscience.fr/id/hydrogeounit/"

It's easy to make QGIS remember that for a given url/URI ( here : "https://data.geoscience.fr/id/hydrogeounit/121AS01) the various representations availabe are X, Y, Z... But if the user interacts a lot with that dataset, that's a lot to store (one entry for each instance in the dataset)

As URI are often designed with a given pattern, it would be handy if the user is capable of editing what he wants QGIS to remember. For that specific example, it would be better just to store that under 'https://data.geoscience.fr/id/hydrogeounit/' the various representations available are X, Y, Z... as, for all the instances in this dataset the resolver will ask the same server (here Geoserver)

sgrellet commented 3 years ago

Link to a server that implements content negociation for features (not content negociation by profile yet) to test the dev See : https://github.com/INSIDE-information-systems/API4INSPIRE#more-details

sgrellet commented 3 years ago

For the sake of highlighting where things are moving more globally

This page provides alternate representations to the URI http://www.opengis.net/def/nil/OGC/0/unknown using the following GET parameters : used '_profile' and '_mediatype'.

For example

Tried using curl (seems only the encoding is forwarded but that's Work In Progress)