Expected Application for OGC Features API Support

[nyrareddy]

Hello community,

I have been reading up on the links for this Idea from the Ideas Page and had a few questions about it.

• Is this a high priority project or are there any other problems which require a more immediate resolution.

We should be able to serve datasets via OAPIF directly from Kart repositories as well as potentially integrate Kart repositories into larger OAPIF server infrastructures like pygeoapi or GeoServer.

• Are we looking to create a new API for kart according to OGC Definitions? If yes, then are there any preferred implementation languages or frameworks?
• Apart from this, we then need to add support for pygeoapi plugins and GeoServer extensions too. Is there any suitable subsystem where this plugin would belong to?

support for incorporating & exposing versioning history

• How should one approach this? Could you provide any ideas or starting points?

It would be great if the mentors of this project (@rcoup, @craigds) could help me with a good starting point or any relevant past work done for researching and working on a possible solution. And also a bit more direction and clarification with regards to the expectations in the proposal.

Thanks.

[rcoup]

Hi Nyra,

Is this a high priority project or are there any other problems which require a more immediate resolution.

This is one of the projects we're proposing for Google Summer of Code, it's not more or less important than the others.

Are we looking to create a new API for kart according to OGC Definitions

The general concept is someone who is using Kart can point a GIS server at a Kart repository location and have it work as a datasource. For pygeoapi, the plugin docs & the associated APIs/code may give a useful starting point (although we're talking millions of features, so everything will need to stream out of the repository unlike their simple examples).

In addition to exposing Kart data through these servers, it'd be nice to produce a lightweight implementation, maybe something like a kart-ogcapi command installed by the plugin. Then,

$ kart-ogcapi /path/to/my/kart/repo

Which would:

• start a process listening for HTTP requests
• exposing an OGC-Features API (OAPIF) service
• with the data from the repository

Apart from this, we then need to add support for pygeoapi plugins and GeoServer extensions too.

We don't expect someone to necessarily do pygeoapi and GeoServer, it's up to your interests & capabilities.

Is there any suitable subsystem where this plugin would belong to?

Initially I'd imagine these plugins will sit outside Kart, but could require changes to Kart to expose any data that we don't otherwise have, adjust interfaces, improve performance, etc.

support for incorporating & exposing versioning history

• How should one approach this? Could you provide any ideas or starting points?

All these things give a different view on the repository:

• branches/tags (refs)
• default/current branch (HEAD)
• specific commits

For pygeoapi/geoserver, being able to specify which ref/commit we want to return data for is probably a reasonable starting point.

Thinking of the lightweight implementation, these views could be exposed different ways:

1. a service only exposing a single specified ref/commit (/api/...), with Kart datasets as the OAPIF Collections
2. a service using different OAPIF endpoints for a set of refs (ala /refs/tags/{tag}/api/..., ), with Kart datasets as the OAPIF Collections. Since IIUC OAPIF doesn't have any formal support for nesting collections/themes/etc yet maybe we should adopt a STAC Catalog-style approach
3. a service like (2), but accepting any commit sha (or ref).

[nyrareddy]

@rcoup and @craigds, could you provide any updates on the proposals as and when you rank them? It would help me know my status and look for other opportunities this summer, if required.