Copyright © 2015 OGC & W3C ® ( MIT , ERCIM , Keio , Beihang ), W3C liability , trademark and document use rules apply.
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 Group s operated by both W3C and OGC .
This
section
describes
the
status
of
this
document
at
the
time
of
its
publication.
Other
documents
may
supersede
this
document.
A
list
of
current
W3C
publications
and
the
latest
revision
of
this
technical
report
can
be
found
in
the
W3C
technical
reports
index
at
http://www.w3.org/TR/.
https://www.w3.org/TR/.
For OGC This is a Public Draft of a document prepared by the Spatial Data on the Web Working Group (SDWWG) - a joint W3C -OGC project (see charter ). The document is prepared following W3C conventions. The document is released at this time to solicit public comment.
The Working Group does not expect to publish further iterations of this document.
This
document
was
published
by
the
Spatial
Data
on
the
Web
Working
Group
as
a
Working
Group
Note.
If
you
wish
to
make
comments
regarding
this
document,
please
send
them
to
public-sdw-wg@w3.org
public-sdw-comments@w3.org
(
subscribe
,
archives
).
All
comments
are
welcome.
Publication as a Working Group Note 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.
This document was produced by a group operating under the 5 February 2004 W3C Patent Policy . W3C maintains a public list of any patent disclosures made in connection with the deliverables of the group; that page also includes instructions for disclosing a patent. An individual who has actual knowledge of a patent which the individual believes contains Essential Claim(s) must disclose the information in accordance with section 6 of the W3C Patent Policy .
This document is governed by the 1 September 2015 W3C Process Document .
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:
This
document
describes
the
results
of
the
first
steps
of
working
towards
these
goals.
Members
of
the
working
group
Working
Group
and
other
stakeholders
have
come
up
with
a
number
of
use
cases
that
describe
how
spatial
data
on
the
Web
could
work.
From
these
use
cases,
a
number
of
requirements
for
further
work
are
derived.
In
this
document,
use
cases,
requirements
and
their
relationships
are
described.
Requirements
and
use
cases
are
also
related
to
the
deliverables
of
the
working
group.
Working
Group.
The requirements described in this document will be the basis for development of the other four deliverables of the Working Group.
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
authoritative
source
of
the
definition
of
deliverables.
A
document
setting
out
the
range
of
problems
that
the
working
groups
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.
The OGC is currently working on refinements of ISO 19123 (in particular, the OGC Coverage Implementation Schema 1.1), which could result in specifications that allow a higher level of interoperability of implementations. The Working Group will also consider these forthcoming standards.
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
standardized
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.
This is really one of several future, but realistic, meteorological scenarios to aim at.
National Hydro-Meteorological Services around the world are coordinated via the WMO (World Meteorological Organization), part of the United Nations system. WMO has the same status as ISO, and its standards and regulatory materials applies to all its 193 national meteorological services and are available in the six working languages ( عربي | 中文 | Fr | Ru | Es | En). WMO has embarked on a long-term (think a decade or so) program to update the global meteorological operational infrastructure. This is known as the WIS (WMO Information System). The global infrastructure also has aviation, oceanographic, seismic and other users. The WIS includes a global, federated, synchronized, geospatial catalog, envisaged to encompass all hydro-meteorological data and services. Currently several nodes are operational, cataloging mainly routinely exchanged observations and forecasts.
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.
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
The Marine and Coastal Access Act 2009 allows for the creation of a type of Marine Protected Area (MPA), called a Marine Conservation Zone (MCZ). MCZs protect a range of nationally important marine wildlife, habitats, geology and geomorphology and can be designated anywhere in English and Welsh inshore and UK offshore waters.
The designation of a MCZ is dependent on a detailed analysis of the marine environment which results in the definition of geometric areas where a given habitat type is deemed to occur and is published as a habitat map.
Being a policy statement, it is important to be able to express the provenance of information that was used to compile the habitat map. Moreover, because the marine environment is always changing, it is important to express the time at which this information was collected.
The information includes:
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 Koubarakis
This use case is about the wildfire monitoring service of the National Observatory of Athens (NOA) as studied in the TELEIOS project. The wildfire monitoring service is based on the use of satellite images originating from the SEVIRI (Spinning Enhanced Visible and Infrared Imager) sensor on top of the Meteosat Second Generation satellites MSG-1 and MSG-2. Since 2007, NOA operates an MSG/SEVIRI acquisition station, and has been systematically archiving raw satellite images on a 5 and 15 minutes basis, the respective temporal resolutions of MSG-1 and MSG-2.
The service active in NOA before TELEIOS can be summarized as follows:
It
would
be
interesting
for
NOA
to
see
how
to
use
the
standards
developed
by
this
working
group
Working
Group
to
achieve
the
following:
This use case is further discussed in Real-Time Wildfire Monitoring Using Scientific Database and Linked Data Technologies . Some of the data used in the operational service is available separately .
Manolis Koubarakis
This use case was studied by the National Observatory of Athens (NOA) in the TELEIOS project. The burnt scar mapping service is dedicated to the accurate mapping of burnt areas in Greece after the end of the summer fire season, using Landsat 5 TM satellite images. The processing chain of this service is divided into three stages, each one containing a series of modules.
The pre-processing stage is dedicated to (i) identification of appropriate data, downloading and archiving, (ii) georeferencing of the received satellite images, and (iii) cloud masking process to exclude pixels “contaminated” by clouds from the subsequent processing steps.
The core processing stage comprises (i) a classification algorithm which identifies burnt and non-burnt sets of pixels, (ii) a noise removal process that is necessary to eliminate isolated pixels that have been classified wrongfully as burnt, and (ii) converting the raster intermediate product to vector format.
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
Working
Group
could
be
used.
Ed Parsons
This is a rather generic and broad use case, relevant to Google but clearly also relevant to anyone interested in machine processing of HTML referring to about locations and activities that take place at those locations. Local search providers spend much time and effort creating databases of local facilities, businesses and events.
Much of this information comes from Web pages published on the public Web, but in an unstructured form. Previous attempts at harvesting this information automatically have met with only limited success. Current alternative approaches involve business owners manually adding structured data to dedicated portals. This approach, although clearly an improvement, does not really scale and there are clearly issues in terms of data sharing and freshness.
The information of interest includes:
Complexities to this include multiple address standards, the differences between qualitative representations of place, and precise spatial co-ordinates, definitions of activities etc.
Ultimately these Web pages should become the canonical source of local data used by all Web users and services.
Ed Parsons
With the increasing availability of small, mobile location aware devices the requirement to identify a location human terms is becoming more important. While the determination of sensor in space to a high level of precision is a largely solved problem we are less able to express the location in terms meaningful to humans. The fact that the Bluetooth-LE tracker attached to my bag is at 51.4256853,-0.3317991,4.234500 is much less useful than the description, "Under your bed at home". At others times the location descriptions "24 Bridgeman Road, Teddington, TW11 8AH, UK" might be equally valid, as might "Teddington", "South West London", "England", "UK", "Inside", "Where you left it Yesterday", "Upstairs", "45 minutes from here" or "150 meters from the Post Office".
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
This use case is for representing the perspective of a party that is interested in publishing data on the Web and wants to do it right with respect to the geographical component of the data. The point of this use case is that it would be good to remove barriers that stand in the way of more spatial data becoming available on the Web.
A data publisher could have the following questions:
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
This use case is somewhat complementary to use case Publishing GeographicalD ata . It takes the consumer perspective, specifically that of a developer of a Web application that should visualize data and allow some kind of user interaction. The hypothetical Web application has little or no prior knowledge about the data it will encounter on the Web, but should be able to do something meaningful with any spatial data that are encountered, like drawing data on a map or rendering the data in a 3D cityscape.
The point of this use case is that in order for spatial data on the Web to be successful, supply and demand must be balanced to create a positive feedback loop. High quality data must be available in high quantities but those data must also be highly usable for experts as well as non-experts.
A Web application developer could have the following questions:
Frans Knibbe, Karl Grossner
Note this use case shares characteristics with Publishing Cultural Heritage Data .
A research endeavor that has just started tries to stimulate researchers in various fields of the humanities to make research data available in such a way that the data are and remain usable by other researchers, and that the data may be used for purposes other than those envisaged by the original researcher. The emphasis lies on spatiotemporal data because they are nice to visualize (a map with a time slider) and because it is thought that it would be interesting to try to discover patterns in time and/or space in interlinked distributed data sets.
This project has the following aspects that seem relevant to this Working Group:
Adding examples below relevant to items 2 and 3 above, from one existing scholarly Web application case, which may contribute to a more general (i.e. not necessarily historical) requirement for representing several types of uncertainty: imprecision, probability, confidence. Standards for gazetteers -particularly historical (temporal) ones- are non-existent, although several projects with potentially global reach are underway. It will be helpful to have this Working Group in dialog with developers for such projects as Pelagios , Library of Congress , Pleiades , and Past Place (cf. Humphrey Southall ).
Clemens Portele
This use is based on the European Location Framework (ELF) .
Mapping and cadastral authorities maintain datasets that provide geospatial reference data. Reference data is data that a user/developer uses to provide location for her own data (by linking to it), by providing context information about a location (overlaying his data over a background map), etc.
A key part of this is persistent identifiers for the published data to allow linking to the reference data. Let's assume that http URIs following the Cool URI note are used as identifiers.
In ELF — and INSPIRE — reference data is typically published using a Web service by the national authority. In ELF this is an OGC Web Feature Service. To provide access to the different datasets via a single entry point, all the national services are made available via a proxy Web service that also handles authentication etc. In addition, it is foreseen to publish the reference data in other commonly used Web-based platforms for geospatial data to simplify the use of the data - developers and users can use the tools and APIs they are familiar with.
As
a
result,
the
same
administrative
unit
(to
pick
an
example)
is
basically
available
via
multiple
(document)
URIs:
via
the
national
Web
service,
the
ELF
proxy
Web
service
and
Web
services
of
the
other
platforms.
Different
services
will
support
different
representations
(GML,
JSON,
etc).
etc.).
The
Web
services
may
not
be
accessible
by
everyone
and
different
users
will
have
access
to
different
document
URIs.
Which real-world object and document URIs for the administrative unit should be maintained and what does a GET return in order:
A
related
challenge
is
that
today
such
links
are
often
implicit.
For
example,
a
post
code
or
a
statistical
unit
code
is
a
property
in
the
other
data,
but
the
link
is
not
explicit
like
an
HTTP
URI.
What
is
a
good
practice
to
make
use
of
such
implicit
links?
Should
they
be
converted
to
HTTP
URIs
to
be
explicit
or
are
there
better
ways
(e.g.
additional
context
that
provide
information
about
the
semantics
and
a
pattern
how
to
construct
dereferencable
dereferenceable
URIs)?
Frans Knibbe
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.
Bart van Leeuwen
During
emergency
Emergency
response
operations
services
in
the
Netherlands
the
only
spatial
data
available
use
Spatial
Data
Infrastructures
(SDI)
to
emergency
response
services
is
the
predefined
help
manage
large
scale
incidents.
Predefined
geographical
data
in
from
their
GIS
warehouses.
Because
warehouses
can
be
used,
but
incidents
and
accidents
handled
by
emergency
response
services
are
by
nature
unpredictable
so
it
is
impossible
to
determine
beforehand
which
data
are
needed.
Ad-hoc
In-house
data
on
the
Web
need
to
be
supplemented
with
a
spatial
component
available
are
not
easily
used
right
now,
neither
can
the
available
data
about
a
incident
be
easily
shared
from
other
sources
based
on
the
Web.
ad-hoc
requirements.
Typically,
supplemental
data
are
available
through
WxS
services.
This
poses
several
problems:
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)
What: The local authorities of Zaragoza (Spain) want to publish the air quality data of the city. Each observation station has a spatial location described with an address. The dataset contains hourly observations and daily aggregations of different gases, e.g. SO 2 , NO 2 , O 3 , CO, etc.
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]
A description of the data set, including its SPARQL endpoint, can be found at https://www.zaragoza.es/ciudad/risp/detalle_Risp?id=131 .
Alejandro Llaves (OEG-UPM)
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.
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.
For
example,
Ordnance
Survey
linked
data
uses
British
National
Grid
SRS
CRS
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
coordinate
reference
systems
will
be
an
important
part
of
this
metadata
description.
A
recommended
canonical
SRS
CRS
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.
A lot of these have geospatial content or refer to geospatial resources in other base registries (such as addresses). At the moment these references are informal and often incorrect or outdated. This means there is a need to express geospatial content in linked data (i.e. a standard vocabulary) and to perform spatial queries over linked data.
Geometries, especially lines and polygons, may contain many coordinates. For example, a municipal boundary could easily contain more than 1500 coordinate pairs. Compared to non-geometric properties, this can result in large amounts of data to transfer and process. The coordinates can easily be 95% of all data of an object when using polygons. The question rises whether there is a need for performance optimization and/or compression techniques for large amounts of coordinates. If so, there could also be a need to standardize such a technique, similar to the PNG format for encoding images.
Coordinate reference systems (CRS) are to geo-information what character encodings are to text. If you don’t know which CRS is used, you can’t use the coordinates. Different CRSs exist for a reason: localized CRSs provide more precise coordinates for a certain part of the globe. It is not possible for a global CRS to be as precise, for example because the continental plates move a few centimeters every year. For large scale data and applications this continental drift could be very relevant over time. Take for example the boundary of cadastral parcels. If this drift is not taken into account, there could be issues if parcel boundaries that were established e.g. 10 years ago are overlaid over recently acquired aerial imagery with high accuracy (e.g. 10 cm). There could be visual differences, while the actual situation did not change.
While the possibility to use different CRSs hinders interoperability (datasets using different CRSs cannot be easily combined, a complex transformation is necessary), on the other hand this option is perhaps needed for use cases where a high precision of coordinates is important. The BGT (large scale topography) is an example of such a use case.
A prototype application, based on linked data, where BGT, BAG, NHR and WOZ data is combined, is here . BAG linked data is here (“Begrippen”: the vocabulary; “BAG Data”: the data)
Lars G. Svensson
Cultural Heritage Data such as library authority files are increasingly being published as Linked (Open) Data. Those datasets contain, among other entities, descriptions of spatio-temporal events such as World War I , the Birth of Albert Einstein (date and place) or Martin Luther's pinning of his 95 theses . The problem is that most of the spatio-temporal information is inexact. This inexactness ranges from time spans ( second quarter of the 9th century , e.g. approx. 825-850, which also could be 823 or 852) to geographic entities such as Renaissance Italy (what did Italy look like at that time, and to what extent is the Italian renaissance as a time period different from the English?).
When cultural heritage institutions put their data on the Web, the staff members mapping their data to Web standards often do not have expertise in temporal or geospatial data formats. Formats such as WKT are standardized but it is difficult to know if the mapping from the local data source is done correctly. A validator for commonly used formats such as WKT or GeoJSON would prove helpful.
Challenges include:
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
usable
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
If there existed a best practice or standard way of publishing this sort of data then it would encourage development of applications on the Web to handle them. The datasets that BGS is generating are:
Rachel Heaven
The UK Government is funding a new Energy Security and Innovation Observing System for the Subsurface (ESIOS). ESIOS will consist of a group of science research facilities where new subsurface activities such as fracking (hydraulic fracturing) for shale gas can be tested and monitored under controlled conditions. This research will address many of the environmental issues that need to be answered for the development of the UK’s home-grown, secure energy solutions. This includes carbon capture and storage, geothermal energy, nuclear waste disposal, underground coal gasification and underground gas storage.
Data will be collected from monitoring boreholes and from surface, airborne and satellite sensors. The raw scientific data will be published freely online, possibly in real-time or near real-time, to encourage transparency and public confidence in the industry, and to provide underpinning science for regulation.
The scientific data will consist of:
We want to be able to publish this raw data on the Web in such a way that it can be easily consumed by third party Web applications for visualization, spatio-temporal filtering, statistical analysis and alerts.
(Another similar use case is for publication of geomagnetic monitoring data, for which the primary outputs are time series tables or graphs, and the location data for the observation station is relatively simple and low accuracy)
Rachel Heaven
BGS
The
British
Geological
Survey
(BGS)
has
valuable
geoscience
data
in
text
form
dating
back
180
years,
which
is
gradually
being
scanned
and
OCR
to
make
it
more
accessible
and
searchable.
Much
of
the
information
in
the
reports
concerns
observations
or
interpretations
made
at
a
location
or
about
a
named
geological
feature.
We
would
like
the
relevant
information
in
those
documents
to
be
retrievable
from
a
Web
search
using
coordinate
limit
criteria
or
using
a
place
name
criteria,
so
this
use
case
requires
a
place
name
ontology
(or
federated
ontologies).
For BGS's purposes the ontology should contain historical place names, named subsurface geological features (e.g. Widmerpool Gulf), palaeogeographic place names, and named submarine features (e.g. GEBCO undersea feature names ).
To extend the capabilities into the vertical dimension then the ontology should also contain the names of qualitative earth realms (vertical divisions within the atmosphere, ocean and solid earth – such as in the SWEET ontology ).
To extend the capabilities into the time dimension then the ontology should also contain the names of historical and geological time periods (e.g. https://www.seegrid.csiro.au/wiki/CGIModel/GeologicTime#GeologicTime_XML , used in a recent example of geological age name parser at http://www.agenames.org )
With a resource like this, all text resources could be parsed to locate them in time and space.
Each named feature should have a spatial attribute, either as topological relations to other named features, or as spatial-temporal extent appropriate for various scales and with appropriate uncertainties (i.e. fuzzy definitions of geometry and time periods). Versioning will be important e.g. for administrative boundaries that change frequently.
(NB Geonames goes much of the way to meeting this requirement)
Cory Henson (Bosch RTC)
Consider the following wildly-fictional scenario: Sue is driving to work in the snow on a cold Pittsburgh morning. On entry, her car recognizes the cold weather and automatically heats the interior to Sue's preferred temperature and turns on the defrost to clear the frost from the wind-shield. On the way, the snow causes significant traffic delay on her route forcing her to re-schedule an early morning meeting. In response, the car suggests she stop at her favorite nearby coffee shop for a Flat White until the roads are clear.
The scenario above requires access to multiple types of observation, spatial, and temporal data which may be local to the car or available on the Web.
The different types of observation data may include:
The different types of spatial data may include:
The different types of temporal data may include:
In addition, the car uses light-weight communication protocols, such as CoAP and/or MQTT, to exchange data (i.e., observations, spatial, and temporal data) between networked components.
This scenario may face the following general challenges for representing, managing, and querying observation data:
Antoine Zimmermann
Intelligent Transportation Systems (ITS) can be defined as the application of advanced information and communications technology to surface transportation in order to achieve enhanced safety and mobility while reducing the environmental impact of transportation. The addition of wireless communications offers a powerful and transformative opportunity to establish transportation connectivity that further enables cooperative systems and dynamic data exchange using a broad range of advanced systems and technologies. - See more at: http://www.its.dot.gov/standards_strategic_plan
ITS do so by exploiting information from various origins, especially the Web. Several Web sites, Web services, datasets related to public transport services, traffic, road network structure, localized incidents, and so on have to be exploited in order to convey users with the best decisions, in real time. All of these information sources rely considerably on spatio-temporal data. The challenge is to model dependency in both space and time seamlessly and simultaneously so that the accuracy of analysis can be improved (for instance for regulation of multimodal transportation network) or the processing of aggregated information can be simplified (for instance for multimodal traveler information system). For such systems to work well in a pervasive way, it is also important that the system can easily discover relevant datasets/services based on the user current location.
Consequently, such systems would greatly benefit from standardized formats, standard practices for publishing or making spatial data available online. A standard way of indicating time and time frames would also help correlate several temporally situated entities such as bus schedules, real time bus position, and traffic light durations.
A specific type of ITS is Advanced Traveler Information System (ATIS) that computes an accurate travel duration. To do so, ATIS should be able to combine data following different spatio-temporal scales. These data could be related to the current or anticipated network traffic (the congestion level), the network topology (number of lines on the routes, presence of traffic lights, etc.), the presence of expected events (which can be static, like work on the road, or dynamic like demonstrations), the weather state (the presence of rain or mist on a part of the itinerary), and so on.
ITSs can also be dedicated to the management of parking spots. For a driver, the choice of its parking spot is a multi-criteria decision process that takes into account static data given by the description of the infrastructure (whether the spot is private or public, reserved for disabled, etc.), dynamic data given by sensors (like traffic) and personal data (destination, budget).
Antoine Zimmermann
In smart grids, energy management has to take into account the fact that any energy consumer may also be a producer (they are thus "prosumers"). This leads to new load balancing problems as well as new forms of economic exchanges regarding selling and buying energy. In order to take an informed decision on what amount of energy to buy from whom at what cost, or to sell, decision algorithms must use information that can be local (their own consumption and production), global (statistical data on seasonal household energy consumption), and possibly external to grid (meteorological data). In such context, reliance on Web data from several sources adds real value to the decision process.
The kind of data that has to be considered are, for the most part, highly fluctuating: weather for assessing heating needs, stock exchange for pricing appropriately, current and future offer and demand, etc.
There is a need for a temporal model that covers historical data for statistical analysis, short term timestamped sensed data, and data about future predictions.
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
Working
Group
as
it
relates
to
geographic
and
spatial
features
geometries.
Wheresoever
Wherever
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:
This additional information supports a broader need for SSN, Coverage and Time considerations for the above three current use cases.
Chris Little (on behalf of Andrew G Hughes, British Geological Survey)
During the period 2011-2013, the UK faced an extraordinary drought only to be saved from a likely major crisis by very high spring and summer rainfall (CEH, 2012). Government asked questions such as “how much water is left in the tank?”, at which point managers and regulators realized that they didn’t know the answer with any certainty (EA, 2012). A National Drought Group of leading stakeholders was formed and led by the Chief Executive of the Environment Agency (EA) reporting to the Secretary of State for Environment, Food and Rural Affairs. The whole of the UK was affected, but the south-east most severely because of the lower rainfall and high water demand.
When will London run out of water? How socially accepted is drought and associated water restrictions to the general public? When will water company groundwater sources begin to switch off? Questions like these are critical for drought management, but often the science is not sufficiently advanced to address them, and where it is, not fully integrated to satisfactorily answer them.
The River Thames Basin is home to 13 Million people, considerable industry and valuable aquatic ecosystems all of which require the effective and sustainable management of the water environment in the basin to thrive. A thorough understanding of the hydrology of the basin is vital to underpin this management to ensure the best use of resources. This is particularly important given the twin pressures of increasing water consumption and climate change. The groundwater system of the Thames consists of around 12 aquifers most of which are not hydraulically connected, except via the River Thames and its tributaries. These aquifers are locally very important for water supply and their provision of base flow sustains the ecology of the river system in dry summer periods and droughts.
To properly simulate the system then a good geological understanding has to be translated into a hydrogeological knowledge and then simulated. This is not a straight-forward task. The important elements of the system include: 3D geological understanding encapsulated into a geological model, dynamic model of the surface processes, groundwater and river systems along with a model of water supply (e.g. IRAS; Mastrosov et al., 2010). This will ultimately involve:
The aim would be to develop an integrated system that can address the question “When will water company groundwater sources begin to switch off” or similar.
Simon Cox (on behalf of Peter Wilson, Bruce Simons @ CSIRO)
Simon Cox (on behalf of Paul Box, Simon Cox and Ryan Fraser @ CSIRO)
This user story covers a number of interrelated use cases:
A bush-fire is underway in Blue Mountains NSW. An incident management team has been established, with an incident controller from NSW Fire and Rescue in charge, based in a coordination centre. She notices that the Twitter analytics feed has flagged a Tweet that mentions a fire in ‘Springwood’. The location of the Tweet shows on the incident map as being in the ‘Blue Mountains’ – (this location is a geocode of place name used in the Tweeter’s Profile). The watch officer enters ‘Springwood’ [uc1] in a multi-gazetteer index and gets 41 hits for Springwood in Australia. She zooms to the Blue Mountains and sees there are 13 places called Springwood. These results include a school, a number of rural properties, and an official suburb named Springwood [uc2] near which most of the other places are located. The officer selects the suburb name in the National Gazetteer, and the map zooms to the bounding box for the selected place [uc3]. The controller wants to find more detailed information about the place and clicks on its identifier (a URI for the place). The user is provided with information about:
An official report of the fire location now also appears on the screen, from a fire service operator on the ground. With the fire location now confirmed, the priority is to identify the areas at risk, and assess community impact, locate possible evacuation centers and set in place evacuation plans.
A fire spread model has been run using reported fire location. An impact analysis and evacuation plan is being developed. The predicted fire spread polygon is shown on the incident map. To assess affected population the analyst needs to find population geography and data. [uc5]
The Springwood place landing page has a link to get information about the data source [uc4]. This is the national gazetteer, which provides bounding box geometries only. This is not accurate enough for her analysis. Returning to the graph of linked resources, the analysis determines that the gazetteer entry has a synonym in the ASGS [uc7.1]. She clicks on this and sees it’s the census geography for the same place (Springwood suburb) [uc4]. She finds the data source link which she discovers uses polygonal geometry and adds this as a service to her map.
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
Geological samples are retrieved from the field and then processed in the laboratory to determine various properties, including chemistry, mineralogy, age, and petrophysical properties like density, porosity, permeability.
Samples obtained as part of economic activities, such as mineral exploration, are usually processed in commercial assay and chemistry labs. For QA/QC purposes, each batch of samples will have a number of control samples inserted, for which the concentration of particular chemical species are already known. For confidentiality reasons the location information associated with each sample is not provided to the lab, but must be re-attached during the interpretation phase. During processing, many derived samples will be generated by various physical and chemical procedures. In some cases the derived samples are strict sub-samples, whose intensive properties are intended to be the same as the parent. In other cases, the split is 'biased', with the derived sample intended to select a specific sub-sample, defined by a particular particle size, density, magnetic properties, etc. The link from the derived sample to the parent sample must be preserved, and the link from the parent to the location from which it was obtained also. In some cases the location is associated with another sampling artifact, such as a drill-hole or traverse or cruise, with the latter carrying the detailed location information.
In a research context some samples have a particularly high-value, having been obtained by an expensive process (involving drilling or ships or spacecraft) or from a location that is hard to visit (remote, offshore, in space). These samples are sometimes sub-divided and distributed to multiple research teams or labs for different specialized observations. Each lab will run its own LIMS system, which will usually assign a local identifier for the sample. When the results of these observations are reported, it is necessary that observations from different labs can be correlated with each other, so that the complete picture around each sample can be assembled.
These stories focus on sensing applications involving ex-situ sampling, where a location is visited and a specimen obtained using some sampling process, then transported to one or more laboratories where it is processed into one or more sub-samples and various observations made. Sample identity is usually key, and the relationships between samples, between samples and other artifacts of the sampling process, and also with other geographic features or locations. The sampling time and analysis and reporting time are all different.
Similar process apply to botanical sampling, and to environmental sampling (water, air, dust).
Simon Cox
Most observations are made on samples that are selected to be somehow representative of the feature of ultimate interest which is being characterized. The sample may be statistical, or related to accessibility, or may be of a proxy phenomenon which can be related to the property of ultimate interest.
In environmental observations, certain spatial distributions are commonly used across multiple disciplines, such as
These may be related to each other (samples taken along a drill-hole, stations on a traverse, shots along a seismic section) and the relationships provide a kind of 'topology' of sampling which assists access and processing. Sampling features may also be associated with other organizational structures, such as cruises, field trips, campaigns, projects, missions, orbits, deployments, platforms, which are used for discovery and for navigation within a datasets. Sampling strategies are often combined with an observational procedure or instrument to define a standard 'protocol' for observations. The protocol may be identified by name.
Additional comment by Rachel Heaven:The locations within a spatial distribution may have a different degree of certainty with respect to each other than the positional certainty of the spatial distribution as a whole e.g. the ends of a sampling traverse may be known in a national or global coordinate reference system to +/-5m accuracy; soil samples may be taken along the traverse at every 1m +/-0.01m interval, or species sightings that need to be re-visited may be described in real world terms such as "half way up the burn on the left hand bank". Similarly, measurements taken down a drill hole are known accurately in down hole depth with respect to the drilling datum, but less accurately in true vertical depth and with respect to a national vertical datum. If the hole deviates from vertical, the absolute location will be even more uncertain.
Bill Roberts (based on needs arising from Swirrl's own work)
Statistical data is frequently referenced against geographical regions. A common requirement is to select a collection of non-overlapping regions with complete coverage of a 'parent' region (a 'Mutually Exclusive Collectively Exhaustive' - MECE - set). This might be used for data aggregation: given the population statistics for all council areas in Scotland, calculate the population of Scotland.
Or it might be for data visualization: retrieve data on average house prices for all parliamentary constituencies in the UK, then combine this with polygons of the constituency boundaries and use it to draw a choropleth map.
Although geographical data frequently includes 'contains' or 'within' relationships between larger and smaller areas, this is not sufficient for the above use cases. A larger area can be broken down into smaller areas in a variety of ways. Sometimes a combination of 'contains' relationships and knowledge of the 'type' of region can be enough: it may allow separating out a particular level in a geographical hierarchy. But that doesn't allow for cases where regions of a particular type don't have full coverage of the parent. An example is 'parishes' in England. The collection of all current parishes is non-overlapping, but it is not exhaustive. Some locations are not in any parish.
The variation of administrative, statistical and political geography over time is also an issue. A particular division of a region into sub-regions may be valid only for a specific period. For example, council boundaries change from time to time. At any given time, there is a MECE set of council boundaries in a region, but the boundaries change occasionally, so if analyzing data on English councils from 2014, a different set of areas is required than would be needed for say 2012. 2012 might involve areas A,B,C,D,E,F whereas 2014 requires A,B,C,D,G,H. A similar issue arises when dividing Europe up into countries for example.
These are common problems and there are probably many separate solutions already in active use. It would be useful however to have a standardized vocabulary to represent these kind of relationships, which would increase the interoperability of data analysis tools.
Kerry Taylor (informed by Matt Paget and Juan Guerschman, CSIRO)
Vegetation fractional cover is a key metric for monitoring land management, both in pastoral and agricultural settings. The aim is to estimate the fractions of photosynthetic and non-photosynthetic vegetation and the remaining fraction of bare soil. Fractional cover is computed from both Landsat and MODIS satellite surface reflectance products but calibration and validation via ground-based observations is also needed.
The method for computing fractional cover was developed by comparing geo-aligned Landsat sensor and two MODIS-derived surface reflectance products. Scaling issues associated with different sensors and spatial resolutions were addressed, along with locally-measured effects of soil color and soil moisture.
Source Data:
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] .
Now, this fractional cover coverage product over Australia is computed monthly and distributed by the NSW government , where it is used for their Dustwatch program amongst other things. The Dustwatch program publishes monthly (PDF) reports of wind-related erosion and groundcover change.
[1]
Guerschman
et
al,
"Assessing
the
effects
of
site
heterogeneity
and
soil
properties
when
unmixing
un-mixing
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 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 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)
Also see additional stories in un-edited emails .
Linda van den Brink (with thanks to Henk Schaap - Gobar)
The Dutch organization Rijkswaterstaat is responsible for the practical execution of the public works and water management, including the construction and maintenance of waterways and roads, and flood protection and prevention in the Netherlands. The following is a use case about sharing Rijkswaterstaat information to support building processes.
A part of a highway is in need of a new tarmac layer. This involves a lot of information sharing between the contractor (Rijkswaterstaat), the organization responsible for organizing the project and the organization responsible for carrying out the maintenance work. Building Information Management (BIM) is used for this and the data is published via a Webserver.
The information being exchanged is asset management information, i.e. the location of the roads, tunnels, bridges, aqueducts, railway lines, surrounding terrain and water bodies involved (geometric information). In addition, non-spatial information is important, like the layers of material the road consists of, when it was last maintained etc. The spatial information is not only shared as 2D geometries: (detailed) 3D information is also used in the building process. The area involved contains about 9.000 relevant physical objects (about 100 different object types) and about 2.000 spatial objects that relate to the traffic network, about which information is exchanged.
Kerry Taylor (on behalf of Aaron Sedgmen of Geoscience Australia)
Geoscience
Australia
(GA)
maintains
an
archive
of
Landsat
5,
7
and
8
satellite
imagery
over
the
Australian
continent
from
1986
to
present.
The
Australian
Reflectance
Grid
25
(ARG25)
dataset
produced
from
the
Landsat
archive
is
a
collection
of
approximately
184,000
individual
Landsat
5
and
Landsat
7
scenes
processed
to
the
ARG25
specification.
The
ARG25
data
are
available
to
the
public
as
file
downloads
and
OGC
Web
services.
The
ARG25
collection
can
be
searched
using
an
OGC
Catalogue
Catalog
Service
(CSW)
containing
ISO
19115
metadata
for
each
scene.
Note
that
the
ARG25
data
services
are
expected
to
be
superseded
by
the
Australian
Geoscience
Data
Cube
when
it
becomes
publicly
available.
The
ARG25
data
services
were
promoted
for
use
at
the
2013
and
2014
Australian
GovHack
events,
a
competition
aimed
at
mainstream
(i.e.
largely
non
geoscience/geospatial
specialist)
Web
and
application
developers,
to
mashup,
reuse,
and
remix
open
government
data.
The
predominant
use
case
for
the
ARG25
data
at
GovHack
has
been
to
perform
spatiotemporal
searches
on
the
catalogue
catalog
for
an
area
of
interest,
retrieve
and
subset/stitch
scenes
from
the
Web
services,
and
provide
an
animated
time
sequence
of
the
imagery
to
allow
users
to
visualize
changes
in
land
cover
over
time,
e.g.
“show
me
how
my
town
has
grown
over
the
last
10
years”.
The relative complexity and richness of the OGC/ISO Web service APIs and data exchange formats presented a barrier to developers who were accustomed to lighter weight APIs and formats optimized for rapid integration and mashing up of data in mobile and browser based applications. As a result, uptake of the ARG25 data at GovHack was less than hoped for, and we see this as indicative of the mainstream Web app development community in the real world.
GA has had much success with OGC and ISO standards in the sharing of data with government, research and industry partners and clients who are power users of spatial data and savvy in the standards. The less traditional users who are not spatial data specialists are less likely to access GA’s data delivered using OGC and ISO standards, and this is a section of the user community that can potentially apply the data to highly innovative and entrepreneurial uses.
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)
Geoscience Australia (GA) collects and curates Australian national geoscience and geographic data sets, for use by government, industry and the community. Following is a typical requirement of a user of GA data - “A mineral exploration company is collating published geological data for their mining lease. They are particularly interested in sample locations where gold ppm values are above 0.1ppm, occurring in greenstone, located on or near a fault line, and aged around 2.6 Ga”.
Users
are
able
to
perform
structured
searches
for
GA
datasets
at
the
collection
level
using
catalogues
catalogs
of
ISO
19115
metadata.
The
collection
level
metadata
provides
users
with
download
links
to
the
packaged
datasets,
and
in
limited
instances,
links
for
accessing
the
data
via
Web
services
and/or
applications
that
provide
visualization
and
GIS
analysis
capability.
To
perform
fine
grained
searches
within
the
dataset,
such
as
feature
level
searches
(e.g.
show
me
sample
locations
in
the
OZCHEM
database
with
gold
ppm
>
0.1),
users
must
download
the
packaged
datasets
to
their
local
environment
and
use
their
own
tools
to
search
through
the
data.
Web
services
providing
data
access,
e.g.
WFS
,
WFS,
and
Web
applications
with
GIS
capability
served
by
GA,
e.g.
the
Rock
Properties
Explorer
app,
can
provide
some
capability
for
searching
within
data
collections.
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)
Geoscience Australia (GA) collects earthquake observation information from the general public to improve its knowledge base of the impact of earthquakes across the Australian continent. An online HTML form is available on the GA Website for members of the public to report their experiences of earthquake events. Information collected includes the person’s location (both geographic and within a building), time of event, perception of intensity and observed effects on the built environment. The information provided by the public is rated against the Modified Mercalli Intensity (MMI) Scale and is used to improve the accuracy of shake maps for earthquake prone regions of the country. This feeds into GA’s understanding of exposure of the Australian built environment to natural disaster, and is used for disaster mitigation purposes including the determination of minimum building codes for various regions of the country.
There is potential for GA to improve the efficiency by which it obtains earthquake observation information from the general public by leveraging popular social media services (such as Twitter), and adopting common standards and best practices for collecting crowdsourced information.
Erich Bremer
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.
Samples of TCGA WSI data can be viewed at: http://cancer.digitalslidearchive.net
Kerry Taylor with Zheng-Shu Zhou, CSIRO
Space-borne Synthetic Aperture Radar (SAR) observations are coming on line rapidly over the next few years. SAR signals are represented in 2D space but can be processed to point observations in 3D space, or to 3D triangulated surfaces using polarimetric and phase information. A compelling use case for SAR data is crop classification, i.e., identification of cereal crops (wheat, barley, rice etc.), through analysis of the radar backscatters and polarizations over the variable-height surface and volume of the crop.
Multispectral (e.g. Landsat or MODIS) satellite imagery has been widely used to estimate vegetation cover and growth rates. It seems that combining SAR derived crop-type observations with Landsat-derived vegetation estimations could be used to estimate crop yields throughout the growth cycle. In principle, access to such data is open, but in practice it is difficult to get hold of and difficult to process for anyone other than well-connected scientists in developed nations. How could this data be opened up to a bigger community to help solve this problem, perhaps aided by reference to local knowledge?
We might expect that this will be used to assist in logistics and market planning in developed countries, and for food security in developing and war-torn nations.
Andrea
Perego
(
Perego,
European
Commission
-
Commission,
Joint
Research
Centre
(JRC)
)
DCAT-AP
(DCAT
application
profile
for
data
portals
in
Europe)
is
a
metadata
interchange
format,
based
on
and
compliant
with
the
W3C
Data
Catalog
vocabulary
(DCAT)
,
defining
a
minimum
set
of
metadata
elements
designed
to
ensure
cross-domain
and
cross-border
interoperability
across
European
data
portals.
Work
is
under-way
for
In
order
to
achieve
this,
DCAT-AP
consists
of
a
development
"core"
profile,
including
a
set
of
an
extension
aiming
at
defining
metadata
elements
commonly
used
across
domains,
whereas
domain-specific
requirements
are
addressed
by
a
DCAT-AP
compliant
representation
set
of
geospatial
metadata,
"extensions".
One
of
them,
referred
to
as
GeoDCAT-AP
.
GeoDCAT-AP
will
build
on
preliminary
work
concerning
the
alignment
of
INSPIRE
metadata
with
DCAT-AP
(referred
to
as
INSPIRE
+DCAT-AP)
.
The
objective
,
is
specifically
designed
to
consolidate
this
work,
and
to
extend
it
provide
a
DCAT-AP
compliant
representation
of
geospatial
metadata.
More
precisely,
GeoDCAT-AP
extends
DCAT-AP
in
order
to
cover
the
set
of
metadata
elements
corresponding
to
the
union
of
the
INSPIRE
metadata
schema
and
the
core
profile
of
ISO
19115.
19115:2003
.
Methodologically,
GeoDCAT-AP
will
be
has
been
designed
based
on
the
following
requirements:
The
requirement
for
point
(2)
is
was
to
identify
an
RDF
representation
of
elements
missing
in
DCAT-AP
that
can
be
re-used,
if
relevant,
in
other
domains.
E.g.,
elements
domains
-
as
those
concerning
data
quality
(e.g.,
conformity,
topological
consistency)
and
granularity
(e.g.,
spatial
/
temporal
resolution),
two
notions
not
supported
in
DCAT-AP
(nor
in
DCAT).
This
implies
implied
that,
in
many
cases,
there
may
be
has
been
the
need
of
relaxing
the
ISO
19115
specification
whenever
it
may
be
was
a
barrier
to
re-use.
Another
key
design
principle
is
was
related
to
the
fact
that
GeoDCAT-AP
is
not
meant
to
be
a
replacement
of
ISO
19115
/
19139,
but
an
alternative
representation,
built
on
a
set
of
harmonized
mappings.
mappings,
enabling
sharing
and
re-use
of
geospatial
metadata.
For
this
reason,
the
principle
is
that
any
ISO
19115-conformant
metadata
record
could
be
transformed
into
a
GeoDCAT-AP
one,
but
the
opposite
is
was
not
a
requirement.
Issues
to
be
addressed
include
identified
during
the
following:
development
of
GeoDCAT-AP,
highlighted
that
the
effective
cross-domain
and
cross-platform
sharing
and
re-use
of
geospatial
metadata
is
undermined
by
the
lack
of
best
practices
concerning:
Related use cases:
Andrea
Perego
(
Perego,
European
Commission
-
Commission,
Joint
Research
Centre
(JRC)
)
Use case based on work presented at INSPIRE 2014 by Adam Iwaniak (Wroclaw University of Environmental and Life Sciences, Poland)
Geoportals offer effective discovery functionalities for specialists. However, as in most data portals, using basic free text search is usually far from being a satisfactory experience. Actually, users (both non-experts and specialists), when searching for data, are frequently making use of popular search engines as a first step to get to the data they are looking for.
Improving free text search in (geo)data portals is unlikely to address this issue. Moreover, it would not help users who do not know in which portal(s) the relevant data are available. Users will keep on using in any case search engines for this purpose.
An option would be optimizing geoportals for Web discovery, by implementing consistently SEO (Search Engine Optimization) techniques. The advantages include (but are not limited to) the following:
Best
practices
for
publishing
geospatial
metadata
on
the
Web
should
be
recommended.
This
includes,
for
example,
standard
serialisations
serializations
of
geospatial
metadata
in
formats
and
vocabularies
used
by
search
engines
to
index
Web
resources
-
e.g.,
RDFa,
Microdata,
Microformats
Related use cases:
Erwin Folmer, Dutch Cadastre (via public-sdw-comments@w3.org)
The European INSPIRE directive leads to the availability of many datasets with geographical aspects. Unfortunately the burden for data providers to comply with INSPIRE is high, which leads to the potential danger that the means ( INSPIRE ) becomes more important than the end (to have interoperable data). For many data providers the sole purpose is to state that they are INSPIRE compliant. This limited but understandable approach of data providers results in potential users being overlooked. Implementations of more user-friendly Web-related solutions will be very difficult and limited in the next few years, unless we find a (documented, proven and accepted) way to comply with INSPIRE by using Web standards (Linked Data).
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
Events
are
geographic
phenomena.
They
comprise
activity
associated
with
particular
locations
on
the
earth
Earth's
surface,
and
their
participants'
locations
and
attributes
over
time
are
integral
to
their
analysis
as
well
as
their
indexing
in
information
systems.
Event
participants
may
be
human
and
agentive
or
not
-including
for
example
objects
present
at
or
resulting
from
activity,
or
natural
phenomena
like
hurricanes
or
earthquakes.
In addition to class or type, and the nature of their participants, essential descriptors for events include their static or dynamic location(s) and temporal extents, described with spatial and temporal reference systems. Location may be static or dynamic. Static events routinely modeled include crime, mortality, battles, performances, etc. Temporal extents may be modeled as instants or intervals, in cases aggregated as "multi-instants" or "multi-intervals."
Although it is inherently difficult to model dynamic phenomena, there are many compelling reasons to do so. They can be conceived variously, as processes modeled as sequences of discrete events or as functions. Examples include: trajectories of people in commercial activity, journeys, battles, and biographical "life-paths."
From a spatial perspective, many places are essentially dynamic and modeling these is a core challenge in historical and cultural heritage applications. The size and shape of political entities changes over time; they grow, shrink, split, merge, disappear, reappear, etc. The point being their spatial extent is directly bound to time. Historical periods are considered as 'place-at-period' - for example there is not a simple "Bronze Age" period, rather "Bronze Age Britain" and "Bronze Age Southern Levant."
Taken together these share a requirement to consider space and time together.
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
National Meteorological Services (NMS), such as Met Office , maintain a network of weather observation sites within their region of responsibility in order, amongst other things, to provide input to their numerical weather prediction models. The cost of maintaining these weather observation sites means that their number is limited.
Within the UK, and likely in other places too, there is a high demand for weather observations for specific locations. To meet this demand, the Met Office provides data for many more locations than the number of weather observation sites they maintain. In order to do this, “virtual observations” for these locations are derived from the “analysis” of the numerical weather prediction model. (“Analysis” is the term used to describe the initial state of the numerically modeled atmosphere from which the forecast is calculated; it incorporates real observations and provides a dynamically balanced representation of the atmosphere at a snapshot in time.)
The metadata needed to provide context to a “virtual observation" is identical to that for normal observations; albeit that the procedure used to create the observation involves a computational simulation rather than a physical sensor and stimulus. Clearly, it is important to provide information about the procedure used to create the observation so that “real” observations can be distinguished from “virtual” observations.
Stefan Lemme, DFKI/Saarland University
This
use
case
relates
to
4.8
Consuming
geographical
data
in
a
Web
application
and
maintains
the
bridge
to
3D-web
3D-Web
applications
(without
targeting
the
actual
rendering
process,
which
is
out
of
scope
for
this
Working
Group).
Visualizing geospatial data, such as geo-referenced 3D geometry of buildings, 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 the W3C did previous work to determine the requirements, options, and use cases for 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)
The CityPulse project has identified 101 smart city scenarios and related use-cases in cooperation with partner cities and the City Stakeholder Group in the project. The scenarios are made available online for the wider community to rank the use cases. The scenarios are available online . A Large set of semantically annotated datasets collected from partners of the CityPulse EU FP7 project and relevant resources for smart city data are also available . The annotation tool for the datasets can be found here .
In "101" Smart City use cases, each scenario is described in a short narrative and is ranked based on stakeholder needs and community groups by completing an online survey. The following lists top three ranked scenarios from the use cases. The complete list and details of the ranking and scenario evaluations are described in M. Presser et al, Smart City Use-cases and Requirements .
Bruce Bannerman (Australian Bureau of Meteorology)
This use case is inspired by one of the conclusions of the UK Parliamentary inquiry into ClimateGate "...It is not standard practice in climate science to publish the raw data and the computer code in academic papers. However, climate science is a matter of great importance and the quality of the science should be irreproachable. We therefore consider that climate scientists should take steps to make available all the data that support their work (including raw data) and full methodological workings (including the computer codes...)." When a climate scientist publishes a paper, he needs to be able to refer reviewers to the source data and software source code that underpins the assertions made within the paper. Climate data are typically time-series and can be quite complex. Data can be sourced from a single National Meteorological and Hydrological Service (NMHS), or from a number of NMHS. Software source code is typically stored within a software revision control repository, such as git.
Climate data may comprise all of the following:
So using the description of climate data above, when a paper is published, the scientist needs to be able to refer viewers to:
This is not a trivial data management problem to address, however its resolution will provide a solid data management grounding for future climate science and help address much spurious debate. Parts of the puzzle are currently being worked on, e.g.:
The missing part is: How can the provenance of the collection of climate data and the software used to manipulate it be best modeled and in the future, found via the Internet? The resolution of this issue will be of relevance to many domains.
Phil Archer on behalf of the SmartOpendata project
Beginning in late 2013, the EU-funded SmartOpenData project carried out a number of pilots examining the potential of Linked Data for environmental and rural issues, particularly in National Parks. One aspect of the project required parts of the European Union's INSPIRE data model to be represented in RDF and used across the different pilots.
The INSPIRE data model is large, complex, and designed for use in a Geospatial Information System and not for Linked Data. Initially, the model was followed directly, creating classes and properties that exactly matched those in the original INSPIRE model. However, this produced cumbersome RDF that was hard to use, was difficult to link to other data points, and offered no advantage over the original. It was using Linked Data for the sake of it.
As a result, the decision was taken not to attempt to replicate the whole model in RDF but to follow a more Linked Data centric approach, re-using concepts wherever necessary but simplifying it where possible, and making maximum use of external URI sets. An important reference in this work was the Study on RDF and PID s for INSPIRE by Diederik Tirry and Danny Vandenbroucke. It summarized work by three experts: Clemens Portele, Linda van den Brink and Stuart Williams. The establishment of the INSPIRE Registry , that provides stable URIs for many of the code lists was also a key development.
As a result of the work by the European Commission and the SmartOpenData project, a set of small RDF vocabularies is available that represents a subset of the INSPIRE model. The desire to see these extended by future projects is stated explicitly.
Sander Stolk (Semmtech)
In civil engineering and asset management settings, data from different domains exist alongside each other. Such data typically overlap and complement each other. Think of design data (CAD), geospatial data (GIS), and data for systems engineering (SE). These are produced by different software, and use different perspectives - although they are quite possibly about the same subject (e.g. a specific office building or road).
Problems arise when combining data about a single subject from different perspectives, in an attempt to complement information from one with that of another. This means terminology is needed to capture that resources may be about the same subject but use different perspectives. For example, here are three example perspectives on the same subject - an office building:
The perspectives above are not exhaustive. What they exemplify is that vastly different perspectives of the world and its real-life objects exist. Resources that are about the same subject and are captured using the same perspective, or representation, can often be considered equal or identical. Attributes captured for the one can then be said to also hold for the other. Resources captured using different perspectives, however, cannot be deemed equals. The one resource is then, for example, a registration of the other.
If differences in perspective are not identified and made explicit, an attempt at integrating data from different perspectives is likely to lead to false conclusions. For instance, that a tangible office building in the real world is also a vector of coordinates, and that it has a filled out table cell called 'shape'. It is exactly such relations between resources, signaling differences in perspective (e.g. that one resource is a registration of another), that should be able to be captured using explicit and standardized properties.
This problem is present in several projects in the construction domain where integration of data from different perspectives plays a role. An example is V-Con . However, data from these projects are currently not open.
This chapter lists the requirements for the deliverables of the Working Group, in alphabetical order.
In some requirements the expression 'recommended way' is used. This means that a single best way of doing something is sought. It does not say anything about the form this recommended way should have, or who should make the recommendation. A recommended way could be a formal recommendation or standard from an authoritative standards body like the OGC or W3C , but it could just as well be a more informal specification, as long as it is arguably the best way of doing something.
It should be possible to represent spatial extent directly bound to time, e.g. journey trajectories.
Data consumers should be helped in avoiding coordinate transformations when spatial data from multiple sources are combined.
When geometric data from different sources have no shared Coordinate Reference System (CRS), a data consumer will have to transform the coordinates of at least one data source to another CRS to spatially combine the data. Such a transformation takes time and could introduce errors in the output, so it is preferable to avoid it. Having multiple CRSs to choose from, and different data publishers using common CRSs can help in avoiding coordinate transformations.
There should be a recommended way for publishing and requesting the bounding box and centroid of a spatial thing.
Standards
or
recommendations
for
spatial
data
on
the
Web
should
be
compatible
with
existing
methods
of
making
spatial
data
available
(like
WFS
,
WFS,
WMS,
CSW,
WCS).
WCS)
and
with
existing
information
models.
Spatial data on the Web should be compressible (for optimization of data transfer).
The use of precision that matches uncertainty in coordinate data should be facilitated and encouraged.
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 ,Spatial data on the Web should be crawlable, allowing data to be found and indexed by external agents.
There should be a recommended way of referencing a Coordinate Reference System (CRS) with a HTTP URI, and to get useful information about the CRS when that URI is dereferenced.
Useful things to know about a CRS are the extent of its applicability and its units of measurement.
It should be possible to represent dates, time and duration.
There
For
users
of
geometric
spatial
data
it
should
always
be
a
default
Coordinate
Reference
System
(CRS)
that
can
be
assumed
possible
to
be
used
for
coordinates
that
otherwise
have
no
specification
of
the
CRS.
determine
which
coordinate
reference
system
(CRS)
is
used.
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 recommended way of 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.
Many different types of coverage exist. When coverage data are published on the Web it should be easy to identify the coverage type.
Standards or recommendations for spatial data on the Web should be independent on the reference systems that are used for data.
This
requirement
reflects
that
spatial
data
incorporate
geographical
data,
but
can
also
be
data
that
are
not
directly
related
to
earth
Earth
or
its
scale.
A
Show
how
the
SSN
ontology
can
be
applied
in
the
context
of
lightweight
API
is
needed
needs
for
implementation
on
the
Internet
of
Things
(IoT)
devices.
(IoT).
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.
There should be a recommended way of linking vector geometry/geometries to the Coordinate Reference System (CRS) that is used for positions in the geometry/geometries.
Standards or recommendations 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.
2.3
Time
Ontology
in
OWL
4.45
Event-like
geographic
features
,
4.19
Publication
model
actuation
functions
of
raw
subsurface
monitoring
data
sensing
devices.
Actuation
of
a
sensing
device
is
its
ability
to
change
something
in
existing
models
shall
be
considered
for
adoption,
e.g.
O&M,
SoilML
or
the
OGC
coverage
model.
its
environment
upon
receiving
a
signal.
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.
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
There
should
be
possible
to
represent
many
different
types
a
recommended
way
of
coverage.
For
instance,
to
classify
coverage
publishing
geometric
data
by
grid
complexity:
GridCoverage
(GML
3.2.1),
RectifiedGridCoverage,
ReferenceableGridCoverage,
etc.
with
multiple
Coordinate
Reference
Systems
(CRSs).
it
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 represent aggregations of observations.
It should be possible to describe the observed property represented by a coverage.
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
specification
(ISO-19115).
It
should
be
possible
to
describe
properties
of
the
data
quality,
e.g.
uncertainty.
quality
(e.g.
uncertainty)
per
data
sample.
It should be possible to identify and reference chunks of data, e.g. for processing, citation, provenance, cataloging.
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 recommended ways for describing the spatial characteristics of data (data objects, data sets or data services), like:
There should be a recommended way for expressing spatial relationships between spatial entities. These relationships can be topological, mereological (part-whole), directional or distance related.
There
should
be
a
recommended
way
for
the
definition
and
use
of
spatial
operators.
Spatial
things
can
have
spatial
relations:
topological
relations,
directional
or
distance
relations.
Operators
based
on
these
relations
(e.g.
'Contains'.
'Intersects',
'Nearest')
'Nearest',
'within
a
radius
of')
should
be
well
defined
and
easy
to
use.
It
should
be
possible
to
describe
for
vague
or
informal
expressions
of
locations
in
a
vague,
imprecise
manner.
For
instance,
to
represent
or
spatial
descriptions
from
crowdsourced
observations,
such
relationships
to
be
useful
as
"we
saw
a
wildfire
at
spatial
data.
Examples of vague or informal expressions of locations are:
Examples of vague or informal expressions of spatial relationships are:
It should be possible to represent satellite data using the SSN model, including sensor descriptions.
There should be a recommended way for defining profiles (constrained subsets) of the SSN model and for checking compliance of profiles against the SSN model.
There should be examples of how the SSN ontology can be used together with other vocabularies.
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.
There should be a recommended way to express that data based on different models are about the same real world spatial thing.
Standards or recommendations for spatial data on the Web should be applicable to three-dimensional data.
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.
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 definition of the temporal reference system (e.g. Unix date, Gregorian Calendar, Japanese Imperial Calendar, Carbon Date, Geological Date) should be referenceable online.
It
should
be
possible
to
describe
time
points
and
intervals
in
a
vague,
imprecise
manner.
For
instance,
to
represent
an
example:
It should be possible to represent time series of data.
It should be possible to represent uncertainty in observations.
OWL Time should be updated to align with the 2012 update of OWL datatypes and 2012 update of xsd datatypes
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.
Although data validation is a general topic, this requirement is included because validation of spatial data requires specialist spatial techniques.
Ensure
alignment
with
existing
methods
for
expressing
the
time
in
which
data
are
valid
(e.g.
dcterms:valid)
dcterms:valid).
This requirement does not mean that the way expressions of time can be used is considered in scope for the Time Ontology, but it does mean that being able to express temporal validity using the Time Ontology is considered important for location data.
It must be possible to represent synthetic observations made by computational procedures or inference.
For convenience, this chapter lists requirements grouped by Working Group deliverable.
The
editors
are
grateful
for
all
contributions
made
to
this
document,
in
document.
In
particular
we
thank
the
people
that
have
contributed
use
case
authors.
cases
(their
names
are
mentioned
with
each
use
case)
and
the
Working
Group
members
that
helped
in
mining
and
refining
the
requirements.
A summary of the main changes between the First Public Working Draft (published 2015-07-23) and the Second Public Working Draft (this version) of this document:
A summary of the main changes between the Second Public Working Draft (published 2015-12-17) and the Third Public Working Draft (this version) of this document: