[GeoSciML] Changes needed to get qualified lithology query working

Boisvert, Eric Eric.Boisvert at RNCan-NRCan.gc.ca
Fri Jun 14 09:34:38 EDT 2013


> 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.

Yes.   Also my recollection

You can express the filter in xpath as long as you don't have more than one "non equality" operator (ie, >, >=, <= and <, != , LIKE, BETWEEN).  This of course, is if the WFS only implements required XPath (it could implement more and then the problem goes away for that particular WFS instance).
I think the spirit of the XPath requirement is to allow selection of the right property to test ( to navigate the graph to the right property).  

> 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.

Yes. Did not get any response from Alexandre yet.

Edit: Actually, his email keeps bouncing back (I just noticed it on my "unwanted email folder" where those notification end).  I will have to find his new email or find somebody else to annoy.

*There is* another option, which is to create a server side function. But apparently, implementer are reluctant to support this (I don't understand why)

> 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.

I don't remember this. But it make sense. Ironically, this is essentially what CGI_Value were.  CGI_Value were ogc:Filter friendly while SWE are not. But again, we are bending backward to please WFS/FES


-----Message d'origine-----
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] De la part de Sen, Marcus A.
Envoyé : 14 juin 2013 09:15
À : Public: A mailing list for GeoSciML
Objet : [GeoSciML] Changes needed to get qualified lithology query working

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.

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.

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.

(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.)

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?

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.


More information about the GeoSciML mailing list