-
Notifications
You must be signed in to change notification settings - Fork 4
GSIP 20 Automated Regionating in KML MapProducer
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 Proposal Backwards Compatability Feedback Voting Links
David Winslow
1.7.0
Under Discussion
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 \\
http://someserver/geoserver/wms?bbox=--180,-90,0,90&styles=&Format=application/vnd.google-earth.kml+xml&request=GetMap&version=1.1.1&layers=topp:somelayer&width=800&height=386&srs=EPSG:4326
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.
| Option | Description |
|---|---|
| regionateBy | specifies the name of a regionating algorithm to be used, such as “sld” (the default), “data”, or “geo” |
| regionateAttr | specifies the name of the attribute to use for regionating algorithms that depend on the data |
| relLinks | specifies whether to include paging links as used for the GeoSearch index pages (can be “true” to enable the links or anything else to disable them (default)) |
| Algorithm | Description |
|---|---|
| sld | Use the SLD scale denominators (current behavior) |
| data | The zoom level at which features show up is determined based on some attribute of the data, for example, city data might show features with the highest “population” value first |
| geo | The zoom level at which features show up is determined based on a geometric attribute of the data. This is very similar to the “data” algorithm, but has the potential to “look” better since geometry has a strong influence on the appearance of the map as clients zoom in. For example, we could ensure that no feature is put into a tile whose bounding box does not entirely contain the feature. |
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:
- GeoSearchMapProducer.java
- GeoSearchMapProducerFactory.java
- GeoSearchTransformer.java
- GeoSearchVectorTransformer.java
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.’
- Move RegionatingStrategy and the current implementations thereof to the core wms module
- Add them to the spring context and modify KMLVectorTransformer to use RegionatingStrategy as an extension point for filtering the KML producer’s output
- Ensure that the SLD strategy is used when none is specified.
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.
Andrea Aime: +1 Alessio Fabiani: Justin Deoliveira: Jody Garnett: +1 Saul Farber: Rob Atkinson: +1
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]\\