Andrea Aime wrote: > David Winslow ha scritto: >> Hi all, >> >> I've been doing some work on automated regionating for KML output in >> a community module. I'd like to move that code into the main KML map >> producer. I've written up a GSIP at >> http://geoserver.org/display/GEOS/GSIP+20+-+Automated+Regionating+in+KML+MapProducer >> >> >> >> Of course, comments/questions/general feedback are welcome. It would >> be nice to be able to vote on this at next week's IRC meeting. > > KML support is getting so big that it is really starting to ask > for its own module (hello Justin ;) ) > > As for merging stuff directly inside the KMLVectorTransformer, I'm > having some reservations. I understand it's the easiest way to > get that done, but at the same time this would add to a class > that's already 1200loc. I'm wondering if it would be possible > to split up some more code in pluggable separate classes, so > that you would use one for standard KML, another for regionated > KML, and so on. > > To give you another idea, some time ago Jason Pickering asked > the KML to be split along the values of one or more attributes, > building a classification tree that could be seen from GE as > a tree control, stuff like roads with childs as "major roads", > "local roads", and so on. > > I believe having some pluggability in how the generated KML is > organised (besides the regionating strategy, but more on the > lines of flat, regionalted, classified) would be good from > a maitentance and understandability point of view. > > I'm not asking this to be done this way, just that you consider > this as an alternative and see if it could lead to a cleaner > (and more extensible) implementation without expanding too > much the scope of your work. > > Cheers > Andrea > > !DSPAM:4040,483fc940286101137850744! >
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. 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.) 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. -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
