[GeoSciML] Borehole-Portrayal [SEC=UNCLASSIFIED]

Steve Richard steve.richard at azgs.az.gov
Tue Nov 6 22:54:59 EST 2012


For the simple feature models we’ve been developing for the Geothermal
system, the issue of UOM has been an ongoing debate. The dust is starting to
settle around the view that since the point of the data delivery content
model is to make client consumption of the data as simple as we can,
measured quantities should use prescribed units, and we put the UOM in the
field name to make this clear, thus depth_ft, maxTemperature_F. If there is
a perceived need to allow multiple systems, then there should be another
field e.g a depth_ft field and a depth_m field. The data provider takes care
of units conversion.  

 

If you want to take the borehole data and plots 2.5-D ‘sticks’ using say
ArcScene, you have to have one column that uses the same units all the way
through. If there is a value field and a uom field, the client has to
process the data from the service response to check that all units are
consistent before doing anything 

 

So I’d vote for boreholeLength_m

elevation_m, with the convention that the elevation reported is the
elevation from which depth is measured (GL, KB, DF
)

postionalAccuracy in the other portrayal models is free text. The logic is
that it’s not something someone will want to query or filter on, and it
could be reported in lots of different ways and still be useful for
evaluating the data in detail.

 

Just for entertainment value, I’ve attached the excel workbook for the
content model we’re using for the geothermal data system. The primary use
case for the ‘well header’ service is as an index to data linked to the
well, with links in a text blob called ‘relatedResource’. We included some
engineering stuff (casing, hole diameter) that doesn’t get populated very
often and I’d probably leave out in future versions (with a separate service
for borehole engineering data). There is a formation at TD, and true
vertical depth. Based on comments we’ve been getting, adding a bottom hole
X,Y location  is looking like a good compromise to deal with deviated holes.
Also have some silly extra location fields using the publich land survey
system that is always used by drillers, and an optional UTM coordinate
field.  We have to consider what the practice is to deal with wells that
have multiple wellbores
.

 

steve

 

From: geosciml-bounces+steve.richard=azgs.az.gov at lists.opengeospatial.org
[mailto:geosciml-bounces+steve.richard=azgs.az.gov at lists.opengeospatial.org]
On Behalf Of Bruce.Simons at csiro.au
Sent: Tuesday, November 06, 2012 5:54 PM
To: geosciml at lists.opengeospatial.org
Subject: Re: [GeoSciML] Borehole-Portrayal [SEC=UNCLASSIFIED]

 

I’d avoid content control on any field.

The simple feature view is so data providers have an easy entry to deliver
whatever happens to be in their database (“25.4”, “25.4m”, “25.4 metres”,
...). The URI to the fully described data (WFS) is the important field we
should be aiming to get populated (i.e. to set-up fully described data
services that can be filtered).

 

My ¼ of 8.

 

Cheers

Bruce

 

Environmental Information Systems
CSIRO Land and Water

PO Box 56 Highett,
Graham Road, Highett, Vic 3190


Ph +61-3-92526514 |  Mob +61-429177155

 

 

 

From: geosciml-bounces+bruce.simons=csiro.au at lists.opengeospatial.org
[mailto:geosciml-bounces+bruce.simons=csiro.au at lists.opengeospatial.org] On
Behalf Of Oliver.Raymond at ga.gov.au
Sent: Wednesday, 7 November 2012 11:45 AM
To: geosciml at lists.opengeospatial.org
Subject: Re: [GeoSciML] Borehole-Portrayal [SEC=UNCLASSIFIED]

 

You raise good points Bruce.  A WMS/SF-WFS portrayal model is primarily for
basic SLD portrayal schemes and human-readable information, not serious
querying.  That’s what the complex WFS is for.

 

1.  I note that we have positionalAccuracy (characterString) without uom in
our other portrayal view classes.  Is it envisaged that this field was ever
meant to be anything more than informative?  There is no control over what a
data provider puts in that field (eg, “250”, “250 metres”, “between 100 and
500 metres”).  So it would seem that we envisaged these positionalAccuracy
attributes to be informative, not seriously queried.

 

2.  Testing a CGI profile of “always use metres for borehole length and
positional accuracy” would be difficult (impossible?) in the absence of uom
fields - where would a service profile tester like Schematron look for this
information to test? GetCaps?  Where would a client look in a metadata
document for “borehole length uom” information?

 

3.  Rob, uom is part of the gml:Measure or swe:Quantity elements in the real
WFS world, but our basic portrayal models are trying to use just basic
strings, numbers, and uri’s for attribute types.  So any multi-part elements
like Measure or Quantity need to either be broken down into their component
bits of “value” (eg, 25.4) + “uom” (eg, metres), or be concatenated into a
text string (eg, “25.4 metres”).

 

4.  The question we need to answer for  Borehole portrayal is on which
fields in the model would we want to use a SLD filter, and thus require some
content control (ie, similar to representativeLithology and
representativeAge for GeologicUnits).  Potential fields might be:
                - purpose
                - drillStartDate
                - drillEndDate
                - boreholeLength

 

More comments please.

 

Cheers,

Ollie

 

__________________________________________________________________

Ollie Raymond
Senior Geologist  - Information Management  |  Continental Geology Section
Minerals and Natural Hazards Division  |  GEOSCIENCE AUSTRALIA

Oceania Councillor & Interoperability Working Group
IUGS Commission for the Management and Application of Geoscience Information
__________________________________________________________

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 Bruce.Simons at csiro.au
Sent: Wednesday, 7 November 2012 09:55
To: geosciml at lists.opengeospatial.org
Subject: Re: [GeoSciML] Borehole-Portrayal [SEC=UNCLASSIFIED]

 

The need for the UOM properties depends on what use case the Simple Feature
view of a borehole meets. This is not clear from Ollie’s email. 

I interpret the need for it as a simple response to a WMS query. I don’t
think the model would be expected to meet the WFS filters we typically
envisage for complex WFS (e.g. “Show all Boreholes where boreholeLength > X
metres”).

 

As such, having the UOM properties is informative for use in say a GIS, but
not designed for filtering.

 

Whether we use Eric’s solution or leave them in the model, what and how the
properties are intended to be used will need to be documented:

1.      Eric’s solution is to document the UOMs somewhere and indicate these
must be followed to conform with the CGI profile; or

2.      Document that UOM properties are designed for informative purposes
and the simple WFS is unlikely to support complex across service queries.

 

Having two models, a simplified and complete model, is always going to cause
tension between the simple model being ‘over-extended’ and the complex model
being ‘over-simplified’. Documenting the intention of each model may help to
avoid this.

 

Cheers

Bruce

 

Environmental Information Systems
CSIRO Land and Water

PO Box 56 Highett,
Graham Road, Highett, Vic 3190


Ph +61-3-92526514 |  Mob +61-429177155

 

 

 

From: geosciml-bounces+bruce.simons=csiro.au at lists.opengeospatial.org
[mailto:geosciml-bounces+bruce.simons=csiro.au at lists.opengeospatial.org] On
Behalf Of Rob.Atkinson at csiro.au
Sent: Wednesday, 7 November 2012 9:24 AM
To: geosciml at lists.opengeospatial.org
Subject: [ExternalEmail] Re: [GeoSciML] Borehole-Portrayal
[SEC=UNCLASSIFIED]

 

IMHO uom is already logically part of the data model (part of Measure) - and
the use of a separate attribute in the XML, or assumption of a constant
value, is an encoding concern – noting that encodings may be lossy with
respect to the model, so it’s ok to lose per-value UoM option.

 

So, should probably lose it from the model anyway J.  In the water space
we’ve been working through issues around data products needing to restrict
content of such encoding artefacts. Looks like we’ll need feature type
catalogs with quite explicit information around how model elements are
mapped to particular encodings J

 

Rob Atkinson

 

From: geosciml-bounces+rob.atkinson=csiro.au at lists.opengeospatial.org
[mailto:geosciml-bounces+rob.atkinson=csiro.au at lists.opengeospatial.org] On
Behalf Of Oliver.Raymond at ga.gov.au
Sent: Wednesday, 7 November 2012 8:33 AM
To: geosciml at lists.opengeospatial.org
Subject: Re: [GeoSciML] Borehole-Portrayal [SEC=UNCLASSIFIED]

 

Hi Eric,

 

Personally, I tend to agree with you.  I did this to reflect the gdb model
we came up with in Redlands, but I am ambivalent about their inclusion.  I’d
be happy to drop the UOM fields if others agree.  It forces a provider to
provide only one type of unit, but that is probably not a bad thing.

 

Cheers,

Ollie

 

 

  _____  

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 Boisvert, Eric
Sent: Tuesday, 6 November 2012 23:28
To: A mailing list for GeoSciML
Subject: Re: [GeoSciML] Borehole-Portrayal [SEC=UNCLASSIFIED]

 

having uom as a field is a real pain for users.  Every filter or SLD must
take this into account because it implies there can be mixed uom.

 

this is annoying: 

 

(boreholeLength > 10 AND boreholeLength_uom = 'm')

OR

(boreholeLength > 32.42 AND boreholeLength_uom = 'ft.')

 

it gets even worse when you need to combine with other uom because it
becomes a n x m problem.

 

I know, provider will stick to a single unit. But if it does, why this field
? just document what uom is used somewhere else (like how you documented
inclinationType) and keep them consistent (positionalAccuracy must be in
meter if depth and elevation are in meter)

 

my two cents...

 

 

 

 

 

  _____  

De :
geosciml-bounces+eric.boisvert=rncan-nrcan.gc.ca at lists.opengeospatial.org
[mailto:geosciml-bounces+eric.boisvert=rncan-nrcan.gc.ca at lists.opengeospatia
l.org] De la part de Oliver.Raymond at ga.gov.au
Envoyé : 5 novembre 2012 21:51
À : geosciml at lists.opengeospatial.org
Objet : [GeoSciML] Borehole-Portrayal [SEC=UNCLASSIFIED]

Hi all,

 

Geoscience Australia would like to try and formalize a Borehole simple
feature WFS and WMS standard, similar to GeologicUnitView, ContactView, and
ShearDisplacementStructureView in GeoSciML-Portrayal v2.

 

I have attached a proposed structure, based on the existing  xxxView classes
and work done in the AuScope project and at ESRI earlier this year.

 

Comments please.

 

Cheers,

Ollie

 

__________________________________________________________________

Ollie Raymond
Senior Geologist  - Information Management  |  Continental Geology Section
Minerals and Natural Hazards Division  |  GEOSCIENCE AUSTRALIA

Oceania Councillor & Interoperability Working Group
IUGS Commission for the Management and Application of Geoscience Information
__________________________________________________________

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

 

 

 

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

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

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/20121106/6ddeec73/attachment.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: WellHeaderContentModel1.7.zip
Type: application/x-zip-compressed
Size: 347317 bytes
Desc: not available
URL: <http://lists.opengeospatial.org/pipermail/geosciml/attachments/20121106/6ddeec73/attachment.bin>


More information about the GeoSciML mailing list