]> git.vanrenterghem.biz Git - git.ikiwiki.info.git/blobdiff - doc/todo/osm_arbitrary_layers.mdwn
Added a comment
[git.ikiwiki.info.git] / doc / todo / osm_arbitrary_layers.mdwn
index 4895aa5aef813009e27e3be71e65a59c6de11fd3..d59f394ee82a21fe55c565423cdb4e90458bd724 100644 (file)
@@ -1,4 +1,4 @@
-[[!template  id=gitbranch branch=anarcat/master author="[[anarcat]]"]]
+[[!template  id=gitbranch branch=anarcat/osm_arbitrary_layers author="[[anarcat]]"]]
 
 I got tired of hacking at the osm.pm every time I wanted to change the layers, so I made it so the layers can be changed in the .setup file. In my master branch, there are now two new configuration settings: `osm_layers` and `osm_layers_order` which replace the hackish `osm_mapurl`. The variables are a hash and an array that allow the operator to define the list of URLs to be loaded as layers and also to change the order of layers. -- [[users/anarcat]]
 
@@ -19,3 +19,25 @@ I got tired of hacking at the osm.pm every time I wanted to change the layers, s
 > > That said - maybe you're right and this should be passed as an argument to the OSM directive. The problem then is that you need to pass this stuff around the waypoint directive too. It also makes it hard to have a consistent set of maps all across the wiki. On our site, we have map inserts here and there, and it's nice to have them consistent all around.
 > > 
 > > In closing, I would say that I agree that `.._order` is confusing: maybe I should just have a `_default` to choose the first one? -- [[anarcat]]
+
+>>> If there's no reason to order the other layers, that makes some sense.
+>>> --[[Joey]]
+
+>>>> The layers are ordered because that's the way they are displayed in the menu. Take a look at the base layers on the top left here for an idea: <http://wiki.reseaulibre.ca/ikiwiki.cgi?map=map&do=osm&zoom=12&lat=45.5227&lon=-73.59554>. -- [[anarcat]]
+
+>>>> After sleeping over this - maybe it would be simpler if `osm_layers` was just an array. First, it would get rid of the duplication with `osm_layers_order`. Then I do not feel that having the keys in that hash is worth the duplication anymore. The only reason this is a hash is to provide an arbitrary string description for the layers. We could replace this with an automated description based on the path to the tiles provided.
+>>>> 
+>>>> If that's an acceptable solution for you, I'll go right ahead and rewrite this in a separate branch for merging. Note that on my master branch, there are now 3 main  changes that are not merged: arbitrary OSM layers (includes Google Maps support), KML formatting improvements (indentation, non-duplication of tags), minor OpenLayers improvements (don't sort layers arbitrarily, folders support, higher default zoom level and projection fixes). I can either make a branch for those three things or leave it on my master branch, but be warned that it will be hard to separate those as distinct/orthogonal patches as they mangle each other quite a bit.
+>>>>
+>>>> So basically, I need to know two things from you:
+>>>>
+>>>> 1. on the layers design: a) hash (which include arbitrary descriptions) + default value or b) a simple array with automated descriptions
+>>>> 2. the above changes on a single branch or on 3 different ones?
+>>>>
+>>>> Thanks for your time.  -- [[anarcat]]
+
+>>>>> I have implemented 1.b) and 2. (ie. it's a simple array now, and I split this stuff in different branches.) I'll open another todo for the other branches. --[[anarcat]]
+
+>>>>>> [[merged|done]] --[[Joey]] 
+
+Confirmed, thanks!! --[[anarcat]]