[Auscope-geosciml] RE : WFS filter woes

Boisvert, Eric Eric.Boisvert at RNCan-NRCan.gc.ca
Wed Mar 3 07:23:48 EST 2010


ok.  I see how you do it - pretty clever.  Actually, I will have to check our own mediator to see if it does it correctly when confronted with denormalised services.
 
Merci
 

________________________________

De : auscope-geosciml-bounces at lists.arcs.org.au [mailto:auscope-geosciml-bounces at lists.arcs.org.au] De la part de Tellez-Arenas Agnes
Envoyé : 3 mars 2010 05:58
À : auscope-geosciml at lists.arcs.org.au
Objet : Re: [Auscope-geosciml] RE : WFS filter woes


 
>Is your translator  (ogc:Filter => ogc:Filter) or (ogc:Filter=>SQL) ?  You probably told me the other day but I have no memory.
(ogc:Filter => ogc:Filter) 
Because we provide a connector that is then installed in front of a WMS/WFS (MapServer, ESRI ArcGis Server 9.3.x, or geoserver) 
 
>Is this rule hardcoded (specific for this use case) or can be configured for other similar use cases ?
Hopefully... not hardcoded. We start from a configuration file which gives the association GML_attribute / GSML_path, with a notion of "group" to simulate the UML boxes  (compositionPart...). 
 
Then the connector will use the groups to "link together" the atomic elements of a filter (the first step is to transform any AND/OR/NOT tree to obtain a simple  tree which Root is OR, and branchs are AND list of atomic filter (EqualsTo, Not EqualsTo, ...).
 
We are working on the translation of the filter. I am pretty sure that my algorithm is right but since it is not yet implemented... (the developers should provide something very soon). We try to avoid any specific configuration for the filters. The mecanism will (?) be automatic for any filter (hope, hope). I plan to write something in the twiki to explain the whole process (what are we doing, how and why, and what is the use in the geoportal).
 
<GeoSciML_Mapping>
  <entry>
  <attribute>gu_name</attribute> 
  <gsml_uri>gsml:MappedFeature/gsml:specification/gsml:GeologicUnit/gml:name</gsml_uri> 
  </entry>
 <group>
  <gsml_path>gsml:MappedFeature/gsml:specification/gsml:GeologicUnit/gsml:composition/gsml:CompositionPart</gsml_path> 
 <entry>
  <attribute>cp_role_1</attribute> 
  <gsml_uri>gsml:role</gsml_uri> 
  </entry>
 <entry>
  <attribute>cp_litho_1</attribute> 
  <gsml_uri>gsml:lithology at xlink:href</gsml_uri> 
  </entry>
 <entry>
  <attribute>cp_proportion_1</attribute> 
  <gsml_uri>gsml:proportion/gsml:CGI_TermValue/gsml:value</gsml_uri> 
  </entry>
  </group>
 <group>
  <gsml_path>gsml:MappedFeature/gsml:specification/gsml:GeologicUnit/gsml:composition/gsml:CompositionPart</gsml_path> 
 <entry>
  <attribute>cp_role_2</attribute> 
  <gsml_uri>gsml:role</gsml_uri> 
  </entry>
 <entry>
  <attribute>cp_litho_2</attribute> 
  <gsml_uri>gsml:lithology at xlink:href</gsml_uri> 
  </entry>
 <entry>
  <attribute>cp_proportion_2</attribute> 
  <gsml_uri>gsml:proportion/gsml:CGI_TermValue/gsml:value</gsml_uri> 
  </entry>
  </group>
  </GeoSciML_Mapping>


________________________________

De : auscope-geosciml-bounces at lists.arcs.org.au [mailto:auscope-geosciml-bounces at lists.arcs.org.au] De la part de Boisvert, Eric
Envoyé : mercredi 3 mars 2010 11:33
À : auscope-geosciml at lists.arcs.org.au
Objet : RE : [Auscope-geosciml] RE : WFS filter woes


Yeah, renormalisation is another headache. We had the very same problem with multiple codeSpace+name in the same tuple.
 
Is your translator  (ogc:Filter => ogc:Filter) or (ogc:Filter=>SQL) ?  You probably told me the other day but I have no memory.
 
Is this rule hardcoded (specific for this use case) or can be configured for other similar use cases ?
 
Eric

________________________________

De: auscope-geosciml-bounces at lists.arcs.org.au de la part de Tellez-Arenas Agnes
Date: mer. 2010-03-03 05:20
À: auscope-geosciml at lists.arcs.org.au
Objet : Re: [Auscope-geosciml] RE : WFS filter woes





Hi,

We have similar problem for 1G-E, we hope to solve it with our connector that translates the ogc filters.
We express the following filter to request all the GeologicUnit which main lithology is metamorphic_rock:
<ogc:And>
<ogc:PropertyIsEqualTo>
<ogc:PropertyName>gsml:MappedFeature/gsml:specification/gsml:GeologicUnit/gsml:composition/gsml:CompositionPart/gsml:lithology at xlink:href</ogc:PropertyName>
<ogc:Literal>urn:cgi:classifier:CGI:SimpleLithology:201001:metamorphic_rock</ogc:Literal>
</ogc:PropertyIsEqualTo>
<ogc:PropertyIsEqualTo>
<ogc:PropertyName>gsml:MappedFeature/gsml:specification/gsml:GeologicUnit/gsml:composition/gsml:CompositionPart/gsml:proportion/gsml:CGI_TermValue/gsml:value</ogc:PropertyName>
<ogc:Literal>urn:cgi:classifier:CGI:ProportionTerm:201001:predominant</ogc:Literal>
</ogc:PropertyIsEqualTo>
</ogc:And>

Our GML is (more or less) the following (if we have 3 compositionPart, each defined by one lithology and one proportion)
<litho_1>urn:metamorphic_rock</litho_1>
<proportion_1>urn:predominant</proportion_1>
<litho_2>urn:sand</litho_2>
<proportion_2>urn:subordinate</proportion_2>
<litho_3>urn:granit</litho_3>
<proportion_3>urn:subordinate</proportion_3>

This filter does not express exactly what we want. A translation of the filter should be:
<and>
 <or>
    litho_1='urn:metamorphic_rock'
    litho_2='urn:metamorphic_rock'
    litho_3='urn:metamorphic_rock'
 <or>
    proportion_1='urn:predominant'
    proportion_2='urn:predominant'
    proportion_3='urn:predominant'  

The only solution we have (using WFS 1) is to "decide" that the semantic of the first filter is what we want!
We are modifying our connector to be able to translate the first filter in a filter that requests the intial GML WFS, but translating in such a way that the final filter looks like:

<or>
 <and>
    litho_1='urn:metamorphic_rock'
    proportion_1='urn:predominant'
 <and>
    litho_2='urn:metamorphic_rock'
    proportion_2='urn:predominant'
 <and>
    litho_3='urn:metamorphic_rock'
    proportion_3='urn:predominant'  

I don't like this solution but I don't see any other in the short time we have in the projet to setup the WFS.

Agnès
-----Message d'origine-----
De : auscope-geosciml-bounces at lists.arcs.org.au [mailto:auscope-geosciml-bounces at lists.arcs.org.au] De la part de Boisvert, Eric
Envoyé : mercredi 3 mars 2010 00:01
À : steve.richard at azgs.az.gov; auscope-geosciml at lists.arcs.org.au; auscope-geosciml at lists.arcs.org.au
Objet : [Auscope-geosciml] RE : WFS filter woes

WFS 1.0.0 : no
WFS 2.0.0 : yes.

For GIN, we try to implement a solution using XPath predicates similar to this

________________________________

De: auscope-geosciml-bounces at lists.arcs.org.au de la part de Stephen M Richard
Date: mar. 2010-03-02 15:52
À: auscope-geosciml at lists.arcs.org.au
Objet : Re: [Auscope-geosciml] WFS filter woes


just a wild guess--
can the ogc:propertyName include an xpath filter ?

<ogc:Filter>
        <ogc:And>
        <ogc:PropertyIsEqualTo>
                <ogc:PropertyName>subFeatureProperty/SubFeature[propB = '40']/propA</ogc:PropertyName>
                <ogc:Literal>10</ogc:Literal>
        </ogc:PropertyIsEqualTo>
</ogc:Filter>

steve


On 3/2/2010 1:34 PM, Boisvert, Eric wrote:

        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> 




       
        _______________________________________________
        Auscope-geosciml mailing list
        Auscope-geosciml at lists.arcs.org.au
        http://lists.arcs.org.au/cgi-bin/mailman/listinfo/auscope-geosciml
         


--
Stephen M. Richard
Section Chief, Geoinformatics
Arizona Geological Survey
416 W. Congress St., #100
Tucson, Arizona, 85701 USA

Phone:
Office: (520) 209-4127
Reception: (520) 770-3500
FAX: (520) 770-3505

email: steve.richard at azgs.az.gov
_______________________________________________
Auscope-geosciml mailing list
Auscope-geosciml at lists.arcs.org.au
http://lists.arcs.org.au/cgi-bin/mailman/listinfo/auscope-geosciml
**********************************************************************************************
Pensez a l'environnement avant d'imprimer ce message
Think Environment before printing

Le contenu de ce mel et de ses pieces jointes est destine a l'usage exclusif du (des) destinataire(s) designe
(s) comme tel(s).
En cas de reception par erreur, le signaler e son expediteur et ne pas en divulguer le contenu.
L'absence de virus a ete verifiee e l'emission, il convient neanmoins de s'assurer de l'absence de
contamination a sa reception.

The contents of this email and any attachments are confidential. They are intended for the named recipient
(s) only.
If you have received this email in error please notify the system manager or the sender immediately and do
not disclose the contents to anyone or make copies.
eSafe scanned this email for viruses, vandals and malicious content.
**********************************************************************************************

_______________________________________________
Auscope-geosciml mailing list
Auscope-geosciml at lists.arcs.org.au
http://lists.arcs.org.au/cgi-bin/mailman/listinfo/auscope-geosciml


P Pensez à l'environnement avant d'imprimer ce message

       Think Environment before printing

Le contenu de ce mél et de ses pièces jointes est destiné à l'usage exclusif du (des) destinataire(s) désigné(s) comme tel(s). 

En cas de réception par erreur, le signaler à son expéditeur et ne pas en divulguer le contenu. 
L'absence de virus a été vérifiée à l'émission, il convient néanmoins de s'assurer de l'absence de contamination à sa réception.

 

The contents of this email and any attachments are confidential. They are intended for the named recipient(s) only. 

If you have received this email in error please notify the system manager or  the sender immediately and do not disclose the contents to 
anyone or make copies. 

eSafe scanned this email for viruses, vandals and malicious content.

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


More information about the GeoSciML mailing list