Hi Andy, I know that it's not easy - and I'm sure it's not possible to do completely without manual work, but I think, it would be great to have something like that.
Let's see, what a feature in a map key usually is. 1) a label in the users language describing the features meaning (e.g. city, capital, ...) 2) a small graphical image showing how that feature looks like. The Problem Andy pointed out is, that there is nothing like "a feature" in the Map Style languages we have so far. Mapnik simply uses the painters algorithm to draw parts of the map on top of each other, building a feature out of several individual parts (like: highway casing, highway fill, highway marker (e.g. oneway), highway label halo, highway label). MapCSS and CartoCSS tackle this slightly introducing special features to connect these parts together. Style developers don't have to use these, but it's possible. Here we now have something like "a highway with this casing, that fill and a label like that". Nevertheless this must not be connected completely. E.g. a tunnel might "inherit" the highways attributes, as in the background it's still mapniks painter algorithm processing the map data. But what's necessary to build a map key item? - we have to know what should be in this map key - we have to know if that map key should be displayed. For Mapnik we could use an additional attribute to any symbolizer. Let's call it mapkey, and let it work semantically like the class attribute in html, containing a list of class names. >From that we could generate a map key: - for each "mapkey" value (where one mapkey attribute is a list of values) get all items sharing the same map key. - generate a data item for that: - from the symbolizer types decide if you use a rectangle, line or point as a basis - add the features to match filters and label-attributes - render as usual with the mapnik style This could be tweaked, e.g. rendering on different background colors or whatever, but it's essentially what I would expect in the map key. Now only the label texts (describing the individual features) are missing, but you could use the "class" names for this as a key in any localization engine like on osm.org. Your https://github.com/gravitystorm/mapnik-legendary approach IMHO is exactly the right direction, it's just one additional step to add it to the stylesheets instead of adding an additional file. For your example file [1], as far as I understand it: - width height and background are general settings for the map key. - features is a set of features to add to the map key - with my sketched idea above these would be the individual mapkey "classes" from cartocss. - type: as described: depends on the symbolizers used on the current class - tags: as described: pulled from filters and labelling-commands - layers: might not be necessary - zoom: should be a zoom range and could be pulled from the zoom selectors of the layers. I'm sure it's possible to bundle that together, and even bundling that to cartocss should be possible - and might be interesting for tilemill as well. regards Peter [1] https://github.com/gravitystorm/mapnik-legendary/blob/master/examples/openstreetmap-carto-legend.json Am 16.09.2013 14:53, schrieb Andy Allan: > On 16 September 2013 12:14, Peter Wendorff <wendo...@uni-paderborn.de> wrote: > >> as far as I know all map keys are created by hand. > > I think that's true, and therefore somewhat tedious! > >> 2) it would be really great to have some automatic map key generation >> out of the style files. For Mapnik that's incredible ugly as mapnik does >> not have any semantic connection between e.g. highway casing, fill and >> label. For CartoCSS (which is used since a while for the default style) >> this might be possible in parts. > > I don't think it's particularly feasible - the definitions for all the > symbolizers that make up a zoom level 17 trunk bridge are spread > around a fair amount, and so you'd need a "CartoCSS-complete" parser > to figure out what symbolizers apply to a feature, and then a > "mapnik-complete" rendering engine to ensure that the symbolizer > attributes are accurately reflected in the legend images. Which is > why... > >> In any case it would require additional information like which label to >> use for a particular feature in the map key, which items should NOT be >> displayed (as Tom mentioned) or in which order items should be displayed. > > ... I've been developing something that does this. It takes a > legend.json file which describes what features should be drawn (and in > what order, what description to use, which geometries etc) and spits > out a series of mapnik renderings for each feature. It's still very, > very alpha quality but it's available at > > https://github.com/gravitystorm/mapnik-legendary > > I aim to make it configurable enough to recreate what we have at the > moment, and to make it easy/feasible for me to create legends for my > other styles, and to add more functionality like sprite images. The > ultimate goal is to be able to create legends like the Ordnance survey > have - for those not familiar with them, have a look at > https://github.com/gravitystorm/mapnik-legendary and check out the way > that the railway crossings in the 1:25,000 or water features in the > 1:50,000 maps are shown for some inspiration. > > Overall, I have no intention of manually updating the legend that we > have at the moment. If anyone wants to take it on then feel free, but > my efforts are going into mapnik-legendary > > Cheers, > Andy > _______________________________________________ dev mailing list dev@openstreetmap.org https://lists.openstreetmap.org/listinfo/dev
