OGC API & STAC - Proof of Concept

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.

You might also like...
Proost - A small proof assistant written in Rust
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

Proost 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

Mysten Labs 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

Mario Carneiro 16 Apr 13, 2023
A fast zero-knowledge proof friendly Move language runtime environment.
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

YoungRocks 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

null 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

Succinct 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

Devon Govett 431 Dec 24, 2022
binance API client

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

null 28 Nov 13, 2022
Rust API guidelines

Rust API guidelines This is a set of recommendations on how to design and present APIs for the Rust programming language. They are authored largely by

The Rust Programming Language 1.1k Jan 3, 2023
Comments
  • License

    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

    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
Owner
Camptocamp
Innovative Solutions by Open Source Experts
Camptocamp
GitHub
Proof of concept implementation of ProtoGalaxy

protogalaxy-poc Proof of concept implementation of ProtoGalaxy (https://eprint.iacr.org/2023/1106.pdf) using arkworks. Experimental code, do not use i

null 30 Aug 13, 2023
Proof of concept implementation of Sigmabus

sigmabus-poc Proof of concept implementation of Sigmabus https://eprint.iacr.org/2023/1406, a cool idea by George Kadianakis and Mary Maller and Andri

arnaucube 5 Sep 30, 2023
Proof-of-concept Typst webapp alternative

Proof-of-Concept Typst Webapp Alternative With the following features: Collaborative editing (using operational-transform and referenced from ekzhang/

Matt Fellenz 3 Nov 7, 2023
gRPC client/server for zero-knowledge proof authentication Chaum Pederson Zero-Knowledge Proof in Rust

gRPC client/server for zero-knowledge proof authentication Chaum Pederson Zero-Knowledge Proof in Rust. Chaum Pederson is a zero-knowledge proof proto

Advaita Saha 4 Jun 12, 2023
Simple automated proof assistant.

Esther is a work-in-progress, proof-of-concept automated theorem proof assistant based on Homotopy Type Theory. Acknowledgements Arend, Lean, Coq and

Aodhnait Étaín 5 Sep 14, 2021
Composable proof transcripts for public-coin arguments of knowledge

Merlin: composable proof transcripts for public-coin arguments of knowledge Merlin is a STROBE-based transcript construction for zero-knowledge proofs

dalek cryptography 99 Dec 22, 2022
Implementation of Proof of Existence consensus using Substrate Framework, Frame, Pallets, RUST

Substrate Node Template A fresh FRAME-based Substrate node, ready for hacking ?? Getting Started Follow the steps below to get started with the Node T

Vijayendra Gaur 1 Jun 8, 2022
OpenZKP - pure Rust implementations of Zero-Knowledge Proof systems.

OpenZKP OpenZKP - pure Rust implementations of Zero-Knowledge Proof systems. Overview Project current implements ?? the Stark protocol (see its readme

0x 529 Jan 5, 2023
Rust implementation of Namada, a sovereign proof-of-stake blockchain that enables asset-agnostic private transfers

Namada Overview Namada is a sovereign proof-of-stake blockchain, using Tendermint BFT consensus, that enables multi-asset private transfers for any na

anoma 144 Jan 2, 2023
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

Selendra 16 Nov 29, 2022