I've added these ideas and a couple of others to the wiki at http://geoserver.org/display/GEOS/GSIP+21+-+KML+Vector+Transformer+Refactoring . I haven't looked at the entire KML transformer family of classes yet, just the vector transformer, so there may be some further additions when I do. Still, fire away with the feedback.
-David David Winslow wrote: > Andrea Aime wrote: > >> David Winslow ha scritto: >> ... >> >>> Hi Andrea, >>> >>> I get the impression that you are thinking of regionated KML as a >>> single file containing all the features, separated into different >>> Documents with appropriate level-of-detail configurations for each >>> feature grouping. >>> >> No no, I know what superoverlays are, sorry I leaved the doubt. >> >> >>> One point of the regionating process is to avoid spending bandwidth >>> and client-side resources on features that the end user won't be able >>> to see anyway, so it's a filter on the features that are included in >>> the document at all; with the assumption that NetworkLinks will be >>> used to pull in the appropriate tiles as the client zooms in. >>> Grouping the features into separate documents is something completely >>> orthogonal (although having this hierarchy in a regionated tile >>> hierarchy would probably not work well; the treeview is pretty much >>> overwhelmed by all the NetworkLinks for even a few zoomlevels' worth >>> of data from a regionated hierarchy. You can check out the demo at >>> http://geo.openplans.org:8080/geowebcache-unstable/service/kml/topp:glin_benzo.geosearch-kml.kmz >>> >>> to see what I mean.) >>> >> My point with the classification example was not to imply it >> was related somehow to regionating, but only to show there is >> "features" pressure building on the KML module, this implies >> it's getting more and more complex. I just wanted to express a concern >> and present an idea (pluggability) to avoid the transformer >> class explosion. >> >> >>> In general I'm not opposed to code cleanup, but I think it would be a >>> pretty large increase in scope for me to add the feature you're >>> talking about. >>> >> Classification was just meant as an example, not as a request for you >> to implement it. Same goes for increased modularity of the kml >> transformers, I just wanted to throw the concept on the plate and see >> if any bright idea came out. >> I'm painfully aware of how under pressure each one of us is, last thing >> I want is to overly increase your scope. You're right that modularizing >> more KML generation is probably gong to take some sizeable time... >> I believe sooner or later we'll have to cross that bridge, but it does >> not have to be today ;) >> >> Cheers >> Andrea >> >> >> >> > Okay, this clears things up a bit. I am not sure I have a good idea of > what parts of the KML transformer are appropriate for extension, perhaps > we could put together a list of (potentially silly) features that we'd > like to at least have the potential to support before I put too much > time into investigating a refactor of that code. Counting the > classification you've mentioned, there are three aspects of the > generated KML that have been mentioned already as candidates for > extension points: > > * Filters on what data is included (aka RegionatingStrategies.) My > regionating code already includes an interface, > RegionatingStrategy, intended to allow easy addition of new > filtering policies. My current code just uses a chain of if's to > choose between the three strategies that I have implemented, but > refactoring this to a full-fledged Spring extension point would be > fairly straightforward. RegionatingStrategy currently lives at > > http://svn.codehaus.org/geoserver/trunk/geoserver/community/geosearch/src/main/java/org/vfny/geoserver/wms/responses/map/kml/RegionatingStrategy.java > if you'd like to take a look. > * Extra XML nodes to attach to Placemarks (for example, <atom:link> > elements to help Google's GeoSearch identify features and avoid > duplicates in their index.) The code that handles this in the > GeoSearch module is currently all in methods that have just been > added to the KMLVectorTransformer. I guess for this we would want > to have a PlacemarkListener interface which would have > implementations for each of the details we currently include, and > further information could be added by registering other listeners > through spring. If we allowed each listener to have some string > identifier then we could add some format_option to toggle them as > well. This would probably look like > > public interface KMLPlacemarkListener { > public void writeNode(OutputStream out, SimpleFeature f); > } > > * Classification. This feels a bit harder (since it would actually > change the structure of the produced KML, from having 1 document > to N documents). I think the most straightforward approach here > would be to sort the features for each request by whatever > attribute is being used to classify them, and then start a new > document whenever the KML producer encounters a value of that > attribute that doesn't match the previous value. But we might > want to do something smarter (for example, maybe we want to > cluster towns alphabetically, or classify on a numeric field) so > the condition for starting a new document would be the extension > point. I guess this would be a KMLClassificationPolicy interface > along the lines of > > public interface KMLClassificationPolicy { > public SortBy[] getSortBy(MapLayerInfo layer); > public boolean terminateClass(SimpleFeature f); > } > > Here I'm thinking of extensions as being some classes that are > registered in spring and then the kml transformer delegates tasks to > them, rather than extending the KML vector transformer as currently is > done. If there's a nicer way to deal with this, feel free to enlighten > me :) A nice thing about keeping it as one class that is customized > through spring extension points is that we should be (mostly) able to > introduce the extension points incrementally to avoid a sudden plunge > where everything is broken at once. > > I guess there are also some things in the vector transformer that might > want to be factored out and generalized away from the KML producer > entirely, such as the methods that find the style rules that apply to a > particular feature at a particular scale. > > This has mostly been off the top of my head so far, I'll look at the > actual code in a bit more depth sometime this week. I feel like it may > make sense to have 'make KML easy to work with' as a separate GSIP though ;) > > -David > > ------------------------------------------------------------------------- > This SF.net email is sponsored by: Microsoft > Defy all challenges. Microsoft(R) Visual Studio 2008. > http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ > _______________________________________________ > Geoserver-devel mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/geoserver-devel > > !DSPAM:4040,4841b5e8135121030819293! > > ------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ _______________________________________________ Geoserver-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/geoserver-devel
