[GeoSciML] swe:QuantityRange - RE: Changes needed to get qualified lithology query working [SEC=UNCLASSIFIED]

Steve Richard steve.richard at azgs.az.gov
Mon Jun 17 14:35:55 EDT 2013


Painful, but true.  

 

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: 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 Oliver.Raymond at ga.gov.au
Sent: Sunday, June 16, 2013 8:31 PM
To: geosciml at lists.opengeospatial.org
Subject: [GeoSciML] swe:QuantityRange - RE: Changes needed to get qualified
lithology query working [SEC=UNCLASSIFIED]

 

Thanks Bruce.  I was hoping to get another opinion on this one, as I thought
my comment might be contentious.

 

By extension of your comment "It is the main reason we have proportion as a
numerical value" to the rest of the model, then there are a lot of places in
GeoSciML where we must review our current use of swe:QuantityRange. 

 

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 Bruce.Simons at csiro.au
Sent: Monday, 17 June 2013 10:28 AM
To: geosciml at lists.opengeospatial.org
Subject: Re: [GeoSciML] Changes needed to get qualified lithology query
working

 

Re "laugh test": personally, I don't think that a complex query like "find
me all units with greater than 25% sandstone" is laugh testable.  While it
might be a desirable query, it is a pretty complex query (3 elements in one
query).  I think that the simpler "Find me all units containing sandstone"
is a query that should be able to pass a laugh test.

 

The test  "find me all units with greater than 25% sandstone" is a test that
should be supported. It is the main reason we have proportion as a numerical
value.

 

Cheers

Bruce Simons
SDI Information Modeller

Environmental Information Systems
CSIRO Land and Water

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


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

EIS: http://www.csiro.au/science/Environmental-Information-Systems

CLW:  <http://www.clw.csiro.au/> www.clw.csiro.au 
ACLEP:  <http://www.clw.csiro.au/aclep> www.clw.csiro.au/aclep

ASRIS:  <http://www.asris.csiro.au/> www.asris.csiro.au 

 

 

 

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 Ollie Raymond
Sent: Saturday, 15 June 2013 10:37 PM
To: Public: A mailing list for GeoSciML
Subject: Re: [GeoSciML] Changes needed to get qualified lithology query
working

 

Hi Marcus,

 

See comments from me inline below...

 

Cheers,

Ollie

 

============================================================================
===

 

On 14 June 2013 23:14, Sen, Marcus A. <mase at bgs.ac.uk> wrote:

I'd like to check my recollection of our conclusions about what is needed to
get a useful lithology query working following the St Petersburg meeting.

In summary, for OneGeology we would like to be able to query a WFS server to
return something like "all the GeologicUnits which have at least 25%
sandstone lithology. This does not seem to be possible currently.

The first factor that seemed to prevent it was as a result of the restricted
subset of XPath which FES says implementations are obliged to support. This
problem turned out to be soluble in our example although the general problem
of more complex queries remains.

 

Ollie: My understanding is that we had solved this problem by using an
appropriate construction of the xpath in the filter text (ie, starting the
xpaths for queried tags at a higher level).


The second problem was the fact that we can't extract one of the numbers
from a swe:Quantity range to do a numerical comparison on using FES. If the
range was encoded with separate tags for upper and lower bounds we could do.
At the moment, as we are re-using SWE this possibility is not available.
Eric emailed Alexandre Robin to ask whether the SWE working group would
consider modifying SWE to allow an encoding of a range with separate tags.
Even if they would, I guess that this wouldn't become a published standard
for some time.

 

Ollie: My understanding is that we were going to wait for a reply from Alex
Robin to Eric's email before deciding our next move. 


I have a vague recollection that we may have mentioned the idea of making a
small modification to GeoSciML 3.x so that we could encode a range in
separate tags pre-emptively before SWE does if we thought it was going to
happen at some stage. This would allow us to pass John Laxton's "laugh test"
of being able to do the above query.

 

Ollie: As Eric mentions, separate tags is returning to the days of
CGI_Value.  Funny how things come full circle.  If we can't get a definite
and short term solution from SWE and WFS for swe:QuantityRange, them I would
definitely support a return to using separate attributes for upper and lower
values in GSML v4.  This is not an optimal solution, given that we only
started using swe:Quantity in version 3, but unless swe:Quantity is
queryable I feel we must abandon it.

 

To be able to query Porportion values in GSML v3.x, we would need to add 2
optional swe:Quantity attributes (upperPorportion and lowerProportion) to
the  GeologicUnit:CompositionPart class.  This could be done, but I'd like
to fully explore the results of Eric's email to Alex Robin first. 

 

Re "laugh test": personally, I don't think that a complex query like "find
me all units with greater than 25% sandstone" is laugh testable.  While it
might be a desirable query, it is a pretty complex query (3 elements in one
query).  I think that the simpler "Find me all units containing sandstone"
is a query that should be able to pass a laugh test.

 

(In the longer term we have more general thinking to do about how queryable
we expect such services to be, whether we need a separate query profile from
the data model to support the queries we want to be able to do etc.)

 

Ollie: I agree we need to identify those parts of the model that have a
definite need to be queryable and make sure that they are.  It is
unfortunate that we have to make these decisions based on current
technological limitations, but it seems we must.

 

Could Eric, in particular, confirm whether my summary is correct and could
Olly comment on whether modifying GeoSciML 3.x is an idea with any traction
or not?

 

Ollie: see comment above re potential GSML 3.x changes for
CompositionPart/proportion.


Any other comments, feel free...

Marcus



This message (and any attachments) is for the recipient only. NERC is
subject to the Freedom of Information Act 2000 and the contents of this
email and any reply you make may be disclosed by NERC unless it is exempt
from release under the Act. Any material supplied to NERC may be stored in
an electronic records management system.

 

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/20130617/2a911e47/attachment-0001.htm>


More information about the GeoSciML mailing list