[GeoSciML] Borehole schema v3.2 [SEC=UNCLASSIFIED]

Steve Richard steve.richard at azgs.az.gov
Thu Jul 18 13:41:02 EDT 2013


Ollie-sorry about the delay. I've got some time to look at GSML finally.

Anyway, the interval begin and end solution looks good to me.  There are
still some interesting conventions w.r.t. simplifications for some common
borehole types. As I see things, we've got 3 situations:

1.      The simple straight vertical borehole with one wellbore segment.
Interval begin and end with the origin position are all that's necessary to
switch between the borehole crs and a 3D geospatial CRS

2.      Straight inclined borehole. In addition to the interval begin,
interval end, and origin position, need to know the bearing and plunge of
the wellbore trace.  Solution with current scheme would be indicate inclined
hole with inclinationType property on BoreholeDetails and provide a
mappedInterval shape that has one GM_Curve/segment/GM_LineSegment with
origin at borehole origin and end at the 3-D TD location (use
DirectPositions with dimension 3).  Is it worth defining a convention for
this?

3.      General curvilinear borehole, have to use general GM_Curve for shape
if want to go from borehole CRS to 3D geospatial.

 

 

A couple of comments looking at the eap for 3.2 in subversion branch/3.2.0

Shouldn't the IntervalBegin and IntervalEnd properties be
'estimatedProperty'

The 'interval' association from DrillingDetails to GM_Object has cardinality
1, which is OK if we add the 'voidable' stereotype on the association.

I think we could make the model more specific for the GM_Object associated
with DrillingDetails, by showing the 'interval' association target to be
'GM_Curve' (see GML scope notes on GM_Curve below).  In this light is would
also make sense to add a constraint that the 'shape' GM_Object for a
MappedInterval must be a GM_Curve.  

 

Somehow we also need to weasel things so the 'shape' on a MappedInterval is
'voidable'.  This can easily be written into the requirements classes in the
abstract model, but is tricky in the UML. I guess we'd have to make 'shape'
voidable on MappedFeature and note that rules for use of nil values are
applied for specific usages of MappedFeature and its subtypes?

 

steve

 

 

 

GML scope notes on GM_Curve element:

"GM_Curve (Figure 11) is a descendent subtype of GM_Primitive through
GM_OrientablePrimitive. It is the basis for 1-dimensional geometry. A curve
is a continuous image of an open interval and so could be written as a
parameterized function such as c(t):(a, b)REn where "t" is a real parameter
and En is Euclidean space of dimension n (usually 2 or 3, as determined by
the coordinate reference system). Any other parameterization that results in
the same image curve, traced in the same direction, such as any linear
shifts and positive scales such as e(t) = c(a + t(b-a)):(0,1) REn, is an
equivalent representation of the same curve. For the sake of simplicity,
GM_Curves should be parameterized by arc length, so that the
parameterization operation inherited from GM_GenericCurve (see 6.4.7) will
be valid for parameters between 0 and the length of the curve. 

Curves are continuous, connected, and have a measurable length in terms of
the coordinate system. The orientation of the curve is determined by this
parameterization, and is consistent with the tangent function, which
approximates the derivative function of the parameterization and shall
always point in the "forward" direction. The parameterization of the
reversal of the curve defined by c(t):(a, b)REn would be defined by a
function of the form s(t) = c(a + b - t):(a, b)REn.

A curve is composed of one or more curve segments. Each curve segment within
a curve may be defined using a different interpolation method. The curve
segments are connected to one another, with the end point of each segment
except the last being the start point of the next segment in the segment
list."



 

 

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: Oliver.Raymond at ga.gov.au [mailto:Oliver.Raymond at ga.gov.au] 
Sent: Monday, June 24, 2013 10:15 PM
To: steve.richard at azgs.az.gov
Subject: Borehole schema v3.2 [SEC=UNCLASSIFIED]

 

Hi Steve,

 

I have added elements to a potential v3.2 borehole schema thus:

 

   <complexType name="DrillingDetailsType">
        <sequence>
                ..

            <element name="interval" type="gml:GeometryPropertyType">
                <annotation> 
                    <documentation>A shape that is a 1-D interval (eg, a
"from" and "to", or "top" and "base" measurement) and uses the SRS of the
containing borehole</documentation>
                </annotation>
            </element>
            <element name="intervalBegin" minOccurs="0" maxOccurs="1"
type="swe:QuantityPropertyType">
                <annotation>
                    <documentation>The measured distance of the start of the
mapped interval along the path of the borehole. The measured value must be
less than or equal to the intervalEnd value.  The "intervalBegin" and
"intervalEnd" elements are added in version 3.2 as a measure to overcome
problems with the delivery and queryability of 1D GML shapes via the
"interval" element.</documentation>
                </annotation>
            </element>
            <element name="intervalEnd" minOccurs="0" maxOccurs="1"
type="swe:QuantityPropertyType">
                <annotation>
                    <documentation>The measured distance of the end of the
mapped interval along the path of the borehole. The measured value must be
greater than or equal to the intervalBegin value.  The "intervalBegin" and
"intervalEnd" elements are added in version 3.2 as a measure to overcome
problems with the delivery and queryability of 1D GML shapes via the
"interval" element.</documentation>
                </annotation>
            </element>
        </sequence>

 

and.

 

   <complexType name="MappedIntervalType">
        <complexContent>
            <extension base="gsml:MappedFeatureType">
                <sequence>
                    <element name="mappedIntervalBegin" minOccurs="0"
maxOccurs="1" type="swe:QuantityPropertyType">
                        <annotation>
                            <documentation>The measured distance of the
start of the mapped interval along the path of the borehole. The measured
value must be less than or equal to the mappedIntervalEnd value. The
"mappedIntervalBegin" and "mappedIntervalEnd" elements are added in version
3.2 as a measure to overcome problems with the delivery and queryability of
1D GML shapes via the "shape" property.</documentation>
                        </annotation>
                    </element>
                    <element name="mappedIntervalEnd" minOccurs="0"
maxOccurs="1" type="swe:QuantityPropertyType">
                        <annotation>
                            <documentation>The measured distance of the end
of the mapped interval along the path of the borehole. The measured value
must be greater than or equal to the mappedIntervalBegin value. The
"mappedIntervalBegin" and "mappedIntervalEnd" elements are added in version
3.2 as a measure to overcome problems with the delivery and queryability of
1D GML shapes via the "shape" property.</documentation>
                        </annotation>
                    </element>
                </sequence>
            </extension>
        </complexContent>
    </complexType>

 

Giving us a Borehole instance document thus.

 

<gsmlbh:downholeDrillingDetails>
        <gsmlbh:DrillingDetails>
            <gsmlbh:drillingMethod xsi:nil="true" nilReason="missing"/>
            <gsmlbh:boreholeDiameter>
                <swe:Quantity>
                    <swe:uom code="mm"
xlink:href="http://unitsofmeasure.org/ucum.html#millimeter"
xlink:title="millimetre"/>
                    <swe:value>70</swe:value>
                </swe:Quantity>
            </gsmlbh:boreholeDiameter>
            <gsmlbh:interval>
                <gml:LineString gml:id="MyBoreholeTest" uomLabels="m"
srsDimension="1" srsName="#MyBoreholeShape">
                    <gml:posList>0 55</gml:posList>
                </gml:LineString>
            </gsmlbh:interval>
            <gsmlbh:intervalBegin>
                <swe:Quantity>
                    <swe:uom code="m"
xlink:href="http://www.opengis.net/def/uom/OGC/1.0/metre"
xlink:title="metre"/>
                    <swe:value>0</swe:value>
                </swe:Quantity>
            </gsmlbh:intervalBegin>
            <gsmlbh:intervalEnd>
                <swe:Quantity>
                    <swe:uom code="m"
xlink:href="http://www.opengis.net/def/uom/OGC/1.0/metre"
xlink:title="metre"/>
                    <swe:value>55</swe:value>
                </swe:Quantity>
            </gsmlbh:intervalEnd>
        </gsmlbh:DrillingDetails>
    </gsmlbh:downholeDrillingDetails>
    <logElement>
        <MappedInterval gml:id="MyBoreholeInterval1">
            <gsml:observationMethod xsi:nil="true" nilReason="missing"/>
            <gsml:positionalAccuracy xsi:nil="true" nilReason="missing"/>
            <gsml:resolutionScale xsi:nil="true" gco:nilReason="missing"/>
            <gsml:samplingFrame nilReason="missing"/>
            <gsml:shape>
                <gml:LineString gml:id="MyBoreholeInterval1String"
uomLabels="m" srsDimension="1" srsName="#MyBoreholeShape">
                    <gml:posList>24 25</gml:posList>
                </gml:LineString>
            </gsml:shape>
            <gsml:specification nilReason="missing"/>
            <gsml:metadata xsi:nil="true" gco:nilReason="missing"/>
            <gsmlbh:mappedIntervalBegin>
                <swe:Quantity>
                    <swe:uom code="m"
xlink:href="http://www.opengis.net/def/uom/OGC/1.0/metre"
xlink:title="metre"/>
                    <swe:value>24</swe:value>
                </swe:Quantity>
            </gsmlbh:mappedIntervalBegin>
            <gsmlbh:mappedIntervalEnd>
                <swe:Quantity>
                    <swe:uom code="m"
xlink:href="http://www.opengis.net/def/uom/OGC/1.0/metre"
xlink:title="metre"/>
                    <swe:value>25</swe:value>
                </swe:Quantity>
            </gsmlbh:mappedIntervalEnd>
        </MappedInterval>
    </logElement>

 

Is this what you had envisaged?

 

Cheers,

Ollie

_________________________________________________________________

Ollie Raymond
Senior Geologist  - Information Management  |  Continental Geology Section
Minerals and Natural Hazards Division  |   <http://www.ga.gov.au/>
GEOSCIENCE AUSTRALIA

Oceania Councillor & Interoperability Working Group
 <http://www.cgi-iugs.org/> IUGS Commission for the Management and
Application of Geoscience Information

Chair, GeoSciML Standards Working Group
 <http://www.opengeospatial.org/projects/groups/geoscimlswg> Open Geospatial
Consortium
____________________________________________________

Phone:  +61 2 6249 9575    Fax:  +61 2 6249 9971
Email:   <mailto:Oliver.Raymond at ga.gov.au> Oliver.Raymond at ga.gov.au    Web:
<http://www.ga.gov.au/> www.ga.gov.au
Cnr Jerrabomberra Avenue and Hindmarsh Drive   Symonston   ACT
GPO Box 378   Canberra   ACT   2601   Australia

Applying geoscience to Australia's most important challenges

 

From: geosciml-bounces+oliver.raymond=ga.gov.au at lists.opengeospatial.org
[mailto:geosciml-bounces+oliver.raymond=ga.gov.au at lists.opengeospatial.org]
On Behalf Of Steve Richard
Sent: Tuesday, 18 June 2013 2:58 AM
To: 'Ollie Raymond'; 'Public: A mailing list for GeoSciML'
Cc: Bodor Lazar; Florence.Tan at csiro.au; Rini.Angreani at csiro.au
Subject: Re: [GeoSciML] locating intervals in boreholes

 

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.

 

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

> >

 

 

 

Geoscience Australia Disclaimer: This e-mail (and files transmitted with it)
is intended only for the person or entity to which it is addressed. If you
are not the intended recipient, then you have received this e-mail by
mistake and any use, dissemination, forwarding, printing or copying of this
e-mail and its file attachments is prohibited. The security of emails
transmitted cannot be guaranteed; by forwarding or replying to this email,
you acknowledge and accept these risks.
----------------------------------------------------------------------------
---------------------------------------------

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opengeospatial.org/pipermail/geosciml/attachments/20130718/cc44b9e7/attachment-0001.html>


More information about the GeoSciML mailing list