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 ------------------------------------------------------------------------- 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
