Hello people Sorry for the fast coding! We just wanted to see something working to give us a better idea. But it's definitely not meant to be kept as it is, just to start the process for us (especially since we are no SLD-experts).
OK, so let's see if I gather everything here: - Ideally, we should move to 2.6 soon. I have two questions about that: is it as stable as 2.5.x right now? And is there much to change to make the move? I ask this because we want to make a first release of our projects using GeoTools in about two months time, so.. Either we do it now, or later on, around May-June. And a side-effect question is: does anyone want support for this in 2.5.x? - Nice thing about the XML bindings! We were actually looking for that, and quite puzzled with the whole SLDParser and SLDTransformer thing (why reading and writing was done by separate classes, why it didn't use the xsd definitions, etc, etc). But I understand it's not in use right now, and there is a lot missing, right? Or is that just for 2.5.x? Are things more developped in 2.6? - I really like the idea of working with actual Units. Sorry I didn't notice that before: it is certainly the right way to do it, be it 2.5.x or 2.6, SLDParser or SLD bindings. So, from my point of view, our next moves back here should be: 1. Determine if we can move right away to 2.6. If you have any hints on how tough that could be (and how we could make it easier), please tell me. Truth is, we sticked to 2.5.x since the beginning since it was labelled as the "stable release". 2. Determine if we can move to the XML bindings framework. That depends on how much work we need to do to start to get things going. I guess it also depends on the state of the bindings for Filter. In any case, when we decide which way to go, we will reimplement things using the GeoAPI interface. What do you guys think? Milton Jody Garnett wrote: > I agree Andrea; they started coding very quickly :-) Is there any chance > you guys can use geotools 2.6? I would much rather see you work on > respecting the UOM entry that is already there; and copy the SLDParser > so we can modify and read that value in correctly. > > I like to work on things we can keep :-) Rather then seeing you work on > a fork of geotools that will not last beyond your project. > > Jody > > On Sun, Feb 15, 2009 at 8:49 PM, Andrea Aime <[email protected] > <mailto:[email protected]>> wrote: > > Jody Garnett ha scritto: > > Dragging this back to the list; there is way too much content > here for a private discussion. > > > Indeed, especially since it left out all the people involved in > the rendering module (basically me and Jesse, nobody else committed > anything to that module in ages). > > The thread is way too long now for me to chime in, especially since > quite some coding already went in. > > The UOM functionality is interesting, thought the changes implemented > are specific for 2.5.x, the situation on trunk is different, the unit > of measure is already available at the symbolizer level, thought > nothing in the rendering chain actually uses it (the people that > worked on SE 1.1 started their own renderer, which they said is > going to be open source but so far haven't actually seen the sources > of it). > > The GeoApi Symbolizer interface has this: > > Unit<Length> getUnitOfMeasure(); > > that influences the interpretation of all the measures. > > As for parsing, hacking on the current parser is definitely easier, > thought it's not going to address a SE document parsing, but the parsing > of an augmented SLD 1.0 one (augmented in the meaning of having more > attributes around). > > If you look in modules\extension\xsd\xsd-sld you'll find an already > available set of bindings for SLD 1.0 using the new parser architecture. > As far as I know the module was made by Justin as a proof of concept, > but was never actually used in practice, so I don't know how much > of a SLD document it can parse. For sure it does not deal with the > TextSymbolizer extensions (Priority, VendorParameter) that we added > with time in the sax based parser. > > Cheers > Andrea > > -- > Andrea Aime > OpenGeo - http://opengeo.org > Expert service straight from the developers. > > -- Milton Jonathan Grupo GIS e Meio Ambiente Tecgraf/PUC-Rio Tel: +55-21-3527-2502 ------------------------------------------------------------------------------ Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA -OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise -Strategies to boost innovation and cut costs with open source participation -Receive a $600 discount off the registration fee with the source code: SFAD http://p.sf.net/sfu/XcvMzF8H _______________________________________________ Geotools-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/geotools-devel
