On Fri, May 20, 2011 at 8:47 AM, Andrea Aime
<andrea.a...@geo-solutions.it>wrote:
> 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
>
Cool. Thanks Andrea.
>
>
>>
>> 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
>
> Proposal updated with an example.
> 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.
------------------------------------------------------------------------------
vRanger cuts backup time in half-while increasing security.
With the market-leading solution for virtual backup and recovery,
you get blazing-fast, flexible, and affordable data protection.
Download your free trial now.
http://p.sf.net/sfu/quest-d2dcopy1
_______________________________________________
Geotools-devel mailing list
Geotools-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel
