HTMLImageMap GetMapProducer Proposal

Source code for the GetMapProducer

Please find attached an alternative implementation which seems to be less complete than the one Mauro Bartolomeoli.
Unfortunately I haven't had the time yet to look into that implementation. However, maybe our solution may be of some use too.

Robert Saenger

Mauro, I've started looking at your contribution.
I've created a community module in my geoserver trunk checkout, added a pom.xml (was missing) and started doing some changes in order to make it compile on trunk. Most of the changes involved using GeoAPI filters instead of the odl gt2 filters and stuff like that.
Now, I have the tests mostly passing, but I have one, the testMapProduceReprojectAndLabel that's not working. Was it working for you?
Another question I have is about the Decimator, if I interpret the changes correctly you modified it in order to have it clone the geometry during decimation. It's something I like to avoid, and use the standard Decimator (which I have optimized on trunk) and do the eventual initial cloning like the streaming renderer does. What do you think?

Sorry for the pom.xml, I thought it was in the archive (it was in my working dir). I noticed some deprecation warnings on filters, but I don't know GeoTools so well (I'm still learning).
On the testMapProduceReprojectAndLabel, I had some problems too: I had different reprojected coordinates using epsg-hsql or epsg-wkt. I don't know if my reprojection code is correct. Can you verify it?
I think your approach of initial cloning (do you intend to use LiteShape2 as Robert Saenger did on his implementatiion?) is the right approach. I was thinking to rewrite it that way, but I did'nt have the time yet.

I'm currently doing some test on a possible extension: producing html with embedded base64 images (firefox, opera and safari support them) to have a raster interactive map with a single request (using FreeMarker templates we can create customizable html pages). Unfortunately Internet Explorer is not able to read this format, but it reads an alternative format (MHTML) with similar features. Do you think it could be interesting for the community?

Ok, I'll have a look at the reprojection code. As for the extended formats, I think they would be interesting for the community all right.
I guess deciding which format to hit will be something that a client side javascript has to deal with? (by doing a browser identification).

Mass close all issues that have been resolved for more than one month without further comments (assuming they are fixed for good since there is no more discussion)