Justin Deoliveira ha scritto: > Hi all, > > When handling an issue report yesterday: > > http://jira.codehaus.org/browse/GEOS-1829 > > For the fix I submitted the patch which allows BinarySpatialOperator > (like "Touches") to contain a "Function" as the second argument, in > place of a "Geometry" or an "Envelope". Example: > > <Touches> > <PropertyName>the_geom</PropertyName> > <Function name="buffer"> > <Literal> > <gml:Point>...</gml:Point> > </Literal> > <Literal>100</Literal> > </Function> > </Touches> > > Now as Andrea points out, this is actually not supported by the filter > spec. So the question is: do we want to be lenient in this case?
On one side, we've been lenient on other things already, so it would not be a first. On the other side, you're replacing a known quantity (geometry literal) with an unknown one, that is function result, which may be dependent on the feature being evaluated. Even if you don't pass attribute names to the Function, the Function still receives the Feature as an argument and it can use it in whatever way it wants. This _may_ break filter visitors that do assume a proper OGC structure. I say may because I did not check, so there may be some, or not... An investigation of this kind is in order before we apply this patch. If there is no know usage that breaks, I'm ok with relaxing the behaviour. Cheers Andrea ------------------------------------------------------------------------- Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace _______________________________________________ Geoserver-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/geoserver-devel
