Last modified: 2013-09-17 09:14:01 UTC
Hello, When doing a map as vector graphics, it is very interesting to make this map interactive by putting wikilinks pointing to the dedicated articles. You can take a look at the two following examples: * http://fr.wikipedia.org/wiki/Mod%C3%A8le:Carte_des_ch%C3%A2teaux_cathares * http://fr.wikipedia.org/wiki/Mod%C3%A8le:Carte_de_Kinshasa This methode using CSS has many drawbacks: - Everytime you resize the image frame, all the links have to be changed by hand. - Everytime you change the SVG file and this change includes a resize, all the links have to be changed by hand. - This method is very boring and takes a looooooong time. It would be _really_ practical to have some extension that would parse an SVG file looking for text with wikisyntax. Thus, links could be added directly in the SVG file. This would really improve the map features of MediaWiki: - Images could be resized without making the position of the links obsolete - The links could be placed directly in Inkscape, thus making it much more practical to place them - All maps could be made interactive
This should be part of the ImageMap extension, maybe? Since SVGs are rendered to PNG, of course, you'll have to generate an HTML <map> element with all the correct positions when you render the thumbnail.
I'm a rank beginner wrt SVG but I know <imagemap> quite well. There are a couple of things to watch for in the proposal and I propose ways to deal with this. 1 - SVGs can contain a lot of elements and not all will be needed in an imagemap. While some users might create a nice SVG, in general an SVG could swamp imagemap if it contained too many bits. 2 - Placing links directly in the SVG makes the SVG unusable in other contexts. In other words, if the SVG of a map of a city that links to real estate info would not be useful as a map of tourism - a second version would be required. The links should not be in the SVG. For that reason, I would not recommend having the SVG "drive" the imagemap. Rather, make sure the imagemap and the user specify the elements in the SVG that are to be used and map those to links. I would propose that a new keyword be added to imagemap that allows this. For example: Add a keyword "group" with the following syntax: group group-id link-definition Example: <imagemap> image nycboroughs.svg|300px|center default [[New Your City Tourist Information]] group manhattan [[Manhattan Tourist Information]] group bronx [[The Bronx Tourist Information]] ... </imagemap> Within nycboroughs.svg, you'd have a group like: <g id="manhattan"> <rect x="50px" y="75px" width="80px" height="240px" /> </g> Thus <imagemap> can find group-id "manhattan", get the contained rectangle and generate the appropriate area html: <area href="index.php/Manhattan_Tourist_Information" shape=rect coords="50, 75, 130, 315" alt="Manhattan Tourist Information" title="Manhattan Tourist Information"> Obvious problems (and in this an expert on SVG may offer help): - This requires that the SVG creation software generate appropriate data - one shape per group for the relevant area. I don't know whether this is under the control of the user in a typical software package (like Inkscape). - For reusability of the SVG, there should be an easy method of finding the appropriate group names contained in the SVG. I offer this as a starting point...
On further consideration, the requirement for one area per group is not necessary. If more than one area is provided (e.g. union of two polygons that may or may not be contiguous) to define one image region, using both of those areas in the imagemap will be easy to deal with. If two <area> HTML lines are created with the same link, it provides the same functionality. In fact, using <g>roup as a level of identifying the information for a single link seems that it will allow for a lot of complex image regions to be handled correctly. HTML Image maps do not have a problem with overlap, so if all areas within a group are rendered separately as an area, it should work fine. If two distinct groups have overlapping regions, then it should still work, since IIRC, HTML rules on overlap in image maps are consistent with SVG's on rendering - the last definition takes precedence over the earlier ones. This means no clipping calculations need be done to produce the correct image map areas.