From: Justin D. <jde...@op...> - 2011-09-30 05:34:11
|
Hi all, As many know over the past few months we have been working on a wfs 2.0 implementation for GeoServer. Naturally much of this work trickles down into GeoTools. Some of which has made it to trunk already. Now that the user acceptance testing phase with the client has more or less wrapped up I have time to start pushing the patches out of my github branch and into svn. Quite a few changes accumulated, as tends to happen when one is out on a branch for so long. I have tried to organize the patches as coherently as possible. Here goes. * Joins Most of the discussion here has happened as a proposal was actually submitted a while back. As a refresh here is the proposal: http://docs.codehaus.org/display/GEOTOOLS/Join+Support And here is the issue that has the attached patch: http://jira.codehaus.org/browse/GEOT-3657 * PropertyIsNil Filter (FES) 2.0 adds a new filtering construct named PropertyIsNil. To be honest I am still a bit fuzzy on what this is actually supposed to do. However I did get some clarification from wfs-dev list: assume you have a GML feature type which has a property p where the property > element is declared with minOccurs="0" and nillable=true. > PropertyIsNull results in true, if the WFS would return the feature without > any property element <tns:p>. > PropertyIsNil results in true, if the WFS would return the feature with a > property element <tns:p xsi:nil='true'>. This can be refined using the > nilReason parameter. And as it turns out i completely misinterpreted the spec... so my implementation of PropertyIsNil doesn't match that at all :) However I am not sure how to implement it property... our filter model doesn't have any notion of schema like this requires. Anyways, in the end all the client wanted to click a check box, and not really to do anything with it so i never went back and revisited. Here is the patch I came up with though: http://jira.codehaus.org/browse/GEOT-3870 I am tempted to simply just have PropertyIsNil be an alias for PropertyIsNull at this point... and when someone has a mandate to implement it properly they can do so. Thoughts? * ExtendedOperator Filter 2.0 also adds the notion of extended operators. Which are essentially a way to extend filter with new constructs (just like functions) but by actually extending the filter language. For example you could add a new type of filter with something like this: <Filter> <Function name="foobar"> ... </Function> </Filter> What extended operators allow you to do is the following: <Filter> <myns:foobar> ... <myns:/foobar> </Filter> So really they are just syntactic sugar. So I came up with a factory interface called ExtendedOperatorFactory that looks much like FilterFunctionFactory. I won't get into any more details now... this one probably warrants a proposal and possibly a total reimplementation. I wish i had time to get feedback on this one at the time but didn't. But anyways, here is the patch I came up with: http://jira.codehaus.org/browse/GEOT-3871 There is no default implementation, what i did was actually come up with an implementation in geoserver that allowed one to write extended operators in its templating language freemarker. As part of pushing the wfs 2.0 work into geoserver i would like to revisit this and actually make it so you can write regular functions in freemarker, and invoke them through either a filter function or an extended operator. * WFS 2.0/FES 2.0 Object model and bindings Not much to say here... I added new emf objects models for wfs 2.0 and fes 2.0. And implemented all the bindings for them in the xsd modules. Patch attached to these issues: http://jira.codehaus.org/browse/GEOT-3541 http://jira.codehaus.org/browse/GEOT-3542 For those who like browsing patches on github i pushed all these 5 patches onto a new "staging" branch in my github repo: https://github.com/jdeolive/geotools/tree/wfs2_staging Feedback much appreciated. -Justin -- Justin Deoliveira OpenGeo - http://opengeo.org Enterprise support for open source geospatial. |