Hi,
Actually, I sent a mail to the maps mailing list already but there was no feedback at all so I am taking Jeroens advice and try it again here, there might be some users using maps and waiting for the image maps feature. I already included some of the features suggested in my last mail to "maps-l@lists.wikimedia.org" a little different though.
Recently I have been fixing the Maps extension openlayers image feature to use images as maps again (the feature was broken around Maps 1.0).
Besides fixing the feature for the next version of maps, I have implemented the following features already: * Additional parameters on layer pages (unit, maxScale, minScale) to better control how the map is being displayed. * Markers can have a group, each group is represented as one overlay layer and has its own marker colour (for default markers). * the "display_..." functions/tags using a layer: page store this in the database, layer-pages show which pages are using the layer and pages using a layer will be purged when the layer changes. * Database table for layers which should increase performance and allows to define several layers in one page to group them. Using the layer page name will include all of these group members into the base map-selection of a map. Also, a <layer name="" type="">...properties...</layer> tag is used to define layers now. Via 'name' the layer can have a name so a specific group member layer can be used instead of the whole group of layers defined on the same layer-page.
now I am writing because I am planing on implementing some more features which I need some opinion on:
--------
1. I have implemented first attempts of allowing overlay maps. The overlay feature introduces the attribute 'overlays' for 'display_map' and 'display_point' like: <display_map service="openlayers" layers="Moon Map" overlays="Moon Station, Moon City">0,0</display_map> where 'Moon Station' and 'Moon City' could be smaller maps located on 'Moon Map', simply images with more detail where you can zoom in from a overall view of moon into a detail view of the base and the city. The cool thing about this is, that overlay maps also could be displayed as baselayers if you use them with the 'layers' parameter instead (since they must have a layer: page anyway)
This works, but it doesn't make much sense without coordinates for the overlays. So I am thinking about a appropriate syntax but can't come up with anything nice: <display_map service="openlayers" layers="Moon Map" overlays="Moon Station|20;40, Moon City|100;40">0,0</display_map> for example wouldn't be very consistent syntax compared to the other map syntax and I don't even want to think about #display_points which has some weird syntax compared to <display_points> How about: <display_map service="openlayers" layers="Moon Map" overlays="Moon Station|Station, Moon City|City" addresses="Station (20,40), City (100,40)">0,0</display_map> So we would first declare some named addresses and assign them to coordinates, from then on we can use the names for image layers just like in mapping services like bing or google maps where you can just write 'New York' instead of the actual geographical coordinates. And not using the () within 'overlays' has the advantage that layer sites still can contain '(' and ')' within the site name. It also allows to use the addresses for markers like: <display_points service="openlayers" layers="Moon Map" overlays="Moon Station|Station, Moon City|City" addresses="Station (20,40), City (100,40)"> Station | Moon Station | This is the moon station | station.png | Group 1 </display_map> So instead of using coordinates we can use names as coordinates for markers within image layers as well! This goes even one step further with the following...
2. ...allowing to define addresses within the layer page. This could be a parameter 'addresses' which contains coordinates and names of addresses which can be used for overlays and markers for 'display_point' and for overlays using 'display_map'. This could look like: <layer type="image"> source = moon.jpg ... addresses = station (20,40), city (100,40), .... </layer>
addresses would be case-insensitive and would even make the use of the 'addresses' parameter within the display functions obsolete when using overlays but the main advantage would of course be that markers can be added very fast and without searching for coordinates first since all important coordinates are described already. 'addresses' parameter of display functions will overwrite if one name is given there and on a layer page.
3. its difficult with units. Layers can have different units like degree, km, miles... I didn't look into how it works if markers with units are defined in display_marker if there are layers with different units. Perhaps we should allow coordinates with units like "20km,200m" to make it clear. This could also be included in layer pages so we can say "left-extend=20km" and stuff like that instead of having a "unit" attribute. There might me more simple solutions though, have not really looked into that yet.
4. Since the custom layer features will require database support and update now, we are thinking about making it as a separate extension for Maps extension like SemanticMaps. Would be some work to separate all the stuff though so I am also thinking about simply disabling the layers functionality in case no database update was run yet - without throwing any php errors.
--------
Any thoughts on that? If you have any further ideas for the image layer feature, please write a separate mail instead of answering to this one, except it is highly related to one of the points above! Thanks!
Cheers, Daniel
Daniel Werner wrote:
- its difficult with units. Layers can have different units like
degree, km, miles... I didn't look into how it works if markers with units are defined in display_marker if there are layers with different units. Perhaps we should allow coordinates with units like "20km,200m" to make it clear. This could also be included in layer pages so we can say "left-extend=20km" and stuff like that instead of having a "unit" attribute. There might me more simple solutions though, have not really looked into that yet.
ParserFunctions extension is able to convert between units, so you could accept mixed units and canonalize to your prefered one.
wikitech-l@lists.wikimedia.org