Coordinate reference system

[duncandewhurst]

Mapping is a cross-cutting use case for data on the physical location of fibre infrastructure.

Users need to know which coordinate reference system (CRS) is used in data so that they can accurately plot locations on a map.

Either the standard can specify a single CRS which must be used by all publishers or publishers can specify the CRS used in their data.

We propose to follow GeoJSON's approach, which is to require the use of:

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.

The GeoJSON RFC notes that the use of alternative (publisher specified) CRS has proven to have interoperability issues.

In general terms, the disadvantage of allowing publishers to specify a CRS is that the effort of transforming between systems is placed on data users and consuming applications, some of which may not have access to CRS databases and transformation parameters.

Specifically for OFDS, given that we plan to support JSON, GeoJSON and CSV publication formats and to provide conversion tooling, this would mean that a tool for converting from JSON or CSV to GeoJSON form would need to be 'CRS aware', which adds significant complexity. It would also open up the possibility of the same dataset being available with different CRS's depending on the publication format, which could be confusing for users.

Under the proposed approach of requiring the use of urn:ogc:def:crs:OGC::CRS84, users still need to know the CRS used in published data. That information should be proximate to the data, i.e. users shouldn't need to read the standard documentation to find it. There are two options (not mutually exclusive) for communicating the CRS

1. Recommend that implementers include the CRS in their dataset's metadata
2. Include a field in the standard to specify the CRS, which would be set to the same value across all datasets.

In my experience of other standards, publishers often fail to follow guidance on publishing other information alongside a dataset so I think that doing both would be a pragmatic solution, even if the second option seems somewhat duplicative.

This issue is to surface any other options that should be considered and to seek feedback on the preferred option(s).

[lgs85]

I agree with the proposed approach of requiring urn:ogc:def:crs:OGC::CRS84, and that including the CRS in both the metadata and the schema is a sensible, albeit imperfect, compromise.

[stevieflow]

The IATI standard requests that users include the attribute srsName="http://www.opengis.net/def/crs/EPSG/0/4326" whenever including a pair of lat longs in their data:

Note: The @srsName attribute should always be populated with http://www.opengis.net/def/crs/EPSG/0/4326.

Alas, on checking the data, of the 1 million instances of the publication of this attribute:

• around 400,000 are blank
• A smaller proportion (around 2,000) mistype the reference:

http://opengis.net/def/crs/EPSG/0/4326
http://ww.opengis.net/def/crs/EPSG/0/4326
http://www.opengis.net/def/crs/EPSG/0/432
http://www.opengis.net/def/crs/EPSG/0/4327

Hence, this suggests that a static value is not published consistently. The 400k blank records render the field almost redundant.

That information should be proximate to the data, i.e. users shouldn't need to read the standard documentation to find it.

Understood/agreed, but perhaps this illustrates the need for some very specific and direct user guidance. Such material can then cover the fact that this value is consistent to all data.

[duncandewhurst]

Thanks, @stevieflow. I've added the non-normative documentation label as a reminder to include this in the data use guidance.

[duncandewhurst]

Noting that, since draft 6, JSON schema includes support for constant values.

[IsabelBirds]

Prior art research surfaced these recommendations from Ordnance Survey for UK authoritative data providers.

The relevant part for here is the recommendation to specify an EPSG code for WGS84, as multiple CRS use the WGS84 datum. For the international standard geographic CRS this is EPSG:4326.

[duncandewhurst]

As discussed here, due to the ordering of coordinates in GeoJSON, the EPSG code 4326 (WGS84) cannot be used to identify the CRS for GeoJSON data.

I think that the correct approach is to use either URN specified in the GeoJSON spec (though I'm confused why the [version] component is missing) or to use the equivalent resolvable URI: http://www.opengis.net/def/crs/OGC/1.3/CRS84. In fact, if we make crs an object we could do both:

{
  "crs": {
    "name": "urn:ogc:def:crs:OGC::CRS84",
    "uri": "http://www.opengis.net/def/crs/OGC/1.3/CRS84"
  }
}

[duncandewhurst]

Noting that the approach we settled on conforms to the W3C's Spatial Data on the Web Best Practice 8: State how coordinate values are encoded.

I'm going to close this issue as the schema, normative documentation and non-normative documentation have all been updated.