On Thu, Dec 23, 2010 at 1:49 PM, Gabriel Roldán <grol...@opengeo.org> wrote: > Hi Simone, > > thanks for the detailed description of the intended work. It sounds very > interesting to me and the approach just right. > > In my opinion, if there's something preventing innovation on trunk then > our process is weak, even if trunk is approaching a release. May be we > shouldn't release from trunk but move it to a "stable" branch before it > reaches the release status?
The thing is, as it often happen with funded work, that we'd have to include this improvement in the next stable version. That's why we though hard to make it as painless as possible. Basically all we need to do is to add a method to the FeatureTypeStyle interface in GeoTools, add parsing in the parsers for that new element (which will be a function) and call it from the renderer before starting to roll over data. All in all it should be something like changing 100 lines of code. All the transformations and the process/function bridge will require more but that can be done at ease later, as that does not need rolling out new api. > Hopefully most of us are already used to have our own git clones of > trunk and to keep them in sync, which makes it way easier to have non > disruptive experimental branches. Meh, wouldn't count much on that. I normally use only git as a SVN client (which works wonders), and hear other people that are still a bit in distress when having to work against a pure git server. > So I'd say go for it. If you see you > can make it for the release then merge, otherwise just keep your branch > in sync for after the release and then merge. It's totally up to you > guys and I'm sure you'll get it right. > > Question: is sld:Transformation in SE 1.1. or would it be a custom > extension? Would be a custom extension. We're pushing the limits here, just like we did with generic pluggable geometry transformations. Maybe SLD 3.0 will pick up some ideas from our book (I head that SLD 2.0 is moving towards something similar to geometry transformations and adding support for labeling params similar to the ones we have in our extensions, so I guess we did something right there). Cheers Andrea ----------------------------------------------------- Ing. Andrea Aime Senior Software Engineer GeoSolutions S.A.S. Via Poggio alle Viti 1187 55054 Massarosa (LU) Italy phone: +39 0584962313 fax: +39 0584962313 http://www.geo-solutions.it http://geo-solutions.blogspot.com/ http://www.linkedin.com/in/andreaaime http://twitter.com/geowolf ----------------------------------------------------- ------------------------------------------------------------------------------ Learn how Oracle Real Application Clusters (RAC) One Node allows customers to consolidate database storage, standardize their database environment, and, should the need arise, upgrade to a full multi-node Oracle RAC database without downtime or disruption http://p.sf.net/sfu/oracle-sfdevnl _______________________________________________ Geotools-devel mailing list Geotools-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geotools-devel
