Hi, Thanks all for sharing your thought on this. I find this discussion very stimulating! Obviously each solution has some advantages and some disadvantages. Here are my comments on Martin's answer.
################################################################## Martin wrote: "I think we all agree that ultimately we want to have some kind of compatibility with SLD and/or Mapnik" I can understand the benefits of technical convergence. Still I do not fully agree. From my personal point of view, my aim is not to have a software compatible with Mapnik (usable only by expert users?), my aim is to let less advanced users easily define their graphic semiology, to bridge the gap between map makers and map users (one reason is that OSM data is so rich that you can do thousands of different custom maps). That's why I started working on a set of QGIS styles for OSM: I found it too difficult to rewrite quantumnik styles to fit my needs. In more general terms, the QGIS philosophy is somewhat different from Mapnik's. Mapnik is aimed for expert users who do not mind defining thousands of parameters in XML code. If I understood the aims of QGIS correctly, QGIS is also for intermediate users who need to understand how to use the software in a reasonable amount of time, and will use it predominantly with the mouse. Current osm.xml mapnik stylesheet has more than 7000 lines and about 640 filters. There are 35 filters for [highway] = 'secondary' alone; those 35 filters are in 7 different part of the osm.xml stylesheet. I suspect that only developers say that Mapnik and osm.xml files are easy to understand, use and modify. But QGIS should be useful for non-developers as well. Anyway, I believe that there is some compatibility between the symbol levels approach and the mapnik approach. The symbol layers are just a way to organize the superposition of layers (drawing order information is gathered in one place); the mapnik way is linear (order in file defines drawing order), but ultimately (during the actual rendering) both are translated into operations that follow the same logic. Thus it is possible to convert a stylesheet from one system to the other and vice versa. In terms of usability, I think symbol levels win: ----------------------------------- With symbol levels, rules are defined this way: rule 5: [highway] = 'secondary' or [highway] = 'secondary_link' - draw black road outline as layer 1 - draw orange road line as layer 12 ----------------------------------- Mapnik works this way: rule 17: [highway] = 'secondary' or [highway] = 'secondary_link' - draw black road outline rule 18: [...] .... ... rule 313: [...] ... ... rule 314: [highway] = 'secondary' or [highway] = 'secondary_link' - draw orange road line ... ----------------------------------- There is a 1-to-n relationship between a feature and its symbol layers; this idea is simple and translates directly into the symbol levels system. Mapnik model is redundant: it has to repeat the rule for each symbol layer. (To make a comparison: in a relational database, this would be considered bad practice). My final comment on "we want to have some kind of compatibility with SLD and/or Mapnik": If Mapnik were the best ever possible renderer and if it would be possible (and easy!) to achieve every imaginable graphical effect with it, then maybe it would be more efficient to build a quantumnik GUI to modify those stylesheets, and use the Mapnik renderer as the default QGIS renderer, instead of building a new renderer (or trying to modify the existing rule-based renderer to make it resemble mapnik). ################## "implement the "else" filter which is hard to achieve right now." My understanding is that a different type (but still useful) of "else" logic is achieved with "apply first matching rule". I described a useful extension to the "apply first matching rule" logic here: http://trac.osgeo.org/qgis/ticket/3222#comment:16 (see bullet 1. in comment:16: For each rule, let the user say whether (if this rule is matched) it should be the last rule tested) #################### "The only downside I see here is that the symbols which are going to be use the effect of overpainting - like the roads with outlines - have to be split to bottom and top layer and applied in two different styles. But I think that is a relatively low price given the advantages. Finally, there are not that many symbols that would need this effect." My experience with OSM data is quite different. I currently have about 70 rules for OSM linear features. More than half of them use 2 to 3 symbol levels with overpainting across features. So for me using overpainting is the rule, not the exception, if you want to have a beautiful rendering. (And it is not limited to road outlines). #################### Here are some additional comments and questions. 1. While designing the architecture, we should work with real cases: pick up a mapping problem (for instance a region with some OSM data) and see what kind of graphical effect we need there. Then, see which solutions allow to do this easily, and which do not. I followed this approach for the proposal I made here: http://trac.osgeo.org/qgis/ticket/3222#comment:16 2.There are two more things (related to this discussion) that I cannot do currently with QGIS; ideally future improvements should solve those: 2a- simply use the OSM "Layer" tag (roads above other roads, etc.): http://wiki.openstreetmap.org/wiki/Layer To do this, currently 11 layers for each feature type are needed. One solution could be to use symbol levels with a level modifier defined based on a field. The final symbol level could be defined as: (Layer+5)*1000+[original symbol level] (or simply Layer*1000+[original symbol level] if we accept negative levels or if the user modifies the Layer attribute first) For instance, all roads with 'Layer'='-5' would be rendered with symbol levels from 0 to 999. All roads with 'Layer'='0' would be rendered with symbol levels from 5000 to 5999. 2b- define symbol levels across feature layers (for instance: most linestrings should be ABOVE polygons, but some river linestrings should be BELOW lake and riverbanks polygons, while still being above forest polygons where relevant). Shapefiles cannot store heterogenous geometries but postgis and spatialite can. Still if I'm correct QGIS cannot take advantage of this yet. 3. An additional comment about the comparison with Mapnik: The slippy-map mapnik rendering of OSM shows results at a limited number of fixed scales. We want continuous zooming, so some of the problems we are facing are not major problems for OSM Mapnik. 4. Probably it is possible to learn a lot from Mapnik to improve current QGIS rendering. My question is: when shall this be available to the users? Could that be for QGIS 1.7? Maybe not if there are no clear answers on those questions so far. Still, today, with symbol levels, we can have quite nice results. I have uploaded a bigger example of rendering with symbol levels here: http://wiki.openstreetmap.org/wiki/QGIS (QGIS wiki is not responsive right now). Although not perfect, I believe it shows that QGIS could give fair enough rendering with symbol levels. Without symbol levels, we will probably not give QGIS users the opportunity to create "professional maps" using rule-based rendering, to use Martin words: On 23 February 2011 at 13:54 +0100, Martin Dobias wrote: > using 'symbol levels' [...] > produces a desirable effect if you are drawing roads with outlines as > seen in professional maps. When you start thinking about rendering > road maps with various types of crossings, the order becomes > more complex. Thanks for reading. Hope it helps! Best regards, Mayeul _______________________________________________ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer