Warning:
This wiki has been archived and is now read-only.
Cross reference of UCR to CovJSON spec
This page is work in progress - and will contain a cross-reference and discussion from relevant requirements of the SDW UCR to the CoverageJSON draft spec
Requirements in UCR (highlighted as relevant for coverage)
5.4 It should be possible to add temporal references to spatial coverage data.
CovJSON has a means to add temporal references: [1] . This seems to be defined to make the common case easy, (using Gregorian calendar) but allows alternative temporal reference systems.
5.10 It should be easy to find spatial data on the Web, e.g. by means of metadata aimed at discovery. When spatial data are published on the Web, both humans and machines should be able to discover those data.
CovJSON does not have much to say on the topic of metadata at the whole-document or whole-dataset level. A CovJSON file/object could be described by DCAT and similar metadata in the same way to other formats.
5.14 The coverage data model should consider the inclusion of metadata to allow georectification to an arbitrary grid.
CovJSON approach to spatial reference systems: [2]. Seems flexible and extensible
5.15 It should be possible to georeference spatial data.
Notes: is this just the same as the previous requirement? I propose merging them.
5.23 Spatial data modeling issues solved in existing models shall be considered for adoption, e.g. O&M, SoilML or the OGC coverage model.
(agreed to drop this as too generic)
5.25 Multilingual support
CovJSON approach to multilanguage labels: [3]
5.26 It should be possible to represent many different types of coverage. For instance, to classify coverage data by grid complexity: GridCoverage (GML 3.2.1), RectifiedGridCoverage, ReferenceableGridCoverage, etc.
The 'domainType' parameter [4] allows specification of the type of coverage domain. The spec includes definitions of several common domain types [5] and has a mechanism for extensions [6] if other kinds of coverage are required. This just allows a link to an external definition.
The spec points out a couple of ways in which CovJSON differs from CIS with regard to specification of domains:
"CIS enforces exactly one coordinate reference system (CRS) per coverage, CoverageJSON allows CRSs to be associated with a given combination of coordinates.
CIS has separate domain concepts for grids vs other types, CoverageJSON always uses collections of orthogonal axes for organizing domains, whether gridded or not."
5.32 Ensure alignment of models or vocabularies for describing provenance that exist in the geospatial and Semantic Web domains. Examples are the W3C provenance ontology (PROV-O) and the OGC metadata specfication (ISO-19115).
CovJSON doesn't specify particular ways to describe provenance, but as with other metadata, should be compatible with established approaches of describing provenance. See also the discussion in this Github issue around use of URI fragments for identifying bits of a coverage [7]. Would be good to see that finalised and incorporated in the spec.
5.33 It should be possible to describe properties of the data quality, e.g. uncertainty.
Not sure of how this would be tackled, but know Jon and Maik have been thinking about it. I'll follow up with Jon on it.
5.34 It should be possible to identify and reference chunks of data, e.g. for processing, citation, provenance, cataloging.
There are several approaches in CovJSON to dividing a large coverage into bits, and there is an approach to fragment identifiers in development
5.43 It should be possible to describe locations in a vague, imprecise manner. For instance, to represent spatial descriptions from crowdsourced observations, such as "we saw a wildfire at the bottom of the hillside" or "we felt a light tremor while walking by Los Angeles downtown". Another related use case deals with spatial locations identified in historical texts, e.g. a battle occurred at the south west boundary of the Roman Empire.
I'm not sure that any coverage format is suitable for representing data at vague locations. An external connection could be made between a vaguely expressed location and a precisely defined region that might approximate it, for example a bounding box. The coverage format should then be able to deliver data relating to that region of interest.
5.44 It should be possible to represent satellite data using the SSN model, including sensor descriptions.
This may be a requirement on the SSN model rather than a coverage format.
definition of parameters?
5.46 Standards or recommendations for spatial data on the Web should be applicable to three-dimensional data.
CovJSON can represent 3 dimensional spatial domains - [11]
5.51 It should be possible to represent time series of data.
CovJSON can represent time series data - [12].
5.54 It should be possible to use coverage data as input or output of computational models, e.g. geological models.
Different computation models will have their own requirements for input and output data and any single format for coverage data will not match all models. However, a reasonable requirement for a coverage data format would be to deliver data in an easy to process format, and to have flexible options for delivering extracts of the data in different dimensions. CovJSON satisfies those general requirements.
Other requirements in UCR that also seem relevant
5.2 Standards or recommendations for spatial data on the Web should be compatible with existing methods of making spatial data available (like WFS, WMS, CSW, WCS).
CovJSON incorporates the same concepts of domain, range, parameters as other coverage formats such as WCS. It differs in some respects from the OGC Coverage Implementation Schema [13]
5.3 Spatial data on the Web should be compressible (for optimization of data transfer).
CovJSON consists of JSON objects, which can be compressed using standard approaches.
5.5 Spatial data on the Web should be crawlable, allowing data to be found and indexed by external agents.
Like any other 'file' on the web, CovJSON objects can have a URL and so can be found by crawlers. Whether an agent is able to interpret the contents of a CovJSON file is another question. More important for crawling and hence discovery might be metadata associated with CovJSON data.
See also comments on 5.19 below.
5.6 CRS definition - coverage work should follow the recommended CRS definition - once it is decided what that is
See CovJSON's current approach to defining CRS: [14]
5.8 Determinable CRS - it should be possible for a user to determine which CRS is used.
CovJSON requires that a CRS is always specified [15]
5.9 It should be possible to represent data using different time models, such as geological time and non-Gregorian calendars.
CovJSON approach to time reference systems allows various approaches: [16]
5.19 Spatial data on the Web should be linkable (by explicit relationships between different data in different data sets), to other spatial data and to or from other types of data.
TODO: describe use of incoming and outgoing links in CovJSON
5.20 Standards or recommendations for spatial data on the Web should work well in machine to machine environments.
This is a vague requirement, but CovJSON seems well suited in general to machine processing.
5.22 It should be possible to represent spatial extent directly bound to time, e.g. journey trajectories.
CovJSON has a 'trajectory' option for its domain types: [17]
5.31 It should be possible to describe the observed property represented by a coverage.
The CovJSON approach to describing parameters is explained at [18] and seems to meet this requirement
5.38 It should be possible to attach the procedural description of a sensing method.
It is possible to provide a text description of a parameter, which could potentially contain a description of the sensing method [19]
5.45 Data should be streamable, a consumer should be able to do something meaningful before the end of the data message is received. This could be considered a general requirement for data on the Web, but it is recorded here because spatial data often consist of large chunks of data.
CovJSON is probably not well suited to streaming - but that requirement may be at odds with previous requirements around compression, and splitting large coverages into tiles or other smaller parts.
5.50 Standards or recommendations for spatial data on the Web should support tiling (for raster and vector data). Tiling of spatial data can drastically improve the speed of data retrieval and allows having simple caches of data around the Web.
CovJSON supports tiling [20]
