I wrote a PHP hack (with caching) that lives on icons.opengeo.org: http://icons.opengeo.org/dynamic/circle/aaffaa_aaffaa_8.png http://icons.opengeo.org/dynamic/square/aaffaa_aaaaff_12.gif
All the images are 32x32, since that's what GE expects. The syntax I used was <shape>/fillrgb_outlinergb_diameter.format Not sure whether the caching was important, it may be overkill, but it's definitely handy to be able to specify an ouline color. -Arne Andrea Aime wrote: > 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 > > ------------------------------------------------------------------------------ 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
