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.
