Coverage UCR notes

These are rough notes on the implications of particular use cases for the way we represent and manage use of coverage data

UC4.1 Meteorological data rescue

• need for multilingual metadata
• mostly a metadata related use case

UC4.2 Habitat zone verification for designation of Marine Conservation Zones

• ability to address a subset of a coverage dataset so that it can be linked to a spatial thing. Hence to document the provenance of data used to decide on MCZ designation.
• gridded coverage and point cloud coverage relevant
• from a provenance point of view, there could be a lot of processing from the 'raw' data that is collected by a satellite or sonar (for example) and the corresponding conclusions about the state of the ground or seabed. How do we document those steps - PROV-O ? Need vocabs for describing the steps in that process?

UC4.3 Real-time wildfire monitoring

• timeliness of data, hence pros and cons of on the fly delivery vs processing and storage
• lots of processing steps (see provenance point above)

UC4.4 Diachronic burnt scar mapping

• also perhaps a need to relate a polygon to a coverage subset

UC4.7 Publishing geographical data

• want to relate a real world place, represented in some CRS as eg a polygon or point, to some set of attributes at a particular time.

UC4.8 Consuming geographical data in a web application

• enable automation of data processing by describing the nature of the data represented

UC4.12 Using spatial data from the web in GIS systems during emergency response operations

• want to combine different data sources so need a shared geo representation
• spatial relationships and administrative relationships between areas
• relate a spatial thing to data about it (links to subsets again)

UC 4.18 Dissemination of 3D geological data

• note need for 3d coordinate systems and 3d volumes, hence need for coverage subsetting to work in 3 spatial dimensions (and presumably also potentially a time dimension)
• need for subsetting of a complex shape - eg overlaying the 3d shape of a tunnel on a 3d geological coverage
• possible need for varying resolution, to represent features like faults - so need triangulated irregular networks as well as grids

UC4.19 Publication of raw subsurface monitoring data

• an example of a point cloud approach rather than gridded approach.
• provide in a way that makes it easy to use (parts of) the data in visualisations, statistical analysis, alerts

UC4.21 Driving to work in the snow

• need to find data from a coverage dataset for a particular point - what's the most recent measured temperature at point X
• spatial and temporal subsetting of coverage data

Summary

I think the most important requirements can be summarised as:

• can assign an identifier to a subset of a coverage dataset
• can deliver a subset of a coverage dataset in a 'web-friendly' format (that might need defining! depends on which user group)
• can describe the origin and processing that has happened to produce a coverage dataset (or subset)

We can probably think of delivery of a full coverage dataset as a special case of the subsetting.

Some more detailed things to consider that come out of the use cases:

• some use cases refer to non-gridded coverage data (point-clouds, time-series) so while grid coverages are quite common, we shouldn't restrict ourselves only to those
• defining the region of interest for a subset might be complicated: simplest case is probably a bounding box, but also maybe an irregular polygon or 3d volume, could include restrictions in other dimensions, eg time, or only one of a set of possible variables.