[GeoSciML] locating intervals in boreholes

Steve Richard steve.richard at azgs.az.gov
Fri Jun 14 12:19:25 EDT 2013

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.




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] 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/20130614/3014c241/attachment.htm>

More information about the GeoSciML mailing list