One of the most fundamental aspects of publishing spatial data, data about location, is how to express and share the location in a consistent way. In almost all cases where you are publishing data for use by the wider web community the use of latitude and longitude coordinates (Lat and Long) is most appropriate. Latitude and longitude coordinates are global and offer a level of precision well suited to many applications: you can express a location to within a few metres which is perfect for locating your favorite coffee shop, geocoding a photograph or capturing an augmented reality Pokemon hiding in your local park.
-As with everything to do with spatial data, things can get more complicated. One of the most common problems occurs because not all Coordinate Reference Systems (CRS) agree how to express latitude and longitude coordinates. Some CRS order the coordinates Lat/Long while others use Long/Lat; some use decimal degrees while others use degrees, minutes and seconds (dms). Axis order mistakes can mean the difference between a position in the Netherlands or somewhere off the coast of Somalia, while encoding coordinates in decimal degrees when dms is expected can lead to positional errors on the kilometer scale.
+As with everything to do with spatial data, things can get more complicated. One of the most common problems occurs because not all Coordinate Reference Systems (CRS) agree how to express latitude and longitude coordinates. Some CRS order the coordinates Lat/Long while others use Long/Lat; some use decimal degrees while others use degrees, minutes and seconds (dms). Axis order mistakes can mean the difference between, say, a position in the Netherlands or somewhere in Somalia, while encoding coordinates in decimal degrees when dms is expected can lead to positional errors on the kilometer scale.
Therefore it is very important to provide explicit information to your users about how coordinates are encoded. For example, this snippet of results from the Google Geocoding API makes explicit which is the latitude and which is the longitude coordinate.
@@ -526,7 +526,7 @@Other mechanisms include using a data format that specifies how the coordinates are included (such as GeoJSON [[RFC7946]] where section 4. Coordinate Reference System specifies coordinate order of longitude and latitude using units of decimal degrees) or by having your data explicitly reference the CRS definition you're using. See Best Practice 17: Describe the location according to a Coordinate Reference System for more information.
+Other mechanisms include using a data format that specifies how the coordinates are included (such as GeoJSON [[RFC7946]] where section 4. Coordinate Reference System specifies coordinate order of longitude and latitude using units of decimal degrees) or by having your data explicitly reference the CRS definition you're using. See Best Practice 17: State how coordinate values are encoded for more information.
Users of spatial data are often interested in the third dimesion too: vertical elevation (or altitude). For most situations, we can consider elevation to be the vertical distance above (or below) mean sea level. The elevation is most often expressed in meters (but this can vary between CRS definititions) and is provided as a third value in a coordinate position.
@@ -547,25 +547,23 @@So it may be that you have information in a projected CRS, rather than global latitude and longitude - what should you do? You can publish data as is in one of these many projected CRS, but you need to tell users which particular CRS is being used. A good directory of Coordinate Reference Systems is maintained by the International Association of Oil and Gas Producers: the EPSG Geodetic Parameter Dataset.
It is common for a CRS to be described by its ESPG code. For example, 2-dimensional WGS 84 (Lat/Long) is EPSG:4326, 3-dimensional WGS 84 (Lat/Long/elevation) EPSG:4979, Web-Mercator (a global projected CRS used in most Web-mapping applications) is EPSG:3857 and OSGB 1936 / British National Grid (a national projected CRS) is EPSG:27700.
-Lists of Coordinate Reference Systems are available from the Open Geospatial Consotium CRS Register, Spatial Reference and EPSG.io (an open-source web service which simplifies discovery of coordinate reference systems utilized worldwide).
+It is common for a CRS to be described by its ESPG code. For example, 2-dimensional WGS 84 (Lat/Long) is EPSG:4326, 3-dimensional WGS 84 (Lat/Long/Elevation) EPSG:4979, Web-Mercator (a global projected CRS used in most Web-mapping applications) is EPSG:3857 and OSGB 1936 / British National Grid (a national projected CRS) is EPSG:27700.
+Definitions of coordinate reference systems are available from the Open Geospatial Consotium CRS Register, Spatial Reference and EPSG.io (an open-source web service which simplifies discovery of coordinate reference systems utilized worldwide).
Alternatively you can re-project your coordinates to WGS 84 using many available tools online. So for example the location at 516076, 170953 in British National Grid Coordinates is -0.331841, 51.425708 in WGS 84 Long/Lat. This conversion is a useful step as it makes you data more accessible to global users. So if you can do so, it is helpful to publish data in both local (projected) and global coordinates.
Alternatively you can re-project your coordinates to WGS 84 using many available tools online. So for example the location at 516076, 170953 in British National Grid (EPSG:27700) coordinates is -0.331841, 51.425708 in WGS 84 Long/Lat. This conversion is a useful step as it makes you data more accessible to global users. So if you can do so, it is helpful to publish data in both local (projected) and global coordinates.
Re-projecting to a better known CRS is also a necessary step if you are publishing data in the form of engineering or Computer Aided Design (CAD) drawings of a new building or road layout for example. Usually these drawings are made using a very local coordinate reference system for the site itself, so the data will need to be reprojected to “fit” with existing data.
-A number of open source software implementations are available to help users do such conversions. For example Apache SIS® provides an application programming interface (API) to convert coordinates into different coordinate systems (for more information on Apache SIS® please refer to their documentation). Other implementations include the Geospatial Data Abstraction Library (GDAL) and the Cartographic Projections Library (PROJ.4) for which there is a JavaScript implementation.
-So we are now at the point where almost everyone publishing spatial data on the Web can stop reading. But for those with specific requirements concerning high precision locations, there are a few more topics that need to be mentioned.
-If you need to be able to measure in terms of a few centimetres or less then things are more complicated. With this level of precision required you need to take into account a more sophisticated model of the shape of the Earth (because depending on your location, different ellipsoids will provide a better approximation of the local Earth's surface at the expense of a poorer match elsewhere) and take into account plate tectonics.
+If you need to be able to measure in terms of a few centimetres or less then things are more complicated. With this level of precision required you need to take into account a more sophisticated model of the shape of the Earth and take into account plate tectonics.
+ +For these more complex use cases other reference systems with alternative geodetic datums are used. The geodetic datum can be thought of as the model of the Earth's surface over which the coordinate reference system is applied. Different datums use different models for the precise shape and size of the Earth in order to provide more accurate horizontal or vertical measurements at different positions on the globe (because depending on your location, different ellipsoids will provide a better approximation of the local Earth's surface - but this is at the expense of a poorer match elsewhere).
-For these use cases more complex reference system and geodetic datums are used. For example in Europe a system called ETRS89 (EPSG:4258) can be used instead of WGS 84, while in North America a similar system called NAD-83 (EPSG:4269) is used. So it might be that you have measurements made using these reference systems. Here the best practice is once more to be explicit in describing the CRS used, but also to be careful re-projecting to different systems as required accuracy may be lost.
+While WGS 84 provides a reasonable fit at all points on the Earth's surface, many other datums are defined for improved fit within a regional or national area. For example in Europe a system called ETRS89 (EPSG:4258) can be used instead of WGS 84, while in North America a similar system called NAD-83 (EPSG:4269) is used. So it might be that you have measurements made using these reference systems. Here the best practice is once more to be explicit in describing the CRS used, but also to be careful re-projecting to different systems as required accuracy may be lost.
-Finally another issue is that points on the surface of the earth are actually moving relative to the coordinate system, due to geologic processes. You may think this is of interest only to geologists, but when I tell you that Australia has moved around 1.5m since the framework was last reset 20 years ago, and remind you that we are entering the age of self-driving cars, then you will probably think again. Re-calculating the datum from time to time, or maybe continuously, really does matter for some applications. See Best Practice 3: Specify Coordinate Reference System for high-precision applications for more information.
+Finally another issue is that points on the surface of the earth are actually moving relative to the coordinate system, due to geologic processes. You may think this is of interest only to geologists, but when I tell you that Australia has moved around 1.5m since the framework was last reset 20 years ago, and remind you that we are entering the age of self-driving cars, then you will probably think again. Re-calculating the datum from time to time, or maybe continuously such as in the case of the dynamic New Zealand Geodetic Datum (NZGD2000), really does matter for some applications. See Best Practice 3: Choose the coordinate reference system to suit your user's applications for more information.
Detailed discussion of coordinate reference system definitions themselves is beyond the scope of this best practice document. Should this topic be of interest, please refer to specialist documentation such as [[OGC-TOPIC-2]] / [[ISO-19111]].
@@ -769,7 +767,7 @@In Spatial Data Infrastructures the accepted standard for describing metadata is @@ -895,64 +893,73 @@
Use the most accurate Coordinate Reference System Datum available for - high-precision applications
-For high accuracy applications (such as precision agriculture and defense) where spatial referencing must be accurate to a few meters or even centimeters the most accurate Datum must be used.
+Choose the coordinate reference system to suit your user's applications
+Consider your user's intended application when choosing the coordinate reference system(s) used to publish spatial data.
Why
-One of the core components of a Coordinate Reference System (CRS) is the Datum used. The datum can be thought of as the model of the object over which a coordinate reference grid and other elements of a CRS are applied. Earth based or “Geodetic Datums” start with a reference ellipsoid (stretched sphere), which approximates the shape of the Earth and one or more points on the Earth's surface chosen as anchor "base-points". Different datums use different models for the precise shape and size of the Earth in order to provide more accurate measurements at different positions on the globe. For example, NAD83 provides a more accurate datum for North America than the WGS84 datum. While less accurate in North America, WGS84 provides a good general datum for the whole of the earth and for this reason is the datum used by the Global Positioning System (GPS). However, WGS84 is usually inappropriate for high accuracy applications. The Web Mercator projection (EPSG::3857) never is as its datum is spherical and not true to the shape of the earth.
-Horizontal datum - allow latitude and longitude or other coordinate system to describe relative ground position, usually based on sea level. Vertical datum - provide a reference for measuring elevations or depths.
-The use of different datums often results in different co-ordinate values. This is commonly known as datum shift. This datum shift can vary from one place to another and can be anything from zero to hundreds of meters or more. The datum choice may also effect the position of the poles and equator. Dynamic datums such as the New Zealand Geodetic Datum (NZGD2000) are designed to adjust with time to account for tectonic shifts. North America and Europe are receding from each other by a couple of centimeters per year, whereas Australia is moving several centimeters per year north-eastwards due to continental drift. New Zealand shifts position in multiple directions. So, for better accuracy in the New Zealand case, NZGD2000 was devised and it is frequently revised to take account of earth deformations.
-For users to judge if the data is usable to them, they must always be able to determine what datum is used. Individual numbered CRS published in EPSG use a specific datum. The datum also has a specific identifier. For instance, the WGS84 CRS identified as EPSG::4326 GeodeticCRS is based on WGS84 Datum which is identified as EPSG::6326 GeodeticDatum. It is unfortunate that both (as well as a few more CRS) are referred to colloquially as “WGS84”. The WGS84 Datum is a popular datum for a large number of other projections as well, such as from Example 6, "WGS 84 / UTM zone 30N" (EPSG::32630 Projected CRS). In some cases the Datum may be determined by the specification of the data format that is used, e.g GeoJSON uses WGS84 CRS. Regardless, the Datum should be specified as part of the CRS metadata so that clients and users can judge if the data is usable. -
-A multitude of coordinate reference systems exist because there is no perfect solution to meet all requirements:
+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 a geodetic datum that is described using an ellipsoid. 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 by ETRS89 / EPSG:4258) provide a better fit in a given region at the expense of accuracy elsewhere.
+Spatial data is often projected 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 with datums, projections are often chosen to better support regional, national or local needs.
+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 the New Zealand Geodetic Datum (NZGD2000) that is frequently revised to take account of earth deformations.
+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 or satellite imagery etc. are often captured and stored in an engineering coordinate refence system as measurements from a local datum (e.g. X and Y pixel positions along orthogonal axes of an image or, in the case of linear referencing, distance along a specified feature from a fixed point).
+Although it is possible to convert coordinates from one CRS 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 the spatial data - especially where users have limited expertise with spatial data.
+ +When publishing spatial data it is best to help users avoid the need for them to transform spatial data between coordinate 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 applictions of their user community.
+ +Intended Outcome
-Clients or users can determine the Datum which CRS is based. Also, a Coordinate Reference System (CRS) Datum sensitive to the intended domain of high accuracy application should be chosen for the spatial data useful to these.
+Spatial data is provided in a coordinate reference system, or systems, that are sensitive to the needs of user's intended applications.
+The majority of a publisher's anticipated user community do not need to transform coordinate values prior to using the spatial data.
Possible Approach to Implementation
-Recommendations about CRS referencing should consider:
-Whichever coordinate reference system is chosen for the publication of spatial data, it is imperative that that choice is made clear to users. Please refer to Best Practice 17: State how coordinate values are encoded for further details.
+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 data from multiple sources to be readily combined for display or computation. 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. Although Web Mercator (EPSG:3857) has global coverage data publishers should be aware that its geodetic datum is spherical and not true to the shape of the earth, thereby introducing positional differences of upto 20 kilometers when compared with WGS 84.
+ +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 prioritised 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:
+publication through government data portals that require use of a projected CRS defined by the national mapping agency - and similar legislative requirements;
+The Basisregistraties Adressen en Gebouwen (BAG), or Basic Registers for Addresses and Buildings, provided by Kadaster, publishes data in both OGC CRS84 (using the WGS 84 geodetic datum) and the Amersfoort / RD (EPSG:28992) coordinate reference systems.
+The INSPIRE Directive 2007/2/EC of the European Commission requires that the European Terrestrial Reference System 1989 ETRS89 (EPSG:4258) is used for the referencing of spatial data sets.
+Discussion of coordinate system transformations is beyond the scope of this best practice document. However, we note that there are a number of open source software implementations are available to help users do such conversions. These include: the Geospatial Data Abstraction Library (GDAL), the Cartographic Projections Library (PROJ.4), its associated JavaScript implementation (PROJ4.JS) and the Apache Spatial Information System Library (SIS).
+How to Test
-...
+Spatial data is available in at least WGS 84 Lat/Long (EPSG:4326) or WGS 84 Lat/Long/Elevation (EPSG:4979).
Evidence
-Relevant requirements: R-DeterminableCRS
+Relevant requirements: + R-AvoidCoordinateTransformations, + R-CoordinatePrecision. +
[ORPHAN TEXT FROM BP 17 (TEMPORARY)]
-The following describes some of the key considerations in choosing a CRS.
-Make your spatial data indexable by search engines
Search engines should be able to crawl spatial data on the Web and index spatial things for direct discovery by users.
@@ -1141,7 +1136,7 @@In the Spatial Metadata section we provided a Best Practice on how +
In the Spatial Metadata section we provided a Best Practice on how to deal with CRS in spatial data on the web. There is also a clear link between CRS and data quality, because the accuracy of spatial data depends for a large part on the CRS used. This can be seen as conformance of data with a "standard" - in this case, a (spatial @@ -2624,11 +2619,11 @@
There is a predominant view that "I just need to use Lat and Long - and I'm done".
Although the vast majority of spatial data published on the Web uses WGS 84 Long/Lat (as used by GPS), we strongly recommend that spatial data is published with all the necessary information to interpret coordinate values. Even where it the use of latitude and longitude angular measurements is obvious, the choice of datum and units of measurement have an impact. In particular, angular measurements appearing as floating point numbers are mostly likely to be provided in decimal degrees, may be radians or gons (also known as grads).
-The problem that the assumption of a "predominant view" leads to ambiguity. For example, many spatial data users work entirely with information provided in their national coordinate reference system (such as the Dutch Amersfoort / RD, EPSG:28992 or OSGB 1936 / British National Grid EPSG:27700) which make all coordinates in WGS 84 Long/Lat (especially the negative numbers) utterly perplexing.
+The problem that the assumption of a "predominant view" leads to ambiguity. For example, many spatial data users work entirely with information provided in their national coordinate reference system (such as the Dutch Amersfoort / RD EPSG:28992 or OSGB 1936 / British National Grid EPSG:27700) which make all coordinates in WGS 84 Long/Lat (especially the negative numbers) utterly perplexing.
In practice, a publisher not documenting their CRS and presuming that latitude and longitude can be treated as cartesian is often bailed out by fuzzy use cases and software that takes care of projections. However, CRS and coordinate axis order ambiguity leads sooner or later to serious and avoidable errors, while ignorance of datums and map projections leads to broken applications. Furthermore, these practices will also become less and less tenable as new applications such as Augmented Reality require higher data precision and accuracy.
There are three common ways that this information can be provided:
+There are four common ways that this information can be provided:
Provide each coordinate value with explicit labels and provide metadata to indicate what each label means.
@@ -2724,7 +2719,14 @@State within the data itself which coordinate reference systemis used.
+State within the data itself which coordinate reference system is used.
<gml:Polygon srsDimension="2" axisLabels="east north"
srsName="http://www.opengis.net/def/crs/EPSG/0/28992">
@@ -2758,7 +2760,7 @@ Other best practices
</gml:exterior>
</gml:Polygon>
- The example above encodes the polygon for Anne Frank's House in [[GML]]. The XML attribute srsName (srss 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 example above encodes the polygon for Anne Frank's House in [[GML]]. The XML 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.
{
@@ -2774,17 +2776,48 @@ Other best practices
"@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))"
+ "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 the coordinate reference system used. 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.
When using the wktLiteral datatype specified in [[GeoSPARQL]], the coordinate 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.
When using the wktLiteral datatype specified in [[GeoSPARQL]], the coordinate 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 by Kadaster, uses this default behaviour. Anne Frank's House, is identified using the URI http://bag.basisregistraties.overheid.nl/bag/id/pand/0363100012169587. HTML, JSON, TTL and XML representations are available.
Describe the coordinate reference system in the dataset metadata.
++@prefix ex: <http://data.example.org/datasets/> . +@prefix dcat: <http://www.w3.org/ns/dcat#> . +@prefix dcterms: <http://purl.org/dc/terms/> . +@prefix skos: <http://www.w3.org/2004/02/skos/core#> . + +ex:ExampleDataset + a dcat: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 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]].
For more information about dataset metadata, please refer to Best Practice 1: Include spatial metadata in dataset metadata.
+ +Evidence
-...
+Relevant requirements: + R-DeterminableCRS, + R-CRSDefinition, + R-GeoreferencedData, + R-LinkingCRS. +