InSDIs information about spatial datasets is published as authoritative metadata records and collated in Web-based catalogues. This approach causes several problems:

1. the catalogues are often designed to primarily support expert users — people may not even be aware of their existence;
2. once you have discovered a dataset that meets your needs and identified where it is available from, a second step is required to access the data itself — often requiring the use of unfamiliar protocols or complexAPI requests; and
3. the data itself is not indexed — discovery relies on the metadata records that are often sparsely populated or out of date.

Search engines are the common starting point for people looking for content on the Web that is widely understood. By publishingspatial data in a way that enables their crawlers to index spatial datasets including eachSpatial Thing, the fidelity of search results should improve. Users will be able to directly search for specific entities rather than having to look for a dataset and then parse through it; e.g. to search for "Anne Frank’s House" (https://g.co/kg/m/02s5hd) rather than looking for a dataset about "Cultural Heritage in Amsterdam" and hoping that it contains a reference to what you’re interested in.

Information about spatial datasets and things is indexed by search engines.

Users can findSpatial Things using common search engines.

That is, your data is more findable.

In general, you need to:

1. publish a HTML Web-page for the spatial dataset and eachSpatial Thing that it describes; and
2. make sure that those pages can be crawled.

The Web-page for the dataset is an entry point for humans to browse and for the search engines to crawl your data. This landing page should provide descriptive metadata that helps users evaluate whether the dataset meets their needs (seeBest Practice 15: Include spatial metadata in dataset metadata and [DWBP]Best Practice 2: Provide descriptive metadata), and may providelinks to other service end-points,APIs or tools that will help a user work with the dataset. When metadata for datasets has already been created, e.g. to create a record in a metadata catalogue or to describe the data available from a service end-point, this information should be re-used — publishing it in a Web-friendly way that humans and Web-crawlers can consume. The landing page should be indexable by the search engines so that it can be discovered too!

To enable humans and Web-crawlers to find HTML pages for theSpatial Things, the "landing page" needs to include hyperlinks that can be followed. Where you have a larger collection of Spatial Things, you should support paging through the collection.

You may also consider usingSitemaps to direct the Web-crawler. For larger datasets, multiple sitemaps can be provided and grouped by a sitemap index file. If a dataset contains millions ofSpatial Things (e.g. a building dataset with national extent), generating and maintaining the sitemaps may require a custom implementation to keep the sitemaps with the set of Spatial Things synchronized.

For very large datasets paging through thousands of pages is not useful for a human either. Consider supporting filtering and/or organize theSpatial Things into subsets, as described in13.4Spatial data access.

In case of an address dataset, you could organize theSpatial Things (the addresses) by municipality, postcode and street name to support a human user to get to a building with a few clicks.

A pre-condition for this best practice isBest Practice 1: Use globally unique persistent HTTP URIs for Spatial Things as persistent identifiers are essential to support reliable indexing and linking. Traditionally spatial datasets have not been maintained with stable identifiers forSpatial Things, but to sharespatial data on the Web stable identifiers are a must. Sharing spatial data is more than "just" making the dataset available on the Web.

Each Web-page, and the hyperlinks used to relate theSpatial Things to the dataset landing page, can likely be generated programmatically from the data you hold about the Spatial Thing, either directly from the data or by using anAPI that makes the data available on the Web.

Possible implementation approaches for addressing this best practice in the context of an existingSDI are discussed in more detail inBest Practice 13: Expose spatial data through 'convenienceAPIs' for additional information. For example, by using a proxy tool likeldproxy or by mapping the data in theSDI dynamically to crawlable resources on the Web using the [R2RML] standard and Linked Data Publication tools. Both approaches generate crawlable data fromSpatial Things in your spatial datasets at query time and allow to enrich the data on the Web with additional information andlinks.

It is important to keep in mind that the HTML representations should not mainly be designed for search engines, but they should present the data in a clear and understandable way to human users. The page about theSpatial Thing should be useful to a user and encourage others to link to the page when they share other information about the Spatial Thing. This typically will also improve the ranking of these pages in search results.

TheNanaimo Parks Search, Canada provides a landing page and one page per park. The landing page offers a search capability and the option to select from a map. This data is indexed; a search for, for example, "Planta Park, Nanaimo" in a popular search engine returns the Nanaimo data for thisSpatial Thing as one of the first results.

TheBathing Water Quality Explorer for England provides a landing page and one page per site. Sites can be searched, selected from a list or in a map.

In both cases, the pages of theSpatial Things are generated from the underlying data at request time.

The property Web-pages in Nanaimo also use [MICRODATA] annotations using [SCHEMA-ORG], which is discussed below.

In addition to exposing thespatial data as linked HTML Web-pages, indexing by Web-engines can be further enhanced by incorporating a description of theSpatial Thing as structured markup (in particular [MICRODATA] or [JSON-LD] annotations using [SCHEMA-ORG]) as this enables the search engines to make more detailed assumptions about your resource. It is important to note that this is not only helpful to search engines, but also to other tools that want to understand more about the semantics of the resource, for example, its location.

In [SCHEMA-ORG], a spatial dataset is aDataset and aSpatial Thing is in general aPlace or anEvent. For some types of Spatial Things, more specific sub-types exist, for exampleCity orMountain.

Location information about aSpatial Thing is typically provided using ageometry (GeoCoordinates orGeoShape) or aPostalAddress. [SCHEMA-ORG] coordinates are restricted to WGS 84 withlongitude andlatitude. Supported geometry types are points, line strings, polygons, boxes and circles.

By using [SCHEMA-ORG] annotations, search engines, and others can connect location information with other information, e.g. about the nature of theSpatial Thing, opening hours, contact details, etc.

The use of [SCHEMA-ORG] forspatial data is in its early days and should be understood as an "emerging practice".

This code-snippet illustrates a [JSON-LD] annotation using a [SCHEMA-ORG]Dataset for an address dataset in the Netherlands that may be embedded in the HTML of the Web-page. It includes a name, a description, the spatial extent using a bounding box, the URL of the Web-page, and alink to another dataset containing this dataset. The same annotation could also be provided using [MICRODATA], but we use [JSON-LD] here as this presents the structured data in a more human-readable way.

<scripttype="application/ld+json">{"@context" : {"@vocab" :"http://schema.org/"  },"@type" :"Dataset","@id" :"http://www.ldproxy.net/bag/inspireadressen/","name" :"Adressen","description" :"INSPIRE Adressen afkomstig uit de basisregistratie Adressen, beschikbaar voor heel Nederland","url" :"http://www.ldproxy.net/bag/inspireadressen/","isPartOf" : {"@type" :"Dataset","url" :"http://www.ldproxy.net/bag/"  },"keywords" :"Adressen","spatialCoverage" : {"@type" :"Place","geo" : {"@type" :"GeoShape","box" :"47.975,3.053 53.504,7.24"    }  }}</script>

This code-snippet illustrates a [JSON-LD] annotation using a [SCHEMA-ORG]Place for the address of the "Anne Frank’s House" in that dataset. It includes the location, the URL of the Web-page, and the structured postal address information.

<scripttype="application/ld+json">{"@context" : {"@vocab" :"http://schema.org/"  },"@type" :"Place","@id" :"http://www.ldproxy.net/bag/inspireadressen/inspireadressen.3329155","url" :"http://www.ldproxy.net/bag/inspireadressen/inspireadressen.3329155","geo" : {"@type" :"GeoCoordinates","longitude" :"4.88399","latitude" :"52.37520"  },"name":"Anne Franks House","description":"Museum house where Anne Frank & her family hid from the Nazis in a secret annex, during WWII.","address" : {"@type" :"PostalAddress","streetAddress" :"Prinsengracht 267","addressLocality" :"Amsterdam","postalCode" :"1016GV"  }}</script>

The Web-pages should also provide a mechanism to download data in the formats you decide to support. [DWBP]Best Practice 14: Provide data in multiple formats provides guidance.

Typically, multiple formats for a resource are supported using two mechanisms: HTTP content negotiation and by adding format-specific file extensions to the resource URI like ".json", ".xml" or ".ttl". Content negotiation is the standard mechanism of HTTP and the format-specific URIs enable the use of clickablelinks to the resource in a specific format.

Search engines may also index resource representations in other formats than HTML.

At the time of writing, Google is indexing [KML] documents and supporting advanced searches that are restricted to KML documents. [GML] files are also indexed, but only like any otherXML [XML11] documents.JSON [RFC7159], including GeoJSON [RFC7946], is currently not indexed.

Using a Web browser,

1. Search for the landing page of your dataset, and
2. Check that you can browse to human-readable HTML pages for eachSpatial Thing that the dataset describes.

Monitor the search consoles of the search engines about the progress in indexing your Web-pages and their structured data. In case any errors are reported, try to fix them.

Relevant requirements:R-BoundingBoxCentroid,R-Crawlability,R-Discoverability,R-Linkability,R-MachineToMachine.

• Discoverability
• Reuse
• 
• 

Spatial data is used by a range of user communities, each with their own purposes, knowledge and preferred tools. Data publishers should consider which communities and purposes they want to serve and make appropriate choices for the approach to encoding data. In general terms, data usefulness is increased when it can be used for more purposes. This might involve providing data in several different formats. (See [DWBP]Best Practice 14: Provide data in multiple formats.)

Spatial data can be used easily and reliably by the target users.

Your data is more interoperable.

A high-level objective of these best practices is to highlight approaches that data publishers can take to maximize the ease of use of theirspatial data via the Web and hence present data in a way that meets the needs of as wide a range of users and applications as possible.

One way of classifying the applications of spatial data is as follows:

1. Web pages for people to read aboutSpatial Things
2. Web mapping or visualization applications
3. Data integration — combining spatial data with other data
4. Spatial analytics — discover meaningful patterns in spatial data

Each of these has different needs: often it will be possible or desirable to support several of these application groups.

The main objective is to encode data in a way that recipients can easily decode and understand. To decide this, you need to consider which purpose(s) and which audience(s) you are aiming to serve and the characteristics of the data that you want to share. For example:

• the volume of data
• how many spatialdimensions it covers (points, lines, areas, 3D)
• what kind of area it covers (one building, a town, a whole country)
• how frequently it changes
• the level of spatial precision that exists in the data and the precision needed by users

InBest Practice 1: Use globally unique persistent HTTP URIs for Spatial Things, we recommend the use of HTTP URIs as a way of assigning identifiers toSpatial Things. The data publisher should offer the ability to look up ('dereference') such a URI to find out useful information about thatSpatial Thing in human readable form (as well as machine readable formats — see the discussion below on data integration). EachSpatial Thing therefore gets its own Web page — in addition it might be useful to have Web pages about groups ofSpatial Things, but the 'page per thing' approach enables fine-grained linking of information.

To promote the discovery of such Web pages in search engines, each page should contain a clear text description of what it is, ideally in a way that distinguishes it from pages about other similarSpatial Things. Including metadata using the [SCHEMA-ORG] vocabulary, embedded as [MICRODATA], [HTML-RDFa] or as [JSON-LD] in the<head> section of the page can provide additional information to search engines to support more precise indexing. SeeBest Practice 2: Make your spatial data indexable by search engines for a more detailed discussion.

It is also very useful in such Web pages to includelinks to descriptions of theSpatial Thing in other formats (typically machine-readable formats) as well as linking to relatedSpatial Things.

In most cases, a web page about a Spatial Thing should include information on its location. This can be done by providing spatial coordinates (seeBest Practice 7: Choose coordinate reference systems to suit your user's applications for guidance on how to do this).

A common way of specifying the location of a building is to use its postal address. Most spatial applications require an address to be turned into spatial coordinates, so that its location can be marked on a map, or compared with locations of other things, a process known asgeocoding. Although a publisher could leave this process of geocoding to the data user, ideally the publisher should take responsibility for this as they are in a better position to check the accuracy of the results. Different ways of specifying addresses can sometimes lead to errors in the geocoding process.

Other approaches can be taken to specifying location.What3words is an example of a service that assigns an alternative kind of address to a location — in this case a sequence of three common words associated with a 3m by 3m square on the ground. It allows every location to be given such an address and what3words also provides a means to relate the address tolatitude andlongitude coordinates. Like conventional addresses, converting to coordinates is necessary for many spatial data applications (e.g. to calculate the distance between points or whether a point is inside a region), but the process of conversion is more reliable and precise.

Wikipedia includes web pages about many Spatial Things, for exampleFlorence Cathedral. This page provides latitude and longitude coordinates for the cathedral, as well as linking to other pages about the city of Florence and the region of Tuscany. It would be better if typical Wikipedia pages about Spatial Things were explicit about the coordinate reference system used. However, a link is also provided to the 'Geohack' service which provides detailed location information, including the CRS.

A common application ofspatial data on the Web is delivering map data in a tiled form, suitable for display in zoomable 'slippy maps'. TheOGC'sWeb Map Tile Service [WMTS] is an established standard for doing this. Other approaches in common use includeMBTiles or 'Tile layers' inGoogle MapsAPIs

Another frequent requirement is to draw markers or polygons on top of a Web map. A typical approach is for the browser to display a base map, then separately retrieve data aboutSpatial Things of interest, typically as GeoJSON [RFC7946], [GeoRSS] feeds, [GML] using the Simple Features profile [GML-SF] or [KML] files, then combine the two using appropriate JavaScript libraries. For applications involving boundary polygons of geographical areas, a common consideration is how to make this process efficient at different zoom levels. A high level of detail is appropriate when zoomed in, but many areas may be visible when zoomed out, and delivering boundaries of all of those at full detail can lead to very large amounts of data and hence poor performance, so simplified lower resolution versions of polygons may be required.

See thiscomparison of different spatial data formats to help guide the choice of which approach is best suited to your purpose.

d3.js is a widely used JavaScript library for creating visualizations in web pages. Thistutorial by Mike Bostock describes how to use D3 to work with geometrical data and display it in a web page.

Many important applications ofspatial data involve combining it with other kinds of data: for example, opening times of nearby supermarkets, or statistical information on the economy of a town. Often one or moreSpatial Things are at the center of the data analysis process.

Other applications involve distinguishing or selectingSpatial Things according to their non-spatial characteristics: hospitals with an emergency department or restaurants that serve Japanese food.

To enable such questions to be answered using data from different sources, it is important to describeSpatial Things using shared identifiers and vocabularies. This is described in [DWBP]Best Practice 10: Use persistent URIs as identifiers within datasets and [DWBP]Best Practice 15: Reuse vocabularies, preferably standardized ones.

From aspatial data perspective, the question of identifiers is discussed inBest Practice 1: Use globally unique persistent HTTP URIs for Spatial Things. How to relate aSpatial Thing to itsgeometry is described inBest Practice 5: Provide geometries on the Web in a usable way.

A common approach to encoding data to enable data integration isLinked Data [LD-BP] andRDF [RDF11-PRIMER]. The spatial aspects of the data can either be included in the RDF data model, or the entity in question can link to an external Web resource containing thegeometry in one of the standard spatial data formats. Although RDF is well-suited to important aspects of best practice, including use of URIs as identifiers and re-use of vocabularies, other data formats are also consistent with this approach. Most spatial data formats enable associating attributes of an entity alongside its geometry.

The publisher's choice of data model to represent the data will depend on what data is available and which audiences and purposes it seems most important to support. However, a reasonable general rule is that it is always useful to provide a label and a type for each entity in the data collection. (See [DWBP]Best Practice 16: Choose the right formalization level)

Common vocabularies for describing the address or location of aSpatial Thing include: [SCHEMA-ORG], [VCARD-RDF] and [LOCN]. See thiscomparison of different vocabularies for describing Spatial Things to help decide which is best for your application.

Publishing explicit relationships between the Spatial Thing of interest and other related Spatial Things helps support data integration applications: for example, providing hierarchical relationships between different kinds of administrative area.

The Scottish Government makes a lot of statistical data available via their websiteStatistics.gov.scot. Every statistical data point is referred to a geographical area, identified by an HTTP URI, making it easy to compare different datasets about an area of interest. See for example this page about theCity of Edinburgh Council Area.

Spatial analytics (or spatial analysis) is about deriving new insights by applying formal techniques to studySpatial Things using their topological or geometric properties. Combiningspatial data with other data (see item 3 above) is a typical preparatory step before analyzing the one or more datasets usingspatial operators, statistical algorithms, etc.

For spatial analytics on the Web, the data should be accessible via anAPI as described in13.4Spatial data access and results should be shared using the best practices described in this document. Currentspatial data infrastructures have some limitations with respect to sharing spatial data on the Web (as discussed in12.Why are traditional Spatial Data Infrastructures not enough?). Nonetheless this approach is a well-established and powerful way of distributingspatial data, based on open standards and suited to a community of expert users. It is thus one of the options a data publisher should consider when deciding how to encode theirspatial data.

In addition to publishing the data that represents the results of the analysis, maps and other forms of visualization (see item 2 above) are typically used to communicate the results.

The Meteorological Service of Canada (part of Environment and Climate Change Canada) publishes theirdaily climate observations as anOGCAPI - Features - Part 1: Core [OAF1] service. The landing page of the service can be requested with the following:

In addition,API conformance can be determined in the following way:

The four main classes of application above have a wide range of requirements. To support such a wide range may require a lot of effort and cost on behalf of a data publisher. There are many aspects to the 'quality' of aspatial data publishing approach, but in general terms it relates to how well the data and approach to data delivery meet the needs of the target audience. By choosing to concentrate on only some kinds of application the publisher can keep cost down. Other factors to consider include performance (speed with which data is delivered), timeliness of updates — which can be a significant consideration if the underlying data changes frequently, software complexity or maintenance.

In many cases a mixture of technologies can be used together to find a good compromise of quality or performance and cost. The strengths of various approaches can be applied to the part of the publishing 'spectrum' that suits them best. For example, if using aLinked Data approach, one option is to keep all data in atriple store; but hybrid approaches are also possible, for example where geometrical information is stored and served from flat files, or where non-geometrical data and metadata is stored in a triple store and used to generate Web pages and machine readable descriptions ofSpatial Things, while geometrical data is indexed by software such as Lucene Spatial, PostGIS or Elasticsearch. Use of shared Web-accessible identifiers forSpatial Things can help support the interconnections between a range of diverse information systems.

[EO-QB] describes a 'spectrum of linkiness' for coverage data. At one end of the spectrum, you can assign each individual data point or pixel within a coverage (such as a satellite image) an individual identifier and web page. At the other, you can link just to an entire dataset and provide metadata for that. An intermediate approach involves dividing the data into tiles, each of which can have its own identifier and metadata. The balance of quality and cost in this example corresponds to the size of tiles that can be individually referenced, described and retrieved.

Check if spatial data is encoded, so that it can be understood and re-used reliably.

Consider the main target audience or audiences of a web page or service, and check if spatial information is provided in a way appropriate for that audience.

Relevant requirements:R-DeterminableCRS,R-Discoverability,R-GeoreferencedData,R-Linkability,R-MachineToMachine,R-SpatialRelationships

• Comprehension
• Processability
• Reuse
• Interoperability
• Access
• 
• 
• 
• 
• 

The geospatial, Linked Data, and Web communities use differentgeometry formats and tools, which reflect different requirements with respect to data complexity and manipulation.

When deciding how ageometry should be described, it is therefore necessary to consider the intended uses and the related user communities. This may also imply providing alternative geometry descriptions.

This best practice helps with choosing the right format for describinggeometries, based on aspects like intended use(s), performance, and tool support. It also helps with deciding when encoding geometries as literals rather than as structured objects is a useful simplification.

The format chosen to express geometry data should:

• Support thedimensionality of thegeometry (from points — 0D — to volumes — 3D) — not all geometry formats support all dimensions.
• Support thecoordinate reference system you need.
• Be supported by the software tools used within particular data user communities — the geospatial and Web communities use different tools often suited to different geometry formats.
• Keep geometry definitions to a level of detail and size that is appropriate for the intended applications — Web applications do not typically require detailedgeometries.

Ideally, to enable their widest re-use,geometries should be described having in mind the geospatial, Linked Data and Web communities. This may not be always feasible, but the objective should at least be to describe geometries (also) for Web consumption.

Steps to follow:

• Identify the intended uses and applications. In particular, it is important to verify ifgeometries need to be used in one or more of the following scenarios:
  • specific geospatial applications;
  • linked data applications;
  • Web consumption.
• For each of the intended uses / applications, provide possibly alternative descriptions of geometries, considering:
  • The appropriategeometrydimensionality (0D — points, 1D — curves, 2D — surfaces, 3D — solids). See7.Spatial Things, Features and Geometry for more information.
  • The appropriatecoordinate reference system(s). See10.Coordinate Reference Systems (CRS) for more information.
  • The appropriate geometry encoding(s) / representation(s) — also considering the software tools that you anticipate your user community to employ. SeeA.Applicability of common formats to implementation of best practices for more information.
  • The appropriate level of detail. SeeBest Practice 6: Provide geometries at the right level of accuracy, precision, and size for more information.
• Where multiple representations are required, consider offering as many as you can — balancing the benefit of ease of use against the cost of the additional storage or additional processing if converting on-the-fly. See [DWBP] for more information.
  Note

  HTTP content negotiation only works for media type, character set, encoding, and language. Consequently, it is not possible to select one representation that conforms to a given "profile" (e.g. data model, complexity level,CRS) from several that all share the same media-type; e.g. asking for the GeoJSON [RFC7946] features with "simple"geometries (compacted polygons or just points) not the "complex" geometries; or asking for the representation that uses CRS84 not Amersfoort-RD.

It is important to note that the steps outlined above are interrelated. For instance, thedimensionality of ageometry determines the set ofcoordinate reference systems that can be used, as well as the geometry encodings / representations.

Another issue to be considered when choosing the geometry format is whether the coordinate axis order is unambiguous — i.e., whether the order of the position coordinates defining each geometry is, e.g.,longitude/latitude or latitude/longitude. This specific topic is covered byBest Practice 8: State how coordinate values are encoded.

Currently, there are two referencesgeometry formats widely used in the geospatial and Web communities, respectively, [GML] and GeoJSON [RFC7946].

[GML] provides the ability to express any type ofgeometry, in anycoordinate reference system, and up to 3dimensions (from points to solids) but is typically serialized inXML [XML11].

GeoJSON [RFC7946] supports only onecoordinate reference system (CRS84 — i.e., WGS 84 longitude/latitude), andgeometries up to 2 dimensions (points, lines, surfaces) but is serialized inJSON [RFC7159], which is often easier for browser-based Web applications to process.

To facilitate the use ofgeometry data on the Web as well inGIS, it is desirable that complex [GML]-encoded geometries be made available also in simplified form as GeoJSON [RFC7946], by applying any requiredcoordinate reference system transformation, as well as simplifying and generalizing the original geometry as needed (e.g., by transforming a 3D geometry into a 2D one). Simplified geometries may of course also be published in [GML], for example by conforming to the GML Simple Feature profile [GML-SF]. (On this topic, seeBest Practice 6: Provide geometries at the right level of accuracy, precision, and size).

Finally,RDF-based representations ofgeometries are used in the Linked Data community. This is achieved by using specific vocabularies, as [W3C-BASIC-GEO] (only for points), [GeoRSS] (points, lines, boxes, circles, polygons) or [GeoSPARQL] (for any simple features geometries). For a high-level comparison of common spatial data vocabularies, seeA.Applicability of common formats to implementation of best practices.

Thesegeometry representations are either stored with the related data, or are maintained separately, and possibly denoted with HTTP URIs (seeExample 22).

RDF representations ofgeometries can support mostgeometry types anddimensions (up to at least 2 dimensions), with any level of complexity, in anycoordinate reference system. On the other hand, many existingSemantic Web tools such astriple stores are currently not efficient enough to perform spatial queries which are complex and/or on complex geometries. It may therefore preferable to maintain geometries separately, in software platforms designed for these specific tasks.

It is nonetheless still desirable to make simplifiedgeometries available for Web consumption in GeoJSON [RFC7946] or embedded in Web pages.

The following [TURTLE] snippet shows the [GeoDCAT-AP] representation of the dataset inExample 12. Here the bounding box is provided in multiple literal encodings (WKT, [GML], GeoJSON [RFC7946]), by using propertydcat:bbox [VOCAB-DCAT-2].

@prefix dcat:      <http://www.w3.org/ns/dcat#> .@prefix dcterms:   <http://purl.org/dc/terms/> .@prefix geosparql: <http://www.opengis.net/ont/geosparql#> .@prefix locn:      <http://www.w3.org/ns/locn#> .<http://www.ldproxy.net/bag/inspireadressen/> a dcat:Dataset ;  dcterms:title "Adressen"@nl ;  dcterms:title "Addresses"@en ;  dcterms:description "INSPIRE Adressen afkomstig uit de basisregistratie Adressen,                   beschikbaar voor heel Nederland"@nl ;  dcterms:description "INSPIRE addresses derived from the Addresses base registry,                   available for the Netherlands"@en ;  dcterms:isPartOf <http://www.ldproxy.net/bag/> ;  dcat:theme <http://inspire.ec.europa.eu/theme/ad> ;  dcterms:spatial [    a dcterms:Location ;    dcat:bbox# Bounding box in WKT      "POLYGON((3.053 47.975,7.24 47.975,7.24 53.504,3.053 53.504,3.053 47.975))"^^geosparql:wktLiteral ,# Bounding box in GML      "<gml:EnvelopesrsName=\"http://www.opengis.net/def/crs/OGC/1.3/CRS84\"><gml:lowerCorner>3.053 47.975</gml:lowerCorner><gml:upperCorner>7.24  53.504</gml:upperCorner></gml:Envelope>"^^geosparql:gmlLiteral ,# Bounding box in GeoJSON      "{ \"type\":\"Polygon\",\"coordinates\":[[           [3.053,47.975],[7.24,47.975],[7.24,53.504],[3.053,53.504],[3.053,47.975]         ]] }"^^geosparql:geoJSONLiteral  ] .

In the above example, thecoordinate reference system used for the bounding box is CRS84 (equivalent to WGS 84, but with coordinate axis-order longitude/latitude), which is explicitly specified in the [GML] encoding via attribute@srsName, and by using the relevant HTTP URI from theOGC CRS registry. Thecoordinate reference system is not specified for theWKT encoding, since CRS84 is the defaultcoordinate reference system forWKT in [GeoSPARQL], and therefore it can be omitted. Thecoordinate reference system is also not specified in the GeoJSON [RFC7946] encoding, since CRS84 is the only supportedcoordinate reference system in GeoJSON [RFC7946]. From GeoSPARQL 1.1 onwards, coordinate reference systems of serializations of the same geometry are required to be the same if the serialization format supports the representation of the general coordinate reference system. In future iterations of GeoSPARQL, the coordinate reference system is likely to be represented completely in RDF.

Always with reference toExample 12, the following snippet shows the [GML] and theRDF [RDF11-PRIMER] representations of the entry in the BAG Dutch register concerning the building where Anne Frank's house is located. For the corresponding GeoJSON [RFC7946] representation, see the relevantexample inBest Practice 8: State how coordinate values are encoded.

A [GML] representation of Anne Frank's house building:

<bag:pandgml:id="pand.3323294"><bag:identificatie>363100012169587</bag:identificatie><bag:bouwjaar>1635</bag:bouwjaar><bag:status>Pand in gebruik (niet ingemeten)</bag:status><bag:gebruiksdoel>woonfunctie</bag:gebruiksdoel><bag:oppervlakte_min>1</bag:oppervlakte_min><bag:oppervlakte_max>21</bag:oppervlakte_max><bag:aantal_verblijfsobjecten>20</bag:aantal_verblijfsobjecten><bag:geometrie><gml:MultiSurfacesrsDimension="2"axisLabels="east north"srsName="urn:ogc:def:crs:EPSG::28992"><gml:surfaceMember><gml:PolygonsrsDimension="2"><gml:exterior><gml:LinearRing><gml:posList>                120749.725 487589.422  120752.55  487594.375  120751.227 487595.129                120732.539 487605.788  120723.505 487589.745  120721.387 487585.939                120740.668 487575.07   120743.316 487573.589  120747.735 487581.337                120751.564 487579.154  120755.411 487576.96   120750.935 487569.172                120755.941 487566.288  120764.369 487581.066  120749.725 487589.422</gml:posList></gml:LinearRing></gml:exterior></gml:Polygon></gml:surfaceMember></gml:MultiSurface></bag:geometrie></bag:pand>

The correspondingRDF representation is provided in the following [TURTLE] snippet (taken from theBAG Linked Data service). NB: The RDF representation below has been complemented with additional properties (marked with# Added) for demonstration purposes.

@prefix bag:       <http://bag.basisregistraties.overheid.nl/def/bag#> .@prefix dcterms:   <http://purl.org/dc/terms/> .@prefix geosparql: <http://www.opengis.net/ont/geosparql#> .@prefix gml-ont:   <http://www.opengis.net/ont/gml#> .@prefix locn:      <http://www.w3.org/ns/locn#> .@prefix rdfs:      <http://www.w3.org/2000/01/rdf-schema#> .@prefix schema:    <http://schema.org/> .@prefix w3cgeo:    <http://www.w3.org/2003/01/geo/wgs84_pos#> .<http://bag.basisregistraties.overheid.nl/bag/id/pand/0363100012169587>   a geosparql:Feature, bag:Pand ;  rdfs:label "Pand 0363100012169587"@nl;  rdfs:isDefinedBy <http://bag.basisregistraties.overheid.nl/bag/doc/2016083000000000/pand/0363100012169587> ;  bag:identificatiecode "0363100012169587"^^xsd:string;# Added  dcterms:identifier "363100012169587"^^xsd:string ;  bag:status <http://bag.basisregistraties.overheid.nl/id/begrip/PandInGebruik_nietIngemeten> ;  bag:oorspronkelijkBouwjaar "1635"^^xsd:gYear;# Added  dcterms:created "1635"^^xsd:gYear ;# Added  locn:address <http://www.ldproxy.net/bag/inspireadressen/inspireadressen.3329155> ;  geosparql:hasGeometry <http://bag.basisregistraties.overheid.nl/bag/id/geometry/5C1F8F11324717378B437B2CD12871FF> ;  bag:geometriePand <http://bag.basisregistraties.overheid.nl/bag/id/geometry/5C1F8F11324717378B437B2CD12871FF>.<http://bag.basisregistraties.overheid.nl/bag/id/geometry/5C1F8F11324717378B437B2CD12871FF>   a geosparql:Geometry, gml-ont:Surface ;  geosparql:asWKT     "POLYGON ((      4.8842353  52.375108 , 4.884276 52.375153 ,       4.8842567  52.375159 , 4.883981 52.375254 ,       4.8838502  52.375109 , 4.883819 52.375075 ,       4.8841037  52.374979 , 4.884143 52.374965 ,       4.8842069  52.375035 , 4.884263 52.375016 ,       4.8843200  52.374996 , 4.884255 52.374926 ,       4.8843289  52.374901 , 4.884451 52.375034 ,       4.8842353  52.375108    ))"^^geosparql:wktLiteral ;# Added  geosparql:asWKT     "<http://www.opengis.net/def/crs/EPSG/0/28992> POLYGON ((      120749.725 487589.422 , 120752.55 487594.375  ,         120751.227 487595.129 , 120732.539 487605.788 ,      120723.505 487589.745 , 120721.387 487585.939 ,       120740.668 487575.07  , 120743.316 487573.589 ,       120747.735 487581.337 , 120751.564 487579.154 ,       120755.411 487576.96  , 120750.935 487569.172 ,       120755.941 487566.288 , 120764.369 487581.066 ,       120749.725 487589.422    ))"^^geosparql:wktLiteral.

The differentWKT encodings in the example show alternative ways of specifying thecoordinate reference system used.

The two instances of propertygeosparql:asWKT follow the syntax recommended in [GeoSPARQL], where the specification of thecoordinate reference system is required only if different from CRS84. The coordinate axis-order used is determined here by thecoordinate reference system, and in both cases, it is longitude / latitude (more precisely, east/north for EPSG:28992).

Example 21 shows also howgeometries forSpatial Things can be published as separate Web resources. This approach can be particularly suitable for giving access to huge geometries, consisting of hundreds of vertex positions (as the detailedgeometry of the boundaries of a geographical region), without attaching them to the relevantSpatial Things. Moreover, this allows the same geometry to be linked from (i.e., re-used by) different Spatial Things. Finally, it is possible to use mechanisms (including HTTP content negotiation) to provide access to different representations / encodings of the geometry ([GML],WKT, GeoJSON [RFC7946], etc.) as media types, thus addressing different use cases. (On this topic, see alsoBest Practice 10: Use appropriate relation types to link Spatial Things).

The following URI:

https://data.kkg.kadaster.nl/id/gebouw/0200100000085932

denotes an office of the Dutch Kadaster in Apeldoorn. However, itsgeometry is provided as two separate, standalone resources, denoted by the following URIs:

https://data.kkg.kadaster.nl/id/gebouw/0200100000085932/bag-geometrie

https://data.kkg.kadaster.nl/id/gebouw/0200100000085932/bgt-geometrie

An additional example is theAPI of theGADM-RDF project provides an access to spatiallinked data concerning administrative areas. For instance, the following URIhttp://gadm.geovocab.org/id/0/60 returns a description of administrative area "Germany", which links to the geometry of Germany's boundaries, provided via a separate URI:http://gadm.geovocab.org/id/0/60/geometry.

Dereferencing thegeometry URIs operated by the GADM-RDFAPI returns different geometry representations / encodings (SVG included), that can be accessed via HTTP content negotiation or by appending the format extension to the URI. For instance, URIhttp://gadm.geovocab.org/id/0/60/geometry.geojson returns the GeoJSON [RFC7946] representation of the geometry. Directlinks to the supported geometry representations / encodings are specified in theRDF and HTML representations of the geometry.

Check if:

1. Geometries are made available in possibly different formats and levels of complexity, considering their intended uses and their consumption on the Web.
2. The chosengeometry descriptions comply withBest Practice 6: Provide geometries at the right level of accuracy, precision, and size,Best Practice 7: Choose coordinate reference systems to suit your user's applications, andBest Practice 8: State how coordinate values are encoded.
3. The (possibly) alternativegeometry descriptions can be accessible via standard mechanisms, as HTTP content negotiation.

Relevant requirements:R-MultipleCRSs,R-BoundingBoxCentroid,R-Compressible,R-CRSDefinition,R-EncodingForVectorGeometry,R-IndependenceOnReferenceSystems,R-MachineToMachine,R-SpatialMetadata,R-3DSupport,R-TimeDependentCRS,R-TilingSupport.

• Processability
• Reuse
• Interoperability
• Access
• 
• 
• 
• 

Geometry data always provide an approximate description of the shape andextent ofSpatial Things, which is fit for specific uses. For instance, portraying a geometry on a Web map would typically not require the level of detail that is needed for using the same geometry for spatial analysis. Moreover, although a 3D description of a geometry of a building might be available, a Web map would be typically capable of portraying just its 2-dimensional footprint.

Other issues to be taken into account are network bandwidth and the processing capabilities of the target tools. For instance, ageometry of a total size of 1GB or more, could be more efficiently transmitted after being compressed. On the other hand, a tool with limited processing capabilities (as a Web browser) may not be able to efficiently handle such geometry (e.g., for displaying it on a Web map).

This best practice complementsBest Practice 5: Provide geometries on the Web in a usable way by outlining some of the approaches that can be used to publish alternative versions ofgeometry data, with respect to the level of accuracy, precision, and size, fit for the most general use cases and the reference target communities.

Geometry data should be made available at (possibly different) levels of accuracy, precision, and size, taking into account:

• The required level of precision and accuracy of the intended use case(s).
• The processing capabilities of the target tools.
• Optimization in terms of network bandwidth consumption

As said inBest Practice 5: Provide geometries on the Web in a usable way, the requirements of the geospatial, Linked Data, and Web communities should be ideally taken into account also with respect to the accuracy, precision, and size ofgeometry data. Whenever this is not feasible, Web consumption requirements should at least be addressed.

A number of techniques can be used to deliver representations ofgeometries at an accuracy, precision, and size fitting the requirements of a given use case.

The following list, although not exhaustive, outlines the approaches most widely used, especially for the Web delivery and consumption ofgeometry data.

Choosing the right technique requires taking primarily into account whether the derivedgeometry is fit for the target use case. Technical limits — as network bandwidth and processing capabilities — are of course important, but secondary. Of course, the ideal situation is when you are able to find the technique offering the right trade-off between these two types of requirements.

Whatever option is used, the key requirement is that the derivedgeometry does not replace the original ones, but are made available as alternative representations.

Best Practice 5: Provide geometries on the Web in a usable way,Best Practice 16: Describe the positional accuracy of spatial data andBest Practice 13: Expose spatial data through 'convenienceAPIs' provide general guidelines that can be used for the publication of alternative representations ofgeometries, providing at the same time information on their characteristics. These include, but are not limited to, the use of different URIs for different representations, and HTTP content negotiation. Moreover, whenevergeometry is made available inRDF [RDF11-PRIMER], specific properties can be used to specify the geometry type and the level of accuracy and precision. More specific examples are included in the approaches described below.

1. Compressgeometry data

   Using standard compression algorithms, aszip andgzip, addresses the issue of efficient transmission ofgeometry data, without information loss. Notably, some formats come with alternative compressed encodings — e.g.,KMZ is used to deliver compressed [KML] data.

   Compression can be easily carried out on the fly, and it is also supported by the HTTP protocol via content negotiation — see [RFC2616],section 3.5: Content Codings.

2. Use formats optimizing access to and processing ofgeometry data

   Some formats support a more compact description ofgeometry data, which potentially results in reducing network bandwidth consumption and/or more efficient client-side processing.

   This is, for instance, the case ofTopoJSON, an extension to GeoJSON [RFC7946] which reduces redundancy in the description of a geometry, by splitting it into segments (referred to as "arcs") that can be re-used.

   To achieve the same results, other formats are designed to enable the stream-based delivery of geometry data. For instance, GeoJSON Text Sequences [RFC8142] is a format designed to optimize access and processing of GeoJSON [RFC7946] data, by enabling a client application to use the received data even before the transmission is completed.

   Another approach, focused on efficient client-side processing, isGeoJSON-VT, a library that enables a client to create on-the-fly vector tiles from GeoJSON [RFC7946] data.

   Finally,Geohash provides a compact way of encoding 0-dimensionalgeometries (points), which, at the same time, can be used for spatial indexing.

   Example 23

   The point coordinates of the address of Anne Frank's House (seeExample 12) can be encoded withGeohash asu173zns7thy (corresponding to the following WGS 84 lat/long coordinates:52.375204.88399).

3. Provide geometries at different levels of generalization

   Generalization is a traditional technique used inspatial data — first of all, in cartography — to reduce the precision and/or accuracy of ageometry for specific purposes. A typical example is provided by how geometries are portrayed in maps of different scales: for instance, a large-scale map can depict the width of a road (2-dimensional geometry), whereas, at lower scales, the same road can be shown as a line with zero width (1-dimensional geometry).

   Providinggeometries at different scales or resolutions is actually one of the first criteria to be considered for addressing different use cases. This is common practice in the geospatial domain, especially, but not only, for reference data. For instance, the dataset of theNomenclature of Territorial Units for Statistics (NUTS) of the European Union is made available at five different scales — ranging from 1:1,000,000 to 1:60,000,000.

   Example 24

   TheGADM-RDF project provides access togeometries of administrative areas at a resolution of 100m, 1km, 10km, and 100km. Each of these variants is associated with a different HTTP URI, andgeometry is made available in different formats. For instance, the geometry of Germany at 100m resolution is denoted by the following URIhttp://gadm.geovocab.org/id/0/60/geometry_100m, whereas the variant at 100km resolution is available from the following URI:http://gadm.geovocab.org/id/0/60/geometry_100km (see alsoExample 22).

   Scale reduction uses a number of generalization techniques that can be used also outside this specific use case in order to providegeometries at different levels of accuracy and precision.

   These techniques include the following:

   Reducing precision

   It boils down to reducing the number of decimals in point coordinates of ageometry. This feature is widely supported in geospatial tools and Web libraries, and it provides a way to effectively reduce the size of geometry data without losing too much information about its shape.

   Note

   The precision with which coordinate positions are reported often does not reflect the accuracy of the measurement. For example,latitude andlongitude reported to six decimal places corresponds to a precision of around 1cm on the ground. GPS-enabled consumer devices are accurate to within a few meters: centimeter-accuracy can only be achieved with professional equipment. Yet a lot of software defaults to use of six, seven or even more decimal places when expressing coordinate positions which may mislead users to thinking that the data is more accurate than it actually is!

   Best Practice 16: Describe the positional accuracy of spatial data for a discussion on precision and accuracy.

   Simplification

   This basically consists in reducing the number of point coordinates of ageometry. Examples of algorithms used for this purpose areRamer-Douglas-Peucker (RDP) andVisvalingam-Whyatt.

   Conversion of geometrydimensions

   One of the cases is the example mentioned earlier in this section, where thegeometry of a road, originally, 2-dimensional, is converted into a 1-dimensional object (a line). This can also apply to conversion from 3-dimensionalgeometries into 2-dimensional ones (e.g., the 3D representation of a building is converted into its 2D footprint), and to conversion of ann-dimensional geometry into a point.

4. Provide the centroid and bounding box of a geometry

   Centroids and bounding boxes are another example of how ageometry can be generalized, but serving different purposes. More precisely, a centroid is meant to specify the position of aSpatial Thing by converting its actual geometry to a point, corresponding to its center. On the other hand, a bounding box provides a simplified description of the maximumextent of aSpatial Thing.

   Although both these generalization methodologies result in a high-level information loss with respect to the originalgeometry, they play an important role in spatial analysis because of the topological information they provide. Moreover, centroids and bounding boxes could provide an accurate enough description of a geometry for those use cases where, respectively, the extent or precise shape of aSpatial Thing is not relevant. Finally, they are widely used also outside the geospatial domain.

   Computation of centroids and bounding boxes is supported by allGIS tools and Web mapping libraries, which makes it possible to be carried out on the fly. However, performing this operation client-side can be extremely inefficient if the target tool has limited processing capabilities.

   This issue can be addressed by providing access to centroids and bounding boxes as alternative representations of a givengeometry.

   Example 25

   In the following [TURTLE] snippet, [W3C-BASIC-GEO] and [GeoRSS] are used to specify, respectively, the centroid (w3cgeo:lat andw3cgeo:long) and bounding box (georss:box) of the 2-dimensional footprint of the building hosting Anne Frank's Museum (seeExample 21).

   @prefixbag:       <http://bag.basisregistraties.overheid.nl/def/bag#> .@prefixgeorss:    <http://www.georss.org/georss/> .@prefixgeosparql: <http://www.opengis.net/ont/geosparql#> .@prefixrdfs:      <http://www.w3.org/2000/01/rdf-schema#> .@prefix w3cgeo:    <http://www.w3.org/2003/01/geo/wgs84_pos#> .<http://bag.basisregistraties.overheid.nl/bag/id/pand/0363100012169587>   ageosparql:Feature,bag:Pand ;  rdfs:label"Pand 0363100012169587"@nl;  # Detailed geometry      geosparql:hasGeometry <http://bag.basisregistraties.overheid.nl/bag/id/geometry/5C1F8F11324717378B437B2CD12871FF> ;  bag:geometriePand     <http://bag.basisregistraties.overheid.nl/bag/id/geometry/5C1F8F11324717378B437B2CD12871FF> ;  # Centroid  w3cgeo:lat"52.37509"^^xsd:float ;  w3cgeo:long"4.88412"^^xsd:float ;  # Bounding box  georss:box"52.3749,4.8838 52.3753,4.8845"^^xsd:string ;.

   Editor's note

   Added the following example on the use of [VOCAB-DCAT-2] for the specification of centroids and bounding boxes.

   The same example can be written as follows, using the relevant properties from [VOCAB-DCAT-2] (dcat:centroid anddcat:bbox):

   @prefix bag:       <http://bag.basisregistraties.overheid.nl/def/bag#> .@prefix dcat:      <http://www.w3.org/ns/dcat#> .@prefix geosparql: <http://www.opengis.net/ont/geosparql#> .@prefix rdfs:      <http://www.w3.org/2000/01/rdf-schema#> .<http://bag.basisregistraties.overheid.nl/bag/id/pand/0363100012169587>   a geosparql:Feature, bag:Pand ;  rdfs:label "Pand 0363100012169587"@nl;  # Detailed geometry      ...  # Centroid  dcat:centroid "POINT(4.88412 52.37509)"^^geosparql:wktLiteral ;  # Bounding box  dcat:bbox "POLYGON((4.8838 52.3749,4.8838 52.3753,4.8845 52.3753,             4.8845 52.3749,4.8838 52.3749))"^^geosparql:wktLiteral ;.

Check if:

• The original and most detailed version ofgeometry data is available.
• Compressed version of geometry data can be obtained via HTTP content negotiation or other mechanisms.
• Centroids and bounding boxes are made available, without the need of downloading and processing the relevant geometry data.
• It is possible to get a 2-dimensional representation of a 3-dimensional geometry.
• Geometry is available at different levels of precision, e.g., by allowing users to specify the maximum number of decimals in point coordinates.
• Geometry is available at different scales / spatial resolutions.

Relevant requirements:R-BoundingBoxCentroid,R-Compatibility,R-Compressible,R-CoordinatePrecision,

• Processability
• Reuse
• Access
• 
• 
• 

A multitude ofcoordinate reference systems exist because there is no perfect solution to meet all requirements:

1. The Earth is a complicated shape (neither spherical nor flat!):

   For each (Earth-based)coordinate reference system, the topographical surface of the Earth is approximated to ageodeticdatum that is described using anellipsoid. The trouble with approximation is that nothing is perfect everywhere, which means that compromise is inevitable. Some datums, like WGS 84, provide a reasonable (but not highly accurate) fit everywhere on the Earth, while other datums (such as the European Terrestrial Reference System 1989 — as used byETRS89 / EPSG:4258) provide a better fit in a given region at the expense of accuracy elsewhere.

   Spatial data is oftenprojected from the curved surface of the Earth onto a flat plane (e.g. a computer screen or a topographical map) to make it easier to compute distances between positions and calculate areas. There are many choices of projection (e.g. equirectangular, mercator, stereographic, orthographic etc.), each of which is designed for particular tasks. As withdatums, projections are often chosen to better support regional, national or local needs.

2. It is also worth noting that as a living planet, the Earth continues to change its shape; for example, continental drift moves Australia north-eastwards several centimeters each year and New Zealand shifts in multiple directions. To retain accuracy,datums need to be adjusted from time to time — as is the case of the New Zealand Geodetic Datum (NZGD2000) that is frequently revised to take account of earth deformations.

   Geodesists refer to those coordinate reference systems which are continually updated so that the same set of coordinates refers to the same place on (or near) the surface of the earth as 'plate-fixed' or 'static coordinate reference systems'; others (such as WGS 84) are 'earth-fixed' or 'dynamic' (a set of coordinates will not resolve to the same spot on the moving surface of the earth).

   If your intended application requires a combination of positional accuracy and persistence over time, then use a static coordinate reference system or ensure that each set of coordinates is accompanied by the date it was measured.

   See https://www.youtube.com/watch?v=IKM-bR6SwVs for further explanation.

3. Sometimes we don't want to measure relative to the surface of the Earth at all:

   Spatial data such as descriptions of the built environment, geological surveys, satellite imagery, etc. are often captured and stored in anengineeringcoordinate reference system as measurements from a local datum. For example,XY survey coordinates relative to a building corner, pixel positions within the image swath of a satellite camera, or distance along a line from a fixed origin point.

Although it is possible to convert coordinates from oneCRS to another, many users will be put off by the need to do so. Furthermore, the need for such transformations introduces a point where errors can be introduced to thespatial data — especially where users have limited expertise with spatial data.

When publishingspatial data, it is best to help users avoid the need for them to transform spatial data betweencoordinate reference systems themselves by providing data in a form, or forms, which they can use directly. To determine which coordinate reference system(s) are needed, data publishers must consider the intended applications of their user community.

Spatial data is provided in acoordinate reference system, or systems, that are sensitive to the needs of user's intended applications.

Most of a publisher's anticipated user community do not need to transform coordinate values prior to using the spatial data.

The first thing that publishers ofspatial data need to do is consider their audience.

When publishingspatial data on the Web, the largest community of potential users will be unknown: anyone might find and use data published on the Web! To support thisunanticipated reuse, we recommendalways publishing yourspatial data using a globalcoordinate reference system which allows spatial data from multiple sources to be readily combined for display or computation. Forgeospatial data with point, line or polygongeometries (i.e.vector data), WGS 84 Lat/Long (EPSG:4326) or WGS 84 Lat/Long/Elevation (EPSG:4979) are good choices as many of the tools and applications used by Web developers are set up to use data from GPS-enabled mobile devices that all use WGS 84. Where you have geo-imagery (i.e.raster data, comprised of a rectangular pattern of pixels on a flat plane) it is best to use Web Mercator (EPSG:3857) which has near-global extent.

Where considerations of the known user community (or communities) call for differentcoordinate reference systems, we recommend publishingspatial data in multiple representations: one for each of the prioritized coordinate reference systems. Clearly, the number of representations provided needs to be determined with respect to the associated effort. However, remember that a decision not to publish data in a priorityCRS will result in each member of your user community needing to do that task — or them not using your data.

Common reasons for needing to publish in additional coordinate reference systems include:

1. publication through government data portals that require use of aprojected CRS defined by the national mapping agency — and similar legislative requirements;

   Example 26

   TheBasisregistraties Adressen en Gebouwen (BAG), orBasic Registers for Addresses and Buildings, provided byKadaster, publishes data in bothOGC CRS84 (using the WGS 84 geodeticdatum) and the Amersfoort / RD (EPSG:28992)coordinate reference systems.

   Example 27

   TheINSPIRE Directive 2007/2/EC of the European Union requires that the European Terrestrial Reference System 1989 ETRS89 (EPSG:4258) is used for the referencing of spatial datasets.

2. applications such as augmented reality, defense and precision agriculture that require coordinates to be accurate to tens of centimeters or less, thereby requiring the use of aCRS with an alternative geodeticdatum that provides a superior fit for the local or regional geographic area — noting that every CRS and datum should define the geographic area, and perhaps timescale, within which it is intended to be used;
3. the need to support applications that work in a local frame of reference using an engineering CRS — such as in an urban environment, inside a building complex or using chainage along a survey line;
4. avoiding computationally intensive reprojection of raster data such as satellite imagery or base maps within end-user applications — which may mean publishing vector data in the sameprojected CRS so that can be easily aligned with the raster data; and
5. the need to retain the integrity of raster data by publishing in its original projection, thereby avoiding modification of pixel values due to the reprojection.

Check thatgeospatial data (i.e. data about things located relative to the Earth) is available, as a minimum, in a globalcoordinate reference system: for vector data, this should be WGS 84 Lat/Long (EPSG:4326) or WGS 84 Lat/Long/Elevation (EPSG:4979); for raster data this should be Web Mercator (EPSG:3857).

Relevant requirements:R-AvoidCoordinateTransformations,R-CoordinatePrecision.

• Comprehension
• Processability
• Reuse
• Interoperability
• Access
• 
• 
• 
• 
• 

Thegeometry ofSpatial Things is described using position coordinates; for example,latitude andlongitude. Because coordinates describe a position relative to adatum (e.g. zero latitude is the equator and zero longitude is the prime meridian — often the Greenwich Meridian), it is important to understand both the datum and the units that are used for coordinates along with the order which the coordinate axes are defined: thecoordinate reference system (CRS).Spatial data is published in a wide variety of CRS. This variety can create confusion and inconsistencies in using and interpreting spatial data. Unless the CRS is known, errors are likely to be introduced when determining the position and extent of aSpatial Thing on the Earth and this makes comparing or combining spatial data from different sources extremely problematic.

Where the application requires accuracy over time but the data uses a dynamic coordinate system, you will also need to provide the 'epoch' - the data the coordinates were recorded; seeBest Practice 7.

Sufficient information is provided to enable coordinates to be related to the correct position, thereby enablingspatial data to be correctly interpreted by humans and software agents.

Spatial data from different sources can be combined without introducing unwarranted positional errors.

A user ofspatial data will need to know:

1. which coordinate value relates to which axis;
2. what units used for each coordinate; and
3. whatdatum is used

There are five common ways that this information can be provided:

1. Describe thecoordinate reference system in the dataset metadata.

   Example 28: Coordinate reference system stated in [GeoDCAT-AP] (TTL encoding)

   @prefixex:      <http://data.example.org/datasets/> .@prefixdcat:    <http://www.w3.org/ns/dcat#> .@prefixdcterms: <http://purl.org/dc/terms/> .@prefixskos:    <http://www.w3.org/2004/02/skos/core#> .ex:ExampleDataset   adcat:Dataset ;  dcterms:conformsTo <http://www.opengis.net/def/crs/EPSG/0/32630> .<http://www.opengis.net/def/crs/EPSG/0/32630>   a dcterms:Standard, skos:Concept ;  dcterms:type <http://inspire.ec.europa.eu/glossary/SpatialReferenceSystem> ;  dcterms:identifier"http://www.opengis.net/def/crs/EPSG/0/32630"^^xsd:anyURI ;  skos:prefLabel"WGS 84 / UTM zone 30N"@en ;  skos:inScheme <http://www.opengis.net/def/crs/EPSG/0/> .

   The example above illustrates how to describe thecoordinate reference system used for a dataset within [GeoDCAT-AP] metadata. TheconformsTo property from [DCTERMS] is used to assert the relationship between dataset andCRS in the same way that conformance with astandard is expressed in [VOCAB-DQV].

   Dataset metadata forspatial data should always provide details of theCRS used. For more information about dataset metadata, please refer toBest Practice 15: Include spatial metadata in dataset metadata.

2. Provide each coordinate value with explicit labels and provide metadata to indicate what each label means.

   Example 29: Coordinate position provided using [W3C-BASIC-GEO]

   @prefix w3cgeo: <http://www.w3.org/2003/01/geo/wgs84_pos#> .@prefixdcterms: <http://purl.org/dc/terms/> .:myPointOfInterest a w3cgeo:SpatialThing ;    dcterms:description"Anne Frank's House, Amsterdam."    w3cgeo:lat"52.37514"^^xsd:float ;    w3cgeo:long"4.88412"^^xsd:float ;    .

   The labels (or terms)w3cgeo:lat andw3cgeo:long are provided by the [W3C-BASIC-GEO] vocabulary which states that it is:

   A vocabulary for representinglatitude,longitude and altitude information in the WGS 84 geodetic referencedatum.

   The terms themselves (plusw3cgeo:alt) are defined with all the necessary information as follows:

   • lat: The WGS 84 latitude of aSpatial Thing (decimal degrees).
   • long: The WGS 84 longitude of a Spatial Thing (decimal degrees).
   • alt: The WGS 84 altitude of a Spatial Thing (decimal meters above the local referenceellipsoid).
   Example 30: Coordinate position provided using [JSON-LD] and [SCHEMA-ORG]

   <scripttype="application/ld+json">{"@context" : {"@vocab" :"http://schema.org/"  },"myPointOfInterest" : {"@type" :"Place","geo" : {"@type":"GeoCoordinates","latitude":"52.37514","longitude":"4.88412"    }  }}</script>

   In the example above, the labelslatitude andlongitude are defined in [SCHEMA-ORG], as indicated by the [JSON-LD] key@vocab. The associated definitions in [SCHEMA-ORG] are:

   • latitude: Thelatitude of a location. For example 37.42242 (WGS 84).
   • longitude: Thelongitude of a location. For example -122.08585 (WGS 84).
   Note

   The definitions provided in [SCHEMA-ORG] do not indicate the unit of measure. However, we have included this example as [SCHEMA-ORG] is very commonly used. The unit of measure used forlatitude andlongitude are decimal degrees, and decimal meters is used for the remaining coordinate position propertyelevation.

   The metadata for axis labels may also be provided in the documentation for anAPI from which thespatial data is accessed. For more information on documentingAPIs, please refer to [DWBP]Best Practice 25: Provide complete documentation for yourAPI.

   Example 31: Coordinate position provided using column in tabular data

   GID,On Street,Long,Lat,Species,Trim Cycle,Diameter at Breast Ht,InventoryDate,Comments,Protected1,ADDISON AV,-122.15649,37.44096,Celtis australis,Large Tree Routine Prune,11,10/18/2010,,2,EMERSON ST,-122.15675,37.44096,Liquidambar styraciflua,Large Tree Routine Prune,11,6/2/2010,,6,ADDISON AV,-122.15630,37.44115,Robinia pseudoacacia,Large Tree Routine Prune,29,6/1/2010,cavity or decay; trunk decay; codominant leaders; included bark; large leader or limb decay; previous failure root damage; root decay;  bewareof BEES,YES

   In this example (adapted from the City of Palo Alto tree operations database and published astabular data and as aninteractive map) the coordinate position of each tree is specified using separate columns (Long andLat).

   We see the definitions of thoseLong andLat columns provided in the dataset metadata, in this case a tabular metadata document, as per approach (1) above.Long andLat are mapped onto the definitions provided by [W3C-BASIC-GEO] to ensure that the meaning of the data values in those columns is clear:

   Example 32: Abridged tabular metadata providing column meanings

   {"@context": ["http://www.w3.org/ns/csvw", {"@language":"en"}],"@id":"http://example.org/tree-ops-db","url":"tree-ops-db.csv","dcterms:title":"Tree Operations",  ..."tableSchema": {"columns": [{"name":"GID","titles": ["GID","Generic Identifier"      ],"dcterms:description":"An identifier for the operation on a tree.","datatype":"string","required":true,"suppressOutput":true    }, {"name":"on_street","titles":"On Street","dcterms:description":"The street that the tree is on.","datatype":"string"    }, {"name":"Long","titles":"Longitude","dcterms:description":"The WGS 84 longitude of the tree (decimal degrees).","propertyUrl":"http://www.w3.org/2003/01/geo/wgs84_pos#long""datatype": {"base":"number","minimum":"-180","maximum":"180"      }    }, {"name":"Lat","titles":"Latitude","propertyUrl":"http://www.w3.org/2003/01/geo/wgs84_pos#lat""dcterms:description":"The WGS 84 latitude of the tree (decimal degrees).","datatype": {"base":"number","minimum":"-90","maximum":"90"      }    },    ..."primaryKey":"GID","aboutUrl":"http://example.org/tree-ops-ext#gid-{GID}"  }}

   Note

   Please refer to [TABULAR-DATA-PRIMER]section 6.2 How do you support geospatial data? for more details on working with geospatial content in tabular data.

3. Use a data format that specifies axes, their order,datum and unit of measurement for coordinates.

   Example 33: Coordinates encoded using GeoJSON [RFC7946] in HTTP response

   HTTP/1.1200 OKDate:Sun, 05 Mar 2017 17:12:35 GMTContent-length:543Connection:closeContent-type:application/geo+json{"type":"Feature","geometry": {"type":"Polygon","coordinates": [      [ [4.884235,52.375108], [4.884276,52.375153],         [4.884257,52.375159], [4.883981,52.375254],         [4.883850,52.375109], [4.883819,52.375075],         [4.884104,52.374979], [4.884143,52.374965],         [4.884207,52.375035], [4.884263,52.375016],         [4.884320,52.374996], [4.884255,52.374926],         [4.884329,52.374901], [4.884451,52.375034],         [4.884235,52.375108] ]      ]  },"properties": {"name":"Anne Frank's House"  }}

   The media typeapplication/geo+json is used to designate that content is provided in GeoJSON format, as specified in [RFC7946].

   [RFC7946]Section 4. Coordinate Reference System provides all the necessary information to interpret the coordinates, stating that:

   Thecoordinate reference system for all GeoJSON [RFC7946] coordinates is a geographic coordinate reference system, using the World Geodetic System 1984 (WGS 84) [WGS84]datum, withlongitude andlatitude units of decimal degrees. This is equivalent to the coordinate reference system identified by the Open Geospatial Consortium (OGC) URN urn:ogc:def:crs:OGC::CRS84. AnOPTIONAL third-position elementSHALL be the height in meters above or below the WGS 84 referenceellipsoid. In the absence of elevation values, applications sensitive to height or depthSHOULD interpret positions as being at local ground or sea level.

   Example 34: Coordinate position provided using [JSON-LD] and [SCHEMA-ORG]

   <scripttype="application/ld+json">{  "@context" : {    "@vocab" : "http://schema.org/"  },  "myPlaceOfInterest" : {    "@type" : "Place",    "name" : "Anne Frank's House",    "geo" : {      "@type": "GeoShape",      "polygon": "52.375108,4.884235 52.375153,4.884276                   52.375159,4.884257 52.375254,4.883981                   52.375109,4.883850 52.375075,4.883819                   52.374979,4.884104 52.374965,4.884143                   52.375035,4.884207 52.375016,4.884263                   52.374996,4.884320 52.374926,4.884255                   52.374901,4.884329 52.375034,4.884451                   52.375108,4.884235"    }  }}</script>

   The [SCHEMA-ORG] definition ofGeoShape states:

   The geographic shape of a place. A GeoShape can be described using several properties whose values are based on latitude/longitude pairs. Either whitespace or commas can be used to separatelatitude andlongitude; whitespace should be used when writing a list of several such points.

   Note

   In these two previous examples, we see a prime example of why coordinate axis order is important: GeoJSON [RFC7946] uses Long/Lat while [SCHEMA-ORG] uses Lat/Long. Getting the axis order in the wrong order puts Anne Frank's House somewhere off the coast of Somalia rather than the Netherlands!

4. State within the data itself whichcoordinate reference system is used.

   Example 35: Coordinate reference system stated in [GML]

   <gml:PolygonsrsDimension="2"axisLabels="east north"srsName="http://www.opengis.net/def/crs/EPSG/0/28992"><gml:exterior><gml:LinearRing><gml:posList>        120749.725 487589.422  120752.55  487594.375  120751.227 487595.129        120732.539 487605.788  120723.505 487589.745  120721.387 487585.939        120740.668 487575.07   120743.316 487573.589  120747.735 487581.337        120751.564 487579.154  120755.411 487576.96   120750.935 487569.172        120755.941 487566.288  120764.369 487581.066  120749.725 487589.422</gml:posList></gml:LinearRing></gml:exterior></gml:Polygon>

   The example above encodes the polygon for Anne Frank's House in [GML]. TheXML [XML11] attributesrsName (srs meaning "spatial reference system") refers to theAmersfoort / RD CRS (EPSG:28992) used in the Netherlands. Also note that additional useful information (srsDimension andaxisLabels) is provided within the document for easy reference.

   Example 36: Coordinate reference system stated in [GeoSPARQL] WKT ([JSON-LD] encoding)

   {  "@context": {    "geosparql" : "http://www.opengis.net/ont/geosparql#" ,    "rdfs" : "http://www.w3.org/2000/01/rdf-schema#" ,    "asWKT" : {      "@id" : "http://www.opengis.net/ont/geosparql#asWKT" ,      "@type" : "geosparql:wktLiteral"    }  } ,  "@id" : "http://example.org/register/id/building/0363100012169587" ,  "@type" : "http://www.opengis.net/ont/geosparql#Feature" ,  "rdfs:label" : "Building 0363100012169587" ,  "geosparql:hasGeometry": {    "geosparql:asWKT" : "<http://www.opengis.net/def/crs/EPSG/0/4326>                         POLYGON ((52.375108 4.884235, 52.375153 4.884276,                                   52.375159 4.884257, 52.375254 4.883981,                                   52.375109 4.883850, 52.375075 4.883819,                                   52.374979 4.884104, 52.374965 4.884143,                                   52.375035 4.884207, 52.375016 4.884263,                                   52.374996 4.884320, 52.374926 4.884255,                                   52.374901 4.884329, 52.375034 4.884451,                                   52.375108 4.884235))"  }}

   The "Well Known Text" (WKT) encoding, itself defined in [SIMPLE-FEATURES], is extended by [GeoSPARQL] to include designation of thecoordinate reference system used, which in turns determines the coordinate axis-order. The example above encodes the polygon as a [GeoSPARQL]wktLiteral data type, designating thecoordinate reference system as<http://www.opengis.net/def/crs/EPSG/0/4326> (EPSG:4326) — WGS 84 Lat/Long.

   Note

   When using thewktLiteral datatype specified in [GeoSPARQL], thecoordinate reference system URI may be omitted. In such a case, WGS 84 Long/Lat (urn:ogc:def:crs:OGC::CRS84) is used. Please refer to [GeoSPARQL]Requirement 11 for more details.

   The Basisregistraties Adressen en Gebouwen (BAG — the Dutch "Basic Registers for Addresses and Buildings"), provided byKadaster, uses this default behavior. Anne Frank's House, is identified using the URIhttp://bag.basisregistraties.overheid.nl/bag/id/pand/0363100012169587.HTML,JSON,TTL andXML representations are available.

   Note

   It is worth noting that, in the [SIMPLE-FEATURES] definition ofWKT, the coordinate axis order is by default longitude / latitude, irrespective of thecoordinate reference system used. The same applies toEWKT (Extended WKT) — a PostGIS extension toWKT supported also by otherGIS tools -, which includes a parameter (SRID) for specifying the coordinate reference system.

   For this reason, whenever usingWKT to encodegeometries, it is important that the referenceWKT specification can be unambiguously determined.

5. Support advertising the usedCRS in the endpoint serving the data.

   Because of the inconsistent provision of CRS metadata in geospatial encodings and the continued confusion caused by the axis order of coordinates,OGCAPI - Features part 2 [OAF2] defines a mechanism for a server to clearly and unambiguously assert the CRS and axis order being used in a response document independent of the requested output format. The method used is an HTTP header namedContent-Crs containing a URI identifying theCRS.

   Example 37: Advertise CRS using OGC API - Features building block

     $ curl -i"https://example.com/api/v1/collections/poi/items/1?crs=http%3A%2F%2Fwww.opengis.net%2Fdef%2Fcrs%2FEPSG%2F0%2F3395"  HTTP/1.1200 OKDate: Sun,24 May202015:30:56 GMT  Content-Type: application/geo+json  Content-Language: en  Content-Crs:   Link: ; rel="self"; title="This document"; type="application/geo+json"Link: ; rel="alternate"; title="This document as HTML"; type="text/html"Link: ; rel="collection"; title="The collection the feature belongs to"Vary: Accept-Language,Accept-Encoding  Content-Length:1064  ...

For a givenspatial data publication, check that users can find information about the coordinate axes, their order, and unit of measurement, plus thedatum used.

Relevant requirements:R-DeterminableCRS,R-CRSDefinition,R-GeoreferencedData,R-LinkingCRS.

• Comprehension
• Processability
• Reuse
• Interoperability
• 
• 
• 
• 

Geocentriccoordinate reference systems describe position relative to the earth itself. It can also be valuable or even necessary to describe the position of an entity relative to a second entity. In some cases, this is a navigation convenience, for example, a tour kiosk might be described as located between the Boston Common Frog Pond and the Park Street T entrance, or in one's lower left view when looking up at the Statehouse. In other cases of moving or generalized entities, it may be that the entity can only usefully be given a relative position. For example, a package is reported left on seat 32L1 on the #59 bus, or part number PRG5460 is always located at position (51, 73, 3) in Acme warehouses.

It should be possible to describe the location of an entity in relation to one or more other entities or places, instead of specifying its own geocentric position orgeometry.

The relative positioning descriptions should be machine-interpretable and/or human-readable as required by the intended application. The positions and/orgeometries of reference entities, if available, should be retrievable through theirlink relations.

Positioning of one entity (A) relative to another referenced entity (B) is a combination of two factors: the referencing target, and the means of relative positioning. "Geocentric" referencing targets the planet itself or at least a fixed point on it. "Allocentric" referencing targets another entity. "Egocentric" referencing targets a particular field of view of an observer or camera. Positioning can take the form of a completecoordinate reference system (e.g. engineeringCRS), a qualitative relation such as "beside", or a quantitative relation such as "30m northwest"

• Descriptions of the positions of entities as explicitlinks to target entities.
• Semantic descriptions of the target entities and type of positioning.
• Encodings of the specific entity relations or the relative coordinate positions in the case of engineeringCRS'

"Metes and Bounds" are a widely-used system for defining land parcel boundary edges as cardinal directions and distances relative to survey markers or other landmarks. This would be considered an allocentric quantitative relation type of relative positioning

The positions of pixels in an image captured by a satellite or other camera sensor are originally recorded relative to the field of view of the sensor. A model of the sensor optics, and platform position and orientation, together with transmission path effects (if available), may be used later to derive geocentric pixel positions.

In hydrology, positions of river features and/or observations such as water depth are often recorded as distance along a stream relative to a well-known origin point such as a stream confluence. This provides a reproducible form of positioning even if thegeometry of the stream has not been precisely determined.

Augmented or mixed reality content is presented to the viewer in positions both relative to the real-world entities that it augments and relative to the viewer's visual perspective on those entities. For example, an informational callout needs to be juxtaposed with its target but also occupy the user's field of view in a meaningful fashion.

Check that, when positions of entities are described as relative to other entities, these descriptions can be interpreted by a machine as well as humans, and the positions of the reference entities can be retrieved through theirlink relations.

Relevant requirements:R-MachineToMachine,R-SamplingTopology.

• Processability
• 

Geography is often described as the "glue that binds Linked Data"; thelinks betweenSpatial Things — and between other resources andSpatial Things — describe how the world around us is structured and interrelated and form an important facet of the Web of Data.

Spatial relationships can often be derived mathematically based ongeometry — but this can be computationally expensive.Topological relationships such as these can be asserted, thereby removing the need to do geometry-based calculations. A useful secondary benefit is that these relationships are easier for humans to understand!

Different authorities and agencies seek to describe the world around them by publishing spatial data, and in doing so, each minting their own URIs (as recommended inBest Practice 1: Use globally unique persistent HTTP URIs for Spatial Things). WhereSpatial Things are of common interest to multiple agents, it is almost inevitable that a givenSpatial Thing will end up being identified with several URIs. Given necessary due diligence, multiple identifiers may be linked, thereby supporting a combination of multiple sets of information and yielding new perspectives on Spatial Things.

Application domains often require Spatial Things to be related; to convey the correct meaning, specific link relation types need to be used.

Spatial things are related to other resources in the Web of data using links with appropriate semantics.

Your data is more interoperable.

Before examining the link relation types that might be used in spatial data, let's considerwhat we should link to.

1. Link to theSpatial Thing.

   Thegeometry description orextent of aSpatial Thing may be expressed using an object with its own URI. For example:

   Example 42: Independently identified geometry extent for the City of Edinburgh Council Area (TTL format)

   @prefixrdfs:      <http://www.w3.org/2000/01/rdf-schema#> .@prefixadmingeo:  <http://data.ordnancesurvey.co.uk/ontology/admingeo/> .@prefixgeom:      <http://data.ordnancesurvey.co.uk/ontology/geometry/><http://data.ordnancesurvey.co.uk/id/7000000000030505>  aadmingeo:District ;  rdfs:label"City of Edinburgh" ;  geom:extent <http://data.ordnancesurvey.co.uk/id/geometry/30505-10> .<http://data.ordnancesurvey.co.uk/id/geometry/30505-10>  a geom:AbstractGeometry ;  geom:asGML"<gml:MultiPolygon>...</gml:MultiPolygon>"^^rdf:XMLLiteral ;  geom:hectares27300.411 .

   As can be seen in the example above, thegeometry30505-10 is anattribute of theCity of Edinburgh (osuk:7000000000030505). If your intent is to make a statement about, or refer to, the real-world entity then make sure you link to theSpatial Thing rather than thegeometry. Furthermore, note that the geometry record may be updated and re-published with a new identifier, for example, if the city boundary was resurveyed and would then result in a brokenlink.

   Data publishers should also be aware of a common pattern used in the publication ofLinked Data, where theSpatial Thing and the information resource that describes it are identified separately — often, but not always, using/id as part of the URI forSpatial Thing, and/doc for the corresponding page/document/record. When the URI for the Spatial Thing is dereferenced, aHTTP 303 (see other) response is used to redirect the browser to the page/document/record URL. For example:

   • http://statistics.gov.scot/id/statistical-geography/S12000036 redirects tohttp://statistics.gov.scot/doc/statistical-geography/S12000036
   • http://dbpedia.org/resource/Anne_Frank_House redirects tohttp://dbpedia.org/page/Anne_Frank_House

   While this disambiguation has its advantages, it often seems to confuse users (and even some experts). Be aware of thisredirect pattern, and make sure you use the correct URI i.e. the identifying one — especially if you're copying the URI from a browser's address bar which usually ends up showing the page/document/record URL.

2. Link toSpatial Things from popular repositories.

   Linking with URIs from popular repositories may improve the discoverability of your data. Not only does this provide users with better context by enabling them to browse the information published by the popular repository, but it also helps relate your data with datasets from other parties who have also used those URIs as points of reference.

   There are many popular repositories containing sets of identifiers forSpatial Things; the following list suggests the primary sources worth checking:

   • GeoNames
   • Wikidata
   • DBpedia
   • National open spatial datasets such as are made available by for example the UK and Dutch governments.

   Finding out which national open spatial datasets are available, and how they can be accessed, currently requires some insider knowledge — in most cases because these datasets are often not easily discoverable. Look for national data portals / geoportals such asNationaal Georegister (Dutch national register of spatial datasets) orDataportaal van de Nederlandse overheid (Dutch national governmental data portal).

   Once you've found well-known URIs forSpatial Things that you want to link to, proceed to createlinks using properties such as those described above —owl:sameAs (if you're careful!) andgeosparql:sfWithin, or perhaps qualitative relationships likegeonames:nearby or theproposedschema:samePlaceAs (see related discussion in15.6Defining that two places are the same).

   However, don't try to makelinks toeverything. It is not always feasible to link yourSpatial Things to well-known resources. For example, if you were maintaining a registry of cultural heritage in Amsterdam, it would be reasonably simple to look up identifiers for the city's 50 or so museums and map these to your Spatial Things. But it would be a huge task for, say, a topographic mapping agency to cross-reference their entire catalogue of named places containing tens of thousands of Spatial Things with third-party resources (although in the spirit of crowd-sourcing, if someone else found those links useful, they may take on the task of relating the Spatial Things and publishing those relationships to the Web as a complementary resource!). In essence, you should only create the data that you have the resources to maintain.

Now, let's take a look at link relation types that may be applicable to spatial data. These fall into three broad categories: spatial relations, equality relations, and domain-specific relations.

In this best practice document, we cannot cover all the possible vocabularies and ontologies that provide link relation types for spatial data. Other than a few areas of specific guidance, we are not recommending specific vocabularies for spatial linking. Instead, we hope to have introduced patterns that show the types of spatial linking that might be used and leave it to spatial data publishers to determine which specific vocabulary best suits their purpose. In this regard, [DWBP]section 8.9 Data Vocabularies and, in particular, [DWBP]Best Practice 15: Reuse vocabularies, preferably standardized ones are highly relevant.

Also, readers should note that in many cases, there will often be value in linkingSpatial Things with multiple relationships — each of which provides different semantics. Having identified your intended user communities and the vocabularies that they commonly use, choose thoselink relation types that meet their specific needs, and then add more generalizedlink relation types to support broader reuse of your data.

However, data publishers should only assert those relationships that they know about and that they think will be of interest to their user community. Don't try to cover all possible requirements! That said, publishers should try to avoid making assumptions about what the user may or may not know. For example, users may lack the expertise or resources to calculate a topological relationship, or lack the domain knowledge to determine how twoSpatial Things are related, if at all. As the data publisher, you are likely to be in a better position to make these judgements than the user — so help them out by making these relationships clear.

1. Spatial relationships

   Topological relationships betweenSpatial Things can be computed based on assessment of theirgeometry. [GeoSPARQL] defines families of topological relationships (based on theDE-9IM pattern) that, in mathematical terms, specify the spatial dimension of the intersections of the interiors, boundaries and exteriors of two geometric objects that may be 2-dimensional (e.g. area), 1-dimensional (e.g. linear) or 0-dimensional (e.g. point).

   Most commonly used are the simple feature relationship family, described in [SIMPLE-FEATURES] section6.1.15.3 Named spatial relationship predicates based on the DE-9IM. The set of seven named relationships, orspatial predicates, and their associated [GeoSPARQL] properties are listed below:

   • Equals —geosparql:sfEquals
   • Disjoint —geosparql:sfDisjoint
   • Touches —geosparql:sfTouches
   • Crosses —geosparql:sfCrosses
   • Within —geosparql:sfWithin
   • Contains —geosparql:sfContains
   • Intersects —geosparql:sfIntersects

   We recommend the use of the Simple Features relation families for describing topological relations between points, lines and areas. Further details are provided in [GeoSPARQL] section7 Topology Vocabulary Extension.

   Example 43: Asserting topological relationship 'crosses' (JSON format)

   <scripttype="application/hal+json">{"ex:type-nl":"brug","ex:type-en":"bridge","ex:name":"Lelieslius","_links": {"self": {"href" :"http://data.example.org/topo/ams/brug/Leliesluis" },"curies": [       {"name":"geosparql","href":"http://www.opengis.net/ont/geosparql#{rel}","templated":true       } , {"name":"ex","href":"http://data.example.org/def/topo#{rel}","templated":"true"      }     ],"geosparql:sfCrosses": {"href" :"http://data.example.org/topo/ams/kanaal/Prinsengracht" }  },"_embedded": {"ex:type-nl":"kanaal","ex:type-en":"canal","ex:name":"Prinsengracht","_links": {"self": {"href" :"http://data.example.org/topo/ams/kanaal/Prinsengracht" }    }  }}</script>

   The example above uses theHypertext Application Language (HAL) conventions for expressing hyperlinks inJSON [RFC7159]. It illustrates how one would indicate usinggeosparql:crosses that two linearSpatial Things, a bridge and a canal, cross over each other.

   Note

   The spatial predicates specified in [GeoSPARQL] describe 2-dimensional topological relations. There is no evidence of common practice for describing 3-dimensional topological relationships.

   In addition to the mathematically precise spatial predicates described above, several vocabularies define similar relationships but without the formal mathematical underpinning. For example, [SCHEMA-ORG] defines a pair of basic containment relationships for use withschema:Place:

   • schema:containsPlace:The basic containment relation between a place and another that it contains.
   • schema:containedInPlace:The basic containment relation between a place and one that contains it.

   It is also commonplace to usespatial relationships to convey distance (e.g.at,nearby orfar-away) and direction (e.g.left,inFrontOf,astern andbelow). However, we find no evidence that points to use of common vocabularies to express these relationships — perhaps because these relationships are often subjective and dependent on application context (e.g. the meaning of “near” will be quite different between an endurance cycling App and the App I use to find the Bluetooth tag attached to my house keys!).

   Two notable examples of distance relations are:

   • foaf:based_near which states "We do not say much about what 'near' means in this context; it is a 'rough and ready' concept."; and
   • geonames:nearby which simply states, "Afeature close to the referencefeature".
   Example 44: Asserting distance spatial relationship using GeoNames ontology (GeoJSON [RFC7946] format)

   <scripttype="application/geo+json">{"id" :"http://sws.geonames.org/6618987/","type":"Feature","geometry": {"type":"Polygon","coordinates": [ [ ... ] ]  },"properties": {"http://www.geonames.org/ontology#name":"Anne Frank's House","http://www.geonames.org/ontology#nearby" :       ["http://sws.geonames.org/6950949/","http://sws.geonames.org/6951798/","http://sws.geonames.org/6944503/",        ... ]  }}</script>

   This example snippet, adapted to use the GeoJSON [RFC7946] format, shows a list ofSpatial Things (e.g. Westerkerk, Homomonument and Westertoren) that are deemed 'nearby' Anne Frank's House according toGeoNames.

   Note

   TheJSON [RFC7159] format provides only simple primitive types; string, number, boolean etc. The lack of a datatype for URIs means that they must be encoded as strings. As such, conventions (such as those defined inHAL) are required to tell applications that a given string value is a URI. However, GeoJSON [RFC7946] does not define any conventions for describing URIs and forbids any extension of the data format specification.

   To mitigate this, details about object types, etc. included in data payload should be provided in the documentation for theAPI or service end-point from which the data is accessed. See [DWBP]Best Practice 25: Provide complete documentation for yourAPI for further details.

2. Synonyms and equality

   As described above, it is not uncommon for aSpatial Thing to be identified using more than one URI (also known as the "non-unique naming problem"). If you think that this is the case, the propertyowl:sameAs may be used to express this. However, caution is advised asowl:sameAs is an extremely strong statement; literally "these two URIs identify the same resource". As there is onlyoneSpatial Thing, all the properties and attributes returned when resolving any of the equated URIs are considered to apply to thatSpatial Thing. Given that spatial data is often published by different parties, each concerned with their own perspective, theSpatial Thing equality is often difficult to determine and depends heavily on the semantics involved.

   So, the advice is: if in doubt, don't useowl:sameAs.

   By way of example, let's explore some data for Edinburgh.

   TheCity of Edinburgh Council Area (e.g. the geographical area that Edinburgh City Council is responsible for) is identified by theOffice for National Statistics (the recognized national statistical institute of the UK) using their GSS code (a 9 character alpha numeric identifier)S12000036 and the URIhttp://statistics.data.gov.uk/id/statistical-geography/S12000036. At the same time, the devolved government in Scotland, operating under its own jurisdiction, retains the GSS code but uses the URIhttp://statistics.gov.scot/id/statistical-geography/S12000036. Furthermore, theOrdnance Survey maintain yet another URI for the City of Edinburgh Council Area as part of its 'Boundary Line' service that contains administrative and statistical geography areas in the UK:http://data.ordnancesurvey.co.uk/id/7000000000030505. Similarly, Geonames identifies Edinburgh, asecond-order administrative division, ashttp://sws.geonames.org/2650225/. All of these URIs refer to the sameSpatial Thing and are equated usingowl:sameAs.

   Example 45: Asserting equality between URIs for the City of Edinburgh Council Area (TTL format)

   @prefixowl:          <http://www.w3.org/2002/07/owl#> .@prefixscotgov-stat: <http://statistics.gov.scot/id/statistical-geography/> .@prefixukgov-stat:   <http://statistics.data.gov.uk/id/statistical-geography/> .@prefixosuk:         <http://data.ordnancesurvey.co.uk/id/> .@prefixgeonames:     <http://sws.geonames.org/> .scotgov-stat:S12000036owl:sameAsukgov-stat:S12000036 .osuk:7000000000030505owl:sameAsukgov-stat:S12000036 .geonames:2650225owl:sameAsukgov-stat:S12000036 .

   Also note that in this [TURTLE] snippet one could easily include additional properties to help users determine whether thelink is worth traversing, such as providing human-readable labels and specifying thetype designated by each data publisher.

   In contrast, the resource identified byhttp://data.os.uk/id/4000000074558316 defines thenamed place Edinburgh — a colloquial definition for the city itself. This is not the same as theCity of Edinburgh Area and therefore use of theowl:sameAs relationship is inappropriate.

   Note

   The mechanics of determining whether the information provided when resolving two or more URIs does indeed describe the sameSpatial Thing is a complex topic all in its own right and way beyond the scope of this best practice document. Tools such asOpen Refine and theSilk Linked Data Integration Framework are designed to work with, transform and integrate heterogeneous data sources. Their documentation may provide further insight regarding these challenges.

   Given the very strong semantics of theowl:sameAs property, alternative properties with weaker semantics are commonly used. Examples include:

   • schema:sameAs defined by [SCHEMA-ORG] whose description states:

     URL of a reference Web page that unambiguously indicates the item's identity. E.g. the URL of the item's Wikipedia page, Freebase page, or official website.

   • ov:similarTo defined byOpen.vocab.org, with the description:

     Having two things that are not the owl:sameAs but are similar to a certain extent. It is thought of being used where owl:sameAs is too strong but rdfs:seeAlso is too loose.

   All of the properties list above, are concerned with equality or similarity about resources themselves. However, we often want to talk about the similarity of Spatial Things in terms of location orplace. Spatial relations (seeabove) can be used to describe how locations are related — either using rigorous topological relationships derived from geometry, such asgeosparql:sfEquals, or ones without formal mathematical underpinning, such asgeonames:nearby. Butplace is a social concept that reflect how we humans perceive the space around us, often with a vague or imprecise notion of location; you can’t always define a boundary for a place likeThe Sahara because not everyone agrees where its edge lies!

   Talking of places, theCity of Edinburgh [Administrative] Area andEdinburgh thenamed place are strongly related; you might say that they are thesame place if that makes sense for your application. This also provides an example where it is worthwhile to provide multiple relationships between Spatial Things: Ordnance Survey uses thewithinlink relation type to relate thenamed placeEdinburgh and theCity of Edinburgh (osuk:7000000000030505) administrative area.within complements a qualitativesame-place-as relation between two places.

   However, while we see people wanting to assert such qualitativesame-place-as relationships based on human perception of place, there is no evidence of a best practice in how to achieve this; see15.6Defining that two places are the same for more details about possible approaches that could be adopted.

3. Domain-specific relationships involvingSpatial Things

   In addition to thespatial relationships that are applicable to a wide variety of domains, there are a huge number of cases where asserting a relationship betweenSpatial Thing is useful. Clearly, enumerating all these cases is more than we can do here — but we can look at some of those that commonly occur.

   First, there are the properties used to describe relationships betweenSpatial Things in agazetteer. These properties are often used in combination with spatial predicates to describe the relationship between administrative units. For example,Ordnance Survey define specific properties to describe the relationships between the administrative units used within the UK:county (admingeo:county),district (admingeo:district),ward (admingeo:ward), etc.

   Example 46: Asserting gazetteer relationships for the City of Edinburgh Council Area (TTL format)

   @prefixrdfs:      <http://www.w3.org/2000/01/rdf-schema#> .@prefixgeosparql: <http://www.opengis.net/ont/geosparql#> .@prefixadmingeo:  <http://data.ordnancesurvey.co.uk/ontology/admingeo/> .<http://data.ordnancesurvey.co.uk/id/7000000000030505>  aadmingeo:District ;  rdfs:label"City of Edinburgh" ;  admingeo:gssCode"S12000036" ;  admingeo:ward    <http://data.ordnancesurvey.co.uk/id/7000000000043412> ,     <http://data.ordnancesurvey.co.uk/id/7000000000043415> ,     <http://data.ordnancesurvey.co.uk/id/7000000000043411> ,    ... ;  geosparql:sfTouches    <http://data.ordnancesurvey.co.uk/id/7000000000036552> ,     <http://data.ordnancesurvey.co.uk/id/7000000000030509> ,     <http://data.ordnancesurvey.co.uk/id/7000000000030634> ,     <http://data.ordnancesurvey.co.uk/id/7000000000030632> ;  ...  .

   The example snippet above, provided in [TURTLE] format, shows the relationships between theCity of Edinburgh (osuk:7000000000030505)district (admingeo:district) and theelectoral wards (admingeo:ward) it contains. Also note that complementary use ofgeosparql:sfTouches to relate theCity of Edinburgh (osuk:7000000000030505) to its adjacent districts; Midlothian, West Lothian etc.

   A second domain where relationships betweenSpatial Things and non-spatial resources occur is earth observing. The example below, provided in [GML], relates a monitoring point at Deddington on the Nile River, Tasmania, to the sensor that is deployed there (using thesams:hostedProcedure property) and relates that monitoring point to the waterbody whose properties are being measured (using thesam:sampledFeature property). Here, thelinks are defined using [XLINK11].

   Example 47: Asserting spatial relationship for sensing/earth observation using [XLINK11] and [GML]

   <wml2:MonitoringPointgml:id="xsd-monitoring-point.example"xmlns:wml2="http://www.opengis.net/waterml/2.0"xmlns:gml="http://www.opengis.net/gml/3.2"xmlns:sam="http://www.opengis.net/sampling/2.0"xmlns:sams="http://www.opengis.net/samplingSpatial/2.0"xmlns:xlink="http://www.w3.org/1999/xlink"><gml:description>Hydrological monitoring point for Nile river at     Deddington, South Esk catchment, Tasmania</gml:description><gml:identifiercodeSpace="http://www.example.com/">    http://www.example.com/catchment/south-esk/mpoint/deddington</gml:identifier><sam:sampledFeaturexlink:href="http://sws.geonames.org/2155327/"xlink:title="Nile river"/><sams:shape><gml:Pointgml:id="location_deddington"><gml:possrsName="urn:ogc:def:crs:EPSG::4326">        -41.814935 147.568517</gml:pos></gml:Point></sams:shape><sams:hostedProcedure><wml2:ObservationProcessgml:id="sensor:4c40fd3acdbf"><wml2:processTypexlink:href="http://www.opengis.net/def/waterml/2.0/processType/Sensor"xlink:title="Sensor"/><wml2:processReferencexlink:href="http://www.example.com/sensor/00d97bbc-77ca-4b3d-91ca-4c40fd3acdbf/conf/1489405706"xlink:title="Sensor configuration (updated:2017-03-13)"/></wml2:ObservationProcess></sams:hostedProcedure>  ...</wml2:MonitoringPoint>

   For further information about sensors, sampling, observations and measurements, please refer to [OM-XML] and [VOCAB-SSN].

   Note

   [GML] adopted the [XLINK11] standard to representlinks between resources. At the time of adoption, XLink was the onlyW3C-endorsed standard mechanism for describing links between resources withinXML [XML11] documents. TheOpen Geospatial Consortium anticipated broad adoption of XLink over time — and, with that adoption, provision of support within software tooling. While XML Schema, XPath, XSLT and XQuery etc. have seen good software support over the years, this never happened with XLink. The authors of [GML] note that given the lack of widespread support, use of XLink within [GML] provided no significant advantage over and above use a bespoke mechanism tailored to the needs of [GML].

   Our final example of a domain-specific relationship concerns creative works. For example, one may want to indicate the location a social media message was sent from. In the example below, we assume that Maurits, a tourist in Amsterdam, wants to comment on his visit to Anne Frank's House. His social media App uses the [GEOLOCATION-API] to determine his location (Lat=52.37590 andLong=4.88452) and suggests several places that Maurits might choose from in order to geo-tag his message. Maurits wants people to know roughly where he is, so he chooses "Amsterdam-Centrum" and presses 'send'. The App encodes the message in [SCHEMA-ORG] and pushes the message to the server for distribution. The geo-information is provided using theschema:locationCreated property.

   Example 48: Asserting location that a creative work was created using [SCHEMA-ORG] ([JSON-LD] format)

   <scripttype="application/ld+json">{"@context" : {"@vocab" :"http://schema.org/"  },"@id" :"http://app.example.com/message/867a52e3-6687-4471-b1f2-c7561673552e","@type" :"Message","sender" : {"@type" :"Person","name" :"Maurits" },"datePublished" :"2017-03-12","locationCreated" : {"@id" :"https://g.co/kg/m/0gh6_3j""@type" :"Place","name" :"Amsterdam-Centrum"  }}</script>

   If Maurits had wanted to indicate that the subject of the photograph he took moments later was Leliesluis bridge, then the following [SCHEMA-ORG] markup andschema:mainEntity property could be used:

   Example 49: Asserting the subject of a creative work using [SCHEMA-ORG] ([JSON-LD] format)

   <scripttype="application/ld+json">{"@context" : {"@vocab" :"http://schema.org/"  },"@id" :"http://app.example.com/user/Maurits/photo/e35f1132-461e-4acb-8a76-a5d622a85958","@type" :"Photograph","sender" : {"@type" :"Person","name" :"Maurits" },"datePublished" :"2017-03-12","mainEntity" : {"@id" :"http://data.example.org/topo/ams/brug/Leliesluis""@type" :"Bridge","name" :"Leliesluis bridge","geo" : {"@type" :"GeoCoordinates","longitude" :"4.88435","latitude" :"52.37608"    }  }}</script>

Check that hyperlinks use typed relationships, and thatlink relation type can be located in order to determine how to interpret the hyperlink.

Check that the source and target of the hyperlink areSpatial Things unless thelink relation type definition indicates that this should be otherwise (e.g. when relating a Spatial Thing to itsgeometry).

Relevant requirements:R-Linkability,R-MachineToMachine,R-SpatialRelationships,R-SpatialOperators.

• Comprehension
• Processability
• Linkability
• Interoperability
• 
• 
• 
•