diff --git a/UseCases/SDWUseCasesAndRequirements.html b/UseCases/SDWUseCasesAndRequirements.html index 254cf810..2ddd18a0 100644 --- a/UseCases/SDWUseCasesAndRequirements.html +++ b/UseCases/SDWUseCasesAndRequirements.html @@ -174,7 +174,7 @@
She receives the pamphlet as a scanned image of each page, and she decides that the quantitative information in the paper is useful, so she arranges transcription of the tabular numerical data and their summary values into a digital form and publishes the dataset, with a persistent identifier, and links it to a detailed coverage extent, the original paper source, the scanned pages and her paper when it is published. She also incorporates scanned charts and graphs from the original pamphlet into her paper. Her organization creates a catalog record for her research paper dataset and publishes it in the WIS global catalog, which makes it also visible to the GEO System of Systems broker portal.
- +The research project CERISE-SG aims to integrate data from different domains: government, energy utilities and geography, in order to enable establishment of smart energy grids.
The project has recognized Linked Data as an appropriate concept for integration of data from separate semantic domains. One approach of achieving cross-domain interoperability is to switch from domain-specific semantics to common semantics. For example, the concept of an address has its own definitions in governmental standards and utility standards. Using a common definition improves interoperability.
An example of a domain model that is an international standard in electric utilities is the Common Information Model (CIM). Its data model provides definitions for an important entity: the electricity meter. These meters provide useful data on consumption and production of energy. If it is possible to view these devices as sensors, it could be possible to move from domain specific semantics (CIM) to common semantics (SSN), and to have ready linkage to geographical semantics (location and network topology). What is required in this case is a low-threshold way of using sensor semantics, because people involved in integration of data from multiple domains should not be burdened with having to grasp the full complexity of each domain.
- +How: We use the Location Core vocabulary to model the address, e.g. :station locn:address "C/ Gran Vía (Paraninfo)"^^xsd:string. We use xsd:dateTime to represent hourly observations, e.g. :obs ssn:observationResultTime "2003-03-08T11:00:00Z"^^xsd:dateTime.
Open challenges: The combination of hourly observations and daily aggregations in the same dataset may cause confusion because the granularity of the observation is not explicit. For daily aggregations, we suggest using time:Interval from the Time Ontology. To make the temporal modeling more homogeneous, time:Instant could be used for the hourly observations. [LINK TO DATA SAMPLE TO BE ADDED]
- +What: The Regional Transport Consortium of Madrid (CRTM) wants to make available data about transport card validations and transport card recharging. In the case of transport card validations, the NFC sensors are located on buses, and at the entrance and (some) exit points of metro stations. The observation value of a validation includes data related to the transport card, such as the card identifier and the user profile. The sensors for transport card recharging are ATMs and ticket selling points distributed around Madrid. The observation value of a recharging includes the card identifier and the type of recharging.
How: To model transport card validations, we consider two observed properties: user entry (EntradaUsuario) and user exit (SalidaUsuario). Validation sensors at metro stations have a fixed location and a unique identifier, e.g. 02_L12_P2. A bus validation sensor is moving continuously, so for the sake of pragmatism, there is a unique sensor identifier for each bus stop in every line, e.g. 03_L20_P837. Those identifiers point to an address and geographic coordinates. The observed property when a user adds money to her transport card is the act of recharging (CargaTTP). In both cases, validation and recharging observations, the feature of interest is the transport card.
- +RDF datasets with spatial components are becoming more common on the Web. Many applications could benefit from the ability to combine, analyze and query this data with an RDF triplestore (or across triplestores with a federated query). Challenges arise, however, when trying to integrate such datasets. +
RDF datasets with spatial components are becoming more common on the Web. Many applications could benefit from the ability to combine, analyze and query this data with an RDF triplestore (or across triplestores with a federated query). Challenges arise, however, when trying to integrate such datasets.
For example, Ordnance Survey linked data uses British National Grid SRS and represents geometries with an Ordnance Survey-developed ontology, and LinkedGeoData uses WGS84 longitude latitude and represents geometries as GeoSPARQL WKT literals.
-Best practices in the following areas would help make integration more straightforward. -
Consistent metadata descriptions about spatial datasets will take out a lot of guess work when combining datasets, and standard URIs for spatial reference systems will be an important part of this metadata description. A recommended canonical SRS would make combining datasets more efficient by eliminating the coordinate transformation step, which would make federated GeoSPARQL queries more feasible.
+Best practices in the following areas would help make integration more straightforward.
+Consistent metadata descriptions about spatial datasets will take out a lot of guess work when combining datasets, and standard URIs for spatial reference systems will be an important part of this metadata description. A recommended canonical SRS would make combining datasets more efficient by eliminating the coordinate transformation step, which would make federated GeoSPARQL queries more feasible.
Dutch government data is for a large part open data. However, at the moment the data is difficult to find, and it cannot be easily linked to other data. It is not helping that most registrations are making use of their heavy backoffice standards for opening their data. These problems are counteracted by copying data of others, involving heavy expenses for collecting, converting and synchronizing the data, or by building expensive national provisions. The result is an abundance of copies and much doubt regarding the authenticity of the information.
A better solution would be to make the authentic data permanently available as linked data, so that everyone can use it and the datasets can be interlinked, resulting in more coherence and improved traceability and no more need for copying and synchronization.
-There are now 13 Dutch ‘base registries’ containing government reference data: e.g. +
There are now 13 Dutch ‘base registries’ containing government reference data: e.g.
Challenges include:
Note: This use case has similarities to .
@@ -505,7 +506,7 @@The British Geological Survey (BGS), like all Geological Survey Organizations (GSOs), has as one of its principal roles to be the primary provider of geoscience information within its national territory. Increasingly the information provided is digital and dissemination is over the internet, and there is a trend towards making more information freely available. For BGS’s 2D information this requirement has been met by the provision of various OGC Web map services.
However, geological units and structures are three-dimensional bodies and their traditional depiction on two-dimensional geological maps leads to a loss of information and the requirement of quite a high level of geological understanding on the part of the user to interpret them. The geoscience data user community includes scientific users, but also includes many other stakeholders such as exploration companies, civil engineers, local authority planners, as well as the general public. It is therefore the aim of many Geological Surveys, including BGS, to move towards the provision of geological information as spatial 3D datasets on the Web that are accessible and useable by non-experts.
-We have implemented a few ways of disseminating the 3D data on the Web (http://www.bgs.ac.uk/services/3Dgeology/lithoframeSamples.html, http://www.bgs.ac.uk/services/3Dgeology/virtualBoreholeViewer.html,http://earthserver.bgs.ac.uk/, investigation of augmented reality smartphone application) but the remaining issues are +
We have implemented a few ways of disseminating the 3D data on the Web (http://www.bgs.ac.uk/services/3Dgeology/lithoframeSamples.html, http://www.bgs.ac.uk/services/3Dgeology/virtualBoreholeViewer.html,http://earthserver.bgs.ac.uk/, investigation of augmented reality smartphone application) but the remaining issues are
This additional information supports a broader need for SSN, Coverage and Time considerations for the above three current use cases.
As a result, a combined product is proposed which gives flexibility to use MODIS-derived estimates when large areas and high temporal repetition is desired, and Landsat-derived estimates when high spatial resolution is essential and/or when data prior to 2000 is needed. The algorithms needed for implementing a fractional cover product based on a blended Landsat-MODIS product are given [1].
@@ -855,7 +856,7 @@RLS have visited 2500+ coral and rocky reef sites and have conducted approx 6000 surveys across those sites. Each survey is conducted at a nominal ‘site’.
During a survey observations are recorded of each of (1) vertebrate species abundance and biomass and (2) invertebrate species abundance.
Studying the morphology of disease at the cellular and sub-cellular levels using high resolution tissue images is extremely important to help understand the nature of various cancers. The Cancer Genome Atlas (TCGA) contains over 32,000 de-identified whole-slide microscopy images (WSI) of over two dozen cancer types. These images can contain between 100K-1M nuclei each. Biomedical informatics researcher have developed (and continue to develop) software to automatically segment nuclei for study. The spatial features of each nucleus and groups of nuclei as it relates to other nuclei combined with other linked data such as other morphological features (crypts, ducts, etc.) and/or patient lab results are used in analyzing and categorizing tissues and patients into groups and in comparing such groupings to understand disease mechanisms in a particular cancer type as well as across cancer types.
- Representing nuclear segmentations is often done with binary masks or through polygon representations (e.g., the use of Well Known Text (WKT) representations) and also by leveraging work from the Geospatial community. However, in the case of nuclear segmentations, coordinate systems are 2D & 3D Cartesian based. Although the majority of work is this area is 2D-based, a growing segment of microscopy is also 3D-based as the technology develops and become more sophisticated. As living tissue can change over time through growth, infection, cancer, damage, etc, (as well as its associated organism’s various properties) it is important that spatial locations of features such as nuclear segmentation be also represented in a temporal aspect for proper comparisons. Representing nuclear segmentations is often done with binary masks or through polygon representations (e.g., the use of Well Known Text (WKT) representations) and also by leveraging work from the Geospatial community. However, in the case of nuclear segmentations, coordinate systems are 2D & 3D Cartesian based. Although the majority of work is this area is 2D-based, a growing segment of microscopy is also 3D-based as the technology develops and become more sophisticated. As living tissue can change over time through growth, infection, cancer, damage, etc, (as well as its associated organism’s various properties) it is important that spatial locations of features such as nuclear segmentation be also represented in a temporal aspect for proper comparisons. Samples of TCGA WSI data can be viewed at: http://cancer.digitalslidearchive.net Spatial data modeling issues solved in existing models shall be considered for adoption, e.g. O&M or SoilML. Spatial data modeling issues solved in existing models shall be considered for adoption, e.g. O&M or SoilML.
-
This document describes use cases that demand a combination of geospatial and non-geospatial
data sources and techniques. It underpins the collaborative work of the
Spatial Data on the Web Working Groups operated
by both W3C and OGC.
The mission of the Spatial Data on the Web Working Group, as described in its charter, is to clarify and to formalize standards on spatial data on the web. In particular: The deliverables of this Working Group are described in the Working Group Charter. For convenience those deliverables are replicated in this chapter. The charter remains the authorative source of the definition of deliverables. A document setting out the range of problems that the working groups are trying to solve (this document). This will include: The WG will work with the authors of the existing Time Ontology in OWL to complete the development of this widely used ontology through to Recommendation status. Further requirements already identified in the geospatial community will be taken into account. The WG will work with the members of the former Semantic Sensor Network Incubator Group to develop its ontology into a formal Recommendation, noting the work to split the ontology into smaller sections to offer simplified access. The WG will develop a formal Recommendation for expressing discrete coverage data conformant to the ISO 19123 abstract model. Existing standard and de facto ontologies will be examined for applicability; these will include the RDF Data Cube. The Recommendation will include provision for describing the subset of coverages that are simple timeseries datasets - where a time-varying property is measured at a fixed location. OGC's WaterML 2 Part 1 - Timeseries will be used as an initial basis. Given that coverage data can often be extremely large in size, publication of the individual data points as Linked Data may not always be appropriate. The Recommendation will include provision for describing an entire coverage dataset and subsets thereof published in more compact formats using Linked Data. For example where a third party wishes to annotate a subset of a large coverage dataset or a data provider wishes to publish a large coverage dataset in smaller subsets to support convenient reuse. In order to find out the requirements for the deliverables of the Working Group, use cases were collected. For the purpose of the Working Group, a use case is a story that describes challenges with respect to spatial data on the web for existing or envisaged information systems. It does not need to adhere to certain standardised format. Use cases are primarily used as a source of requirements, but a use case could be revisited near the time the work of the Working Group will reach completion, to demonstrate that it is now possible to make the use case work. The Working Group has derived requirements from the collected use cases. A requirement is something that needs to be achieved by one or more deliverables and is phrased as a specification of functionality. Requirements can lead to one or more tests that can prove whether the requirement is met. Care was taken to only derive requirements that are considered to in scope for the further work of the Working Group. The scope of the Working Group is determined by the charter. To help keeping the requirements in scope, the following questions were applied: Use cases that describe current problems or future opportunities for spatial data on the web have been gathered as a first activity of the Working Group. They were mainly contributed by members of Working Group, but there were also contributions from other interested parties. In this chapter these use cases are listed and identified. Each use case is related to one or more Working Group deliverables and to one or more requirements for future deliverables. Chris Little, based on scenarios used for the WMO infrastructure requirements. She receives the pamphlet as a scanned image of each page, and she decides that the quantitative information in the paper is useful, so she arranges transcription of the tabular numerical data and their summary values into a digital form and publishes the dataset, with a persistent identifier, and links it to a detailed coverage extent, the original paper source, the scanned pages and her paper when it is published. She also incorporates scanned charts and graphs from the original pamphlet into her paper. Her organization creates a catalog record for her research paper dataset and publishes it in the WIS global catalog, which makes it also visible to the GEO System of Systems broker portal. Jeremy Tandy These information types are varied in type and size. In particular, the acoustic survey (e.g. side-scan sonar) is difficult to manage as these survey results can be many gigabytes in size and cover large areas. A way is needed to refer to just a small part of these coverage data sets that are relevant to a particular habitat zone analysis. Manolis KoubarakisMethods 1 & 2
+ Methods 1 & 2
TCGA / Microscopy Imaging
Incorporating geospatial data (e.g. geo-referenced geometry) into interactiv
-
+
Smart Cities
@@ -1308,7 +1309,7 @@ 4D model of space-time
Model reuse
- Spatial Data on the Web Use Cases & Requirements
- W3C Editor's Draft
+ W3C First Public Working Draft
Editors:
@@ -270,14 +268,14 @@
Abstract
+ Abstract
Status of This Document
+ Status of This Document
@@ -289,7 +287,7 @@
- This document was published by the Spatial Data on the Web Working Group as an Editor's Draft.
+ This document was published by the Spatial Data on the Web Working Group as a First Public Working Draft.
If you wish to make comments regarding this document, please send them to
@@ -310,7 +308,7 @@
- Publication as an Editor's Draft does not imply endorsement by the W3C
+ Publication as a First Public Working Draft does not imply endorsement by the W3C
Membership. This is a draft document and may be updated, replaced or obsoleted by other
documents at any time. It is inappropriate to cite this document as other than work in
progress.
@@ -325,6 +323,8 @@
.
+ The group does not expect this document to become a W3C Recommendation.
+
W3C maintains a public list of any patent
@@ -348,10 +348,10 @@
Table of Contents
Table of Contents
1. Introduction
+ 1. Introduction
@@ -364,15 +364,15 @@
The requirements described in this document will be the basis for development of the other four deliverables of the Working Group.
2. Deliverables
+ 2. Deliverables
2.1 Use Cases and Requirements
+ 2.1 Use Cases and Requirements
2.2 Spatial Data on the Web Best Practices
+ 2.2 Spatial Data on the Web Best Practices
develop advice on, or possibly define, RESTful APIs to return data in a variety of formats including those defined elsewhere, such as GeoJSON, GeoJSON-LD and TopoJSON.
2.3 Time Ontology in OWL
+ 2.3 Time Ontology in OWL
2.4 Semantic Sensor Network Vocabulary
+ 2.4 Semantic Sensor Network Vocabulary
2.5 Coverage in Linked Data
+ 2.5 Coverage in Linked Data
3. Methodology
+ 3. Methodology
4. Use Cases
+ 4. Use Cases
4.1 Meteorological Data Rescue
+ 4.1 Meteorological Data Rescue
Envisage an environmental scientist in Cambodia, researching the impact of deforestation in Vietnam as part of investigating the regional impacts of climate change. She submits her search keywords, in Cambodian, and receives responses indicating there is some data from the 1950s, printed in a 1960 pamphlet, in the Bibliothèque Nationale, a library in Paris, France, in French. She receives an abstract of some form that enables her to decide that the data are worth accessing, and initiates a request for a digital copy to be sent.
4.2 Habitat zone verification for designation of Marine Conservation Zones
+ 4.2 Habitat zone verification for designation of Marine Conservation Zones
4.3 Real-time Wildfire Monitoring
+ 4.3 Real-time Wildfire Monitoring
<
Some of the data used in the operational service is
available separately.
Manolis Koubarakis
@@ -493,11 +493,11 @@Finally, the post-processing stage consists of (i) a visual refinement step to ensure product thematic accuracy and consistency, (ii) attribute enrichment of the product by overlaying the polygons with geoinformation layers and finally (iii) generation of thematic maps. It would be interesting for NOA to see where the standards to be developed in this working group could be used.
The burnt scar mapping service is operational.
- - + +Ed Parsons
@@ -515,11 +515,11 @@Ed Parsons
@@ -527,11 +527,11 @@A better understanding of how we describe places in human terms, the hierarchical nature of places and the fuzzy nature of many geographical entities will be needed to make the "Internet of Things" manageable. A new scale of geospatial analysis may be required using a reference frame based on the locations of individuals rather than a global spherical co-ordinate, allowing a location of your keys and their attached bluetooth tag to be described as "in the kitchen".
- - + +Frans Knibbe
@@ -548,11 +548,11 @@From the last two questions it follows that the WG could also be involved in enabling conformance testing and stimulating development of benchmarks for software.
- - + +Frans Knibbe
@@ -573,11 +573,11 @@Frans Knibbe, Karl Grossner
@@ -603,11 +603,11 @@Clemens Portele
@@ -623,11 +623,11 @@Frans Knibbe
@@ -635,11 +635,11 @@The project has recognized Linked Data as an appropriate concept for integration of data from separate semantic domains. One approach of achieving cross-domain interoperability is to switch from domain-specific semantics to common semantics. For example, the concept of an address has its own definitions in governmental standards and utility standards. Using a common definition improves interoperability.
An example of a domain model that is an international standard in electric utilities is the Common Information Model (CIM). Its data model provides definitions for an important entity: the electricity meter. These meters provide useful data on consumption and production of energy. If it is possible to view these devices as sensors, it could be possible to move from domain specific semantics (CIM) to common semantics (SSN), and to have ready linkage to geographical semantics (location and network topology). What is required in this case is a low-threshold way of using sensor semantics, because people involved in integration of data from multiple domains should not be burdened with having to grasp the full complexity of each domain.
- - + +Bart van Leeuwen
@@ -650,11 +650,11 @@Being able to plot and exchange data about active incidents through the Web and visualize them in GIS tools with open standards would be a huge leap forward for Emergency response services.
- - + +Alejandro Llaves, Miguel Angel García-Delgado (OEG-UPM), Rubén Notivol, Javier Celma (Ayuntamiento de Zaragoza)
@@ -663,11 +663,11 @@Open challenges: The combination of hourly observations and daily aggregations in the same dataset may cause confusion because the granularity of the observation is not explicit. For daily aggregations, we suggest using time:Interval from the Time Ontology. To make the temporal modeling more homogeneous, time:Instant could be used for the hourly observations. [LINK TO DATA SAMPLE TO BE ADDED]
- - + +Alejandro Llaves (OEG-UPM)
@@ -675,42 +675,43 @@Matthew Perry (Oracle)
RDF datasets with spatial components are becoming more common on the Web. Many applications could benefit from the ability to combine, analyze and query this data with an RDF triplestore (or across triplestores with a federated query). Challenges arise, however, when trying to integrate such datasets. -
RDF datasets with spatial components are becoming more common on the Web. Many applications could benefit from the ability to combine, analyze and query this data with an RDF triplestore (or across triplestores with a federated query). Challenges arise, however, when trying to integrate such datasets.
+For example, Ordnance Survey linked data uses British National Grid SRS and represents geometries with an Ordnance Survey-developed ontology, and LinkedGeoData uses WGS84 longitude latitude and represents geometries as GeoSPARQL WKT literals.
-Best practices in the following areas would help make integration more straightforward. -
Consistent metadata descriptions about spatial datasets will take out a lot of guess work when combining datasets, and standard URIs for spatial reference systems will be an important part of this metadata description. A recommended canonical SRS would make combining datasets more efficient by eliminating the coordinate transformation step, which would make federated GeoSPARQL queries more feasible.
+Best practices in the following areas would help make integration more straightforward.
+Consistent metadata descriptions about spatial datasets will take out a lot of guess work when combining datasets, and standard URIs for spatial reference systems will be an important part of this metadata description. A recommended canonical SRS would make combining datasets more efficient by eliminating the coordinate transformation step, which would make federated GeoSPARQL queries more feasible.
Linda van den Brink
Dutch government data is for a large part open data. However, at the moment the data is difficult to find, and it cannot be easily linked to other data. It is not helping that most registrations are making use of their heavy backoffice standards for opening their data. These problems are counteracted by copying data of others, involving heavy expenses for collecting, converting and synchronizing the data, or by building expensive national provisions. The result is an abundance of copies and much doubt regarding the authenticity of the information.
A better solution would be to make the authentic data permanently available as linked data, so that everyone can use it and the datasets can be interlinked, resulting in more coherence and improved traceability and no more need for copying and synchronization.
-There are now 13 Dutch ‘base registries’ containing government reference data: e.g. -
There are now 13 Dutch ‘base registries’ containing government reference data: e.g.
+Lars G. Svensson
@@ -739,24 +740,24 @@Note: This use case has similarities to 4.9 Enabling publication, discovery and analysis of spatiotemporal data in the humanities.
+Note: This use case has similarities to 4.9 Enabling publication, discovery and analysis of spatiotemporal data in the humanities.
- - + +Rachel Heaven
The British Geological Survey (BGS), like all Geological Survey Organizations (GSOs), has as one of its principal roles to be the primary provider of geoscience information within its national territory. Increasingly the information provided is digital and dissemination is over the internet, and there is a trend towards making more information freely available. For BGS’s 2D information this requirement has been met by the provision of various OGC Web map services.
However, geological units and structures are three-dimensional bodies and their traditional depiction on two-dimensional geological maps leads to a loss of information and the requirement of quite a high level of geological understanding on the part of the user to interpret them. The geoscience data user community includes scientific users, but also includes many other stakeholders such as exploration companies, civil engineers, local authority planners, as well as the general public. It is therefore the aim of many Geological Surveys, including BGS, to move towards the provision of geological information as spatial 3D datasets on the Web that are accessible and useable by non-experts.
-We have implemented a few ways of disseminating the 3D data on the Web (http://www.bgs.ac.uk/services/3Dgeology/lithoframeSamples.html, http://www.bgs.ac.uk/services/3Dgeology/virtualBoreholeViewer.html,http://earthserver.bgs.ac.uk/, investigation of augmented reality smartphone application) but the remaining issues are -
We have implemented a few ways of disseminating the 3D data on the Web (http://www.bgs.ac.uk/services/3Dgeology/lithoframeSamples.html, http://www.bgs.ac.uk/services/3Dgeology/virtualBoreholeViewer.html,http://earthserver.bgs.ac.uk/, investigation of augmented reality smartphone application) but the remaining issues are
+Rachel Heaven
@@ -789,11 +790,11 @@Rachel Heaven
@@ -806,11 +807,11 @@(NB Geonames goes much of the way to meeting this requirement)
Cory Henson (Bosch RTC)
@@ -846,11 +847,11 @@Antoine Zimmermann
@@ -861,11 +862,11 @@Antoine Zimmermann
@@ -875,31 +876,31 @@The need for spatio-temporal information is even increased if the smart grid is including electric vehicles that can serve as energy producers when they are not consuming electricity for recharging.
- - + +Luigi Selmi (via public-sdw-comments)
Tax assessments are based on the comparison of what is due by a citizen in a year for her ownership of real estates in the area administered by a municipality and what has been paid. The tax amount is regulated by laws and based on many criteria like the size of the real estate, the area in which it is located, its type: house, office, farm, factory and others. Taxpayers can save money from the original due depending on the usage of the estate. A family that owns the house in which they live can save the entire amount. Many other regulations lighten in different ways the burden of the tax for other categories of taxpayers. Furthermore the situation about a taxpayer changes over the years in relation to her properties share and family status. Due to the many different situations met, an employee in charge of performing tax assessments on behalf of a municipality must collect many information before being able to assert with a good degree of confidence that a difference between the original amount and what has been paid is not justified and an advice has to be sent to the taxpayer starting a long and expensive process to recover the difference. Currently each single assessment requires the employee to collect information from different public administrations Web sites, archives, registries, documents. Data scattered in so many silos and formats dramatically reduce employees productivity and assessment effectiveness at the point that it is not always clear whether the money recovered is worth the cost of the assessment. A Linked Data approach for sharing spatial and temporal data would certainly increase the productivity of the assessor.
Kerry Taylor (on behalf of Jamie Baker, Australian Commonwealth Department of Communications)
This use case is provided to extend three primary use cases already before the Working Group:
More broadly the Commonwealth of Australia has developed a National Map Web platform which is currently making available authoritative national datasets. There is a need to recognize that data can an image (e.g. an image-based tile set for example) and therefore in itself also create a time series-based resource (for example, the change in a water course over time which can be visualized as time series layers). Indeed both the ISO and OGC have recognized this in their standards. It is the Australian Government Department of Communication’s view, as the lead agency stewarding spatial data policy, that image-based resources should also be included in the consideration of this working group as it relates to geographic and spatial features geometries. Wheresoever possible the Commonwealth view is to maintain the highest applicability of a standard or best practice guide and not limit conformance options for data holdings (especially of public origin). This also applies to cadastral and other data at the state/territory level which could show the change in land parcel, development or other property and built environment features over time. In terms of our future cities, sensors and other data sources may also need linkage to image-based resources for citizen use. As such:
Chris Little (on behalf of Andrew G Hughes, British Geological Survey)
@@ -937,11 +938,11 @@Simon Cox (on behalf of Peter Wilson, Bruce Simons @ CSIRO)
@@ -952,11 +953,11 @@Simon Cox (on behalf of Paul Box, Simon Cox and Ryan Fraser @ CSIRO)
@@ -993,11 +994,11 @@She is now able to see that Springwood suburb will be within the predicted fire polygon and will need to be evacuated. The analyst clicks linked information resources for Springwood (the synonym in the ASGS dataset) and a graph of related resources is displayed [uc 7.1, 7.2, 6]. This shows a link to a suburb profile based on the most recent national population and census data is available the analyst clicks on this and a query for predefined measurements (plus the place identifier) is passed to a census data cube service. The analyst visualizes and saves the result set locally.
The analyst also notices that information resources are connected to Springwood (in the gazetteer dataset) [uc 7.1, 7.2, 6]. These include a link to a containing local government area (LGA) and links to LGA emergency management resources on the Website. This lists contact information and evacuation centers information which is used to inform development of the evacuation plan.
- - + +Simon Cox
@@ -1008,11 +1009,11 @@Simon Cox
@@ -1029,11 +1030,11 @@Bill Roberts (based on needs arising from Swirrl's own work)
@@ -1044,11 +1045,11 @@Kerry Taylor (informed by Matt Paget and Juan Guerschman, CSIRO)
@@ -1066,54 +1067,54 @@[1] Guerschman et al, "Assessing the effects of site heterogeneity and soil properties when unmixing photosynthetic vegetation, non-photosynthetic vegetation and bare soil fractions from Landsat and MODIS data", Remote Sensing of Environment, to appear 2015.(Note that this paper provides several references to similar approaches to using multispectral coverages to determine vegetation).
- - + +Simon Cox (on behalf of IMOS eMII)
I am a modeler and I want to find, filter and extract water column data that has been collected by profiling instruments (e.g. CTD, XBT, ARGO Floats, CTD’s mounted on animals) so that I can prime my models. I want to easily be able to discover these data either by nominating the collection device type, or by nominating data parameters of interest. Once I can see which datasets meet my broad discovery criteria, and whilst still in the Portal, I want to be able to filter out data that is not of interest (e.g. those data outside of my region of interest, those not covering my features of interest, data which is unqualified, data below a certain depth and data from institutions I don’t trust). I want to extract these data in a harmonized format (i.e. receive a single file of aggregated data expressed using common data fields, or in multiple files where each file has a similar syntactic and semantic encoding). I don’t want to have to spend time transforming datasets with differing formats, nor guess which data fields in datasets from different sources are semantically covering the same information. I need to know what each field in the downloaded data represents.
I am an eMII Project Officer. I spend my day pulling data from partner services and transforming it so that it can be published through the 1-2-3 Portal. Just when I think I have tweaked all of the systems I need to in order to successfully ingest and publish provider data, the provider changes his/her data format, schema syntax or semantics. I then have to re-write or re-configure systems to obtain any new data. This happens very frequently. Even data providers who supply me with data from the same instruments use different data encodings and formats so I have to create individualized database tables to manage their incoming data. I would like data providers to agree on common schema for expressing similar data types and in collaboration develop some ‘governance’ rules surrounding data publication to the Portal to reduce the time I spend on repetitive (and often unnecessary) tasks.
I am an eMII Project Officer and I manage multiple profile type datasets (e.g.: Argo profile, seals profile, XBT profile …). I want to be able to assess the quality of the data provided by partners before inclusion into the IMOS database and making it available through the IMOS portal. I want to set up a system whereby every new profile will be compared with existing profiles available in the IMOS database. The incoming profile will have to conform to a standard format so that it is relatively easy to implement and develop different set of rules to enable comparison with existing profiles. The system will send me an alert if one or multiple profiles failed some tests. Then I will be able to follow up more quickly with the corresponding partners to check if an error occurs during the processing of the data or if actually the data is correct. In the end, this process will enable an increase of the quality of the data provided to the end user.
Simon Cox (on behalf of IMOS eMII)
The ALA would like to integrate their data into the AODN. The ALA serves a range of Web services including WMS and corresponding ISO19115/MCP metadata. The ALA's use case is unusual in that it has tens of thousands of WMS layers and metadata records. This data cannot be added to version 2 of the AODN portal because it is too large to be harvested into the menu tree. ALA will need to be integrated with the 123 portal. Dave Martin's team has created a proof of concept integration. There would be a single metadata record for ALA, which will allow it to be discovered in Step 1 of the portal. After proceeding to Step 2 the user would see something like this mockup.
RLS have visited 2500+ coral and rocky reef sites and have conducted approx 6000 surveys across those sites. Each survey is conducted at a nominal ‘site’. -
During a survey observations are recorded of each of (1) vertebrate species abundance and biomass and (2) invertebrate species abundance.
During a survey downward looking photographs are taken. The photographs are sequenced 1-20 for each site and are not geolocated. Subsequently, the photographs are scored at 5 points within each image. Each point is scored into one of 36 categories. Parameters are date, depth, resolution, major category, minor category, numerical value.
I’m interested in ecosystems, reef assemblages and inter-species interactions. Show me what vertebrate and invertebrate species were found at this site (and any corresponding location/depth/habitat information).
What I want to see:
I have a large-scale question to ask about a particular species, for example, I am interested in broad distribution patterns of lobsters, plankton dispersal and settling rates. Show me all of the sites that were surveyed and the presence/absence of a particular species at each of those sites.
What I want to see:
The IMAS use case includes a number of data collections. The main requirements is a mechanism to easily install the necessary applications. Ideally the AODN will host the applications (GeoNetwork, Geoserver etc) in the NeCTAR Cloud. This cloud based infrastructure will be managed by the AODN, but IMAS will have administrator accounts on each application and will be responsible for data content.
Simon Cox (on behalf of IMOS eMII)
The user would like to download temperature and velocity data from NSW moorings without downloading large numbers of NetCDF files, and without needing many clicks.
(Based on feedback from Robin Robertson).
The user would like an easy way to download the calibrated glider data. The user does not want the data delivered manually via drop box, or to face the difficulty of downloading NetCDF files in the way they are currently provided.
(Based on feedback from Robin Robertson).
The user would like to download the ANMN Timor South moorings data - without needing 160 clicks.
(Based on feedback from Rebecca Cowley).
The user would like to download XBT data from the portal. Not just the metadata - but the actual data.
(Based on feedback from Rebecca Cowley).
The user would like to be able to download NRS moorings data.
(Based on feedback by Peter Thompson)
+The user would like to be able to download NRS moorings data.
(Based on feedback by Peter Thompson)
The user would like to be able to understand the portal even though she is from another field (e.g. genomics).
(Based on feedback from Levente Bodrossy).
The user would like to be able to filter moorings data by deployment and instrument type.
(Based on feedback from Craig Steinberg)
+The user would like to be able to filter moorings data by deployment and instrument type.
(Based on feedback from Craig Steinberg)
The user would like to download sea surface temperature from the Bass Straight as a CSV file - not NetCDF
(Based on feedback from Andre Chiaradia)
+The user would like to download sea surface temperature from the Bass Straight as a CSV file - not NetCDF
(Based on feedback from Andre Chiaradia)
The user would like to download argo data from a particular region in the Southern Ocean.
(Based on feedback from Esmee)
+The user would like to download argo data from a particular region in the Southern Ocean.
(Based on feedback from Esmee)
Also see additional stories in un-edited emails.
Linda van den Brink (with thanks to Henk Schaap - Gobar)
@@ -1192,11 +1193,11 @@Kerry Taylor (on behalf of Aaron Sedgmen of Geoscience Australia)
@@ -1207,11 +1208,11 @@GA does use proprietary and quasi-standard light weight data exchange formats (e.g. JSON) and Web APIs (e.g. ESRI RESTful API) for delivering some geospatial data, although, in accordance with government policy, it is GA’s preference to adopt standards when possible to maximize interoperability.
- - + +Kerry Taylor (on behalf of Aaron Sedgmen of Geoscience Australia)
@@ -1221,11 +1222,11 @@Usability of search and discovery systems would be enhanced by having standards that define the line between spatial data and metadata in the context of searches, and standard methodologies for searching across collection level and feature level data.
- - + +Kerry Taylor (on behalf of Aaron Sedgmen of Geoscience Australia)
@@ -1233,11 +1234,11 @@Erich Bremer
@@ -1246,11 +1247,11 @@Representing nuclear segmentations is often done with binary masks or through polygon representations (e.g., the use of Well Known Text (WKT) representations) and also by leveraging work from the Geospatial community. However, in the case of nuclear segmentations, coordinate systems are 2D & 3D Cartesian based. Although the majority of work is this area is 2D-based, a growing segment of microscopy is also 3D-based as the technology develops and become more sophisticated. As living tissue can change over time through growth, infection, cancer, damage, etc, (as well as its associated organism’s various properties) it is important that spatial locations of features such as nuclear segmentation be also represented in a temporal aspect for proper comparisons.
Samples of TCGA WSI data can be viewed at: http://cancer.digitalslidearchive.net
- - + +Kerry Taylor with Zheng-Shu Zhou, CSIRO
@@ -1259,11 +1260,11 @@Andrea Perego (European Commission - Joint Research Centre)
@@ -1287,16 +1288,16 @@Andrea Perego (European Commission - Joint Research Centre)
@@ -1313,15 +1314,15 @@Related use cases:
- +Erwin Folmer, Dutch Cadastre (via public-sdw-comments@w3.org)
@@ -1329,11 +1330,11 @@The Dutch Cadastre is a major provider of INSPIRE data in the Netherlands. It also maintains the portal PDOK, a central facility for making INSPIRE-compliant geographical data available in the Netherlands.
- - + +Karl Grossner, Stanford Libraries
@@ -1345,11 +1346,11 @@There is ongoing work in several research communities to arrive at better general models for representing and computing over such spatial-temporal and dynamic phenomena. One approach aims at 4-dimensional model of space-time (e.g. CIDOC-CRM E92-Spacetime Volume). Another seeks to add a "when" component to the "where" (geometry) of GeoJSON and GeoJSON-LD.
- - + +Jeremy Tandy, Met Office
@@ -1358,16 +1359,16 @@Stefan Lemme, DFKI/Saarland University
This use case relates to 4.8 Consuming geographical data in a web application and maintains the bridge 3D-web applications (without targeting the actual rendering process, which is out-of-scope).
+This use case relates to 4.8 Consuming geographical data in a web application and maintains the bridge 3D-web applications (without targeting the actual rendering process, which is out-of-scope).
Visualizing geospatial data, such as geo-referenced 3D geometry of building, is a crucial capability even for Web applications. This use case targets Web developers that are using 3D graphics in their (existing) Web applications. To ease the pick up of 3D graphics for Web developers, since they are usually non-graphics experts, the Declarative 3D for the Web Architecture Community Group of W3C did previous work to determine the requirements, options, and use cases for an integration of interactive 3D graphics capabilities into the W3C technology stack. Thereby, they propose a declarative approach to describe the 3D scene content as an extension of HTML5 rather than interfacing low-level APIs for rendering. Several implementations, such as X3D, X3DOM, and XML3D, address this approach. However, Web developers are usually non-geospatial experts. Thus, to achieve a similar low-entrance barrier for them to incorporate geospatial data into interactive 3D graphics on the Web, any (web)service providing geospatial data (including geometry) might consider a compatible content delivery format and API. Firstly, this implies none to only very little processing overhead on the client. In particular, when having mobile Web applications in mind an efficient content delivery (bandwidth-wise as well as client-side-processing-wise) is becoming important. Secondly, Web developers utilize established libraries, such as jQuery, to interface remote (RESTful) APIs. To ease interfacing geospatial services, Web developers tend to reuse their tools. Finally, existing best practices of the Web should be taken into account and applied to the access of geospatial data according, such as paging of result sets, caching of resources at several stages (server, browser), etc.
Payam Barnaghi (on behalf of the EU FP7 CityPulse Project)
@@ -1392,8 +1393,8 @@This chapter lists the requirements for the deliverables of the Working Group, in alphabetical order.
-There should be a common standard for publishing and requesting the bounding box and centroid of a spatial thing.
- - + +Standards for spatial data on the Web should be compatible with existing methods of making spatial data available (like WFS, WMS, CSW, WCS).
- - + +Spatial data on the Web should be compressible (for optimization of data transfer).
- - + +It should be possible to add temporal references to spatial coverage data.
- 4.19 Publication of Raw Subsurface Monitoring Data, 4.3 Real-time Wildfire Monitoring, 4.32 Satellite data processing, 4.30 Spatial Sampling, 4.2 Habitat zone verification for designation of Marine Conservation Zones, - + 4.19 Publication of Raw Subsurface Monitoring Data, 4.3 Real-time Wildfire Monitoring, 4.32 Satellite data processing, 4.30 Spatial Sampling, 4.2 Habitat zone verification for designation of Marine Conservation Zones, +Spatial data on the Web should be crawlable, allowing data to be found and indexed by external agents.
- - + +The URI of the Coordinate Reference System (CRS) shall be specified when geographic coordinates are present in the data.
- - -This requirement possibly needs rephrasing.
It should be possible to represent dates, time and duration.
- - + +There should be a default Coordinate Reference System (CRS) that can be assumed to be used for coordinates that otherwise have no specification of the CRS.
- - + +It should be possible to represent data using different time models, such as geological time and non-Gregorian calendars.
- - + +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.
- - + +It should be possible to represent near real-time streaming sensor measurements.
- - + +There should be a standard for encoding vector geometry (an expression of spatial data that uses coordinates) when such data are published on the Web.
- - + +It should be possible to represent ex-situ (remote) sampling or sensing.
- - + +The coverage data model should consider the inclusion of metadata to allow georectification to an arbitrary grid.
- - + +It should be possible to georeference spatial data.
- - + +It should be possible to represent observations taken by human individuals or communities acting as sensors perceiving the environment.
- - + +Standards for spatial data on the Web should be independent on the reference systems that are used for data.
Note: This requirement reflects that spatial data incorporate geographical data, but can also be data that are not directly related to earth or its scale.
- - + +A lightweight API is needed for implementation on Internet of Things (IoT) devices.
- - -This requirement needs clarification.
Spatial data on the Web should be linkable (by explicit relationships between different features), to other spatial data and to or from other types of data.
- - -The phrasing of this requirement is under discussion.
Standards for spatial data on the Web should work well in machine to machine environments.
- - + +It should be possible to represent sensors that change their location, as well as the current location of the sensor at the observation time.
- - + +It should be possible to represent spatial extent directly bound to time, e.g. journey trajectories.
- - + +Spatial data modeling issues solved in existing models shall be considered for adoption, e.g. O&M or SoilML.
- - -This requirement needs clarification.
It should be possible to refer to features that change their location.
- - + +All vocabularies that will be developed or revised should have annotation in multiple languages.
Note: We assume that is technically possible to have human readable annotation in multiple languages in vocabularies for spatiotemporal data on the Web. With English being the default language, as many other languages as possible should be supported. This will mean that in such cases we will have to call upon WG members that are fluent in languages other than English to provide annotation.
- - + +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.
- - -This requirement needs clarification.
it should be possible to represent qualitative and nominal observations.
- - + +It should be possible to refer to time intervals by nominal temporal references (e.g. January, a named event in a calendar, a geological period, a dynastic period).
- - + +It should be possible to use non-geographic spatial reference systems.
- - + +It should be possible to represent aggregations of observations.
- - + +It should be possible to describe the observed property represented by a coverage.
- - + +It should be possible to add provenance metadata.
- - -Different phrasing of this requirement is necessary.
It should be possible to describe properties of the data quality, e.g. uncertainty.
- - + +It should be possible to identify and reference chunks of data, e.g. for processing, citation, provenance, cataloguing.
- - + +It should be possible to refer to externally-managed controlled vocabularies.
- - -This requirement could be out of scope.
It should be possible to represent topological relationships between observation samples, e.g. specimens located along a borehole or probe spots found on a polished section of rocks.
- - + +It should be possible to include metadata about the sensors producing the observations.
- - + +It should be possible to attach the procedural description of a sensing method.
- - + +It should be possible to represent and integrate data over spatial and temporal scales.
- - + +There should be standards that allow describing the spatial characteristics of data (data objects, data sets or data services), like:
There should be a standard for describing spatial hierarchy. The Dublin Core metadata vocabulary contains the terms hasPart and isPartOf. Can those terms be recommended for specifying spatial hierarchy? Or is something else needed?
- - -Both the title and the description of this requirement should be changed.
There should be common standards for spatial operators. Spatial things can have spatial relations: topological relations, directional or distance relations. Operators based on these relations (e.g. 'Contains'. 'Intersects', 'Nearest') should be standardized.
- - -This requirement needs clarification.
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.
- - + +It should be possible to represent satellite data using the SSN model, including sensor descriptions.
- - + +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.
- - + +All standards for spatial data on the Web should be applicable to three-dimensional data.
- - + +It should be possible for Coordinate Reference Systems to have time dependent components such as the point of origin.
- +If a temporal reference is used, the description of the temporal reference system (e.g. Unix date, Gregorian Calendar, Japanese Imperial Calendar, Carbon Date, Geological Date) needs to be referenceable online.
- - -This requirement could need to be rephrased.
It should be possible to describe time points and intervals in a vague, imprecise manner. For instance, to represent an event happened on the afternoon of June 1st or at the second quarter of the 9th century.
- - -This requirement needs clarification.
Standards 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.
- - + +It should be possible to represent time series of data.
- - + +It should be possible to represent uncertainty in observations.
- - + +It should be possible to use coverage data as input or output of computational models, e.g. geological models.
- - + +It should be possible to validate spatial data on the Web; to automatically detect conflicts with standards or definitions.
- - + +It should be possible to represent the time of validity that applies to a thing, state or fact.
- - -This requirement may be out of scope.
It must be possible to represent synthetic observations made by computational procedures or inference.
- - + +The editors are grateful for all contributions made to this document, in particular the use case authors.