[GeoSciML] Changes needed to get qualified lithology query working

Ollie Raymond ollieraymond99 at gmail.com
Sat Jun 15 08:36:36 EDT 2013

Hi Marcus,

See comments from me inline below...



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

> 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/20130615/2bee1e87/attachment-0001.htm>

More information about the GeoSciML mailing list