[Auscope-geosciml] WFS filter woes

Simon Cox simon.cox at jrc.ec.europa.eu
Tue Mar 2 16:31:03 EST 2010

Can I suggest get on phone to Peter Vretanos in Toronto, and then summarize
for this list!



From: auscope-geosciml-bounces at lists.arcs.org.au
[mailto:auscope-geosciml-bounces at lists.arcs.org.au] On Behalf Of Boisvert,
Sent: 02 March 2010 21:34
To: auscope-geosciml at lists.arcs.org.au
Subject: [Auscope-geosciml] WFS filter woes


This question is for the WFS guys that might be on this list.  I tried to
find a answer or at least validation of what I think is right.

I am struggling with an issue about boolean operator in OGC filter. We try
to implement a use case that requires to select all WaterWell (Borehole)
that has an interval with a certain porosity value and a certain
conductivity value.  The problem is how the AND is scoped.  Let's see this


<?xml version="1.0" encoding="UTF-8"?> 
<Feature id="1"> 
                <SubFeature id="1000"> 

And this filter: 

<wfs:Query typeName="Feature"> 



Am I right to consider this condition as being equivalent to 

<xsl:copy-of select="Feature[subFeatureProperty/SubFeature/propA = '10' and
subFeatureProperty/SubFeature/propB = '40'] "/> ?

If so, the above example should match, because the scoping is the root
element, so there is a path from the root element that satisfy both

My point here is that is no real way to say that I want the AND to be scoped
in a given <SubFeature> (propA = 10 and probB = 40 in a given SubFeature).

But the issue is that once this request will be converted in SQL, the AND
will be scoped depending on where the propA and propB will be (in which
table) and how the JOIN are done.  For instance, if the propA and propB are
in some leaf table, it will scope to the last table prior in the join chain.

The SQL would be equivalent to (scoped to SubFeature) 

<xsl:copy-of select="Feature[subFeatureProperty/SubFeature/[propA = '10' and
propB = '40']] "/>  (and this return an empty set as expected)

While this matches the above example 
<xsl:copy-of select="Feature[subFeatureProperty/SubFeature/[propA = '10' and
propB = '20']] "/>  


I'm not sure if : 

A) there is a implied scoping rule in the way we encode Xpath in WFS that is
different than "root node".  I don't think the "last class/data type" should
be a scoping rule because, for example, all condition involving CGI_Value
will scope to the content of CGI_Value.

B) We should force the database implementation to follow the "root" scoping
rule, otherwise, the result will depend of database implementation.

WFS / Filter 2.0 does not solve the problem with the matchAction, because it
does not specific the scoping either. 


Eric Boisvert 
Spécialiste TI-GI / IT-IM specialist 
Eric.Boisvert at rncan.gc.ca, 418-654-3705, facsimile/télécopieur 
490, rue de la Couronne, Québec (Québec), G1K 9A9 
490, rue de la Couronne, Quebec, Quebec, G1K 9A9 

Laboratoire de cartographie numérique et de photogrammétrie (LCNP) 
Digital Cartography and Photogrammetry Laboratory (DCPL) 
Commission géologique du Canada (Québec) / Geological Survey of Canada
Ressources naturelles Canada / Natural Resources Canada 
Gouvernement du Canada / Government of Canada 
 <http://cgc.rncan.gc.ca/org/quebec> http://cgc.rncan.gc.ca/org/quebec 
http://cgc.rncan.gc.ca/dir/index_f.php?id=4186 /

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

More information about the GeoSciML mailing list