This page last changed on Feb 05, 2013 by aaime.
Classes in the WMS module
Output formats and reflector
Allows to build a WMS request for KML at ease, but in the end it just builds a GetMap request.
Probably no changes needed.
Sets up and runs the KMLMapTransformer, returning a XMLTransformerMap.
Needs to be modified to call the new KML generation classes.
Sets up the KMLMapTransformer in KMZ mode. What this really does is to make code consider the KMSCORE parameter to decide whether to generate a raster overlay to be inlined in the KMZ, or perform a vector dump. The output is a KMZMap, which in turn creates a zip file with the KML dump plus a PNG image for each layer that was requested in the GetMap.
This approach makes the KML generation work against assumptions that there will be certain images in the KMZ package, it might be better to refactor it so that the KML generation can ask for the images to be included in the ZIP file instead.
Output format used any time the special mime types for network link generation are used, which the KMLReflector imposes any time the mode is not "download". Hardly ever called directly, it's the default choice of the KMLReflector.
This one uses the KMLNetworkLinkTransformer to generate the KML, and sets it in superoverlay mode according to the request parameters.
Needs to be modified to use the new KML generation classes. This one serves a different purpose that the KML/KMZ downloads, those tend to be self contained, this one assumes a connection back to GeoServer is always available
Basic KML writing
Not used anywhere, to be removed
A tool writing out CoordinateSequence objects into GML-like coordinates lists. Extends GeoTools own CoordinateWriter to avoid writing out some of the GML attributes.
Needs to be replaced/incorporated into the new KML writer
Extends GeoTools own GeometryTransformer to avoid writing out GML specific prefixes and adds support for extrusion and altitudeMode.
Needs to be replaced/incorporated into the new KML writer
Base class for KMLVectorTransformer and KMLRasterTransformer. Facilities provided:
- date and time formatting (see David's proposal, this should be factored out)
- placemark name encoding, using Freemarker templates to search for a feature title, falling back on a TextSymbolizer label if found, or the feature id
- placemark description encoding, again based on Freemarker templates, with a ack to append GeoSearch specific stuff (_ here is an example of where having an object representing the Placemark to be passed to callbacks would allow GeoSearch to plug in instead of using hacks)
- placemark snipped encoding
- encoding placemark LookAt by delegating to the KMLLookAtTransformer
- lookup the Symbolizers active at the current scale and for the current feature
(this one should be probably somehow shared with StreamingRenderer)
- encode Style from a list of Symbolizers and the current Feature, with special treatment for all types of symbols, turning them into the corresponding KML styles, IconStyle, LabelStyle, PolyStyle, LineStyle. Also sports support for dynamic symbolizer. Misses good support for complex Mark objects, is probably going to break with SVG symbols (this is orthogonal to the refactor, David seems interested in addressing it via some sort of restful symbol server).
- extracts the geometry centroid to be used for the icon (we encode two geometries for lines and polygons, one that is the full geometry, the other for
- encoding placemark "time" via freemarker templates (several support methods for this, would be nice to factor this out as a plugin)
- hooks to encode features with extended data
- support for encoding geometries delegating to the KMLGeometryTransformer
The placemark utilities must be split into base logic (extracting the name, description and so on, and mere encoding of KML.
While it's tempting to have the KML writer take (Feature,Symbolizer) as the information required to encode a feature, that would make it rather in-flexible... we need something lower level to control the details of the encoding, name, description, extended data and the like.
Another observation we can make is that potentially every step in the Placemark generation could be factored out as a plugin, starting with an empty Placemark and giving the plugins the necessary context (feature, symbolizers and whatnot).
Writes out a Layer as a Document named after the layer title (or using the kmltitle parameter), with a lookat.
If the relLinks option is enabled and there is a maxFeatures in the request, the code will setup in paged mode and generate a atom:link to the next page.
Provides hooks to encode the KML 2.2 schema support for extended data, and then goes down and writes each feature in turn as a placemark using the KMLMapTransformer utilities.
Tranforms a feature colleciton to a kml Document element which contains a Folder element consisting of GroundOverlay elements. Eventually emits a clickable icon for each feature. The GroundOverlay works assuming the are images in the KMZ file.
A model object representing the LookAt object.
We might want to preserve it
Builds the lookat KML based on the previous class.
Builds a document with a folder full of network links (and a lookat element9. Can either encode a superoverlay structure, or a simple "overlay."
The superoverlay will generate a section for each layer, whose contents depend on the nature of the layer: if it's a raster one and there is a tile cache available the link will simply delegate to the embedded GWC KML service, if it's a vector instead a Region will be generated with a link pointing back to GeoServer for the superoverlay generation.
Encodes a Document with 2 or 4 network links attached to Region elements to create the superoverlay hierarchy, or direct
Transforms an entire WMSMapContent into KML delegating to the other transformers, raster, vector and superoverlay, and includes eventually the legend.
Relies heavily on KMLUtils for data loading, and for applying the regionation strategies if necessary (this should be factored out).
Just a bit more of an abstract class, will be completely removed with the refactor, since we are not going to use the GeoTools Translator framework anymore.
This one has a load of utilities used by the other translators:
- building back links to the WMS for more GetMap requests
- filtering the active rules given the Style, the current Feature, and the current scale
- matching envelopes to GWC/superoverlay tiles
- basic XML encoding support, such as turning a number or color to hex
- loading data based on the request, regionation strategy and the like
- getting flags controlling the KML generation from the request
- checking if a request is compatible with GWC
We should try hard to remove this class, either by factoring out code shared with the renderer, pushing some in the KML writer, and other in plugins
Builds a ScreenOverlay which in turns calls back, via URL, to WMS GetLegendGraphics
Sounds like a perfect candidate for a plugin at the top-most document level
The SuperOverlay support is build into a hierarchy of regionating strategy:
The idea is that given a GetMap request for a certain layer the strategy will build a filter selecting the features that have to be included in the current KML Region (thus, considering both the current tile and the zoom level).
This needs to be factored out as a plugin that can manipulate the Query used to access the data based on the current request and layer
KML concepts that we need to encode
- IconStyle, LineStyle, PolyStyle, LabelStyle