]> sipb.mit.edu Git - ikiwiki.git/commitdiff
Merge remote-tracking branch 'anarcat/osm_arbitrary_layers'
authorJoey Hess <joey@kitenet.net>
Sat, 25 Aug 2012 14:10:03 +0000 (10:10 -0400)
committerJoey Hess <joey@kitenet.net>
Sat, 25 Aug 2012 14:10:03 +0000 (10:10 -0400)
doc/todo/osm__95__optimisations__95__and__95__fixes.mdwn [new file with mode: 0644]
doc/todo/osm_arbitrary_layers.mdwn

diff --git a/doc/todo/osm__95__optimisations__95__and__95__fixes.mdwn b/doc/todo/osm__95__optimisations__95__and__95__fixes.mdwn
new file mode 100644 (file)
index 0000000..cf58060
--- /dev/null
@@ -0,0 +1,13 @@
+[[!template  id=gitbranch branch=anarcat/osm_kml_formatting author="[[anarcat]]"]]
+[[!template  id=gitbranch branch=anarcat/osm_openlayers_misc author="[[anarcat]]"]]
+
+I have accumulated a small series of patches to the OSM plugin along with the [[other|todo/osm_arbitrary_layers]] [[fixes|bugs/osm_KML_maps_do_not_display_properly_on_google_maps]] I have submitted here. They have lived in a tangled mess on my master branch so far, but not anymore!
+
+I have two main branches that need merging (on top of [[todo/osm_arbitrary_layers]]):
+
+ * `osm_kml_formatting` - indentation of the KML, optimisation: remove duplicate style declarations, folders support (even though [[it's not supported by openlayers just yet|https://trac.osgeo.org/openlayers/ticket/2195]])
+ * `osm_openlayers_misc` - do not override the sorting of layers (so that the order defined in [[todo/osm_arbitrary_layers]] takes effect) and tell Emacs about the non-default indentation policies of the file.
+
+Those two branches are also merged directly on my master branch... along with [[todo/osm_arbitrary_layers]].
+
+I am filing this as one todo to simplify matter, but I can also split it further if needs be. --[[anarcat]]
index a2e41dc6168ad608c14667f5dfa17152578b8505..94cc27bb19c2fc15510aa98ae4abc298da0415a4 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]]
 
@@ -24,3 +24,16 @@ I got tired of hacking at the osm.pm every time I wanted to change the layers, s
 >>> --[[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]]