I have in the past explained on several occasions that the free and open-source software (FOSS) tools available to map designers developing rules for automatically rendered maps are severely lacking and that it would be of high importance for the OSM community to invest strategically in that field because commercial map providers develop tools for fairly narrow short term needs and focus very strongly on technical aspects and have little interest in substantial innovation in actual map design.
But i have never actually explained more in detail what the concrete needs of state-of-the-art rule based map design are regarding tools to be able to produce innovative and high quality maps. The main reason for that is that this is not something you can put into a simple list of requirements a software developer can work through and then ends up with a product that meets the requirements. Most of the needs i will list below are matters that require an in depth discussion between designers and software engineers with a solid background in computer graphics and an open mind towards the work of map designers. Me trying to provide a concise summary of some of the main requirements below is not a substitute for such discussion – although i will try to provide some hints to examples that can help initiating a more in depth contemplation.
The other reason i have been hesitant in discussing this in public is that the most likely practical beneficiaries of such discussion are proprietary software developers. Professional FOSS development in the field of map rendering seems unfortunately very focused on the already mentioned commercial map providers (understandably, because that is what at the moment largely pays for their work) and is fairly detached from the world of actual map design. The vast majority of actual innovation in FOSS tools for map design of the last 5-10 years has happened not by professional software developers but by map designers trying to address their specific needs on their own. Most of these attempts are fairly awkward, too specialized and of low technical quality because most map designers of course lack the software development skills to produce something more solid.
I like to emphasize that this list of requirements is not meant to be complete in any way. Map design is a highly diverse field and my personal areas of focus in map design work of course influence the priorities i see. Other map designers will have additional needs that i do not discuss here. At the same time i tried to keep this limited to clear needs and left out out stuff that would be just nice to have or things that would be worth exploring as potential technical innovations without there being a clear practical necessity visible so far.
I also left out any specific higher level feature requirements for the renderer. I did that because (a) such a list would be highly specific to the design use cases you have in mind and (b) higher level feature can be built directly into the renderer or they could be implemented by the users based on more fundamental drawing functions and a flexible and efficient framework for defining rendering rules. Bottom line: High level rendering features are not strictly required at all. They can, but they do not have to be, an integrated part of a well usable map rendering framework.
I also like to emphasize that this only covers map design in a strict sense. Many map providers these days regard their business as providing an overall map viewing experience with interactivity and integration with other services in the foreground. This is often the most important selling point, not the quality of the map design used. This whole domain i deliberately do not cover.
So here is the list of what – from my perspective – rule based map design requires from the tools it uses to be innovative and produce high quality maps:
- A rendering engine capable of precision rendering. In other words: The rendering engine should faithfully execute the instructions of the map designer on how to draw things. I had previously analyzed a number of rendering engines in that regard in a rudimentary fashion. So far Mapnik (and maybe Mapserver) are the only practically usable map rendering engines that come close to meeting this requirement.
- A map design centered language/file format allowing the map designer to implement their map rendering rules in a way that matches their work and thought process and that scales well with design complexity. The interpreters of this language/file format should support the full feature set of the rendering engine. CartoCSS was fairly revolutionary w.r.t. being map design centered. At least in the form supported by Carto it has, however, only very rudimentary options for the parametrization of design rules and only very limited modularization and code reuse options and therefore is not that well suitable for more complex map design work. And Carto does not support the full feature set of Mapnik. Examples exist in the broader field of graphics design that can provide valuable cues – i for example like to point at POV-SDL, which supports both geometric modeling and defining styling together in a design centered language (for the most part – user defined functions, which were a late addition, are not particularly well usable for designers).
- Practically usable means to define scale dependent precision geometry processing. Practical use cases for this can be found in the AC-Style (like trees, water barriers, fords). Support for this is excellent in the OSM-Carto toolchain but completely lacking in any of the client side rendered frameworks. Even more: This is practically not feasible to add there because the inevitable lossy geometry data compression makes client side precision geometry processing impossible and scale dependent geometry processing on the server side would lead to massive increases of the data volume.
- The ability to define drawing order independent of the way the data is structured. This is currently not possible with Mapnik without unifying all the involved data into a single layer (as done in the AC-Style for the road layers). This is one of the main hard limits of all Mapnik based toolchains.
- The design rules should have access to detailed information on what has been drawn in the map so far. Currently this is limited to simple blocking in most map rendering frameworks, meaning that you can draw something independent of what has been drawn before or you only allow it to be drawn if no other blocking feature has been drawn before at the same location.
- The ability to define drawing order independent of the prioritization of competing elements. Classic example where this is needed is contour line labeling: Contour line labels typically have the lowest priority of all labels and are not to be placed overlapping most of the other features in a map (including line work like roads, water lines etc.) At the same time contour line labels are traditionally cut out from the contour lines with a buffer for good readability and harmonic integration into the map. And the contour lines are drawn below almost everything else in the map. Doing this (drawing the contour lines early but cutting out the low priority labels) is not possible with most automated map rendering frameworks available these days so you will practically not see contour line labels with cutouts in such maps (with very few exceptions).
- Flexible raster compositioning options in the rendering engine. Mapnik has rudimentary support for that (feature and layer based compositioning of the current feature/layer relative to what has been drawn so far). More flexibility here would be very important, in particular regarding rendering performance, because it would reduce the need for expensive geometry processing and for drawing features several times and it would practically allow developing solutions for problems that are currently not solvable in an efficient way (like the road line/polygon layering issue). Cues for this could be taken from common raster processing frameworks like ImageMagick and G’MIC.
- A data processing chain that provides access to the full data model of the source data to the map designer. This has so far not been the case for the OSM-Carto tool chain for OSM data because osm2pgsql only supported multipolygon and route relations and only in a rudimentary way (without exposing relation membership information). The osm2pgsql flex backend improved this a lot though.
- A text rendering engine that provides information on the would-be geometry of labels in the design rules without actually placing the label in the map.
- The practical possibility to do automated integration testing of the full rendering tool chain (from the raw source data to the final raster image).
The list is roughly sorted by importance with the most important requirements on top. The first three points i regard as essential. Without meeting these points at least in a rudimentary fashion the map design work i do is practically impossible. That is the main reason why so far i have very little interest in working with any of the client side map rendering frameworks that are popular these days – because they substantially lack in all three of these points without a clear perspective of improvement in any of them.