Hi Matthias - this "transition to GeoAPI" game is happening in a couple places now - let's see how it works out for style. Matthias Basler wrote: >>> 2. What is the roadmap to get the whole styling API use GeoAPI >>> expressions? >>> >>> >> RIght. >> 1. collapse GeoAPI style interfaces into one (we can do that now since >> Expression works for object; they had one style for graphic and another >> for feature) >> 2. make our interfaces extend the GeoAPI ones; we can leave some extra >> methods there in deprecated form for a bit. >> 3. run through the code base and force GeoTools to only use the GeoAPI >> style interfaces >> 4. release >> > > To your steps: > -> 1. collapse GeoAPI style interfaces into one > Does this mean GeoTools creates another set of interfaces on top of GeoAPI? > Or does this mean to tell the GeoAPI guys that their two style APIs should be > refactored to one? Or am I misunderstanding you? > The GeoAPI two GeoAPI style widgets will become one; the names will be brought inline with the specification. Until this happens we have no interest in using the GeoAPI interfaces (because we know they would just change on us).
(As a side effect of following the specification the methods will be a closer match to the existing GeoTools style interfaces.) > -> 2. make our interfaces extend the GeoAPI ones > Your interfaces already extend the GeoAPI ones, afaik. (That's exactly what I > realized too late after my first mail.) So what is this step about? Extending > any NEW interfaces that do not yet exist? > Right - That is true for Expression. But not for style ... see this link: - http://javadoc.geotools.fr/2.3/org/geotools/styling/LineSymbolizer.html This java interface for LineSymbolizer does not extend either of these GeoAPI interfaces: - http://geoapi.sourceforge.net/2.0/javadoc/org/opengis/go/display/style/LineSymbolizer.html - http://geoapi.sourceforge.net/2.0/javadoc/org/opengis/sld/LineSymbol.html The above two interfaces need to be collapsed into org.opengis.style.LineSymbolizer (in order to agree with the specification, and package naming convention) (Sorry I should of used an explicit example earlier - just was not sure how interested you would be) > -> 3. force GeoTools to only use the GeoAPI style interfaces > The "old" GeoTools style interfaces were deprecated in GT2.3. Does this mean > they can be removed for GT2.4. Or would it be wise to wait with this until > GT2.5? > I am always in favour of a clean code base where deprecations are removed as > soon as people had their chance to switch. But this is not my decision. > I am referring to *only* the GeoTools codebase here; we would make our render methods accept a GeoAPI Style as a paremeter (our geotools Style interface could still be passed in since it would implement the GeoAPI interface). Client code such as GeoServer, GeoWidgets and uDig would have a release cycle as usual. Please note anything extensions LineSymbolizer2 would still remain in the GeoTools codebase (nothing would be taken away). >> You can use a FilterVisitor to traverse the tree structure of the >> expression; making note of any PropertyName elements you see. >> > That is what I was looking for. I'll try this. Thanks for your help. > DataUtilities has some examples for common tasks - including one that does exactly what you want (return the propertyNames used by a single expression). You can use it as an example. I am pretty sure the rendering code uses something similar in order to figure out if optimizations can be applied. I would fire up eclipse and use the hierarchy view to look all implementations of StyleVisistor and see if what you want has been made already. Cheers, Jody ------------------------------------------------------------------------- Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier. Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642 _______________________________________________ Geotools-devel mailing list Geotools-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geotools-devel
