In general, you need to:

1. publish a HTML Web-page for the spatial dataset and each Spatial 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 (see Best Practice 15: Include spatial metadata in dataset metadata and [DWBP] Best Practice 2: Provide descriptive metadata), and may provide links 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 the Spatial 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 using Sitemaps 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 of Spatial 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 the Spatial Things into subsets, as described in 13.4 Spatial data access.

A pre-condition for this best practice is Best 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 for Spatial Things, but to share spatial 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 the Spatial 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 an API that makes the data available on the Web.

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 the Spatial 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.

In addition to exposing the spatial data as linked HTML Web-pages, indexing by Web-engines can be further enhanced by incorporating a description of the Spatial 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 a Dataset and a Spatial Thing is in general a Place or an Event. For some types of Spatial Things, more specific sub-types exist, for example City or Mountain.

Location information about a Spatial Thing is typically provided using a geometry (GeoCoordinates or GeoShape) or a PostalAddress. [SCHEMA-ORG] coordinates are restricted to WGS 84 with longitude and latitude. 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 the Spatial Thing, opening hours, contact details, etc.

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

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 clickable links to the resource in a specific format.

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

A high-level objective of these best practices is to highlight approaches that data publishers can take to maximize the ease of use of their spatial 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 about Spatial 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 spatial dimensions 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

In Best Practice 1: Use globally unique persistent HTTP URIs for Spatial Things, we recommend the use of HTTP URIs as a way of assigning identifiers to Spatial Things. The data publisher should offer the ability to look up ('dereference') such a URI to find out useful information about that Spatial Thing in human readable form (as well as machine readable formats — see the discussion below on data integration). Each Spatial Thing therefore gets its own Web page — in addition it might be useful to have Web pages about groups of Spatial 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 similar Spatial 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. See Best 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 include links to descriptions of the Spatial Thing in other formats (typically machine-readable formats) as well as linking to related Spatial 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 (see Best 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 as geocoding. 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 to latitude and longitude 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.

A common application of spatial data on the Web is delivering map data in a tiled form, suitable for display in zoomable 'slippy maps'. The OGC's Web Map Tile Service [WMTS] is an established standard for doing this. Other approaches in common use include MBTiles or 'Tile layers' in Google Maps APIs

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 about Spatial 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 this comparison of different spatial data formats to help guide the choice of which approach is best suited to your purpose.

Many important applications of spatial 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 more Spatial Things are at the center of the data analysis process.

Other applications involve distinguishing or selecting Spatial 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 describe Spatial 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 a spatial data perspective, the question of identifiers is discussed in Best Practice 1: Use globally unique persistent HTTP URIs for Spatial Things. How to relate a Spatial Thing to its geometry is described in Best Practice 5: Provide geometries on the Web in a usable way.

A common approach to encoding data to enable data integration is Linked Data [LD-BP] and RDF [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 the geometry 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 a Spatial Thing include: [SCHEMA-ORG], [VCARD-RDF] and [LOCN]. See this comparison 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.

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

For spatial analytics on the Web, the data should be accessible via an API as described in 13.4 Spatial data access and results should be shared using the best practices described in this document. Current spatial data infrastructures have some limitations with respect to sharing spatial data on the Web (as discussed in 12. Why are traditional Spatial Data Infrastructures not enough?). Nonetheless this approach is a well-established and powerful way of distributing spatial 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 their spatial 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 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 a spatial 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 a Linked Data approach, one option is to keep all data in a triple 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 of Spatial Things, while geometrical data is indexed by software such as Lucene Spatial, PostGIS or Elasticsearch. Use of shared Web-accessible identifiers for Spatial 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.

Steps to follow:

• Identify the intended uses and applications. In particular, it is important to verify if geometries 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 appropriate geometry dimensionality (0D — points, 1D — curves, 2D — surfaces, 3D — solids). See 7. Spatial Things, Features and Geometry for more information.
  • The appropriate coordinate reference system(s). See 10. 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. See A. Applicability of common formats to implementation of best practices for more information.
  • The appropriate level of detail. See Best 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

It is important to note that the steps outlined above are interrelated. For instance, the dimensionality of a geometry determines the set of coordinate 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 by Best Practice 8: State how coordinate values are encoded.

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

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

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

To facilitate the use of geometry data on the Web as well in GIS, it is desirable that complex [GML]-encoded geometries be made available also in simplified form as GeoJSON [RFC7946], by applying any required coordinate 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, see Best Practice 6: Provide geometries at the right level of accuracy, precision, and size).

Finally, RDF-based representations of geometries 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, see A. Applicability of common formats to implementation of best practices.

These geometry representations are either stored with the related data, or are maintained separately, and possibly denoted with HTTP URIs (see Example 22).

RDF representations of geometries can support most geometry types and dimensions (up to at least 2 dimensions), with any level of complexity, in any coordinate reference system. On the other hand, many existing Semantic Web tools such as triple 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 simplified geometries available for Web consumption in GeoJSON [RFC7946] or embedded in Web pages.

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

In the above example, the coordinate 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 the OGC CRS registry. The coordinate reference system is not specified for the WKT encoding, since CRS84 is the default coordinate reference system for WKT in [GeoSPARQL], and therefore it can be omitted. The coordinate reference system is also not specified in the GeoJSON [RFC7946] encoding, since CRS84 is the only supported coordinate 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 to Example 12, the following snippet shows the [GML] and the RDF [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 relevant example in Best Practice 8: State how coordinate values are encoded.

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

The different WKT encodings in the example show alternative ways of specifying the coordinate reference system used.

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

Example 21 shows also how geometries for Spatial 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 detailed geometry of the boundaries of a geographical region), without attaching them to the relevant Spatial 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 also Best Practice 10: Use appropriate relation types to link Spatial Things).

A number of techniques can be used to deliver representations of geometries 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 of geometry data.

Choosing the right technique requires taking primarily into account whether the derived geometry 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 derived geometry 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 and Best Practice 13: Expose spatial data through 'convenience APIs' provide general guidelines that can be used for the publication of alternative representations of geometries, 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, whenever geometry is made available in RDF [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. Compress geometry data

   Using standard compression algorithms, as zip and gzip, addresses the issue of efficient transmission of geometry 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 of geometry data

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

   This is, for instance, the case of TopoJSON, 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, is GeoJSON-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-dimensional geometries (points), which, at the same time, can be used for spatial indexing.

3. Provide geometries at different levels of generalization

   Generalization is a traditional technique used in spatial data — first of all, in cartography — to reduce the precision and/or accuracy of a geometry 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).

   Providing geometries 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 the Nomenclature 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.

   Scale reduction uses a number of generalization techniques that can be used also outside this specific use case in order to provide geometries 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 a geometry. 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

   Simplification

   This basically consists in reducing the number of point coordinates of a geometry. Examples of algorithms used for this purpose are Ramer-Douglas-Peucker (RDP) and Visvalingam-Whyatt.

   Conversion of geometry dimensions

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

4. Provide the centroid and bounding box of a geometry

   Centroids and bounding boxes are another example of how a geometry can be generalized, but serving different purposes. More precisely, a centroid is meant to specify the position of a Spatial 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 maximum extent of a Spatial Thing.

   Although both these generalization methodologies result in a high-level information loss with respect to the original geometry, 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 a Spatial Thing is not relevant. Finally, they are widely used also outside the geospatial domain.

   Computation of centroids and bounding boxes is supported by all GIS 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 given geometry.

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

When publishing spatial 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 this unanticipated reuse, we recommend always publishing your spatial data using a global coordinate reference system which allows spatial data from multiple sources to be readily combined for display or computation. For geospatial data with point, line or polygon geometries (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 different coordinate reference systems, we recommend publishing spatial 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 priority CRS 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 a projected CRS defined by the national mapping agency — and similar legislative requirements;

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 a CRS with an alternative geodetic datum 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 same projected 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.

A user of spatial data will need to know:

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

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

1. Describe the coordinate reference system in the dataset metadata.

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

   Dataset metadata for spatial data should always provide details of the CRS used. For more information about dataset metadata, please refer to Best 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.

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

   A vocabulary for representing latitude, longitude and altitude information in the WGS 84 geodetic reference datum.

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

   • lat: The WGS 84 latitude of a Spatial 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 reference ellipsoid).

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

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

   The metadata for axis labels may also be provided in the documentation for an API from which the spatial data is accessed. For more information on documenting APIs, please refer to [DWBP] Best Practice 25: Provide complete documentation for your API.

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

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

   Note

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

   The media type application/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:

   The coordinate reference system for all GeoJSON [RFC7946] coordinates is a geographic coordinate reference system, using the World Geodetic System 1984 (WGS 84) [WGS84] datum, with longitude and latitude 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. An OPTIONAL third-position element SHALL be the height in meters above or below the WGS 84 reference ellipsoid. In the absence of elevation values, applications sensitive to height or depth SHOULD interpret positions as being at local ground or sea level.

   The [SCHEMA-ORG] definition of GeoShape 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 separate latitude and longitude; whitespace should be used when writing a list of several such points.

   Note

4. State within the data itself which coordinate reference system is used.

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

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

   Note
   Note

5. Support advertising the used CRS 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, OGC API - 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 named Content-Crs containing a URI identifying the CRS.

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 complete coordinate reference system (e.g. engineering CRS), a qualitative relation such as "beside", or a quantitative relation such as "30m northwest"

• Descriptions of the positions of entities as explicit links 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 engineering CRS'

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

1. Link to the Spatial Thing.

   The geometry description or extent of a Spatial Thing may be expressed using an object with its own URI. For example:

   As can be seen in the example above, the geometry 30505-10 is an attribute of the City 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 the Spatial Thing rather than the geometry. 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 broken link.

   Data publishers should also be aware of a common pattern used in the publication of Linked Data, where the Spatial Thing and the information resource that describes it are identified separately — often, but not always, using /id as part of the URI for Spatial Thing, and /doc for the corresponding page/document/record. When the URI for the Spatial Thing is dereferenced, a HTTP 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 to http://statistics.gov.scot/doc/statistical-geography/S12000036
   • http://dbpedia.org/resource/Anne_Frank_House redirects to http://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 this redirect 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 to Spatial 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 for Spatial 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 as Nationaal Georegister (Dutch national register of spatial datasets) or Dataportaal van de Nederlandse overheid (Dutch national governmental data portal).

   Once you've found well-known URIs for Spatial Things that you want to link to, proceed to create links using properties such as those described above — owl:sameAs (if you're careful!) and geosparql:sfWithin, or perhaps qualitative relationships like geonames:nearby or the proposed schema:samePlaceAs (see related discussion in 15.6 Defining that two places are the same).

   However, don't try to make links to everything. It is not always feasible to link your Spatial 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 linking Spatial Things with multiple relationships — each of which provides different semantics. Having identified your intended user communities and the vocabularies that they commonly use, choose those link relation types that meet their specific needs, and then add more generalized link 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 two Spatial 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 between Spatial Things can be computed based on assessment of their geometry. [GeoSPARQL] defines families of topological relationships (based on the DE-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] section 6.1.15.3 Named spatial relationship predicates based on the DE-9IM. The set of seven named relationships, or spatial 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] section 7 Topology Vocabulary Extension.

   The example above uses the Hypertext Application Language (HAL) conventions for expressing hyperlinks in JSON [RFC7159]. It illustrates how one would indicate using geosparql:crosses that two linear Spatial Things, a bridge and a canal, cross over each other.

   Note

   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 with schema: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 use spatial relationships to convey distance (e.g. at, nearby or far-away) and direction (e.g. left, inFrontOf, astern and below). 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, "A feature close to the reference feature".

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

   Note

2. Synonyms and equality

   As described above, it is not uncommon for a Spatial 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 property owl:sameAs may be used to express this. However, caution is advised as owl:sameAs is an extremely strong statement; literally "these two URIs identify the same resource". As there is only one Spatial Thing, all the properties and attributes returned when resolving any of the equated URIs are considered to apply to that Spatial Thing. Given that spatial data is often published by different parties, each concerned with their own perspective, the Spatial Thing equality is often difficult to determine and depends heavily on the semantics involved.

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

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

   The City of Edinburgh Council Area (e.g. the geographical area that Edinburgh City Council is responsible for) is identified by the Office for National Statistics (the recognized national statistical institute of the UK) using their GSS code (a 9 character alpha numeric identifier) S12000036 and the URI http://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 URI http://statistics.gov.scot/id/statistical-geography/S12000036. Furthermore, the Ordnance 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, a second-order administrative division, as http://sws.geonames.org/2650225/. All of these URIs refer to the same Spatial Thing and are equated using owl:sameAs.

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

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

   Note

   Given the very strong semantics of the owl: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 by Open.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 or place. Spatial relations (see above) can be used to describe how locations are related — either using rigorous topological relationships derived from geometry, such as geosparql:sfEquals, or ones without formal mathematical underpinning, such as geonames:nearby. But place 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 like The Sahara because not everyone agrees where its edge lies!

   Talking of places, the City of Edinburgh [Administrative] Area and Edinburgh the named place are strongly related; you might say that they are the same 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 the within link relation type to relate the named place Edinburgh and the City of Edinburgh (osuk:7000000000030505) administrative area. within complements a qualitative same-place-as relation between two places.

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

3. Domain-specific relationships involving Spatial Things

   In addition to the spatial relationships that are applicable to a wide variety of domains, there are a huge number of cases where asserting a relationship between Spatial 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 between Spatial Things in a gazetteer. 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.

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

   A second domain where relationships between Spatial 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 the sams:hostedProcedure property) and relates that monitoring point to the waterbody whose properties are being measured (using the sam:sampledFeature property). Here, the links are defined using [XLINK11].

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

   Note

   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 and Long=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 the schema:locationCreated property.

   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 and schema:mainEntity property could be used: