GeoServer : GSIP 20 - Automated Regionating in KML MapProducer
This page last changed on Jul 24, 2009 by email@example.com.
Merge the code that does automated "regionating" (a Google-coined term for choosing to hide or show features based on zoom level) in the GeoSearch community module back into the main KML map producer.Motivation
Regionating is the process of dividing up features by zoomlevel and only returning information to clients that is appropriate for the zoom level at which they are viewing a map, often a large performance gain (and bandwidth saver) for web clients such as Google Earth. The 'regionating' code in question performs relatively automated regionating of features in a featuretype served by GeoServer in the KML format.
Having a separate MapProducer for the KML regionating code leads to a number of duplicated classes (there are no fewer than three classes in the GeoSearch module that do absolutely nothing beyond calling a different constructor than the analogous KML class from the main wms module) as well as some minor user-facing issues like using a bogus mimetype to request regionated output. This should be cleaned up.
We should make all of the regionating-related features controllable via format_options. A request like
should return "normal" KML (ie, feature inclusion is controlled by the SLD only) while adding "&format_options=regionateBy:data" will return the same layer filtered by some data-based regionating algorithm.
More information on the regionating algorithms can be found at http://geoserver.org/display/GEOS/Vector+Super+Overlays. Note that the "data" and especially "geo" algorithms are still not completely implemented, and that others may prove useful in the future.
Implementation for this would involve directly modifying the existing KMLMapProducer to respect the new format options; however the regionating algorithms would be delegated to a new set of RegionatingStrategy classes. The implementations currently in GeoSearchVectorTransformer (http://svn.codehaus.org/geoserver/trunk/geoserver/community/geosearch/src/main/java/org/vfny/geoserver/wms/responses/map/kml/GeoSearchVectorTransformer.java) would be copied directly into the KMLVectorTransformer.
The current implementation in SVN includes four classes:
which override methods from the existing KML implementation. Of these, only GeoSearchVectorTransformer overrides any methods that are not simply factory methods calling the constructor of the next class 'down the chain.'
Since there is no integrated means for advertising format_options, we need to make sure clear, easily found documentation is available describing the available options and perhaps some guidance on choosing parameters.
http://geoserver.org/display/GEOSDOC/05-KML+Super+Overlays should be updated to describe how to use the new features.
This section should contain feedback provided by PSC members who may have a problem with the proposal.
Since all the format_options will default to the previous behavior, clients unaware of the regionating functionality will be unaffected by these changes.
Google KML Developer's Guide on regionated KML (there referred to as Region-Based Network Links) http://code.google.com/apis/kml/documentation/regions.html#regionbasednl
|Document generated by Confluence on May 14, 2014 23:00|