On Thu, Aug 4, 2011 at 1:59 PM, Andrea Aime <[email protected]>wrote:

> On Thu, Aug 4, 2011 at 7:27 PM, Justin Deoliveira <[email protected]>
> wrote:
> > Hi all,
> > I have recently noticed some warnings that commit from
> > DefaultFunctionFactory:
> > Aug 4, 2011 11:19:46 AM
> org.geotools.filter.function.DefaultFunctionFactory
> > loadFunctions
> > WARNING: Function in10 clash between FilterFunction_in9 and
> > FilterFunction_in10
> > Aug 4, 2011 11:19:46 AM
> org.geotools.filter.function.DefaultFunctionFactory
> > getFunctionName
> > WARNING: class
> > org.geotools.filter.function.FilterFunction_bufferWithSegments has name
> > conflict betwee 'bufferWithSegments' and 'buffer'
> > Aug 4, 2011 11:19:46 AM
> org.geotools.filter.function.DefaultFunctionFactory
> > loadFunctions
> > WARNING: Function area clash between FilterFunction_area and AreaFunction
> > Aug 4, 2011 11:19:46 AM
> org.geotools.filter.function.DefaultFunctionFactory
> > loadFunctions
> > WARNING: Function in10 clash between FilterFunction_in10 and
> > FilterFunction_in8
> > that seem to point to name clashes. Upon inspection it seems there are
> some
> > typos.
> > 1. in8 and in9 declare the name "in10"
> > 2. bufferWithSegments declares the name "buffer"
> > 3. there are two area functions... one "Area" and one "area"
> > I believe (1) and (2) are just copy and paste errors.
>
> Yep my fault. I was making a round of "function name" implementations
> and I must get drunk doing it.
>

Ha, well that kind of tedious works requires a bottle of whiskey for sure
:)

>
> > However three though
> > is legitimate. The conflict occurs because we actually convert the names
> to
> > lowercase when storing them in the lookup map. Reason being to be a bit
> lax
> > when users specify functions and don't get the case exactly write (which
> > isn't consistent across functions... some all lower case, some camel
> case,
> > etc...)
> > So... to fix (3) what about naming "Area" to "area2" or something?
> > Thoughts?
>
> It seems to be AreaFunction is completely redundant, don't know why James
> implemented it, maybe JTS still did not have an area function back at the
> times?
> By the looks of it, it implements the most common area calculation
> algorithm,
> I would be surprised if the two methods would not return the same value.
>
> Cool, so unless there are any objections i will kill AreaFunction since I
imagine JTS area is probably robust enough for us.

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.
------------------------------------------------------------------------------
BlackBerry&reg; DevCon Americas, Oct. 18-20, San Francisco, CA
The must-attend event for mobile developers. Connect with experts. 
Get tools for creating Super Apps. See the latest technologies.
Sessions, hands-on labs, demos & much more. Register early & save!
http://p.sf.net/sfu/rim-blackberry-1
_______________________________________________
Geotools-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/geotools-devel

Reply via email to