On Fri, May 20, 2011 at 4:09 PM, Justin Deoliveira <jdeol...@opengeo.org>wrote:
>
>
> 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>
>
Cool, makes sense.
+1 on the proposal btw
>
> 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.
>
Yeah, maybe whip up an example of how an update should be done and we can
follow suit
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
-------------------------------------------------------
------------------------------------------------------------------------------
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
