On Fri, Sep 30, 2011 at 7:34 AM, Justin Deoliveira <[email protected]> wrote: > > 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
Read it again, looks good to me. > > 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? Hummm.. I have the impression that this might be solved with a single null checking operation plus a check on the flag that drives the xml encoding. If the encoder is always skipping the elements that have null value: - PropertyIsNull would behave like today, true if the value is null, false otherwise - PropertyIsNil would always return false, it's either not null, and if it is we are not returning the element anyways If the encoder is always encoding the element with the nil flag, it's the opposite. So, I have the impression that a filter transformer knowing how a null value element is going to be encoded can be used to turn the filter in either what we have today, or Filter.Exclude > * 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 Will try to comment on the other thread > 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. Uh... no offense intended but seems a bit like trying to kill birds throwing a mattress... works but does not feel right ;-) May I offer an alternative? If we are looking for a simple way to write a filter function that allows for expressions, string manipulation and even seamless integration with java without having to throw multimegabytes extra dependencies, why don't we look at BeanShell? Adding 170KB (core + classgen) we can have a fitting solution for many light scripting needs. http://www.beanshell.org/download.html If we go through JSR 223 support we can allow people to write the same in jython, groovy, scala and whatnot if that's their preference and they don't care about adding 5-10MB of runtime libraries in the mix. > * 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 The patch in the first is doubly gzip-ped, odd. Anyways, the usual stuff, ton of xsd, EMF (gah, kill me now...) and bindings :-p Cheers Andrea -- ------------------------------------------------------- Ing. Andrea Aime GeoSolutions S.A.S. Tech lead Via Poggio alle Viti 1187 55054 Massarosa (LU) Italy phone: +39 0584 962313 fax: +39 0584 962313 http://www.geo-solutions.it http://geo-solutions.blogspot.com/ http://www.youtube.com/user/GeoSolutionsIT http://www.linkedin.com/in/andreaaime http://twitter.com/geowolf ------------------------------------------------------- ------------------------------------------------------------------------------ All of the data generated in your IT infrastructure is seriously valuable. Why? It contains a definitive record of application performance, security threats, fraudulent activity, and more. Splunk takes this data and makes sense of it. IT sense. And common sense. http://p.sf.net/sfu/splunk-d2dcopy2 _______________________________________________ Geotools-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/geotools-devel
