[GeoSciML] Changes needed to get qualified lithology query working

Bruce.Simons at csiro.au Bruce.Simons at csiro.au
Sun Jun 16 20:27:57 EDT 2013


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: www.clw.csiro.au<http://www.clw.csiro.au/>
ACLEP: www.clw.csiro.au/aclep<http://www.clw.csiro.au/aclep>
ASRIS: www.asris.csiro.au<http://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<mailto: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.

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


More information about the GeoSciML mailing list