Warning:
This wiki has been archived and is now read-only.
CoverageJSON / REST API Reflection
From Spatial Data on the Web Working Group
Contents
CoverageJSON
What works
- practical format, convenient to work with (fixed JSON structure)
- efficient data representation (1D array encoding an nD array)
- ability to add new domain types, reference systems, metadata, ...
- includes collection format
- can embed or URL-reference domain and range data
- fairly easy to understand once the core concepts are understood
- successfully implemented in Java servers and JS clients
What doesn't work (yet)
- in-progress: having an interoperable way to add new semantics / extensions outside the core specification (issue #50)
- JSON-LD not suitable for efficient JSON representation of domain and range
- not sure yet how to relate different variants of a coverage to each other (resolutions, CRS, subsets)
Coverage Data REST API
- experimental, mostly for dynamically subsetting a coverage, and filtering/paging a collection
- based on:
- embedding API controls (=URL templates with meaning) via JSON-LD into a CoverageJSON document, uses draft W3C Hydra ontology
- HTTP Link headers (e.g. for pagination)
- make API self-describing in each HTTP resource
- requires JSON-LD parsers on client side
What works
- it works
- for simple and advanced clients -> partly duality of HTTP Link headers and embedded JSON-LD
What doesn't work (yet)
- too much effort on the client side handling arbitrary JSON-LD, need fixed JSON structure
- duality of HTTP Link headers and JSON-LD only for collection pagination, not for subsetting or collection filtering (as the latter are too complicated to describe in a HTTP Link header)
- some people consider it weird having API controls within the "data" -> in some non-JSON formats this would also be impossible (Q: how to discover API controls for subsetting a netCDF file?)
- implemented in longitude/latitude only at the moment, for simplicity
