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