OGC API & STAC - Proof of Concept

Camptocamp

Last update: Dec 1, 2022

Related tags

Cryptography oapi-poc

Overview

OAPI - POC

Proof of concept (POC) to ingest geospatial datasets from MeteoSuisse into a SpatioTemporal Asset Catalog (STAC), expose as OGC API Features and offer OGC API Environmental Data Retrieval (EDR) capabilities.

Documentation

OGC API and STAC are designed to be explorable through links and a good starting point is the Landing Page (aka Root Catalog) which links to capabilities, descriptions and fundamental resources of the services.

The OpenAPI definition can be consumed through the SwaggerUI. Select the appropriate server and authorization (for endpoints except GET) to try it out.

Be aware that the api definition is not in sync with the service implementation. There are addinonally transactional endpints for Collection and Feature/Item resources and the schemas/definitions might diverge from the actual implementation by the services.

Usage

For now the basic use case is uploading a STAC Asset through the load-asset process. The input schema describes the json body of the post request passed to it's ./execute endpoint. It requires the file as base64 encoded string, some asset properties, the collection id and the item id or an item object to create.

Example python scripts for loading an asset to an existing collection as well as extracting & creating a collection resource from a geocat.ch entry are in the scripts folder.

Consumption

The created resources can for example be consoumed with the STAC Browser. The assets contents accessible through the href reside on a S3 bucket.

Caveats

Only the data on S3 is persisted, the rest lives in the containers of the docker composition.
The asset content is not parsed, nor are any attributes derived.
Only base64 encoded string are supported as file value for now.
An asset can be replaced by specifying the asset id, the S3 key and the item id as value in the inputs.
It is currently not possible to updat the Feature/Item on upload.
Catalog trees can only be created from the collection downwards as the root catalog is immutable for now.

Catalog Trees (advanced & untested)

Potentially catalog trees can be created by adding collection resources with the property type set to Catalog and links with the relations parent, child and/or item. Naturally these relations should be reflected on the linked ressources as well.

Selendra is a multichains interoperable nominated Proof-of-Stake network for developing and running Substrate-based and EVM compatible blockchain applications.

Selendra An interoperable nominated Proof-of-Stake network for developing and running Substrate-based and EVM compatible blockchain applications. Read

16 Nov 29, 2022

Proost - A small proof assistant written in Rust

A simple proof assistant written in Rust. The specification of the project may be found here, and the user manual here. The API documentation c

12 Mar 3, 2023

DAPOL+ Proof of Liabilities using Bulletproofs and Sparse Merkle trees

DAPOL+ implementation Implementation of the DAPOL+ protocol introduced in the "Generalized Proof of Liabilities" by Yan Ji and Konstantinos Chalkias A

5 Apr 9, 2023

Alternative Mizar proof checker written in Rust

Mizar proof checker This is a (still experimental) proof checker for the Mizar language. To compile the project, get Rust 1.67 or later (https://rustu

16 Apr 13, 2023

A fast zero-knowledge proof friendly Move language runtime environment.

zkMove Lite zkMove Lite is a lightweight zero-knowledge proof friendly Move language virtual machine. Move bytecode is automatically "compiled" into c

43 May 20, 2023

Uses Plonky2 proof system to build recursive circuits for Merkle Trees.

ProvableMerkleTrees Introduction This repo provides Rust code to build Merkle Trees, equipped with a Provable interface to generate Zero Knowledge pro

5 Aug 18, 2023

Implementation of zero-knowledge proof circuits for Tendermint.

Tendermint X Implementation of zero-knowledge proof circuits for Tendermint. Overview Tendermint X's core contract is TendermintX, which stores the he

3 Nov 8, 2023

A node API for the dprint TypeScript and JavaScript code formatter

dprint-node A node API for the dprint TypeScript and JavaScript code formatter. It's written in Rust for blazing fast speed. Usage Pass a file path an

431 Dec 24, 2022

binance API client

bian-rs 币安API Rust async SDK 完成情况接口现货 U本位合约币本位合约欧式期权 http 🚧 开发中 🆗 🚧 开发中未开始 websocket 🚧 开发中 🆗 🚧 开发中未开始使用在 Cargo.toml 中添加依赖 [dependencies]

28 Nov 13, 2022

Comments

License

Hi Balthasar, Emmanuel pointed me to this project and I'm excited to see other GIS devs using Rust! I would like to add this project to the https://github.com/pka/awesome-georust#readme watchlist, but the license seems to be missing. Regards, Pirmin

opened by pka 4
"datetime" parameter: issue with ending 'Z' in datetime value

@b4l when doing a request with the datetime parameter, the API requires the datatime value to have an ending 'Z', otherwise and error is returned. Not sure this is the right behaviour. IMHO it shoul accept datetimes without the ending 'Z'. Some clients (e.g. QGIS) do not send the ending 'Z' in request and won't be able to use the API

opened by p1d1d1 1
"datetime" parameter not supported in endpoint /items ?

@b4l I think there is an issue with the 'datetime' parameter. It seems to me that is is not supported/implemented in the endpoint:

/collections/{collectionId}/items

The following request should return only 1 Item: https://poc.meteoschweiz-poc.swisstopo.cloud/root/collections/35ff8133-364a-47eb-a145-0d641b706bff/items?datetime=2022-07-04T13:46:00Z

Same kind of request on the /search endpoint is working: https://poc.meteoschweiz-poc.swisstopo.cloud/root/search?collections=35ff8133-364a-47eb-a145-0d641b706bff&datetime=2022-07-04T13:46:00Z

opened by p1d1d1 1
Unexpected COSMO-1E data
This may be due to my misunderstanding but some of the COSMO-1E data seems to be linked at an incorrect URI:

In the Stac-browser, accessing the https://radiantearth.github.io/stac-browser/#/external/poc.meteoschweiz-poc.swisstopo.cloud/root/collections/cosmo-1e_grib2

I'm selecting the URI

COSMO-1E - GRIB2 - 03 - 002 - T_2M

I'm assuming the components of the URI mean:

03 : Time of calculation of the forecast is 03:00 AM

002 : Leadtime is 2 hours, i.e. looking 2 hours into the future

T_2M : Temperature 2 meters above the ground is forecast

There are 11 datasets under this URI. I'm assuming this is the ensemble of 11 forecasts. However, all 11 datasets are labeled with: Acquired = 10/1/2022, 12:00:00 PM UTC

That is, the acquired time is midnight and not 3 AM as assumed given the URI.

Moreover, the acquired time seems to be the same for all of:

COSMO-1E - GRIB2 - 00 - 002 - T_2M

COSMO-1E - GRIB2 - 03 - 002 - T_2M

COSMO-1E - GRIB2 - 06 - 002 - T_2M

COSMO-1E - GRIB2 - 09 - 002 - T_2M

COSMO-1E - GRIB2 - 12 - 002 - T_2M

COSMO-1E - GRIB2 - 15 - 002 - T_2M

COSMO-1E - GRIB2 - 18 - 002 - T_2M

COSMO-1E - GRIB2 - 21 - 002 - T_2M

Moreover, the data also seems to be exactly the same between those datasets (I checked this only for 00 and 12).

Is my understanding of the URI wrong or is there really something wrong with the linking of the data?
opened by brmanuel 2