Hey Andrea,
Thanks for looking this over. Comments inline.
On Sun, Oct 2, 2011 at 2:07 AM, Andrea Aime <[email protected]>wrote:
> 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.
>
Does this include the patch?
>
> >
> > 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
>
Not sure I follow 100%. How would we know at the time the filter is executed
that a property is going to be nil? Are you saying doing the filtering in
the encoder?
>
> > * 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.
>
Ha, good analogy :) I agree but part of the reason going with freemarker
made sense because (a) we had all machinery to turn features into freemarker
context and (b) it did not involve another dependency. So it was very quick
and easy to implement it that way. But that said I totally agree, not the
tool for the job so I am fine with giving up on that idea in favor of filter
functions via full blown scripting language. However, I don't think going
the JSR 223 is trivial at this point for a few reasons.
First it involves getting all the people doing geoserver scripting in the
various languages to agree on the structure. Should there be a scripts
directory? Should it be broken out by language? etc... Not hard questions by
any means but will require some more thought. Also there is the issue of
geoscript. Currently the way the python extension does filters is that you
don't get a geotools feature, you get a geoscript one (which is backed by a
geotools feature), but regardless. It could possibly
mean inconsistencies among the language runtimes that don't have geoscript,
maybe that is ok though.
Anyways, I think i will drop the idea for now and once I get the wfs 2.0
work all committed start pursuing a JSR-223 scripting hook extension.
>
> > * 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
>
> -------------------------------------------------------
>
--
Justin Deoliveira
OpenGeo - http://opengeo.org
Enterprise support for open source geospatial.
------------------------------------------------------------------------------
All the data continuously generated in your IT infrastructure contains a
definitive record of customers, application performance, security
threats, fraudulent activity and more. Splunk takes this data and makes
sense of it. Business sense. IT sense. Common sense.
http://p.sf.net/sfu/splunk-d2dcopy1
_______________________________________________
Geotools-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/geotools-devel
