[GeoSciML] Borehole-Portrayal [SEC=UNCLASSIFIED]

Oliver.Raymond at ga.gov.au Oliver.Raymond at ga.gov.au
Tue Nov 6 19:44:51 EST 2012


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] 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 :).  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.
-------------------------------------------------------------------------------------------------------------------------

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opengeospatial.org/pipermail/geosciml/attachments/20121107/c0374a9a/attachment.htm>


More information about the GeoSciML mailing list