Hi, I'm looking into improving the way we handle KML marks and icons and could use some opinions.
Basically right now we are replacing all marks with a same colored well known icon (http://maps.google.com/mapfiles/kml/pal4/icon25.png). As for graphics we either replace a fully accessible internet href straight in the url, if possible, or we notice the graphics is in the styles directory, in that case we link straight to it (the style directory contents are published, if you know what the file names are you can access them). Otherwise... we fall back on the well known icon again. Mind that even straight linking does not take into account resizing and won't work with SVG icons. I was considering if we should try harder to represent data in KML the same way we represent it in a normal WMS output, by back linking to a sort of icon service in GeoServer. One way to implement it could be to have the service receive the mark name, the size, the color, the stroke and a few other params and produce an image representing the mark. As for graphics, the same, using the fully expanded graphics url and the target size. Upsides: - would make for nice url, something like geoserver/icons/mark?name=circle&size=10&color=#FF0000 - the results are perfectly cacheable http wise Downsides: - we would not be able to represent all possible marks unless we roll a lot of parameters. Fact is, a Mark can by filled with a graphics fill and painted with a graphics stroke (picture a mark whose rendering involves the definition of another mark, and so on...) Another possibility would be to back reference something more opaque tha uniquely identifies the graphics inside the style. The style name, the feature type style index, the rule index, the symbolizer index (indexes, since names are not guaranteed to be there). Since the marks can be feature attribute dependent, we would also have to provide the name of the layer and the feature id to identify what we want to be painted. Upsides: - high fidelity - once identified the graphics we could use the renderer machinery to have the mark/graphic painted without much fuss - results are not so easily cacheable, feature contents might change Downsides: - ugly looking url (say we want the first symbolizer in the first rule in the first fts): geoserver/icons?style=xx&location=0,0,0&layer=states&featuerId=states.1 - we'd have to make a lot of data store accesses to paint all the icons, one per request What do you think? Quite undecided, shall I toss a coin? :-) Anyone thinking that leaving the icon generation as is now would be better? Cheers Andrea -- Andrea Aime OpenGeo - http://opengeo.org Expert service straight from the developers. ------------------------------------------------------------------------------ Download Intel® Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev _______________________________________________ Geoserver-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/geoserver-devel
