Hi,
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 also have implemented the following features: * 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 (didn't require any database extension!), layer: pages show which pages are using the layer and pages using a layer will be purged when the layer changes.
now I am writing because I am planing on implementing some more features which I need some opinion on:
--------
1. I don't like that layer: pages only allows layer definitions but no wiki text around it. So I thought about wrapping all into one tag, Jeroen suggested something like this: <layer type="image" service="openlayers"> width=foo height=bar ... spam=baz </layer>
I think that would do the trick. I am just not sure about the 'service' attribute, I think layer descriptions should be service independent as far as possible if ever any other services will be supported so I would suggest to do it without 'service'. The 'type' makes sense though.
2. 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:
3. 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.
4. Layer groups: All the other map types like bing or google already bring several maps if you write <display_map service="openlayers" layers="bing"></display_map> for example, you get the Bing Streets, Bing Satellite and Bing Hybrid. For some image layers, I want the same. Think about a image of a location from different time periods for example. Instead of listing them all in 'layers', you should just have to call the group name and all of them should be available as base layers. I came up with a few ideas and found these most promising:
* Subpage related. All subpages belong to one group. This would have the advantage that you could specify all relevant information for group members on the parent page (like addresses and extent boundaries), they will be inherited and can be overwritten by the specific page. For addresses, we collect all addresses of all the group pages and make them available for the display functions except if we only want to display one specific layer of a group, then we get the addresses of that layer and those specified in the group page (where all the inherited values come from anyway). * 'group' parameter for <layer> on layer: pages to assign the layer to a group name. This would require a database table to be efficient I believe. In this case we would collect addresses from all group pages as in the first proposal as well. This would also allow to assign one layer to several groups theoretically. The disadvantage besides needing a db table would be that we have no place for eventual layer-group options (can't think of any right now) and not having the inheritance feature.
Just setting up a db table for this little feature seems a little bit much. Though its not hard to deal with db since it would be a small table only, but still, forcing everybody who wants to use maps to do this even though hes not interested in using image layers would be a little bit much perhaps. Also, I like the subpage idea but I'd like to get your opinion as well.
--------
Jeroens image layer code was quite openlayers specific so far, I didn't change that and am not struggling to allow image layers or other layer types within other mapping services right now. Also, I have not looked into other layer types like vector graphic layers yet. Perhaps in some future version or perhaps somebody else who cares about it will one day.
Any thoughts on that? Especially opinions on points 2 and 4 would be interesting! 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
Hey,
I thought a little more about that:
- Layer groups:
All the other map types like bing or google already bring several maps if you write <display_map service="openlayers" layers="bing"></display_map> for example, you get the Bing Streets, Bing Satellite and Bing Hybrid. For some image layers, I want the same. Think about a image of a location from different time periods for example. Instead of listing them all in 'layers', you should just have to call the group name and all of them should be available as base layers.
I think instead of a db or subpage solution, perhaps a solution where you could define several <layer> sections in one page would be even better. We could introduce a attribute vor <layer> called 'name' which gives the layer a name within the group.
if you write
<display_map layers="moon">0,0</display_map>
you will get all the layers defined on 'Layer:Moon' as base layers for this map. If you write
<display_map layers="moon|name">0,0</display_map>
you will just get the map defined on 'Layer:Moon' which has the attribute 'Name' with the value 'name' like:
<layer type="image" name="name"> ... </layer>
This would not give us the inherit feature but could be more convenient than having one page per layer instead of having one per group. It's at least better than the database solution I guess, still, the subpage solution would allow the inheritance feature.
Daniel