Borehole Intervals

Recent efforts to stand up a WFS service for borehole samples has highlighted a major problem with delivering downhole intervals via WFS. (I thank Ben Caradoc-Davies and the folk at CSIRO for spending the last day talking through the issue.)

1. Examples of what we want to deliver

eg, a specimen or mapped interval located at 1.6 to 2.5 metres down a borehole
            <spec:samplingLocation>
                <gml:LineString uomLabels="m" srsDimension="1" srsName="http://data.geoscience.gov.au/feature/ga/borehole/17008.shape" gml:id="GA-17008-interval-003">  
   <!-- Borehole shape is not encoded inline -->
                    <gml:posList>1.6 2.5</gml:posList>
                </gml:LineString>
            </spec:samplingLocation>

            <spec:samplingLocation>
                <gml:LineString uomLabels="m" srsDimension="1" srsName="#GA.borehole.17008.shape" gml:id="GA-17008-interval-003">  
   <!-- Borehole shape is encoded inline -->
                    <gml:posList>1.6 2.5</gml:posList>
                </gml:LineString>
            </spec:samplingLocation>

   <gsmlbh:MappedInterval gml:id="csiro_borehole_1_log_1">
                        …
      <gsml:samplingFrame xlink:href="#csiro_borehole_1"/>
      <gsml:shape>
         <gml:LineString uomLabels="m" srsDimension="1" srsName="#csiro_borehole_1" gml:id="csiro_borehole_1_log_1_interval" >  
   <!-- Borehole shape is encoded inline -->
            <gml:posList>1.6 2.5</gml:posList>
         </gml:LineString>
      </gsml:shape>
                       …
   </gsmlbh:MappedInterval>

2. The problem

Clause 7.9.2.4.4 in the WFS 2.0 specification (OGC 09-025r1)

7.9.2.4.4 srsName parameter

The optional srsName attribute may be used to assert a specific WFS-supported CRS transformation to be applied to the geometries of the features returned in a response document. The value of the srsName parameter may be the wfs:DefaultCRS or any of the wfs:OtherCRS values listed for the feature type in a server's capabilities document (see 8.3.3). If no srsName value is supplied, then the feature geometries shall be encoded in the response document using the advertised wfs:DefaultCRS value. This attribute has no meaning for feature types with no spatial properties and shall be ignored. Servers that advertise more than one wfs:OtherCRS value in their capabilities document (see 8.3.3) shall be able to transform between the CRS used to store features and any CRS requested using the srsName attribute.

Servers that implement this International Standard shall be able to process srsName attribute values using the following format model: urn:ogc:def:objectType:authority:version: (see OGC 07-092r2) In this format model, objectType shall have the value of "crs", authority shall have the value "crs" and the value is a placeholder for the actual EPSG code value.

This clause indicates that only an EPSG code may be used in srsName in a WFS, to enable reprojection of any gml spatial object delivered by WFS. This has been confirmed by Peter Vretanos. There is no allowance for a local srsName. It is apparent that the WFS community has not considered the use case of a spatial object being defined using a local non-EPSG reference frame because they want everything to be able to be projected. Geoserver currently strictly implements this clause, allowing neither a non-EPSG code srsName, nor the ability to construct a GML spatial object from non-spatial database fields (eg, constructing a gml:LineString from “from” and “to” numeric values in a borehole database). Geosever reads the CRS directly from a spatial database (eg, SRID of Oracle spatial database) with no opportunity for a manual user override of that CRS value.

3. Potential short-term temporary solutions

3.1 Temporary workaround for O&M located specimens
        <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>

3.2 Temporary workaround for GeoSciML mapped intervals
<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/>
   …

4. Potential longer term solutions

Before we choose a permanent solution, we must ask – do we want WFS to support spatial queries on our borehole intervals?

If the answer is yes, then we must either define our borehole interval GML shapes using a coordinate system with an EPSG code, or approach the WFS community with a change request. A change request might require something like WFS 2.0 resolveDepth for srsName to allow reprojection? Or should filter queries on GML geometries with an unrecognised srsName just result in an ows:Exception?

If we don’t require spatial query function on borehole intervals, then we have no need to use GML spatial objects for delivering borehole intervals. We may as well deliver our intervals as numeric, non-spatial elements within GeoSciML/SWE, not GML. Something like:

     <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>

We could ask the Geoserver development team to

  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.

This may be problematic, as the Geoserver community may be reluctant to act contrary to the published WFS 2.0 spec.

5. Where to from here

Either:

  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.

Or:

  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.

-- OllieRaymond - 22 May 2013


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

1. Clemens - it is not the intent of the WFS 2 spec to limit delivery of srsName to EPSG codes only. But the minimum requirement for conformance is to support EPSG codes. Geoserver supports only the minimum WFS requirement.

2. Ben - if Clemens' statement is true, then the wording of the WFS 2 spec needs improvement (see the Change Request below).

3. Ollie - would prefer to fix Geoserver so that it can deliver custom srsName rather than change the model to accommodate a limitation of Geoserver.

4. Rini - a fix for Geoserver would require coding in the core (Geotools) module of Geoserver. Rini can do some software development during July and submit to Geoserver trunk. Good prospect that this would be accepted. Ollie will provide Rini with information for unit tests.

-- OllieRaymond - 05 Jun 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

https://www.seegrid.csiro.au/wiki/CGIModel/BoreHolesAndObservation#Linear_Referencing_40Borehole_41

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).

Topic revision: r4 - 05 Jun 2013, OllieRaymond
 

This site is powered by FoswikiCopyright © by the contributing authors. All material on this collaboration platform is the property of the contributing authors.
Ideas, requests, problems regarding OGC Public Wiki? Send feedback