On Fri, May 20, 2011 at 2:21 AM, Andrea Aime
<andrea.a...@geo-solutions.it>wrote:
> On Thu, May 19, 2011 at 11:00 PM, Justin Deoliveira
> <jdeol...@opengeo.org>wrote:
>
>> Hi all,
>>
>> I have whipped up a proposal for the functionName changes that have been
>> discussed on the list over the past few weeks.
>>
>>
>> http://docs.codehaus.org/display/GEOTOOLS/Detailed+Argument+and+Return+Info+for+FunctionName
>>
>> Feedback welcome.
>>
>
> I only had a quick run at it, but it looks good. Questions:
> - I see only a few functions have been updated to have a full function
> name: what is going to happen with the
> others? I guess there is some sort of defaults triggering? How are the WFS
> 2.0 caps going to look like when the
> defaults trigger in? Would be nice to include an explanation of the
> defaults in the proposal
>
I tried to do so in the Existing Functions section. I guess it was not very
clear. I will try to update with a better explanation. As for the wfs 2.0
caps doc a function (without specifying any of the name or type info
directly) will look like this:
<fes:Function name="StandardDeviation">
<fes:Returns>xs:string</fes:Returns>
<fes:Arguments>
<fes:Argument name="arg0">
<fes:Type>xs:string</fes:Type>
</fes:Argument>
<fes:Argument name="arg1">
<fes:Type>xs:string</fes:Type>
</fes:Argument>
</fes:Arguments>
</fes:Function>
The argument naming convention was part of jody's last proposal on adding
arguments names to functionName. In some cases I tried to be a bit smarter
in geoserver and as a workaround handle some "well known" argument names
such as "geometry". For example:
<fes:Function name="within">
<fes:Returns>xs:string</fes:Returns>
<fes:Arguments>
<fes:Argument name="geometry">
<fes:Type>gml:AbstractGeometryType</fes:Type>
</fes:Argument>
<fes:Argument name="geometry">
<fes:Type>gml:AbstractGeometryType</fes:Type>
</fes:Argument>
</fes:Arguments>
</fes:Function>
Obviously not perfect but some fallback is required since we don't know
about all the filter functions out there. We could try to do a mass update
of all the functions that we currently ship in main... I count about 157 of
them. A tedious task nonetheless. Maybe people will be up for a
collaborative effort of sorts.
- I have the impression you're adding the same methods to both FilterFactory
> interfaces. Afaik one extends
> from the other so adding it to the base FilterFactory interface should be
> enough?
>
Ahh right, unintended. I was unsure of which to modify but from Jody it
seems I should just be modifying FilterFactory.
>
> 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.
------------------------------------------------------------------------------
What Every C/C++ and Fortran developer Should Know!
Read this article and learn how Intel has extended the reach of its
next-generation tools to help Windows* and Linux* C/C++ and Fortran
developers boost performance applications - including clusters.
http://p.sf.net/sfu/intel-dev2devmay
_______________________________________________
Geotools-devel mailing list
Geotools-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel
