All in all your approach seems more complete, so it may make sense
> to try to add
Ok, good.
>>> Also, I'm quite new to GeoTools/GeoServer programming so we surely >> need some review on the code by some expert. >> >> I include some documentation on our plugin at the bottom of the >> message, so that you can decide what is good and what is bad and >> maybe produce a single unified plugin. >> >> Here is the documentation (any suggestion is appreciated): >> >> HTMLImageMap GetMapProducer 1.0 for GeoServer 1.5.x >> >> USAGE >> --------------------------- >> >> The HTMLImageMap GetMapProducer adds support for an additional output >> format for >> WMS GetMap requests. The new format is associated to the "text/html" >> mime type >> and produces an HTML 4.0 image map as defined by W3C.> > I looked around, could not find an official "imagemap" mime type... > given that imagemaps are in fact part of html, it seems it makes > sense to have them be "text/html". > So it means you're producing a full blown html page right?
At the moment I'm outputting just the <map>...</map> fragment (it's
trivial to add an enclosing <html><body>...</body></html> if it's
needed). Our current approach is "less is better", so we don't return
anything else other than the ImageMap.
> Do you present it to the user as is, or do some javascript wizardry > to merge it with another html page?
The latter, we currently use it in a full blown application where we
"merge" a raster map with the imagemap at runtime (when it's needed).
This means two different requests to geoserver, one for the raster map,
one for the "tooltip" imagemap level. But this is the way we use it.
Someone else can probably use it in a different way.
>>> Image Maps can be used to cut images in several areas. Each area can >> have a link, >> title or alt attribute. >> >> Request Example. >> [http://localhost:8080/geoserver/wms?bbox=-130,24,-66,50&styles=population&Format=text/](http://localhost:8080/geoserver/wms?bbox=-130,24,-66,50&styles=population&Format=text/) >> >> html&request=GetMap&layers=topp:states&width=550&height=250&srs=EPSG:4326 >> >> >> Output Example. >> <map name="states"> >> <area shape="poly" id="states.1.0" coords="360,120 358,121 >> 357,121 357,122 >> 357,123 357,124 356,124 355,124 354,123 352,123 351,124 351,125 >> 350,124 350,125 >> 349,125 349,124 348,123 348,122 348,121 348,120 348,118 347,118 >> 346,117 345,116 >> 344,116 343,115 342,114 341,113 341,112 341,111 341,110 342,110 >> 342,109 343,108 >> 342,107 340,106 339,107 338,107 338,105 338,104 337,103 336,102 >> 336,102 335,101 >> 333,100 332,99 332,98 331,97 331,96 331,95 331,94 331,93 332,91 >> 332,90 333,90 334,90 >> 334,89 335,88 336,86 335,85 334,84 335,83 336,82 336,82 338,82 339,82 >> 340,81 341,81 >> 341,80 342,79 342,78 342,77 342,76 341,75 340,74 340,73 339,73 338,72 >> 340,72 344,72 >> 349,72 353,72 354,72 358,72 359,72 363,72 362,74 363,75 364,76 364,78 >> 365,80 365,82 >> 365,84 365,85 365,86 365,89 365,91 365,95 365,97 365,100 365,101 >> 365,102 364,103 >> 364,104 364,105 365,106 365,107 365,108 365,109 364,110 364,110 >> 363,111 363,112 >> 362,113 361,113 362,114 361,115 361,116 360,117 360,118 360,119 >> 360,120" title="IL"/> >> ... >> </map> >> >> Each single feature is rendered as one or more area tag. More than >> one area tag is >> used if the geometry is not compatible with imagemaps constraints, >> and a split in >> more simple geometries is needed.> > Good. A possible improvement would be to generalize the geometries > even further to reduce the size of the image map (just an idea).
We already generalize the geometry using a modifiied version of the
Decimator code I found in the geotools renderer module.
>>> An ID attribute is generated for each area tag. The ID is made up of >> two parts: >> <featureId>.<sequence>, where <featureId> is the id of the feature >> containing the >> geometry rendered in the tag. Sequence is a sequential number (0,1,2, >> ...) appended >> to the id distinguishing different simple geometries in which the >> feature could have >> been splitted. >> >> Usage Example. >> <img src="..." usemap="#states"/> >> >> STYLING >> ---------------------------- >> A little bit of styling is supported through SLD symbolizers. In >> particular: >> - TextSymbolizers are used to append attributes to the area tags. You >> can define a >> Label, whose output will be rendered as an attribute value. By >> default, the >> attribute name is "title" (this permits to define tooltips). You can >> define several >> custom attributes, using different rules, the rule name will be used >> as attribute >> name (eg. >> <Rule>...<Name>href</Name>...<TextSymbolizer>...</TextSymbolizer>...</Rule> >> defines >> an href attribute, binding links to the rendered areas).> > Nice!
Thanks.
>>> - LineSymbolizers stroke-width parameter is used to define a buffer >> along >> linestrings (defaults to 2px if not defined). >> - PointSymbolizers Size is used to define circle radius for rendered >> points >> (currently only Marks with a WellKnownName of "circle" are >> supported).> > So this covers the case Robert was talking about already?
I think so.
> > It seems quite full featured and well integrated in the way GeoServer > does things. Can I have a look at the code?
Sure, just tell me where I can send a zip (or something else you
prefer). I'm not really sure if the "reprojection" code I use is
correct. Due to my inexperience in GeoTools/GeoServer most of the work
has been done copying and pasting from other modules and so I'm not sure
about the result quality. Any suggestion is very much appreciated.
Thanks,
Mauro Bartolomeoli