Re: [Geotools-devel] Backporting UOM work on 2.6.x

2010-06-15 Thread Andrea Aime
Jody Garnett ha scritto: > I think that kind of seals the deal andrea; you are the module > maintainer. As I recall the UOM patch mostly leverages api that was > introduced for 2.6 but did not yet function? Correct, there are no API changes, it's just a matter of applying a style visitor which is

Re: [Geotools-devel] Backporting UOM work on 2.6.x

2010-06-15 Thread Jody Garnett
I think that kind of seals the deal andrea; you are the module maintainer. As I recall the UOM patch mostly leverages api that was introduced for 2.6 but did not yet function? Is there any api changes at all introduced by the patch? If so we could talk about them and see if they are significant

Re: [Geotools-devel] A patch for gt-process and some discussion

2010-06-15 Thread Andrea Aime
Andrea Aime ha scritto: > Michael Bedward ha scritto: >> Hi Andrea et al, >> >> Thanks for looking at ways to improve the process module ! >> >> I'm happy with your comments about both VectorToRaster and RasterToVector. >> >> I would much prefer to have FeatureSource used rather than >> FeatureColl

Re: [Geotools-devel] Backporting UOM work on 2.6.x

2010-06-15 Thread Andrea Aime
Jody Garnett ha scritto: > In general I like to keep new features for trunk; however back > porting existing work if needed seems fine - and the UOM work has > been out for a bit now and released to the public already. > > The main module effected is of course rendering; so if you are happy > with

Re: [Geotools-devel] A patch for gt-process and some discussion

2010-06-15 Thread Andrea Aime
Michael Bedward ha scritto: > Hi Andrea et al, > > Thanks for looking at ways to improve the process module ! > > I'm happy with your comments about both VectorToRaster and RasterToVector. > > I would much prefer to have FeatureSource used rather than > FeatureCollection unless that presents big

Re: [Geotools-devel] ji-tools discussion

2010-06-15 Thread Michael Bedward
Hi Jody, Thanks for the nice words :-) There is a mailing list here... http://groups.google.com/group/jai-tools?pli=1 I should probably make it more obvious on the jai-tools project page. Michael On 16 June 2010 13:41, Jody Garnett wrote: > Hi Michael: > > I am looking over jai-tools, and Ji

[Geotools-devel] ji-tools discussion

2010-06-15 Thread Jody Garnett
Hi Michael: I am looking over jai-tools, and Jiffle :-) I did not see a project mailing list so I thought I would pester you on the geotools list. I eventually had to check out the source code to sort out working examples; thus far I have been very impressed - and also jealous the performance

Re: [Geotools-devel] HashMap Considered Harmful

2010-06-15 Thread christian . mueller
Ben is right here. The problem is spread over all geotools/geoserver tests. As I started with geotools/IBM SDK I fixed a lot of tests having this problem. At the moment, there are some tests which are not easy to fix for me. I am not sure if the library should pass back an ordered collectio

Re: [Geotools-devel] A patch for gt-process and some discussion

2010-06-15 Thread Michael Bedward
Hi Andrea et al, Thanks for looking at ways to improve the process module ! I'm happy with your comments about both VectorToRaster and RasterToVector. I would much prefer to have FeatureSource used rather than FeatureCollection unless that presents big problems for others. Michael

Re: [Geotools-devel] HashMap Considered Harmful

2010-06-15 Thread Ben Caradoc-Davies
On 16/06/10 03:49, Gabriel Roldan wrote: > So, being certain that most probably I introduced some of this problems > myself by having worked on the app-schema code years ago, I still > strongly argument against anyone that expects a given iteration order > out of a method returning a Map Gabriel,

Re: [Geotools-devel] PMC: Map Context Refractor Proposal

2010-06-15 Thread Michael Bedward
On 13 June 2010 01:36, Jody Garnett wrote: > > I have separated out a MapViewport holding the bounds+crs for the map. The > map does retain > an internal MapViewport for use in an interactive session. But I can > understand your need to keep > one on the side for background rendering; or to have

Re: [Geotools-devel] PMC: MapContext proposal final call

2010-06-15 Thread Michael Bedward
Hi Jody, Sorry to be absent for the last few days. I'm sure you were assuming +1 from me :) Thanks again for this great improvement. Michael On 15 June 2010 15:20, Jody Garnett wrote: > So I have a few votes in - and a few reviews (thanks!) > >        • Andrea Aime >        • +1 Ben Caradoc-Da

Re: [Geotools-devel] Backporting UOM work on 2.6.x

2010-06-15 Thread Jody Garnett
In general I like to keep new features for trunk; however back porting existing work if needed seems fine - and the UOM work has been out for a bit now and released to the public already. The main module effected is of course rendering; so if you are happy with the risk as the module maintainer

Re: [Geotools-devel] HashMap Considered Harmful

2010-06-15 Thread lim goh
I guess we fell back to the definition of defensive, I don't know a good replacement word for it, but what I wanted to say is: 1. Using Map as a return type is completely valid, good, should, defensive... 2. Consumer who expects specific implementation detail is wrong, bad, should not. 3. The inter

Re: [Geotools-devel] HashMap Considered Harmful

2010-06-15 Thread Gabriel Roldan
On 6/15/10 3:56 PM, lim goh wrote: > +1 to good discussion here. Good read for me. > > I think I agree with how developers should really know what they are > doing. I bet we all have experienced times where we wish people using > our functions use them properly. > > However, I think Ben still has a

Re: [Geotools-devel] HashMap Considered Harmful

2010-06-15 Thread lim goh
+1 to good discussion here. Good read for me. I think I agree with how developers should really know what they are doing. I bet we all have experienced times where we wish people using our functions use them properly. However, I think Ben still has a point in being DEFENSIVE. I agree with Ben tha

Re: [Geotools-devel] HashMap Considered Harmful

2010-06-15 Thread Justin Deoliveira
I have to add my +1 as well. We have run up against this before when we started supporting java 6 and the moral of the story was that it is up to the downstream developer to ensure that if they are iterating through a map in a case where order matters then the onus is on them to ensure they are

Re: [Geotools-devel] PMC: MapContext proposal final call

2010-06-15 Thread Justin Deoliveira
Sorry for the late review. But I am +0 as that is one of the apis I have not really used in geotools much. So I delegate to the experts on this one. On 10-06-14 11:20 PM, Jody Garnett wrote: > So I have a few votes in - and a few reviews (thanks!) > > • Andrea Aime > • +1 Ben Caradoc-

[Geotools-devel] PostGIS geography column support is in

2010-06-15 Thread Andrea Aime
Hi, just committed support for geography columns on trunk. The patch was not trivial in that I had to change some function call in a way that makes the datastore incompatible with PostGIS 1.1, so no backport just to be on the safe side (wondering if anyone still has PostGIS 1.1 deploys around?) Ch

Re: [Geotools-devel] HashMap Considered Harmful

2010-06-15 Thread Ian Turton
On Tue, Jun 15, 2010 at 10:35 AM, Mª®k wrote: > +1 for Andrea and Christian. > +1 from me too - When I learnt about maps and lists I was taught they do different things and to be clear about which I needed. Ian -- Ian Turton -

Re: [Geotools-devel] PMC: MapContext proposal final call

2010-06-15 Thread Andrea Aime
Jody Garnett ha scritto: > So I have a few votes in - and a few reviews (thanks!) > > • Andrea Aime +1 Cheers Andrea -- Andrea Aime OpenGeo - http://opengeo.org Expert service straight from the developers. -- T

[Geotools-devel] Backporting UOM work on 2.6.x

2010-06-15 Thread Andrea Aime
Hi, I'm having potential funding to backport and eventually make some fixes on the UOM work that Milton (and, to a less extent, yours trunk) worked on on trunk. The patch that I would backport is this one, and it's 65k: http://jira.codehaus.org/secure/attachment/49040/GEOT-2964.patch Afaik Milton

Re: [Geotools-devel] PMC: MapContext proposal final call

2010-06-15 Thread christian . mueller
+0, until now I did not use MapContext directly, but a cleanup sounds good Quoting Jody Garnett : > So I have a few votes in - and a few reviews (thanks!) > > • Andrea Aime > • +1 Ben Caradoc-Davies > • Christian Mueller > • Ian Turton > • Justin Deoliveira > •

Re: [Geotools-devel] PMC: MapContext proposal final call

2010-06-15 Thread Ian Turton
+1 (sorry to be late as it was progressing I assumed I'd voted earlier in the previous mass vote round). Ian -- ThinkGeek and WIRED's GeekDad team up for the Ultimate GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to t

[Geotools-devel] Hudson build is back to normal: geotools-trunk #2790

2010-06-15 Thread Hudson
See -- ThinkGeek and WIRED's GeekDad team up for the Ultimate GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the lucky parental unit. See the pri

Re: [Geotools-devel] HashMap Considered Harmful

2010-06-15 Thread Mª®k
+1 for Andrea and Christian. -- ThinkGeek and WIRED's GeekDad team up for the Ultimate GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the lucky parental unit. See the prize list and enter to win: http://p.sf.net/s

[Geotools-devel] Build failed in Hudson: geotools-trunk #2789

2010-06-15 Thread Hudson
See Changes: [jive] Remove complicated logic from addLayers method; generate default areaOfInterest when first called based on layer bounds, ask FeatureLayer to check that bounds crs and schema crs are in agreement - and if need

Re: [Geotools-devel] PMC: MapContext proposal final call

2010-06-15 Thread Jody Garnett
Commit went through... Had some interesting failures in GeoServer where the wrapper featureSource implementations had an inconsistent CRS between their getSchema() and their getBounds(). So not a smooth transition; but making me glad to do the work in stages. Jody On 15/06/2010, at 3:20 PM, J

[Geotools-devel] Build failed in Hudson: geotools-trunk #2788

2010-06-15 Thread Hudson
See Changes: [afabiani] - fixing GTDataStore catalog multiple typeNames issue -- [...truncated 6622 lines...] INFO: Unable to find crs, continuing with default WGS4 CRS Jun 15, 2010 10:15:0

Re: [Geotools-devel] HashMap Considered Harmful

2010-06-15 Thread christian . mueller
I think like Andrea, filling an ordered collection from an unordered one needs an explicit ordering criteria, otherwise it is nonsense. There is nothing bad about using a HashMap, a set has an exact definition as we all know from mathematics in school (I hope so :-)) Unfortunately, as we ha

Re: [Geotools-devel] HashMap Considered Harmful

2010-06-15 Thread Andrea Aime
Ben Caradoc-Davies ha scritto: > On 15/06/10 16:45, Andrea Aime wrote: >> I would not blame Alice for Bob lack of skill (or simple oversight). >> She exposed a Map and made no promises on ordering, Bob took it and >> promised what he could not deliver. > > How does finger pointing between Alice an

Re: [Geotools-devel] HashMap Considered Harmful

2010-06-15 Thread Ben Caradoc-Davies
On 15/06/10 16:45, Andrea Aime wrote: > I would not blame Alice for Bob lack of skill (or simple oversight). > She exposed a Map and made no promises on ordering, Bob took it and > promised what he could not deliver. How does finger pointing between Alice and Bob help Carol? A bit of defensive pr

Re: [Geotools-devel] HashMap Considered Harmful

2010-06-15 Thread Andrea Aime
Ben Caradoc-Davies ha scritto: > On 15/06/10 16:17, Andrea Aime wrote: >> I still see an incompetent developer in action there. >> You look at that interface, you get a Map, so you know: >> - the API designer decided the iteration order was not important >> - the iteration order cannot be trusted >

Re: [Geotools-devel] HashMap Considered Harmful

2010-06-15 Thread Ben Caradoc-Davies
On 15/06/10 16:17, Andrea Aime wrote: > I still see an incompetent developer in action there. > You look at that interface, you get a Map, so you know: > - the API designer decided the iteration order was not important > - the iteration order cannot be trusted Many other Map implementations have w

Re: [Geotools-devel] HashMap Considered Harmful

2010-06-15 Thread Andrea Aime
Ben Caradoc-Davies ha scritto: > On 15/06/10 15:50, Andrea Aime wrote: >> Developer depending on hashmap order -> chaos >> It's not the fault of poor hashmap that developers use it in a number >> of places where it's unnecessary if not even harmful. > > But the poor developers cannot know if they

Re: [Geotools-devel] HashMap Considered Harmful

2010-06-15 Thread Ben Caradoc-Davies
On 15/06/10 15:50, Andrea Aime wrote: > Developer depending on hashmap order -> chaos > It's not the fault of poor hashmap that developers use it in a number > of places where it's unnecessary if not even harmful. But the poor developers cannot know if they are getting a HashMap if they are a mo

Re: [Geotools-devel] HashMap Considered Harmful

2010-06-15 Thread Andrea Aime
Jody Garnett ha scritto: > Can we arrange for maven to yell at us when HashMap is used? > > Ben I have been known to use a couple of the other Map > implementations; such as ConcurrentHashMap (and we also have our own > WeakHashMap) - we may need to check if these implementations suffer > the same

Re: [Geotools-devel] HashMap Considered Harmful

2010-06-15 Thread Andrea Aime
Ben Caradoc-Davies ha scritto: > [This affects GeoServer too, but I'd rather avoid a cross-list post.] > > Synopsis: > - HashMap has platform-dependent iteration order. > - Use LinkedHashMap to make iteration order consistent across platforms. > - Same rule applies for HashSet: replace with Linked

Re: [Geotools-devel] [ExternalEmail] Re: How to handle Oracle SRID problem

2010-06-15 Thread Andrea Aime
Ben Caradoc-Davies ha scritto: > On 15/06/10 13:27, [email protected] wrote: >> With regards to EPSG: 23038. > > The canonical source for EPSG codes is here: > http://epsg-registry.org/ > > This also lists 23038. Right, it's also in the EPSG database, I must have mistyped the code when I sea