SpatialDataWEB BestPractices
SpatialDataWEB BestPractices
IOS Press
Abstract. Data owners are creating an ever richer set of information resources online, and these are being used for more and more
applications. Spatial data on the Web is becoming ubiquitous and voluminous with the rapid growth of location-based services,
spatial technologies, dynamic location-based data and services published by different organizations. However, the heterogeneity
and the peculiarities of spatial data, such as the use of different coordinate reference systems, make it difficult for data users,
Web applications, and services to discover, interpret and use the information in the large and distributed system that is the Web.
To make spatial data more effectively available, this paper summarizes the work of the joint W3C/OGC Working Group on
Spatial Data on the Web that identifies 14 best practices for publishing spatial data on the Web. The paper extends that work by
presenting the identified challenges and rationale for selection of the recommended best practices, framed by the set of principles
that guided the selection. It describes best practices that are employed to enable publishing, discovery and retrieving (querying)
spatial data on the Web, and identifies some areas where a best practice has not yet emerged.
Keywords: Geographic information systems, Spatial data, Web technologies, World Wide Web, W3C, Open Geospatial
Consortium, OGC
https://www.w3.org/2014/03/lgd/
1 https://data.pdok.nl/datasets 6 https://www.w3.org/2017/sdwig/charter.html
L. van den Brink et al. / Best Practices for Publishing, Retrieving, and Using Spatial Data on the Web 3
Table 1
Standardized aspects of SDIs
Aspect Description Reference standards
Discoverability Annotate resources with metadata ISO 19115 [4, 5], ISO 19119 [6, 7]
Accessibility Web services for discovering, viewing, downloading, OGC CSW [8], OGC WMS [9], OGC WFS
sharing geospatial raster data (coverages) etc. [10], OGC WCS [11]
Portrayal Defining rules for displaying spatial data ISO 19117 [12], OGC SLD [13], OGC SE
[14], OGC KML [15]
Information modeling Describing the contents of information resources, includ- ISO 19103 [16], ISO 19107 [17],
ing geometry ISO 19109 [18], ISO 19110 [19]
Data exchange Defining formats for exchanging the data OGC GML [20]
Spatial reference systems Specifying the location on Earth of geographical informa- ISO 19111 [21, 22]
tion
tunity to combine and integrate information based on requirement are emerging, defining a common or best
location. While spatial data refers to any data that has practice remains a challenge.
a location component either on Earth or within some The Open Geospatial Consortium (OGC), founded
other space such as another planet (as defined earlier), in 1994, publishes technical standards necessary for
geospatial data refers to any data that has a location SDIs to work in an interoperable way. These standards
in terms of geographic coordinates (e.g., GIS coordi- are based on the more abstract standards for geospatial
nates) within Earth. The focus of the Spatial Data on information from the ISO Technical Committee 211
the Web Best Practices, and consequently of this pa- on Geographic information / Geomatics (ISO/TC 211).
per, is on geospatial data. Although non-geospatial use Different aspects of the SDI are standardized (see Ta-
cases were brought to the working group and were in- ble 1).
cluded in the Spatial Data on the Web Use Cases and The OGC developed the first standards for spa-
Requirements (UCR) [23], there were no active par- tial data Web services as of 1998 and has responded
ticipants in the working group who had expertise with to early architectural trends in the Web (e.g., SOA).
spatial data other than geospatial. The focus was there- While SDIs and related standards were developing, so
fore narrowed to geospatial data; requirements of non- did the World Wide Web. Web standards like HTML,
XML and RDF [26] were created in the nineties as
geospatial data might be included in future work. This
well. While the Web started off as mostly documents
paper likewise deals almost exclusively with geospa-
with hyperlinks, over the years it evolved to much
tial data. That said, many of the best practices are ap-
more sophisticated Web applications, including mass
plicable to wider spatial data concerns. In the remain-
applications in which geospatial data was used, like
der of this paper, we simply refer to spatial data for
Bing Maps, Google Maps, Google Earth and Open-
brevity.
StreetMap. More recently, XML has been replaced in
Spatial data can also have a temporal dimension. many Web applications by more lightweight formats
Temporal data varies over time. On the other hand, (e.g. JSON, and RDF).
spatio-temporal data captures spatial data (i.e. current As a generic model or framework, RDF can be
location) associated with the time the data is taken at used to publish geographic information. Its strengths
that particular location [24]. However, in order to use include its structural flexibility, particularly suited
spatial-temporal data, it has to be available and acces- for rich and varied forms for metadata required for
sible. Common practice is to publish this data using different purposes. However, it has no specific fea-
an SDI. SDIs are based on a service-oriented archi- tures for encoding geometry, which is central to geo-
tecture (SOA), in which existing resources are docu- graphic information. Several vocabularies and exten-
mented using dataset-level metadata, published in cat- sions have been proposed for this purpose, including
alogs which are the most important discovery and ac- a core RDF/OWL vocabulary for geographic informa-
cess mechanism [25]. More detailed metadata describ- tion which is part of OGC’s GeoSPARQL [27].
ing structure and content of datasets, as well as service Figure 1 provides an illustration of the main areas of
requests and payloads, are far less commonly shared, overlap between the different communities of practice
and whilst standards suitable for some aspects of this of the Spatial, Semantic and the “mainstream” Web—
4 L. van den Brink et al. / Best Practices for Publishing, Retrieving, and Using Spatial Data on the Web
With the prevalence of sensor and actuator devices As explained in the introduction, the aim of the work
and the increase in location-based services, the use of is to improve the discoverability, interoperability and
spatial technologies is rapidly growing. The existing accessibility of spatial data. The key principle follows
geospatial data, online maps combined with new forms from this: that through the adoption of the best prac-
of dynamic location-based data and services, create an tices identified in the SDWBP, the discoverability and
opportunity for various new applications and services. linkability of spatial information published on the Web
However, to make spatial data more effectively avail- is improved.
able across different domains, a set of common prac-
tices are required. 7 http://www.w3.org/2015/spatial/
L. van den Brink et al. / Best Practices for Publishing, Retrieving, and Using Spatial Data on the Web 5
A second principle concerns the intended audience Lastly, the best practices should comply with the
of the spatial data in question. The aim is to de- principles of the W3C Best Practices for Publishing
liver benefits to the broadest community of Web users Linked Data [29] and the W3C Data on the Web Best
possible—not to geospatial data experts only. The term Practices [30]. Where they do not, this will be iden-
‘user’ signifies a data user: someone who uses data to tified and explained. The Data on the Web Best Prac-
build Web applications that provide information to end tices (referred to as DWBP henceforth) form a natural
users—website visitors and app users—in some way. counterpart to the work on spatial data on the Web. The
These data users are therefore among the intended au- best practices are aligned with DWBP in the following
dience of not only the spatial data, but also the Best ways: a) by using the same best practice template, and
Practice. The SDWBP provides value and guidance for b) by referring to the DWBP instead of repeating it.
application, website and tool builders to address the While the focus of the best practices is on spatial data,
needs of the mass consumer market. Furthermore, the they may include recommendations on matters that are
best practices should provide guidance for spatial data not exclusively related to spatial data on the Web, but
custodians. The best practices can offer a comprehen- are considered by the Working Group to be essential
sive set of guidelines for publishing spatial data on the considerations in some use cases for publishing and
Web. consuming spatial data on the Web, and not covered in
A third principle is to have a broad focus. The first enough detail in DWBP or other documents.
working draft of the best practices solicited several
comments about a perceived “RDF bias”. While to de-
velop spatial data following the 5-star Linked Data 3. The key requirements and best practices for
principles8 was one of the goals at the start, the solu- publishing spatial data on the Web
tions described in the best practices for discoverabil-
ity and linkability should also be applicable to other The following sections discuss the main topics cov-
spatial data on the Web. The best practices promote a ered by SDWBP, and explains how they are addressed
linked data approach, but without asserting a strong as- in the defined best practices. The topics are presented
sociation between linked data and RDF. Linked data in a summarized fashion and are grouped thematically.
requires only that the formats used to publish data Examples of datasets in which these best practices are
support Web linking [28]. Furthermore, any ontolo- implemented are not provided, since these are already
gies developed within the working group should not present in the SDWBP. For the convenience of the
be tightly coupled with upper ontologies (“compatible reader, Table 2 outlines the best practices as they are
with” rather than “dependent upon”); this avoids data stated in SDWBP, and indicates in which of the follow-
publishers having to commit to a given world view, as ing sections they are discussed.
specified within a particular upper ontology, in order
for them to use the best practices and any ontologies 3.1. Geometries and spatial relationships
related to them.
A fourth principle follows from the term ‘best prac- Tobler’s first law of geography states, “everything
tice’ very directly: that its contents are taken from is related to everything else, but near things are more
practice. The aim is not to reinvent or provide ‘best related than distant things” [31]. Like statistics, in ad-
theories;’ in other words, the intention of the best prac- dition to portraying information, spatial data provides
tice is not to create new solutions where good solutions a basis for reasoning, in this case based on location.
already exist or to invent solutions where they do not Integration of data based on a location (i.e. relating
yet exist. The contents of the best practice should be things based on being located at or describing the same
made up of the best existing practices around publish- location) is often very useful. For this to be possible,
ing spatial data on the Web that can be found. Conse- either explicit geometries or topological relationships
quently, the aim is for each of the best practices in the are necessary. Ideally, to enable their widest reuse,
document to be linked to at least one publicly available geometries should be described having in mind the
example(s) of a non-toy dataset that demonstrates the geospatial, Linked Data and Web communities. This
best practice. may not always be feasible, but the objective should
at least be to describe geometries (also) for Web con-
8 http://5stardata.info sumption.
6 L. van den Brink et al. / Best Practices for Publishing, Retrieving, and Using Spatial Data on the Web
Table 2
The Spatial Data on the Web Best Practices [3]—and where they are discussed in the paper
Best Practice 1 Use globally unique persistent §3.3 Best Practice 2 Make your spatial data indexable by §3.9
HTTP URIs for spatial things search engines
Best Practice 3 Link resources together to create the §3.3 Best Practice 4 Use spatial data encodings that §3.1,
Web of data match your target audience §3.6
Best Practice 5 Provide geometries on the Web in a §3.1, Best Practice 6 Provide geometries at the right level §3.1,
usable way §3.10 of accuracy, precision, and size §3.5,
§3.8
Best Practice 7 Choose coordinate reference sys- §3.2, Best Practice 8 State how coordinate values are en- §3.2
tems to suit your user’s applications §3.5, coded
§3.7
Best Practice 9 Describe relative positioning §3.10 Best Practice 10 Use appropriate relation types to §3.1
link spatial things
Best Practice 11 Provide information on the chang- §3.3, Best Practice 12 Expose spatial data through ‘conve- §3.3
ing nature of spatial things §3.6, nience APIs’
§3.7
Best Practice 13 Include spatial metadata in dataset §3.4 Best Practice 14 Describe the positional accuracy of §3.5
metadata spatial data
One of the key best practices (namely, Best Prac- Geo [33], GeoRSS [34], or the ISA Core Location vo-
tice 5) is therefore about providing geometries on the cabulary [35]. Appendix A of SDWBP offers a com-
Web in a usable way. A single best way of publishing parison of the most common spatial ontologies.
geometries was not identified; what is ‘best’ is in this Instead of catering for a single scenario, spatial data
case primarily related to the specific use case and tool publishers should offer multiple geometric representa-
support, which determine the geometry format to be tions when possible, balancing the benefit of ease of
used, the coordinate reference system (CRS) (more de- use against the cost of the additional storage or addi-
tails are included in Section 3.2), as well as the level of tional processing if converting on-the-fly. This can be
accuracy, precision, size and dimensionality of geom- implemented using HTTP content-negotiation; how-
etry data. Note that these aspects are interrelated: for ever, this only works for media-type, character set, en-
instance, the dimensionality of a geometry constrains coding and language. Consequently, it is not possible
the CRSs that can be used, as well as the geometry en- to select one representation that conforms to a given
codings. “profile” (e.g., data model, complexity level, CRS)
Best Practice 5 identifies three scenarios in which from several that all share the same media-type.
geometries can be used: specific geospatial applica- Note that publishing geometries on the Web need
tions, linked data applications, and Web consumption. not always be called for. Although spatial relationships
The practice also offers guidelines for choosing the can often be derived mathematically based on geome-
right vocabularies from several available ones for de- try, this can be computationally expensive. Topologi-
scribing geometry in each scenario. Currently, there cal relationships such as these can be asserted, thereby
are two geometry formats widely used in the geospa- removing the need to do geometry-based calculations.
tial and Web communities, respectively, GML [20] and Exposing such entity-level links to Web applications,
GeoJSON [32]. GML provides the ability to express user-agents and Web crawlers allows the relationships
any type of geometry, in any CRS, and up to 3 dimen- between resources to be found without the data user
sions (from points to solids) but is typically serialized needing to download the entire dataset for local analy-
in XML. GeoJSON supports only one coordinate ref- sis.
erence system (CRS84—i.e., WGS 84 longitude / lati-
tude), and geometries up to 2 dimensions (points, lines, 3.2. Coordinate reference systems and projections
surfaces) but it is serialized in JSON, which is often
easier for browser-based Web applications to process. The key to reasoning and sharing spatial information
In the Linked Data community, several specific vocab- is the establishment of a common coordinate reference
ularies for RDF-based representations of geometries frame in which to position the data. For Earth-based
are available, such as GeoSPARQL [27], W3C Basic data, this may be done in spherical coordinate values
L. van den Brink et al. / Best Practices for Publishing, Retrieving, and Using Spatial Data on the Web 7
such as latitude, longitude and (optionally) elevation, erence height and depth. WGS 84 (EPSG:6326) is an
or in a projected Cartesian coordinate space. The latter example of a Geodetic Datum based on the WGS 84
involves the flattening of a sphere in exchange for mak- (EPSG:7030) Ellipsoid. It uses latitude and longitude
ing it vastly easier to accurately measure area and dis- coordinates (anchored to the equator and poles) to in-
tance. Regardless of the Coordinate Reference System dicate position.
(CRS) chosen, a distortion of the data will occur ei- Geodetic CRSs are useful for collecting informa-
ther in relative angles (positions), sizes (areas), or dis- tion within a common frame. The measurements they
tances. Best Practice 7 identifies the World Geodetic use are good for plotting directions but difficult to use
System 1984 (WGS 84—EPSG:4326), which provides when calculating area or distance. Latitude and longi-
a good approximation at all locations on the Earth, as tude are angular measurements that do not convert eas-
the most commonly used CRS for spatial data on the ily to distance because their size in true units of mea-
Web, but also explains when EPSG:4326 is not recom- sure (e.g., meters) varies according to location on the
mended, especially in use cases that require a higher sphere. They become smaller as you near the poles.
level of accuracy than WGS 84 can offer. In order to measure size and distance, and to display
In the Spatial Data on the Web Working Group, spatial information on a screen or paper, Projected Co-
there was a lot of discussion on this topic. There are ordinate Reference Systems are used. A Projected CRS
a lot of concerns with WGS 84 in the geospatial com- flattens a sphere to enable it to be portrayed and mea-
munity. However, WGS 84 is dominant on the Web; sured in 2 (or 3) dimensions. Figure 3 shows an exam-
it is used by most online mapping providers (e.g. ple of the effects of this based on WGS 84 / Pseudo-
Google, Bing, OpenStreetMap) and popular formats Mercator (EPSG:3857), which is used commonly on
such as GeoJSON. Some explanation is required in or- the Web. As demonstrated by this figure, flattening a
der to understand the concerns of the geospatial com- sphere introduces distortions. Imagine flattening the
munity. All spatial coordinate frameworks begin with skin of an orange. You can preserve fairly accurately
a mathematical model of the object being mapped. measurements for a portion of the skin but the rest
For the Earth, (which is not a true spheroid) an ellip- will necessarily be distorted, either through stretching,
soid model, most fitting to the area being mapped, is compression or tears (see Figure 4). Projected CRSs
commonly used (Figure 2). A Geodetic Datum is then are optimized to preserve distance, area or angular re-
placed on top of the reference ellipsoid to allow numer- lations between spatial things for a chosen region. Dis-
ical expression of position. This may include a Vertical tortion grows the further you move from that region.
Datum, usually an approximation of sea level, to ref- This is one reason why there are so many CRSs.
8 L. van den Brink et al. / Best Practices for Publishing, Retrieving, and Using Spatial Data on the Web
dia 10 and GeoNames 11 or public government data, exposing spatial data from existing WFS services on
such as a national registers of addresses. Mapping the Web. The approach is to create an intermediate
and cadastral authorities maintain datasets that pro- layer by introducing a proxy on top of the WFS (data
vide geospatial reference data. Re-using well-known service) and CSW (metadata service) [8] so the con-
identifiers is a good practice because it makes it tained resources are made available. The proxy maps
easy to recognize that data from different sources the data and metadata to schema.org [38] according to
are related. An example of a spatial thing URI is a provided mapping scheme; assigns URIs to all re-
http://sws.geonames.org/2172517/ which identifies the sources based on a pattern; makes each resource avail-
spatial thing Canberra, while when resolved in a able in HTML, XML, JSON-LD [39], GML [20], Geo-
browser returns information such as the name of JSON [36], and RDF/XML (metadata only); and gen-
the spatial thing, the centroid location, geographical erates links to data in other datasets using SPARQL
boundaries, etc. queries [40].
When exposing spatial data through standard SDIs
(e.g., WFS services [10]), a certain user group is 3.4. Discovery of spatial information
catered for, i.e., users with the expertise and tooling to
use these services based on standards from the geospa- Cataloging of spatial information has always been
tial domain. To allow more users to benefit from the difficult, whether the data is digital or not. A roadmap
data it is important to expose the link to the Web repre- for Wellington NZ may be filed under NZ, Welling-
sentation of the features on the Web. Best Practice 12 ton, Transportation, tourism or a large number of other
identifies two approaches for doing this while keep- categories. Spatial data therefore has a greater require-
ing the SDI in place. One is to add an attribute to ment for metadata. Best Practice 13 recommends the
all spatial things, named rdf_seealso, which con- inclusion of spatial metadata in dataset metadata. As
tains the URI of the Web representation of the spatial a minimum, the spatial extent should be specified: the
thing visible on the map. The Web representation is area of the world that the dataset describes. This in-
created by mapping the data in the SDI dynamically formation is necessary to enable spatial queries within
to crawlable resources on the Web using the R2RML catalog services such as those provided by SDIs and
standard [37] and Linked Data Publication tools. This often suffices for initial discovery. However, further
approach leverages existing SDIs while enriching them levels of description are needed for a user to be able
with dereferenceable linked data representations of the to evaluate the suitability of a dataset for their in-
spatial things. Exposing the data about a spatial thing tended application. This includes at least spatial cover-
as linked data makes sure that the attributes themselves age (continuity, resolution, properties), and represen-
will be URIs and thus unambiguous. The overhead of tation (for example vector or grid coverage) as well as
the extra attribute on existing SDIs is negligible and the coordinate reference system used.
traditional clients will not be hindered by the extra at- In SDIs, the accepted standard for describing meta-
tribute, but more advanced usage allows unlocking of data is ISO 19115 [4, 5] or profiles thereof. To provide
a wealth of connections behind the traditional spatial information about the spatial attributes of the dataset
data. on the Web, DCAT [41] is recommended. An applica-
The other approach is to create a RESTful API as a tion profile of DCAT for geospatial data, GeoDCAT-
wrapper, proxy or a shim layer around WFS services. AP [42], can be applied to more fully express spatial
It is worth mentioning that different spatial data ser- metadata. In addition, several spatial ontologies, al-
vices are often making their data accessible through ready mentioned in Section 3.1, allow the description
REST API services. Content from the WFS service of spatial datasets.
can be provided in this way as linked data, JSON or
another Web-friendly format. There are examples of 3.5. Scale and quality
this approach of creating a convenience API that works
dynamically on top of WFS such as the experimen- The quality of spatial data, as that of any other data,
tal ldproxy.12 This is an attractive option for quickly has a big impact on the quality of applications that
use such data. This is intensified in the Web scenario,
10 http://dbpedia.org where data could be consumed with unforeseen pur-
11 http://geonames.org poses and data that are useful for a particular use case
12 https://hub.docker.com/r/iide/ldproxy/ could come from plenty of sources.
10 L. van den Brink et al. / Best Practices for Publishing, Retrieving, and Using Spatial Data on the Web
Therefore, having quality information about spatial vice can be followed for other relevant spatial quality
data on the Web significantly facilitates two main tasks information.
to the consumer of such data. One of them is the se-
lection of data, allowing to focus on data that satisfy 3.6. Thematic layering and spatial semantics
the needs of a concrete use case. For example, spatial
data accuracy is important when using them in the ap- Spatial data is typically collected in layers. Al-
plication of self-driving cars; guiding an autonomous though this sounds very map-oriented, these layers can
vehicle to a precise parking spot near a facility that has be thought of as collections of instances of a class
a time-bounded service and then booking the charg- within a spatial and temporal frame. In other words,
ing spot requires accurate location data. Another is the layers are usually organized semantically. Although
reuse of data, i.e., understanding the behavior of data SDWBP does not address layers directly, it does ad-
in order to adapt its processing (e.g., by considering dress spatial semantics. DWBP recommends the use
data currentness, refresh rate or availability). A funda- of vocabularies to communicate the semantics, i.e., the
mental concept of spatial data is the scale of the rep- meaning of data, and preferably standardized vocab-
resentation of the spatial thing. This is important be- ularies. There are several vocabularies about spatial
cause combining data designed to be used at differing things available, such as the W3C Basic Geo vocab-
scales often produces misleading results. A scale is of- ulary [33], GeoRSS [34], GeoSPARQL [27], the ISA
ten represented as a ratio or shortened to the denomi- Core Location Vocabulary [35] or schema.org [38];
nator value of a ratio. A 1:1,000 (or 1,000) scale map is overviews on their uses are provided in the litera-
referred to as larger than a 1:1,000,000 (or 1,000,000) ture [44–46]. Best Practice 4 identifies the main vocab-
scale map. Conversely, a million scale map is said to ularies in which spatial things can be described when
the aim is data integration; however, it does not rec-
be a smaller scale than a thousand scale map. Data col-
ommend one of them as the best. Currently there is no
lected at a small scale is most often more generalized
common practice in the sense of the same spatial vo-
than data collected at a larger scale. Concepts related
cabulary being used by most spatial data publishers.
to scale are resolution (the smallest difference between
This depends on many factors; furthermore, describ-
adjacent positions that can be recorded), accuracy (the
ing spatial data multiple times using different vocabu-
amount of uncertainty—how well a coordinate desig-
laries maximizes the potential for interoperability and
nates a position on the actual Earth’s surface) and pre-
lets the consumers choose which is the most useful.
cision (the reproducibility of a measurement to a cer-
Appendix A of SDWBP offers guidance for selecting
tain number of decimal places in coordinate values). vocabularies by providing a table comparing the most
When publishing spatial data on the Web, they commonly used ones.
should be supplemented with information about the The most important semantic statement to be made
precision and accuracy of such data. Such quality in- when publishing spatial data—or any data—is to spec-
formation should at least be available for humans. Best ify the type of a resource. The W3C Basic Geo vo-
Practice 14 is concerned with positional accuracy and cabulary has a class SpatialThing which has a
how spatial data should be accompanied with informa- very broad definition. This can be applicable (as a
tion about its accuracy. Best Practice 7 asserts a link generic concept) to most of the common use-cases.
between CRS and data quality, because the accuracy of Thematic semantics and general descriptions of spa-
spatial data depends for a large part on the CRS used, tial things and their properties should be provided as
as was explained in a previous section. In order to sup- linked data. They should have URIs that return human-
port automatic machine-interpretation of quality infor- and machine-readable definitions when resolved.
mation, such information should be published follow-
ing the same principles as any other data published on 3.7. Temporal dimension
the Web. The CRS of geometries on the Web should al-
ways be made known. For describing other quality as- It is important to consider the temporal dimension
pects, the W3C Data Quality Vocabulary (DQV) [43], when publishing spatial data. The “where” component
which allows specifying data quality information (such of the data is seldom independent of the “when” which
as precision and accuracy), could be used. may be implicit or explicit to the data. Hence, captur-
Even if the recommendations in Best Practice 14 fo- ing the temporal component makes spatial data more
cus on precision and accuracy, evidently the same ad- useful to potential users, since it allows them to verify
L. van den Brink et al. / Best Practices for Publishing, Retrieving, and Using Spatial Data on the Web 11
whether the data suits their needs. For instance, tec- ometries over the Web, this results in very large re-
tonic movements over time can distort the coordinate sponse payloads wasting bandwidth and causing slow
values of spatial things. response times, while for some very common use
This is included in Best Practice 7 on coordinate ref- cases, like simply displaying some things on a Web
erence systems as valuable knowledge when dealing map, high accuracy is not required. The primary basis
with spatial data for precision applications. Further- for simplification is scale. For example, when search-
more, it is recommended in Best Practice 13 to include ing for a Starbucks on a city scale, an accuracy of 3
metadata statements about the (most recent) publica- meters is acceptable, but when providing street-level
tion date, the frequency of update and the time period directions to a shop for a self-driving car it is not.
for which the dataset is relevant (i.e., temporal extent). For those use cases that do not require high ac-
Apart from the need for enhancing spatial data with curacy, common ways of dealing with reducing the
their temporal context, the temporal dimension also af- size of spatial data include degrading precision by
fects the very nature of spatial things, since both spa- reducing the number of decimals, and simplifying
tial things and their attributes can change over time; geometries using a simplification algorithm such as
this is covered in Best Practice 11. When dealing with Ramer-Douglas-Peucker [48, 49] or Visvalingam-
changes to a spatial thing, its lifecycle should be taken Whyatt [50]. These methods result in lower accuracy
into account; in particular, how much change is accept- and precision.
able before a spatial thing can no longer be considered Big spatial data is often not vector data, i.e., a repre-
as the same resource (and requires defining a new re- sentation of spatial things using points, lines, and poly-
source with a new identifier). Creating a new resource gons [16], but coverage data, i.e., gridded data: a data
will depend on whether domain experts think the fun- structure that maps points in space and time to prop-
damental nature of the spatial thing has changed, tak- erty values [51]. For example, an aerial photograph can
ing into account its lifecycle (e.g., a historic building be thought of as a coverage that maps positions on the
replaced by another that has been built on top of it). In ground to colors. A river gauge maps points in time to
this case, the temporal dimension of spatial data can flow values. A weather forecast maps points in space
be expressed by providing a series of immutable snap- and time to values of temperature, wind speed, humid-
shots that describe the spatial thing at various points in ity and so forth. For coverage data, other methods are
its lifecycle, each snapshot having a persistent URI. required to manage size.
In those cases when the spatial thing itself does not DWBP recommends to provide 1) bulk download
change over time but its attributes do, the description and 2) subsets of data. Providing bulk-download or
of the spatial thing should be updated to reflect these streaming access to data is useful in any case and
changes, and each change published as a snapshot. In is relatively inexpensive to support as it relies on
contrast, when a spatial thing has a small number of standard capabilities of Web servers for datasets that
attributes that are frequently updated (e.g., the GPS- may be published as downloadable files stored on a
position of a runner or the water level from a stream server. Subsets, i.e., extracts or “tiles”, can be pro-
gauge), the time-series of data values within such at- vided by having identifiers for conveniently sized sub-
tributes of the spatial thing should be represented. This sets of large datasets that Web applications can work
is relevant in relation to recent advances in embedding with [52]. Actually, breaking up a large coverage
smart sensors and actuators in physical objects and ma- into pre-defined lumps that you can access via HTTP
chines such as vehicles, buildings, and home appli- GET requests is a very simple API. A second way of
ances, which has led to the publishing of large volumes supporting extracts, more appropriate for frequently
of data that are spatio-temporal [47]. changing datasets, is by supplying filtering options
that return appropriately sized subsets of the specific
3.8. Size of spatial datasets dataset.
Spatial data tends to be very large. This can pose dif- 3.9. Crawlability
ficulties when sharing or consuming spatial data over
the Web—particularly in low bandwidth or high la- Search engines use crawlers to update their search
tency situations. Accurate (polygon) geometries tend index with new information that has been found on the
to contain a high number of coordinates. Especially Web. Traditional crawlers consist of two components:
when querying collections of spatial things with ge- URL extractors, i.e., HTML crawlers that extract links
12 L. van den Brink et al. / Best Practices for Publishing, Retrieving, and Using Spatial Data on the Web
from HTML pages in order to find additional sources the Dutch geoportal PDOK.nl which extensively pub-
to crawl, and indexers, i.e., different types of indexes, lishes dataset metadata, for example, the national roads
typically using the occurrence of text on a Web page, dataset,15 resulting in better accessibility through com-
that are maintained by search engines. mon search engines. Several examples of spatial things
A major issue with crawlers identified in the early published in this way are provided in Best Practice 2.
2000’s by Bergman [53] was the inaccessibility of the Currently, spatial information, even when published
so-called “deep Web”: information that was hidden to in accordance with these guidelines, is not widely ex-
traditional crawlers as it is only accessible through ser- ploited by search engines. However, by increasing the
vices (e.g., forms) that require user input. Several so- volume of spatial information presented to search en-
lutions have since been introduced to access and index gines, and the consistency with which it is provided,
information on the “deep Web” [54, 55]. Spatial Data it is expected that search engines will begin offering
services (e.g. OGC Web services and/or other APIs) spatial search functions. Evidence is already seen of
typically make information available only after user in- this in the form of contextual search, such as prioritiza-
put has been provided, leading to a similar problem, tion of search results from nearby entities. In addition,
i.e., a Deep Spatial Web. Further, these services are search engines are beginning to offer more structured,
built to be accessed and searched by domain-specific custom searches that return only results that include
applications rather than general Web services and/or certain schema.org types such as Dataset, Place
search engine crawlers. For example, in the OGC ar- or City.
chitecture, catalog services are intended to be used for
searching spatial assets by using specific client tools, 3.10. Other aspects of spatial data
and are not optimized for indexing and discovery by
general purpose search engines. However, a typical Spatial things may have 0 to 3 dimensions (points,
Web user does not know that these catalogs exist and lines, areas, 3D), and it may be difficult to combine
is accustomed to using general purpose search engines similar things if the dimensions in which they are rep-
for finding information on the Web. Therefore, mak- resented differ. Although SDWBP does not address
ing sure that spatial data is indexable by Web search this at length, Best Practice 5 does recommend de-
engines is an important approach for making spatial scribing the number of dimensions in metadata and
data discoverable by users directly. The addition of notes that one of the selection criteria for choosing a
structured data to Web services that are otherwise not geometry format on the Web is the dimensionality of
accessible to search engines increases the visibility the data.
of a service or dataset in major search engines [56]. In common language, and for spatial things inher-
Schema.org [38], a single schema across a wide range ently related to mobile things, it may be convenient
of topics that includes people, places, events, products, to describe positions of spatial things relative to other
offers, etc., and widely supported by Bing, Google, spatial things. Just as for other spatial things, we would
Yahoo! and Yandex, is the predominant way of mark- like such descriptions to be both human- and machine-
ing up content and services on the Web with struc- interpretable. We advise, in Best Practice 9, that po-
tured data to improve the presentation of the result in sitions or geometries of the target reference things
a search engine [56]. To verify if schema.org markup should be retrievable via link relations, in accord with
on a Web page is recognized by Web agents, Google’s general principles for linkability in Section 2. The geo-
Structured Data testing tool13 can be used. Experimen- centric use case (i.e., position relative to the Earth) is
tal work such as Geonovum’s Spatial Data on the Web generally addressed throughout SDWBP and does not
Testbed14 describes ways to make spatial data index- require an explicit link relation to the Earth. As the ac-
able by publishing an HTML Web page for the spa- tive contributors to SDWBP were primarily interested
tial dataset and each spatial thing that it contains; by in the geocentric case, SDWBP does not explore rela-
using structured data, schema.org and links, as well as tive positioning in depth. We find that practices in this
publishing XML sitemaps containing links to all data area vary widely in the details of implementation and
resources for spatial data services. Another example is so we are able to offer only broad advice and examples.
Spatial relationships as described for Best Practice 10
13 https://search.google.com/structured-data/testing-tool
14 https://github.com/geo4web-testbed/general 15 https://data.pdok.nl/datasets/nationaal-wegenbestand-wegen
L. van den Brink et al. / Best Practices for Publishing, Retrieving, and Using Spatial Data on the Web 13
(Section 3.1) may be useful, but we find no evidence a map. Although there are ways to represent geometry
for suitable common vocabularies for many needs. For in Web data, there are still some gaps in current prac-
some spatial data, the symbology associated with the tice related to selecting a serialization format, select-
data is of high importance because it communicates ing an embedded, file-based or Linked Data approach,
meaning. However, as rendering maps is explicitly out and making geometries available in different CRSs.
of scope, symbology is not addressed in SDWBP. There are several aspects to representing geometries
on the Web. First, there is the question of different se-
rialization formats to choose from. In general, the for-
4. Gaps in current practice mats are the same as for publishing any other data on
the Web: XML, JSON, CSV, RDF, etc. How to select
The best practices described in brief in Section 3, the most appropriate serialization is described in gen-
and in full in the SDWBP document, are compiled eral terms in DWBP. As described in Section 3.1, a sin-
based on evidence of real-world application. This is in gle best way of publishing geometries was not identi-
line with the fourth principle described in Section 2 of fied in SDWBP. The currently most widely used geom-
this paper. However, there are several issues that in- etry formats, namely, GML [20] and GeoJSON [36],
hibit the use or interoperability of spatial data on the do not address all requirements. Therefore, in order to
Web, for which no evidence of real-world applied so- facilitate the use of geometry data on the Web, SD-
lutions was found. These issues are denoted “gaps in WBP recommends that GML-encoded geometries are
current practice” and described as such in this sec- made available also in GeoJSON, by applying not only
tion. An issue is considered a gap when no evidence the required coordinate reference system transforma-
of real-world applied solutions in production environ- tion, but, if needed, by simplifying the original geome-
ments was found. The term ‘production environment’
try (e.g., by transforming a 3D geometry in a 2D one).
signifies a case where spatial data has been delivered
A second, related aspect concerns the existing op-
on the Web with the intention of being used by end
tions for publishing geometries on the Web—e.g., in
users and with a quality level expected from such data.
self-contained files such as GML or GeoJSON, or
In contrast, a “testing environment” is published with
rather to embed geometries as structured data markup
the intent of being tested so that bugs can be discov-
in HTML, or in an RDF-based way, i.e., as Linked
ered and fixed and an experimental publication of spa-
Data. Choosing between these approaches—or not
tial data on the Web is published with the intent of,
choosing but rather offering a combination of these—
for example, exploring possibilities, learning about the
technology, or other goals besides publishing with the depends largely on the intended audience. As ex-
intent of serious use. In the case of gaps, there might plained in Section 3.9, dealing with crawlability, the
be emerging practice, i.e., a solution that has been the- advantage is that HTML with embedded data is in-
orized for a certain issue and has possibly been ex- dexed by search engine crawlers. However, the op-
perimented on in testing/beta settings, but not in pro- tions for embedding geometry in HTML are lim-
duction environments. Gaps and emerging practices in ited. Typically this is done using schema.org [38] as
the area of publishing spatial data on the Web are dis- Microdata [57], RDFa [58], or JSON-LD [39], but
cussed in this section. for specifying only 0D-2D geometries (points, lines,
surfaces)—e.g., the centroid and/or 2D bounding box.
4.1. Representing geometry on the Web An additional issue is that search engines index only
a subset of the terms defined in schema.org, and those
Location information can be an important ‘hook’ concerning geometries are not fully supported. RDF-
for finding information and for integrating different based publication of geometry data is the most ad-
datasets. There are different ways of describing the lo- vanced option, but the audience for this is smaller than
cation of spatial things: referencing the name of a well- the others. GeoSPARQL [27] offers a vocabulary that
known named place, describing a location in relation allows serialization of geometries as GML or WKT
to another location, or providing the location’s coor- (“Well-Known Text”) [59], whereas the ISA Core Lo-
dinates as a geometry. The latter allows the integra- cation vocabulary [35] supports also GeoJSON, but the
tion of data based on location using spatial reasoning, lack of best practices on the consistent use of the exist-
even when explicit links between things are not avail- ing spatial data vocabularies prevents interoperability
able, as well as, of course, showing spatial things on (see Section 4.2).
14 L. van den Brink et al. / Best Practices for Publishing, Retrieving, and Using Spatial Data on the Web
Third, there is a question of how to make geometries CRSs will, in general, introduce errors, so data in one
available in different CRSs. Section 3.2 explains the CRS are not exactly the same as data in another CRS.
existence of many CRSs and why spatial data should Furthermore, CRS is just one of a number of parame-
be published in CRSs that are most common to poten- ters that may characterize a particular geometric repre-
tial users. It follows that, on the one hand, the CRS sentation of a spatial thing, including the type of geom-
should be specified for geometries published on the etry, its relationship to the Thing, method of interpo-
Web and, on the other hand, users should be able to lation, scale or resolution. However, offering a choice
find out which CRSs are available and to get geome- between all these parameters of data objects such as
tries using the CRS of their choice. geometries might be an overloading of HTTP content
Sometimes the CRS used is clear from the represen- negotiation protocols. It might, therefore, be more ap-
tation. In other cases the CRS needs to be specified ei- propriate to handle this in the application layer.
ther on the dataset level or the instance level. How this
is done differs for each serialization. For example, in 4.2. A spatial data vocabulary
GeoSPARQL this is added as a prefix of the WKT lit-
eral while in GML an attribute srsName can be spec- Although a large amount of geospatial data has been
ified on geometry elements. In an OGC WFS [10] re- published on the Web, so far there are few authori-
quest, users can specify the CRS they wish to use by tative datasets containing geometrical descriptions of
specifying the srsName parameter. In GeoSPARQL spatial things available in Web-friendly formats. Their
the getSRID function returns the spatial reference number is growing (e.g., at the time of writing there
system of a geometry, thus making it possible to re- are three authoritative spatial datasets publicly avail-
quest a specific CRS at a (Geo)SPARQL endpoint. able as linked data in the Netherlands containing to-
However, these options require the user to be proficient pographic17 , cadastral18 , and address19 data), but cur-
in either geospatial Web services or Linked Data. rently there is no common practice in the sense of the
A best practice for returning geometries in a spe- same spatial vocabulary—or the same combination of
cific requested CRS has not yet emerged. Many op- spatial vocabularies—being used by most spatial data
tions can be found in current practice, including cre- publishers. The consequence is the lack of a baseline
ating CRS-specific geometry properties (for exam- during the mapping process for application develop-
ple, the Dutch Land Registry does this), and sup- ers trying to consume specific incoming data. Identi-
porting an option for requesting a specific CRS in fying administrative units, points of interest or postal
a convenience API; but one best practice cannot addresses with URIs could be beneficial not only for
yet be identified. Another option worth exploring georeferencing other datasets, but also for interlinking
might be the use of content negotiation, i.e., nego- datasets georeferenced by the direct and indirect loca-
tiate CRS as part of the content format for the ge- tion information.
ometry, as has also been proposed for encoding for- Direct georeferencing of data implies representing
mat. For example, this could be done with an extra coordinates or geometries and associating them to a
media type parameter (e.g., application/ttl; CRS. This requires vocabularies for geometries and
geomLiteral="WKT"; crs="CRS84") or by able to specify which CRS is used. Further, indirect
adding specific request and response headers for ne- georeferencing of data implies associating them to
gotiating CRS to the HTTP protocol. A contribution other data on named places. Preferably, these data on
to address this issue might be provided by the W3C named places should be also georeferenced by coordi-
Dataset Exchange Working Group (DXWG), which nates in order to serve as the basis for data linking be-
is due to deliver a specification on profile-based con- tween indirectly and directly georeferenced datasets.
tent negotiation.16 However, providing different CRS Moreover, vocabularies developed for representing
might be too complicated to handle in the HTTP pro- specific sets of geospatial data on the Web should reuse
tocol. For example, multidimensional datasets will in as much as possible existing ones. This is the case for
general use multiple CRSs (e.g., horizontal, vertical the vocabularies developed by IGN France for geome-
and temporal, maybe more), and conversion between
17 https://brt.basisregistraties.overheid.nl
16 For a description of this deliverable, see the DXWG Charter: 18 https://brk.basisregistraties.overheid.nl
https://www.w3.org/2017/dxwg/charter. 19 https://bag.basisregistraties.overheid.nl
L. van den Brink et al. / Best Practices for Publishing, Retrieving, and Using Spatial Data on the Web 15
tries,20 topographic entities,21 and CRS.22 These vo- as a point, a 2D or a 3D polygon. The polygons could
cabularies contain alignments with existing vocabular- have different versions with different resolutions (gen-
ies, e.g., the class geom:Geometry is a subclass of eralization levels). And all those different geometries
both sf:Geometry (OGC Simple Features vocab- could be published with different coordinate reference
ulary) which is a subclass of the Geometry class of systems. Thus, the vocabulary would provide a foun-
the GeoSPARQL vocabulary; and ngeo:Geometry dation for harmonization of the many different geome-
(Neogeo vocabulary). Furthermore, the topographic try encodings that exist today. An alternative approach
entity class from the IGN France vocabulary is de- is to establish best practices for the consistent use of
clared equivalent to the Feature class from the the most popular spatial vocabularies. An example are
Geonames vocabulary. the guidelines for the RDF representation of INSPIRE
In W3C Basic Geo [33], it is assumed that the CRS data developed in the framework of the EU ISA Pro-
used is WGS 84. However, publishers might have data gramme [61] by following the SDWBP recommenda-
in a different, local CRS. Thus, there is a need for a tions. In such a scenario, the definition of new classes
more generic class for, for example, a point geometry and properties would be limited to cover the gaps in
with the benefit of choosing the CRS of the underlying the existing vocabularies.
data [60]. Existing vocabularies, as GeoSPARQL [27]
and ISA Core Location [35], support this feature, but 4.3. Spatial aspects for metadata
there are currently no best practices for their consistent
use, thus hindering interoperability. Even if all spatial data should become discoverable
Vocabularies like the one by IGN France are cre- directly through search engines, data portals would
ated because, currently, the existing vocabularies do still remain important hubs for data discovery—for ex-
not cover all requirements and no guidance is avail- ample, because the metadata records registered there
able on their consistent and complementary use. SD- can be made crawlable. But, in addition, different data
WBP partially addresses the latter issue, by providing portals can harvest each others’ information provided
examples on how to model spatial information with there is consistency in the types and meaning of in-
widely used vocabularies. However, solving the exist- cluded information, even if structures and technolo-
ing gaps would require the definition of new terms in gies vary. Discovery of spatial data is improved in the
existing or new vocabularies, which was not in scope Netherlands, for example, because the national general
with the work of the Spatial Data on the Web Work- data portal23 harvests the spatial data portal and thus all
ing Group. A possible way forward is an update for spatial datasets are registered in the general data portal
GeoSPARQL. This would provide an agreed spatial as well.
ontology, i.e., a bridge or common ground between ge- In the eGovernment sector, DCAT [41] is a standard
ographical and non-geographical spatial data and be- for dataset metadata publication, and harvesting this
tween W3C and OGC standards, conformant to the metadata is implemented by eGovernment data portals.
ISO 19107 [17] abstract model and based on exist- Because DCAT is lacking in possibilities for describ-
ing vocabularies such as GeoSPARQL [27], the W3C ing some specific characteristics of spatial datasets, an
Basic Geo Vocabulary [33], GeoRSS [34], NeoGeo or application profile for spatial data, GeoDCAT-AP [42,
the ISA Core Location vocabulary [35]. The updated 62], has been developed in the framework of the ISA
GeoSPARQL vocabulary would define basic semantics Programme of the European Union,24 with the primary
for the concept of a reference system for spatial co- purpose of enabling the sharing of spatial metadata
ordinates, a basic datatype, or basic datatypes for ge- across domains and catalog platforms. To achieve this,
ometry, how geometry and real world objects are re- GeoDCAT-AP defines RDF bindings covering the core
lated and how different versions of geometries for a profile of ISO 19115:2003 [4] and the INSPIRE [63]
single real world object can be distinguished. For ex- metadata schema, enabling the harmonized RDF rep-
ample, it makes sense to publish different geometric resentation of existing spatial metadata. The focus was
representations of a spatial object that can be used for on the most used metadata elements, whereas addi-
different purposes. The same object could be modeled tional mappings—as well as the alignment with the lat-
est version of ISO 19115 [5]—could be defined in fu-
20 http://data.ign.fr/def/geometrie/20160628.en.htm
21 http://data.ign.fr/def/topo/20140416.en.htm 23 https://data.overheid.nl
22 http://data.ign.fr/def/ignf/20160628.en.htm 24 https://ec.europa.eu/isa2/
16 L. van den Brink et al. / Best Practices for Publishing, Retrieving, and Using Spatial Data on the Web
ture versions of the specification, based on users’ and for describing spatio-temporal aspects of data, which
implementation feedback. are very important for observations. One of the work
One of the outcomes of the development of items in the Spatial Data on the Web Working Group
GeoDCAT-AP was the identification of gaps in exist- was, therefore, an extension to the existing QB vocab-
ing RDF vocabularies for representing some spatial ulary to support specification of key metadata required
information [64]—such as coordinate reference sys- to interpret spatio-temporal data, called QB4ST [68].
tems and spatial resolution (see also Section 4.2 on QB4ST is an extension to QB to provide mecha-
this topic). But it also highlighted a key issue for spa- nisms for defining spatio-temporal aspects of dimen-
tial data, in that the use of global and persistent iden- sion and measure descriptions. It is intended to enable
tifiers is far from being a common practice. Apart the development of semantic descriptions of specific
from making it difficult to implement a Linked Data- spatio-temporal data elements by appropriate commu-
based approach, this situation has negative effects on nities of interest, rather than to enumerate a static list
the geospatial infrastructure itself. E.g., it makes it im- of such definitions. It provides a minimal ontology of
possible to unambiguously identify a spatial thing or spatio-temporal properties and defines abstract classes
a dataset over time, and it prevents an effective im- for data cube components (i.e., dimensions and mea-
plementation of incremental metadata harvesting in a sures) that use these, to allow classification and discov-
federated infrastructure (such as the INSPIRE one). ery of specialized component definitions using general
Notably, recent activities are contributing to fill at terms. QB4ST is designed to support the publication of
least part of these gaps. For instance, DQV [43] pro- consistently described re-usable and comparable defi-
vides a solution for modeling precision and accu- nitions of spatial and temporal data elements by appro-
racy, as mentioned in Section 3.5. Moreover, the use priate communities of practice. One obvious such case
cases collected by the W3C Dataset Exchange Work- is the use of GPS coordinates described as decimal lat-
ing Group [65] cover also geospatial requirements, itude and longitude measures. Another example is the
which might be addressed by the work of this group in intended publication of a register of Discrete Global
the revision to DCAT [41]. However, the consistent use Grid Systems (DGGS) by the OGC DGGS Working
of global and persistent identifiers in the geospatial do- Group. QB4ST is intended to support publication of
main is an issue that, far from being merely technical, descriptions of such data using a common set of at-
affects the data management workflow, and therefore tributes that can be attached to a property description
needs to be addressed also at the organizational level. (extending the available QB mechanisms for attributes
of observations). The Spatial Data on the Web Work-
4.4. Describing dataset structure and service ing Group has demonstrated the use of QB and QB4ST
behaviors to serve satellite imagery through DGGS and a virtu-
alized triple store [52].
Datasets may be arbitrarily large and complex, and
may be exposed via services to expose useful re- 4.5. Versioning of spatial data
sources, rather than a “download” scenario. Data gath-
ered using automated sensors, in particular, may be im- Future Internet technologies will aim more and
possible to download in its entirety due to its dynamic more to capture, make sense of and represent not only
nature and potential volumes. It is, therefore, neces- static but dynamic content and up-to-date information.
sary in these cases to be able to adequately describe Through Internet technology, connections between de-
the structure of such data and how services interact vices and people will be realized through the exchange
to expose subsets of it—even individual records in a of large volumes of multimedia and data content.
Linked Data context. Such datasets are common in the When the communication latency becomes lower, and
information processing world, and commonly orga- the capacity of the communication gets higher with
nized in “hypercubes”—where “data dimensions” are fifth generation (5G) mobile communications systems,
used to locate values holding results. A standard based the Internet will be an even more prominent platform
on this dimensional model of data is the RDF Data to control real and virtual objects in different parts of
Cube vocabulary (QB) [66]. It has been used to pub- our lives, such as healthcare, education, manufactur-
lish sensor data; for example to publish a homogenized ing, smart grids, and many more [69]. The Internet of
daily temperature dataset for Australia over the last Things [70] and Tactile Internet [71] are some of the
100 years [67]. However, QB is lacking in possibilities technologies that aim to facilitate the interaction be-
L. van den Brink et al. / Best Practices for Publishing, Retrieving, and Using Spatial Data on the Web 17
tween people and devices, observe near real-time phe- high granularity and lightweight format will play a piv-
nomena and actuate devices or robots. The Tactile In- otal role in the development of future Internet tech-
ternet is focused on speeding up this interaction pro- nologies. Moreover, it will allow machines to instantly
cess and reducing the latency in communication sys- exchange information including spatial and geometri-
tems. Such high-speed communication will bring new cal knowledge and carry out their tasks with high pre-
challenges for intelligent systems. There is a big gap cision. The Spatial Data on the Web Interest Group25 ,
in the lightweight and semantically rich representa- the successor of the Working Group, will address the
tion of versioning and temporal aspects of spatial data topic of representing moving objects on the Web.
content. There have been a few attempts to represent
changing and moving spatial objects, such as OGC’s
TimeSeriesML [72] and Moving Features [73]. How- 5. Conclusions
ever, although these ontologies provide a reasonably
good semantic coverage, there is still a need for the Spatial data has become ubiquitous with the ex-
development of lightweight and semantically rich rep- plosive growth in positioning technologies attached
resentations to conduct enhanced (near) real-time op- to mobile vehicles, portable devices, and autonomous
erations. Having heavy semantic expressivity in on- systems. It has proven to be fundamentally useful
tologies can cause a burden on reasoning engines and for countless things, ranging from everyday tasks like
can slow down the processing time for machines. For finding the best route to a location to solving the
instance, it is important to identify and represent the biggest global challenges like climate change adapta-
direction and coverage area of a surveillance camera tion. However, spatial data dissemination is heteroge-
or the orientations and positions of objects or people neous and although the Web is commonly used as a
in the observed environment. In the future, a broken publication medium, the discovery, retrieval, and inter-
car will be fixed by a robot, or surgeries will be carried pretation of spatial data on the Web is still problematic.
out by multiple robots using Tactile Internet [74]. It SDWBP describes how Web principles can be ap-
can also be envisioned that people, who have difficulty plied to the world of complex spatial data to solve this
in walking, will not need to use a walking stick but problem. Good practices can be observed in current
merely a strap of an exoskeleton. These must be con- practice and have been collected into the Best Prac-
trolled by wireless systems to monitor the coverage, tices based on a set of principles and an examination
direction, and identify the objects and people around
of practice. In some cases, a best practice has not yet
them including their shapes.
emerged. There are still questions related to represent-
To conduct such activities, a better representation is
ing geometry on the Web, with regard to recommend-
needed for not only spatial information but also tem-
able serialization forms and formats, and the use of
poral and geometrical aspects of objects. Observed ob-
coordinate reference systems. A Web-friendly way of
jects can change their size during the actuation pro-
publishing spatial metadata has not yet been described
cess. For instance, a group of surgical robots will need
in full, especially with regards to the relevant subset
to know about the shape of an organ and the changes
of spatial metadata standards. A standardized ontol-
regarding its size, geometrical shape, and orientation
ogy for spatial things that covers all the main require-
during surgery and exchange this information among
ments for publishing spatial linked data is not yet avail-
themselves and with doctors to conduct an operation
able, and best practices on the consistent use of the
with high precision and low latency. A self-driving
existing spatial vocabularies are yet to be established.
wheelchair or a self-driving car will be able to com-
Finally, there are new approaches emerging such as
municate with other sensor objects regarding the sur-
QB4ST [68], an extension to the RDF Data Cube to
rounding environment and direction to avoid obstacles.
provide mechanisms for defining spatio-temporal as-
This will prevent possible accidents and harm caused
pects of dimension and measure descriptions.
by machines, such as not falling down stairs or run-
ning into objects with high speed or force. In all these Notwithstanding these gaps and emerging solutions,
scenarios, lightweight representation and exchange of a useful set of actionable best practices for publishing
temporal-spatial knowledge are essential to understand spatial data on the Web has been described. Following
and react fast enough to prevent disasters or to control these guidelines will enable data users, Web applica-
the movement of devices. Having the means to repre-
sent the semantics of activities and phenomena at such 25 https://www.w3.org/2017/sdwig/charter.html
18 L. van den Brink et al. / Best Practices for Publishing, Retrieving, and Using Spatial Data on the Web
tions and services to discover, interpret and use spatial [14] M. Müller, Symbology Encoding Implementation Specifica-
data in large and distributed Web systems. tion, OpenGIS
R
Implementation Standard, OGC, 2006. http:
//www.opengis.net/doc/IS/se/1.1.
[15] D. Burggraf, OGC KML 2.3, OGC
R
Implementation Stan-
dard, OGC, 2015. http://www.opengis.net/doc/IS/kml/2.3.
Acknowledgements [16] ISO/TC 211, ISO 19103:2015 Geographic information – Con-
ceptual schema language, ISO Standard, International Orga-
The authors express their sincere gratitude to all nization for Standardization (ISO), 2015. https://www.iso.org/
the participants in the W3C/OGC Spatial Data on the standard/56734.html.
[17] ISO/TC 211, ISO 19107:2003 Geographic information – Spa-
Web Working Group, who contributed to the work dis-
tial schema, ISO Standard, International Organization for Stan-
cussed in this paper. The authors acknowledge partial dardization (ISO), 2003. https://www.iso.org/standard/26012.
support from NSF (award number 1540849). html.
[18] ISO/TC 211, ISO 19109:2015 Geographic information – Rules
for application schema, ISO Standard, International Organi-
zation for Standardization (ISO), 2015. https://www.iso.org/
References
standard/59193.html.
[19] ISO/TC 211, ISO 19110:2005 Geographic information –
[1] K. Taylor and E. Parsons, Where Is Everywhere: Bring-
Methodology for feature cataloguing, ISO Standard, Interna-
ing Location to the Web, IEEE Internet Computing 19(2)
tional Organization for Standardization (ISO), 2005. https://
(2015), 83–87. doi:10.1109/MIC.2015.50. https://doi.org/10.
www.iso.org/standard/39965.html.
1109/MIC.2015.50.
[20] C. Portele, OpenGIS
R
Geography Markup Language (GML)
[2] I. Masser, All shapes and sizes: the first generation of
Encoding Standard. Version: 3.2.1, OpenGIS
R
Standard,
national spatial data infrastructures, International Journal
OGC, 2007. http://www.opengis.net/doc/IS/gml/3.2.1.
of Geographical Information Science 13(1) (1999), 67–
[21] ISO/TC 211, ISO 19111:2005 Geographic information – Spa-
84. doi:10.1080/136588199241463. https://doi.org/10.1080/
tial referencing by coordinates, ISO Standard, International Or-
136588199241463.
ganization for Standardization (ISO), 2005. https://www.iso.
[3] J. Tandy, L. van den Brink and P. Barnaghi, Spatial Data on the
org/standard/26016.html.
Web Best Practices, W3C Working Group Note, W3C, 2017.
[22] ISO/TC 211, ISO 19111:2007 Geographic information – Spa-
https://www.w3.org/TR/2017/NOTE-sdw-bp-20170928/.
tial referencing by coordinates, ISO Standard, International Or-
[4] ISO/TC 211, ISO 19115:2003 Geographic information – Meta-
ganization for Standardization (ISO), 2007. https://www.iso.
data, ISO Standard, International Organization for Standard-
ization (ISO), 2003. https://www.iso.org/standard/26020.html. org/standard/41126.html.
[5] ISO/TC 211, ISO 19115-1:2014 Geographic information – [23] F. Knibbe and A. Llaves, Spatial Data on the Web Use Cases &
Metadata – Part 1: Fundamentals, ISO Standard, International Requirements, W3C Working Group Note, W3C, 2016. https:
Organization for Standardization (ISO), 2014. https://www.iso. //www.w3.org/TR/2016/NOTE-sdw-ucr-20161025/.
org/standard/53798.html. [24] Y. Fathy, P. Barnaghi and R. Tafazolli, Large-Scale Indexing,
[6] ISO/TC 211, ISO 19119:2016 Geographic information – Ser- Discovery and Ranking for the Internet of Things (IoT), ACM
vices, ISO Standard, International Organization for Standard- Computing Surveys (2017), (in press). http://epubs.surrey.ac.
ization (ISO), 2005. https://www.iso.org/standard/39890.html. uk/id/eprint/844698.
[7] ISO/TC 211, ISO 19119:2016 Geographic information – Ser- [25] J. Nogueras-Iso, F.J. Zarazaga-Soria, R. Béjar, P.J. Álvarez and
vices, ISO Standard, International Organization for Standard- P.R. Muro-Medrano, OGC Catalog Services: a key element for
ization (ISO), 2016. https://www.iso.org/standard/59221.html. the development of Spatial Data Infrastructures, Computers &
[8] D. Nebert, U. Voges and L. Bigagli, OGC
R
Catalogue Ser- Geosciences 31(2) (2005), 199–209, Geospatial Research in
vices 3.0 - General Model, OGC
R
Implementation Standard, Europe: AGILE 2003. doi:10.1016/j.cageo.2004.05.015. https:
OGC, 2016. http://www.opengis.net/doc/IS/cat/3.0. //doi.org/10.1016/j.cageo.2004.05.015.
[9] J. de la Beaujardiere, OpenGIS Web Map Server Implemen- [26] R. Cyganiak, D. Wood and M. Lanthaler, RDF 1.1
tation Specification, OpenGIS
R
Implementation Standard, Concepts and Abstract Syntax, W3C Recommen-
OGC, 2006. http://www.opengis.net/doc/IS/wms/1.3. dation, W3C, 2014. http://www.w3.org/TR/2014/
[10] P.A. Vretanos, OpenGIS Web Feature Service 2.0 Interface REC-rdf11-concepts-20140225/.
Standard, OpenGIS
R
Implementation Standard, OGC, 2010. [27] M. Perry and J. Herring, GeoSPARQL - A Geographic Query
http://www.opengis.net/doc/IS/wfs/2.0. Language for RDF Data. Version 1.0, OGC
R
Implemen-
[11] P. Baumann, OGS
R
Web WCS 2.0 Interface Standard - Core, tation Standard, OGC, 2010. http://www.opengis.net/doc/IS/
version 2.0.1, OGS
R
Implementation Standard, OGC, 2012. geosparql/1.0.
http://www.opengis.net/doc/IS/wcs-core-2.0.1. [28] I. Jacobs and N. Walsh, Architecture of the World Wide Web,
[12] ISO/TC 211, ISO 19117:2012 Geographic information – Por- Volume One, W3C Recommendation, W3C, 2004. http://www.
trayal, ISO Standard, International Organization for Standard- w3.org/TR/2004/REC-webarch-20041215/.
ization (ISO), 2012. https://www.iso.org/standard/46226.html. [29] B. Hyland, G. Atemezing and B. Villazón-Terrazas, Best
[13] M. Lupp, Styled Layer Descriptor profile of the Web Map Ser- Practices for Publishing Linked Data, W3C Working
vice Implementation Specification, OGC
R
Implementation Group Note, W3C, 2014. http://www.w3.org/TR/2014/
Standard, OGC, 2007. http://www.opengis.net/doc/IS/sld/1.1. NOTE-ld-bp-20140109/.
L. van den Brink et al. / Best Practices for Publishing, Retrieving, and Using Spatial Data on the Web 19
[30] B. Farias Lóscio, C. Burle and N. Calegari, Data on the Web [46] L. van den Brink, P. Janssen, W. Quak and J. Stoter, Link-
Best Practices, W3C Recommendation, W3C, 2017. https:// ing spatial data: automated conversion of geo-information
www.w3.org/TR/2017/REC-dwbp-20170131/. models and GML data to RDF, International Journal of
[31] W.R. Tobler, A Computer Movie Simulating Urban Spatial Data Infrastructures Research 9 (2014), 59–85.
Growth in the Detroit Region, Economic Geogra- doi:10.2902/1725-0463.2014.09.art3. https://doi.org/10.2902/
phy 46(sup1) (1970), 234–240. doi:10.2307/143141. 1725-0463.2014.09.art3.
https://doi.org/10.2307/143141. [47] C.C. Aggarwal, N. Ashish and A.P. Sheth, The Internet of
[32] W. Li, M. Song, B. Zhou, K. Cao and S. Gao, Per- Things: A Survey from the Data-Centric Perspective, in: Man-
formance improvement techniques for geospatial web ser- aging and Mining Sensor Data, C.C. Aggarwal, ed., Springer,
vices in a cyberinfrastructure environment - A case 2013, pp. 383–428. doi:10.1007/978-1-4614-6309-2_12. https:
study with a disaster management portal, Computers, //doi.org/10.1007/978-1-4614-6309-2_12.
Environment and Urban Systems 54 (2015), 314–325. [48] U. Ramer, An iterative procedure for the polygonal ap-
doi:10.1016/j.compenvurbsys.2015.04.003. https://doi.org/10. proximation of plane curves, Computer Graphics and Im-
1016/j.compenvurbsys.2015.04.003. age Processing 1(3) (1972), 244–256. doi:10.1016/S0146-
[33] D. Brickley, Basic Geo (WGS84 lat/long) Vocabulary, W3C In- 664X(72)80017-0. https://doi.org/10.1016/S0146-664X(72)
cubator Group Report, W3C, 2006. https://www.w3.org/2003/ 80017-0.
01/geo/. [49] D.H. Douglas and T.K. Peucker, Algorithms for the Reduc-
[34] J. Lieberman, R. Singh and C. Goad, W3C Geospatial Vo- tion of the Number of Points Required to Represent a Digi-
cabulary, W3C Incubator Group Report, W3C, 2007. https: tized Line or its Caricature, The Canadian Cartographer 10(2)
//www.w3.org/2005/Incubator/geo/XGR-geo/. (1973), 112–122. doi:10.3138/FM57-6770-U75U-7727. https:
[35] A. Perego and M. Lutz, ISA Programme Location Core Vocab- //doi.org/10.3138/FM57-6770-U75U-7727.
ulary, Namespace Document, European Commission, 2015. [50] M. Visvalingam and J.D. Whyatt, Line generalisation by re-
https://www.w3.org/ns/locn. peated elimination of points, The Cartographic Journal 30(1)
[36] H. Butler, M. Daly, A. Doyle, S. Gillies, S. Hagen and (1993), 46–51. doi:10.1179/000870493786962263. https://doi.
T. Schaub, The GeoJSON Format, RFC 7946, IETF, 2016. org/10.1179/000870493786962263.
https://www.rfc-editor.org/info/rfc7946. [51] ISO/TC 211, ISO 19123:2005 Geographic information –
[37] S. Das, S. Sundara and R. Cyganiak, R2RML: RDB to RDF Schema for coverage geometry and functions, ISO Standard,
Mapping Language, W3C Recommendation, W3C, 2012. http: International Organization for Standardization (ISO), 2005.
//www.w3.org/TR/2012/REC-r2rml-20120927/. https://www.iso.org/standard/40121.html.
[38] Schema.org. http://schema.org/. [52] D. Brizhinev, S. Toyer and K. Taylor, Publishing and Using
[39] M. Sporny, G. Kellogg and M. Lanthaler, JSON-LD Earth Observation Data with the RDF Data Cube and the Dis-
1.0. A JSON-based Serialization for Linked Data, W3C crete Global Grid System, W3C Working Group Note, W3C,
Recommendation, W3C, 2014. http://www.w3.org/TR/2014/ 2017. https://www.w3.org/TR/2017/NOTE-eo-qb-20170928/.
REC-json-ld-20140116/. [53] M.K. Bergman, The Deep Web: Surfacing Hidden Value,
[40] W3C SPARQL Working Group, SPARQL 1.1 Overview, W3C White Paper, BrightPlanet, 2012. https://brightplanet.com/
Recommendation, W3C, 2013. http://www.w3.org/TR/2013/ 2012/06/the-deep-web-surfacing-hidden-value/.
REC-sparql11-overview-20130321/. [54] B. He, M. Patel, Z. Zhang and K.C.-C. Chang, Ac-
[41] F. Maali and J. Erickson, Data Catalog Vocabulary (DCAT), cessing the Deep Web, Commun. ACM 50(5) (2007),
W3C Recommendation, W3C, 2014. http://www.w3.org/TR/ 94–101. doi:10.1145/1230819.1241670. http://doi.acm.org/10.
2014/REC-vocab-dcat-20140116/. 1145/1230819.1241670.
[42] ISA GeoDCAT-AP Working Group, GeoDCAT-AP: A geospa- [55] J. Madhavan, D. Ko, Ł. Kot, V. Ganapathy, A. Rasmussen and
tial extension for the DCAT application profile for data portals A. Halevy, Google’s Deep Web Crawl, Proc. VLDB Endow.
in Europe. Version 1.0.1, ISA Specification, European Com- 1(2) (2008), 1241–1252. doi:10.14778/1454159.1454163.
mission, 2016. https://joinup.ec.europa.eu/release/geodcat-ap/ https://doi.org/10.14778/1454159.1454163.
v101. [56] R.V. Guha, D. Brickley and S. Macbeth, Schema.org: Evo-
[43] R. Albertoni and A. Isaac, Data on the Web Best lution of Structured Data on the Web, Commun. ACM 59(2)
Practices: Data Quality Vocabulary, W3C Working (2016), 44–51. doi:10.1145/2844544. https://doi.org/10.1145/
Group Note, W3C, 2016. https://www.w3.org/TR/2016/ 2844544.
NOTE-vocab-dqv-20161215/. [57] C. McCathie Nevile and D. Brickley, HTML Microdata,
[44] R. Battle and D. Kolas, Enabling the Geospatial Semantic Web W3C Working Draft, W3C, 2017. https://www.w3.org/TR/
with Parliament and GeoSPARQL, Semantic Web Journal 3(4) 2017/WD-microdata-20171010/.
(2012), 355–370. doi:10.3233/SW-2012-0065. https://doi.org/ [58] M. Sporny, HTML+RDFa 1.1 – Second Edition, W3C
10.3233/SW-2012-0065. Recommendation, W3C, 2015. http://www.w3.org/TR/2015/
[45] S. Athanasiou, L. Bezati, G. Giannopoulos, K. Patroumpas REC-html-rdfa-20150317/.
and D. Skoutas, GeoKnow - Making the Web an Ex- [59] J.R. Herring, OpenGIS
R
Implementation Standard for Geo-
ploratory Place for Geo-spatial Knowledge. Market and graphic information - Simple feature access - Part 1: Common
Research Overview, Project Deliverable, GeoKnow FP7 architecture, Version 1.2.1, OpenGIS
R
Implementation Stan-
Project, 2013. http://svn.aksw.org/projects/GeoKnow/Public/ dard, OGC, 2011. http://www.opengeospatial.org/standards/
D2.1.1_Market_and_Research_Overview.pdf. sfa.
20 L. van den Brink et al. / Best Practices for Publishing, Retrieving, and Using Spatial Data on the Web
[60] G. Atemezing and R. Troncy, Comparing vocabularies for rep- national Conference on Semantic Sensor Networks - Volume
resenting geographical features and their geometry, in: ISWC 904, SSN’12, CEUR-WS.org, 2012, pp. 1–16. http://ceur-ws.
2012, 11th International Semantic Web Conference, Terra org/Vol-904/paper10.pdf.
Cognita Workshop, Volume 901, Boston, US, 2012. http:// [68] R. Atkinson, QB4ST: RDF Data Cube extensions for spatio-
ceur-ws.org/Vol-901/paper1.pdf. temporal components, W3C Working Group Note, W3C, 2017.
[61] ISA Action ARe3NA, Guidelines for the RDF encoding of spa- https://www.w3.org/TR/2017/NOTE-qb4st-20170928/.
tial data, Technical specification, European Commission, 2017. [69] M. Jaber, M.A. Imran, R. Tafazolli and A. Tukmanov,
http://inspire-eu-rdf.github.io/inspire-rdf-guidelines. 5G Backhaul Challenges and Emerging Research Direc-
[62] A. Perego, V. Cetl, A. Friis-Christensen and M. Lutz, tions: A Survey, IEEE Access 4 (2016), 1743–1766.
GeoDCAT-AP: Representing geographic metadata by us- doi:10.1109/ACCESS.2016.2556011. https://doi.org/10.1109/
ing the “DCAT application profile for data portals in Eu- ACCESS.2016.2556011.
rope”, in: Joint UNECE/UNGGIM Europe Workshop on In- [70] P. Barnaghi and A. Sheth, The Internet of Things:
tegrating Geospatial and Statistical Standards, Stockholm, The Story So Far, IEEE Internet of Things eNewslet-
Sweden, 2017. http://publications.jrc.ec.europa.eu/repository/ ter (2014). https://iot.ieee.org/newsletter/september-2014/
handle/JRC107410. the-internet-of-things-the-story-so-far.html.
[63] European Union, Establishing an Infrastructure for Spatial In- [71] M. Simsek, A. Aijaz, M. Dohler, J. Sachs and
formation in the European Community (INSPIRE), Directive G. Fettweis, 5G-Enabled Tactile Internet, IEEE Jour-
2007/2/EC of the European Parliament and of the Council, 14 nal on Selected Areas in Communications 34(3)
March 2007, Official Journal of the European Union 50(L 108) (2016), 460–473. doi:10.1109/JSAC.2016.2525398.
(2007), 1–14. http://data.europa.eu/eli/dir/2007/2/oj. https://doi.org/10.1109/JSAC.2016.2525398.
[64] A. Perego, A. Friis-Christensen and M. Lutz, GeoDCAT-AP: [72] J. Tomkins and D. Lowe, Timeseries Profile of Observa-
Use cases and open issues, in: Smart Descriptions & Smarter tions and Measurements. Version 1.0, OGC
R
Implemen-
Vocabularies (SDSVoc), Amsterdam, Netherlands, 2016. http: tation Standard, OGC, 2016. http://www.opengis.net/doc/IS/
//publications.jrc.ec.europa.eu/repository/handle/JRC103804. timeseries-profile-om/1.0.
[65] I. Faniel, J. Pullmann and R. Atkinson, Dataset Exchange Use [73] H. Hayashi, A. Asahara, K.-S. Kim, R. Shibasaki and N. Ishi-
Cases and Requirements, W3C Working Group Note, W3C, maru, OGC Moving Features Access. Version 1.0, OGC
R
Im-
2017. https://www.w3.org/TR/dcat-ucr/. plementation Standard, OGC, 2017. http://www.opengis.net/
[66] R. Cyganiak and D. Reynolds, The RDF Data Cube vocabu- doc/IS/movingfeatures-access/1.0.
lary, W3C Recommendation, W3C, 2014. http://www.w3.org/ [74] A. Aijaz, M. Simsek, M. Dohler and G. Fettweis, Shaping
TR/2014/REC-vocab-data-cube-20140116/. 5G for the Tactile Internet, in: 5G Mobile Communications,
[67] L. Lefort, J. Bobruk, A. Haller, K. Taylor and A. Woolf, W. Xiang, K. Zheng and X.S. Shen, eds, Springer, 2017,
A Linked Sensor Data Cube for a 100 Year Homogenised pp. 677–691. doi:10.1007/978-3-319-34208-5_25. https://doi.
Daily Temperature Dataset, in: Proceedings of the 5th Inter- org/10.1007/978-3-319-34208-5_25.