[GeoSciML] locating intervals in boreholes

Ollie Raymond ollieraymond99 at gmail.com
Sat Jun 15 10:11:36 EDT 2013


Hi Steve,

Discussions among the group in the last week or so have convinced me that
there is a need for queryability of borehole intervals, both as distance
downhole and distance below a height datum.

However, I am not convinced that we need to provide the interval location
data in multiple formats to satisfy all these needs.  I would suggest that
if users want to deal with boreholes in true 3D space (eg, depth below a
datum, intersections with 3D volumes, etc), then their client application
should be sophisticated enough to convert downhole measurements with an
associated downhole survey into fully 3D locations.  I would not want
to *require
*data providers to provide more than a collar location (X,Y and Z),
downhole measurements, and a borehole survey.  Delivery of fully 3D GML
interval locations in a 3D CRS I personally think is more than many data
providers will have.  Maybe delivering intervals as 3D GML shapes could be
an optional extra?

I am OK with "*a flag to indicate if a borehole can be approximated as a
vertical line (Boolean…)*".  I think that it, along with downhole interval
measurements and a collar location, will service a large number of cases in
2D and 2.5D GIS applications for vertical boreholes (which are very common).

Unless WFS comes up with a query capability for intervals as 1D GML shapes
(unlikely in the short term?) then Option 4 seems the way to go for both
GSML v3.x and v4.

Cheers,
Ollie

====================================

On 15 June 2013 02:19, Steve Richard <steve.richard at azgs.az.gov> wrote:

> For the record--****
>
> I also consider the string approach to be a bad choice.****
>
> ** **
>
> I'd be in favor of an approach like #4-- consider the borehole as a
> collection of linear segments. Based on what I imagine people would be
> interested in doing with borehole interval data, I think we need some
> combination of the following in our model:****
>
> ** **
>
> **·        **3-D point location for top and bottom of interval, as
> separate attributes; could use gml:point with a 3-D CRS, but end up with a
> 'gml:doubleList' as the actual data, so client still has to be able to pull
> the list apart and covert the string tokens to X,Y, and Z numeric
> coordinates. Allows queries for wellbore intervals that intersect some 3D
> volume or surface (with appropriately sophisticated client and server
> software); make visualization in 3D software straightforward.  Makes
> approximation that each interval is a straight line.****
>
> **·        **Top and bottom of the interval measured along the well bore
> as single numeric values, as separate attributes; interval should be
> indexed to a ‘well bore’ object (link by URI) that has the full 3-D
> geometry. This enables queries for intervals at some depth along the well
> bore; if model also has a flag to indicate if a borehole can be
> approximated as a vertical line (Boolean…), then can use this to make 3-D
> visualization (assume also have collar location point).****
>
> **·        **Surface projection of top and bottom of interval; 2 Simple
> 2-D points. Puts onus of projecting 3-D wellbore geometry to map view.
> Enable queries for boreholes intervals beneath some surface location using
> GIS operations. ****
>
> **·        **True vertical depth of the top and bottom (relative to
> borehole collar), as separate attributes; puts the onus on the data
> provider to do the mapping from wellbore geometry to true depth. This makes
> more sense to me that expecting clients to handle the problem.  Allows
> query for intervals at some depth below the local surface. Client could use
> collar location elevation to convert of depth to elevation.****
>
> **·        **Elevation of the interval top and bottom, as separate
> attributes, relative to MSL (or some other datum). Allows queries for
> intervals at some particular elevation. Client could use collar location
> elevation to convert of elevation to depth.****
>
> **·        **Each segment should have a link to a wellbore object that
> includes a full 3-D geometry for the wellbore, but we don’t necessarily
> have to specify how that geometry is represented in our interval model.***
> *
>
> **·        **Each segment should have the collar location point (X,Y SRS)*
> ***
>
> **·        **Each segment should have collar location elevation (Z, CRS)**
> **
>
> ** **
>
> The underlying assumption in most of these is that for those interested in
> 3-D geometry, approximating intervals as straight line segments is good
> enough for most purposes. ****
>
> Next step for me is to go back to our model and see how we can most simply
> convey the information.****
>
> Another important consideration is that this is meant to be an information
> exchange format AND a query schema. Since joins in WFS are not yet
> mainstream, the schema needs to be denormalized for anything we anticipate
> querying.****
>
> And there’s always the issue that we can’t imagine every possible use
> scenario in advance. That said, if we don’t make it relatively easy to  do
> the things that we know we’d like to be able to do, we’ll continue shooting
> ourselves in the foot.****
>
> ** **
>
> steve****
>
> ** **
>
> Stephen M Richard****
>
> Arizona Geological Survey****
>
> 416 W. congress #100****
>
> Tucson, AZ****
>
> AZGS: 520-770-3500****
>
> Office: 520-209-4127****
>
> FAX: 520-770-3505****
>
> ** **
>
> ** **
>
> > -----Original Message-----****
>
> > From: geosciml-bounces+jll=bgs.ac.uk at lists.opengeospatial.org****
>
> > [mailto:geosciml-bounces+jll=bgs.ac.uk at lists.opengeospatial.org<geosciml-bounces+jll=bgs.ac.uk at lists.opengeospatial.org>]
> On ****
>
> > Behalf Of Oliver.Raymond at ga.gov.au****
>
> > Sent: 28 May 2013 05:27****
>
> > To: Ben.Caradoc-Davies at csiro.au****
>
> > Cc: Lazar.Bodor at ga.gov.au; Florence.Tan at csiro.au; ****
>
> > geosciml at lists.opengeospatial.org; Rini.Angreani at csiro.au****
>
> > Subject: Re: [GeoSciML] Geoserver question - using a custom srsName in *
> ***
>
> > gml shape elements [SEC=UNCLASSIFIED]****
>
> >** **
>
> ... snip
>
> > >       GeoSciML v3 options (revised)
>
> > >
>
> > > 1.  Abandon MappedInterval/gml:LineString and use a kludge workaround
>
> > > to deliver the interval coordinates.  Gml:location has been deprecated
>
> > > (thanks for the heads-up John).  We would be stuck with something like:
>
> > >       <gml:description xlink:role="interval in metres">1.3
>
> > > 2.5</gml:description>
>
> > >
>
> > > 2.  Rini (or similar) writes a function for Geoserver to be able to
>
> > > encode gml:LineString for intervals with borehole (ie, non-EPSG)
>
> > > srsNames.  The resultant WFS may very limited (none?) queryability or
>
> > > projectability for intervals, but at least it is delivering GeoSciML
>
> > > v3 and O&M/Specimen/samplingLocation as the schemas intended, and
>
> > > would not cause conniptions for INSPIRE.  I assume that the result
>
> > > would still be a compliant WFS?  [If it can be made to work, this is
>
> > > my preference for GSML v3.]
>
> > >
>
> > >       GeoSciML v4 options (revised)
>
> > >
>
> > > 3. Retain the GeoSciML v3  GM_Object method of delivering borehole
>
> > > intervals as per option 2 above.  WFS and Geoserver may provide a
>
> > > solution for filtering sometime in the future.
>
> > >
>
> > > 4. Remodel GeoSciML v4 to use a numeric attribute to deliver borehole
>
> > > intervals.  Then we have no dependence on WFS or Geosever for a
>
> > > capability that is outside of its comfort zone and with no guarantee
>
> > > that any solution will be forthcoming.  [This is my preference for
>
> > > GSML v4]
>
> > >
>
> > > Cheers,
>
> > > Ollie
>
> > >
>
> ** **
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opengeospatial.org/pipermail/geosciml/attachments/20130616/a5259c05/attachment.htm>


More information about the GeoSciML mailing list