[GeoSciML] locating intervals in boreholes

Steve Richard steve.richard at azgs.az.gov
Mon Jun 17 12:58:09 EDT 2013

Sounds like we're on the same page:

.        Need point location for borehole collar (plot well location on map)

.        Elevation of borehole collar (with datum for elevation, or
convention to use MSL)

.        Link to borehole feature that can carry representation of 3-D
borehole geometry; URI for this feature effectively identifies the CRS for
the wellbore.

.        Coordinate for top of interval (positive down, relative to reported
collar elevation, as measured along wellbore)

.        Coordinate for bottom of interval (positive down, relative to
reported collar elevation, as measured along wellbore)

.        Property to indicate if borehole is vertical. Could be Boolean
(True=vertical), or a term that could provide some other info, something
like 'wellboreshape'  { vertical, inclined down, curved, horizontal,
inclined up, unknown}


Stephen M Richard

Arizona Geological Survey

416 W. congress #100

Tucson, AZ

AZGS: 520-770-3500

Office: 520-209-4127

FAX: 520-770-3505


From: Ollie Raymond [mailto:ollieraymond99 at gmail.com] 
Sent: Saturday, June 15, 2013 7:12 AM
To: Stephen Richard; Public: A mailing list for GeoSciML
Cc: Lazar.Bodor at ga.gov.au; Florence.Tan at csiro.au; Rini.Angreani at csiro.au
Subject: Re: [GeoSciML] locating intervals in boreholes


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.






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

.        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

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/20130617/3b08b41f/attachment-0001.htm>

More information about the GeoSciML mailing list