[GeoSciML] Borehole-Portrayal [SEC=UNCLASSIFIED]

Oliver.Raymond at ga.gov.au Oliver.Raymond at ga.gov.au
Wed Nov 7 18:30:18 EST 2012


Thanks Steve, very informative.

Taking into account all the comments I have received, I have attached a v0.2 version of BoreholeView.

1.  I have amended the attribute descriptions a bit, including some mention of relations of wells and wellbores (see https://www.ppdm.org/wiki/index.php/What_is_a_Well)

2.  "boreholeLength_m" and "elevation_m".  (No "uom" attributes.)

3.  I have added a "parentBoreholeID" attribute to provide a link between parent wells and sidetracks.

4.  I have added, tentatively, a "status" attribute.  ("Status" is not currently in the GeoSciML Borehole model, but I would like it to be in the version 4, so I have added it here.  "Status" is used in borehole databases I have seen, and is in the PPDM model for wells.)

5.  I have added an "any:lax" element to the end of the attribute list, similar to what we did for the view classes in GeoSciML-Portrayal v2.0, to allow for additional user-defined elements where they want to deliver more than the standard BoreholeView attributes.

If I get majority agreement, I'll add it into the GeoSciML-Portrayal trunk UML for GSML-P version 3.

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:  Oliver.Raymond at ga.gov.au<mailto:Oliver.Raymond at ga.gov.au>    Web:  www.ga.gov.au<http://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: Wednesday, 7 November 2012 14:55
To: 'A mailing list for GeoSciML'
Subject: Re: [GeoSciML] Borehole-Portrayal [SEC=UNCLASSIFIED]

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> [mailto:geosciml-bounces+bruce.simons=csiro.au at lists.opengeospatial.org] On Behalf Of Oliver.Raymond at ga.gov.au<mailto:Oliver.Raymond at ga.gov.au>
Sent: Wednesday, 7 November 2012 11:45 AM
To: geosciml at lists.opengeospatial.org<mailto: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:  Oliver.Raymond at ga.gov.au<mailto:Oliver.Raymond at ga.gov.au>    Web:  www.ga.gov.au<http://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> [mailto:geosciml-bounces+oliver.raymond=ga.gov.au at lists.opengeospatial.org] On Behalf Of Bruce.Simons at csiro.au<mailto:Bruce.Simons at csiro.au>
Sent: Wednesday, 7 November 2012 09:55
To: geosciml at lists.opengeospatial.org<mailto: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> [mailto:geosciml-bounces+bruce.simons=csiro.au at lists.opengeospatial.org] On Behalf Of Rob.Atkinson at csiro.au<mailto:Rob.Atkinson at csiro.au>
Sent: Wednesday, 7 November 2012 9:24 AM
To: geosciml at lists.opengeospatial.org<mailto: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 :).  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 :)

Rob Atkinson

From: geosciml-bounces+rob.atkinson=csiro.au at lists.opengeospatial.org<mailto: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<mailto:Oliver.Raymond at ga.gov.au>
Sent: Wednesday, 7 November 2012 8:33 AM
To: geosciml at lists.opengeospatial.org<mailto: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> [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.opengeospatial.org> [mailto:geosciml-bounces+eric.boisvert=rncan-nrcan.gc.ca at lists.opengeospatial.org] De la part de Oliver.Raymond at ga.gov.au<mailto:Oliver.Raymond at ga.gov.au>
Envoyé : 5 novembre 2012 21:51
À : geosciml at lists.opengeospatial.org<mailto: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:  Oliver.Raymond at ga.gov.au<mailto:Oliver.Raymond at ga.gov.au>    Web:  www.ga.gov.au<http://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.
-------------------------------------------------------------------------------------------------------------------------

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/20121108/3e366372/attachment.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: BoreholeView-GeoSciMLPortrayal.xls
Type: application/vnd.ms-excel
Size: 22016 bytes
Desc: BoreholeView-GeoSciMLPortrayal.xls
URL: <http://lists.opengeospatial.org/pipermail/geosciml/attachments/20121108/3e366372/attachment.xls>


More information about the GeoSciML mailing list