graphql-engine
graphql-engine copied to clipboard
hasura
Output OGC API - Features
Component
c/v3-engine
Is your proposal related to a problem?
A big subset of the models of our supergraph contains geodata. In order to enable an integration of our system into the wider ecoystem of ogc based applications such as (Web)GIS tools, we need to expose this subset as an OGC API - Features compliant rest api. With the wider adoption of ogc standards and tools, this is quite likely to become a common requierment for any organization working mainly or to a high degree with geodata.
Describe the solution you'd like
Extend the ddn-engine, metadata schema and hasura language server to enable the compilation of the geodata related subset of the supergraph to an OGC API compliant Features api. The following steps would be required to implement OGC API - Features Part 1 as a prototype.
metadata
kind: OGCConfig
version: v1
definition:
endpoint: /ogc
presence of OGCConfig informs hasura language server that models might declatre ocg configurations.
kind: Model
version: v1
definition:
name: Building
objectType: Building
ogc:
features:
// include model in OGC API - Features rest endpoints
// Model must contain a geomtry or geography field
endpoints
/ogc/conformance Response should be directly dervied from Hasura OGC Implementation
{
"conformsTo":[
"http://www.opengis.net/spec/ogcapi-features-1/1.0/conf/core",
"http://www.opengis.net/spec/ogcapi-features-1/1.0/conf/oas30",
"http://www.opengis.net/spec/ogcapi-features-1/1.0/conf/html",
"http://www.opengis.net/spec/ogcapi-features-1/1.0/conf/geojson"
]
}
/ogc/collections Should be derived from models declaring an ogc features configuration, user permissions and type definitions (description)
{
"links": [
{
"href": "<hausra-project-url>/ogc/collections.json",
"rel": "self",
"type": "application/json",
"title": "this document"
},
{
"href": "<hausra-project-url>/ogc/collections.html",
"rel": "alternate",
"type": "text/html",
"title": "this document as HTML"
}
],
"collections": [
{
"id": "Building",
"title": "Building",
"description": "Buildings in the city of Bonn.",
"extent": {
"spatial": {
"bbox": [
[
7.01,
50.63,
7.22,
50.78
]
]
},
"temporal": {
"interval": [
[
"2010-02-15T12:34:56Z",
null
]
]
}
},
"links": [
{
"href": "<hausra-project-url>/ogc/collections/Building/items",
"rel": "items",
"type": "application/geo+json",
"title": "Buildings"
},
{
"href": "<hausra-project-url>/ogc/collections/Building/items.html",
"rel": "items",
"type": "text/html",
"title": "Buildings"
}
]
}
]
}
ogc/collections/{collectionId} Same as above but returning only one collection
/ogc/collections/{collectionId}/items Should be derived from model, relationships and user permissions. Properties must only include fields and relations user is allowed to access.
{
"type": "FeatureCollection",
"links": [
{
"href": "<hausra-project-url>/ogc/collections/buildings/items.json",
"rel": "self",
"type": "application/geo+json",
"title": "this document"
},
{
"href": "<hausra-project-url>/ogc/collections/buildings/items.html",
"rel": "alternate",
"type": "text/html",
"title": "this document as HTML"
},
{
"href": "<hausra-project-url>/ogc/collections/buildings/items.json&offset=10&limit=2",
"rel": "next",
"type": "application/geo+json",
"title": "next page"
}
],
"timeStamp": "2018-04-03T14:52:23Z",
"numberMatched": 123,
"numberReturned": 2,
"features": [
{
"type": "Feature",
"id": "123",
"geometry": {
"type": "Polygon",
"coordinates": [
"..."
]
},
"properties": {
"function": "residential",
"floors": "2",
"lastUpdate": "2015-08-01T12:34:56Z"
}
},
{
"type": "Feature",
"id": "132",
"geometry": {
"type": "Polygon",
"coordinates": [
"..."
]
},
"properties": {
"function": "public use",
"floors": "10",
"lastUpdate": "2013-12-03T10:15:37Z"
}
}
]
}
/ogc/collections/{collectionId}/items/{featureId}
same as above but returns a single feature
Describe alternatives you've considered
1) pg_featureserv
We could run pg_featureservor GeoServer next to hasura to publish our geodata via an ogc compliant rest api. However this approach has two major drawbacks: we have to maintain an additional application and even worse configure auth rules in to systems and keep them in sync.
2) custom solution on top of hasura
We could build a custom ogc api features server wich maps requests to hasura graphql or openapi. This would allow us to reuse the auth rules defined for hasura, however we would have to maintain an additional application amd even worse keep the data models in sync.
For future reference TiPg is a python based project generating ogc features and ogc tiles rest apis via postgres schema inspection.
@olmohake - thanks a lot for opening this issue with such details - it is an interesting idea that we can look to incorporate in the API engine in time to come but not on the priority as of now. Up next on the release schedule is support of auto-generated JSON API. Here is the technical RFC for that, please let know if any thoughts/comments.
@rahulagarwal13 I totaly get that there are plenty of things you'll have to concetrate on first as they adress the needs of a wider user group. I had a look at the JSON API RFC and am looking forward to its implementation. I guess a lot of the work that needs to be done for the proposed ogc api endpoint will overlap with the implementation of a general JSON API. I will update and expand this proposal accordingly once the auto-generated JSON API has been released and you have settled on OpenDD configurations for it.
Most GIS Tools support SQL Connections as well. Exchanging data with these systems would therfore be enabled by #9590 as well. As SQL as API would furthermore enable the intrgration with a wide range of BI Tools, #9590 should be prioritized.