<spec:SF_Specimen gml:id="GA.Specimen.1517948">  
           …
            <sa:parameter>
                <om:NamedValue>
                    <om:name xlink:title="dowhnole interval location"/>
                    <om:value>
                        <swe:QuantityRange>
                            <swe:uom code="m" xlink:title="metre"/>
                            <swe:value>1.6 2.5</swe:value>
                        </swe:QuantityRange>
                    </om:value>
                </om:NamedValue>
            </sa:parameter>

<gsmlbh:MappedInterval gml:id="csiro_borehole_1_log_1">
   <gml:location xlink:role="downhole interval measured in metres">
      <gml:LocationString>1.6 2.5</gml:LocationString>
   </gml:location>
   …
   <gsml:samplingFrame xlink:href="#csiro_borehole_1"/>
   <gsml:shape/>
   …

     <gsmlbh:MappedInterval gml:id="csiro_borehole_1_log_1">
         <gsmlbh:interval>
            <swe:QuantityRange definition="Downhole interval" referenceFrame="#csiro_borehole_1">
                <swe:uom code="m" xlink:title="metre"/>
                 <swe:value>1.6 2.5</swe:value>
             </swe:QuantityRange>
         </gsmlbh:interval>

     <gsmlbh:DrillingDetails>
         <gsmlbh:interval>
            <swe:QuantityRange definition="Downhole interval" referenceFrame="#csiro_borehole_1">
                <swe:uom code="m" xlink:title="metre"/>
                 <swe:value>1.6 2.5</swe:value>
             </swe:QuantityRange>
         </gsmlbh:interval>

1. change its rules so that it allows a gml:LineString to be generated from non-spatial database fields
2. allow a non-EPSG code in srsName in a GML spatial object, but issue a warning message if a non-EPSG code is delivered.

1. If we want a change to the WFS standard - http://www.opengeospatial.org/standards/cr - Ben Caradoc-Davies suggests that if we get a CR in by next Wednesday, it will be considered for WFS 2.1.

1. Don’t use GML spatial objects for GeoSciML borehole intervals. Change the GeoSciML v4 model at St Petersburg to use a non-spatial numeric element to deliver borehole intervals. This avoids future issues with WFS, but will not help with GeoSciML v3 services.

Summary of exchanged emails between Ollie Raymond, Ben Caradoc-Davies, Clemens Portele and Rini Angreani... (May 2013)

Text of Ben Caradoc-Davies' Change Request for WFS 2.1

Date submitted: 28 May 2013

Spec: Web Feature Service 2.0 Interface Standard (also ISO 19142)

SpecID: 442

Specversion: 2.0

DocNum: 09-025r1

Title: WFS support for non-CRS srsName and multiple dimension geometries

Source: Ben Caradoc-Davies

Category: C

Reason: GML anticipates the use of non-CRS srsName and permits geometries with different srsName in a single instance document, but WFS precludes such patterns, limiting the expressivity of GML. In particular, see the note on non-CRS srsName in section 10.1.3.2 on page 56 of OGC 07-036 (GML 3.2.1).

A specific use-case in which WFS restrictions on encoded geometries is problematic is that of borehole intervals, in which it is desirable that specimens taken from the earth (cores) are georeferenced by their start and end along a curved path (down-hole depth), preserving the relationship between these specimens. GeoSciML is a GML application schema. The GeoSciML community indicate that they would like to represent borehole intervals in GML using a 1D geometry with srsName (an HTTP URI) that references another geometry, the borehole path, rather than a static CRS definition; this appears a natural fit with the information model and encoding available in GML. In effect, every borehole provides its own 1D CRS: the down-hole depth. Another example of such a 1D CRS is a GML 3.3 LinearSRS:

http://www.opengeospatial.org/blog/1654

Section 7.6.5.5 on page 26 and section 7.9.2.4.4 on page 35 and Table 11 on page 48 of OGC 09-025r1 (WFS 2.0.0) require that all geometries in a WFS response be encoded in a single CRS (either DefaultCRS or a member of OtherCRS selected with wfs:Query@srsName). This causes the following problems:

- srsName that references some shape such as a borehole curve cannot be reprojected to reference some other shape. The requirement to encode a response with a particular srsName can only be satisfied if the target srsName is the same as the storage srsName. This is a particular problem for WFS responses that contain multiple boreholes, where each feature contains a geometry with a different srsName; in this case there is no single srsName that can be used for encoding a WFS response.

- WFS responses that contain geometries of different dimensionalities cannot be encoded using a single srsName. For example, a borehole might contain a collar location that is a 2D geometry and also a 3D shape which is the path of the hole itself. The requirement that all WFS responses are encoded in a single CRS precludes the representation of this feature in a WFS response.

In a nutshell: WFS responses are more expressive if some geometries are encoded with srsName other than the target srsName of a request.

Summary: Ease the restrictions in section 7.6.5.5 on page 26 and section 7.9.2.4.4 on page 35 and Table 11 on page 48 of OGC 09-025r1 (WFS 2.0.0) by permitting a service to encode geometries with srsName other than that requested or advertised in the capabilities document; it is anticipated that this would occur when reprojection makes no sense or geometries are of dimension incompatible with with the target srsName of a request. This modified behaviour would allow srsName to be delivered as data content, enhancing the expressivity of WFS responses.

Spatial filter queries are a more difficult problem: should a service be obliged to honour filter queries on properties that it cannot reproject?

The expansion of 1D geometries into higher dimensions to support filtering is analogous to resolveDepth.

Consequences: Clauses: Section 7.6.5.5 on page 26 and section 7.9.2.4.4 on page 35 and Table 11 on page 48 of OGC 09-025r1 (WFS 2.0.0).