Commit 496c6fc

<h2>Gaps in current practice</h2>

<p>The best practices described in this best practice document are compiled based on evidence of real-world application, as described in <a href="#best-practice-criteria" class="sectionRef"></a>. However, there are several issues that inhibit the use or interoperability of <a>spatial data</a> on the Web, for which no evidence of real-world applied solutions is available. These issues are denoted “gaps in current practice”. In the case of gaps, there might be emerging practice i.e. a solution that has been theorized for a certain issue and has possibly been experimented on in beta settings, but not in production environments. Gaps and emerging practices in the area of publishing spatial data on the Web are discussed in this section.

</p>

<section id="c-geometrycrs">

<h3>Requesting different representations of geometries</h3>

<p>Different use cases may require geometries at different levels of accuracy, precision, and size. <a href="#multiplegeometries" class="sectionRef"></a> outlines some of the approaches to address this requirement, considering general application scenarios and providing guidance on the criteria to be taken into account for choosing the appropriate technique (e.g., compress geometry data, use compact formats, apply geometry generalization mechanisms). The overall recommendation is to make available multiple representations of geometry data, and to give data consumers the ability to identify those most fit for purpose. A variety of mechanisms can be used to achieve this, as publishing different geometry representations at different URIs, and accompanying them with a human- and/or machine-readable description of their characteristics (e.g., format, spatial resolution, scale, level of generalization). However, the lack of common practices in this area makes it difficult to provide consistent guidelines on how to publish and access different geometry representations.</p>

<p>A standardized way of requesting a geometry in a different CRS is decribed in OGC API Features part 2: Coordinate Reference Systems by Reference [[OAF2]]. This is done using parameters, which are defined in the standard, and with a <code>Content-Crs</code> response header to tell the client which CRS was used with the geometries in the response. </p>

<aside class="note">

<p>On a more general level, content negotiation (as recommended in <a href="https://www.w3.org/TR/dwbp/#Conneg">DWBP Best Practice 19: Use content negotiation for serving data available in multiple formats</a>) could be a way to deal with requesting different representations of geometries - be it different data formats, CRSs, levels of accuracy, etc. Content negotiation could be expanded to enable its use for choosing a 'profile' concerning the semantics and structure of the data, such as a data vocabulary. The <a href="https://www.w3.org/2017/dxwg/charter">Dataset Exchange WG (DXWG)</a> aspires to provide a REC for "content negotiation by profile" (see also [[RFC6906]] "profile" Link Relation Type).</p>

</aside>