[Auscope-geosciml] RE : WFS filter woes

Boisvert, Eric Eric.Boisvert at RNCan-NRCan.gc.ca
Tue Mar 2 17:57:39 EST 2010


Already sent an email to him 2 weeks ago, I think he is away or something.

________________________________

De: auscope-geosciml-bounces at lists.arcs.org.au de la part de Simon Cox
Date: mar. 2010-03-02 16:31
À: auscope-geosciml at lists.arcs.org.au
Objet : Re: [Auscope-geosciml] WFS filter woes



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, Eric
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 example:

 

<?xml version="1.0" encoding="UTF-8"?> 
<Feature id="1"> 
        <topProperty>100</topProperty> 
        <subFeatureProperty> 
                <SubFeature id="1000"> 
                        <propA>10</propA> 
                        <propB>20</propB> 
                        <propB>30</propB> 
                </SubFeature> 
        </subFeatureProperty> 
        <subFeatureProperty> 
                <SubFeature> 
                        <propA>11</propA> 
                        <propB>0</propB> 
                </SubFeature> 
        </subFeatureProperty> 
        <subFeatureProperty> 
                <SubFeature> 
                        <propA>16</propA> 
                        <propB>40</propB> 
                </SubFeature> 
        </subFeatureProperty> 
</Feature> 

And this filter: 

<wfs:Query typeName="Feature"> 
<ogc:Filter> 
        <ogc:And> 
        <ogc:PropertyIsEqualTo> 
                <ogc:PropertyName>subFeatureProperty/SubFeature/propA</ogc:PropertyName> 
                <ogc:Literal>10</ogc:Literal> 
        </ogc:PropertyIsEqualTo> 

        <ogc:PropertyIsEqualTo> 
                <ogc:PropertyName>subFeatureProperty/SubFeature/propB</ogc:PropertyName> 
                <ogc:Literal>40</ogc:Literal> 
        </ogc:PropertyIsEqualTo> 

        </ogc:And> 
</ogc:Filter> 
</wfs:Query> 

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

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 





================================================================ 
Eric Boisvert 
Spécialiste TI-GI / IT-IM specialist 
Eric.Boisvert at rncan.gc.ca, 418-654-3705, facsimile/télécopieur 
418-654-2615 
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 (Quebec) 
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 <http://cgc.rncan.gc.ca/dir/index_f.php?id=4186>  / http://cgc.rncan.gc.ca/dir/index_e.php?id=4186 <http://cgc.rncan.gc.ca/dir/index_e.php?id=4186>  





-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/ms-tnef
Size: 19792 bytes
Desc: not available
URL: <http://lists.opengeospatial.org/pipermail/geosciml/attachments/20100302/ce0b5dd3/attachment.bin>


More information about the GeoSciML mailing list