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.
September 17, 2023 at 22:44
Ich sehe gerade, dass Ihr Beitrag “Why it is essential for the OpenStreetMap community to actively pursue map design innovation” bereits fast zwei Jahre alt ist. Getan hat sich in dieser Zeit offensichtlich nicht viel. Was mich zu der Frage bringt:
Hat überhaupt eine signifikante Menge von Menschen ein Interesse an schönen Karten?
Die wunderschönen noch handgestichelten Karten des Alpenvereins sind Geschichte, sie wurden von „topografische“ Karten der Landesvermessung abgelöst; ein ähnliches Schicksal ereilt gerade die Swisstopo.
Kann es sein, dass einfach die Zeit der schönen Karten zu Ende geht? Dass nur noch ein paar alten Hanseln (wie z. B. mir) das Herz aufgeht beim Betrachten eines kartografischen Meisterwerks?
Den Aufwand der von Ihnen skizzierten Render-Engine dürfte ans Sechsstellige reichen; und da stellt sich nicht nur die Frage, wie das überhaupt zu stemmen wäre, sondern auch, ob das die dringendste Baustelle im OSM-Projekt ist oder überhaupt eine dringende?
Gruß W.
September 18, 2023 at 01:07
Was man immer im Auge behalten sollte ist, dass historisch betrachtet Kartenproduktion niemals ein in größerem Umfang wirtschaftlich gewinnorientiertes Metier war. Investitionen in Kartengestaltung erfolgten eigentlich immer aus einer von zwei Richtungen: Von staatlicher Seite aus politischen Überlegungen heraus oder, wie bei nicht kommerzieller Kunst ganz generell, aus der Gesellschaft heraus aufgrund individueller Bedürfnisse und Interessen oder Idealismus. Kommerzielle Aktivitäten waren – wenn sie denn existierten – eigentlich immer an einen dieser beiden Bereiche angehängt. So etwas wie eine sich von Grund auf wirtschaftlich selbst tragende kommerzielle Kartographie gab es nie und gibt es nach wie vor nicht. Heutige kommerzielle Kartendienste verwenden entweder OpenStreetMap-Daten oder nutzen (und sind damit indirekt subventioniert durch) staatlich erhobene und finanzierte Geodaten.
Dass die staatliche, politisch motivierte Komponente seit vielen Jahren und praktisch weltweit im Rückgang begriffen ist, ist ziemlich offensichtlich. Dass die andere Säule, getragen durch kulturelle Bedürfnisse und Interessen aus der Gesellschaft, ebenso abbaut, kann ich jedoch nicht bestätigen. Meine Beobachtung ist, dass ganz im Gegenteil das Interesse, und ich meiner hier gerade auch das anspruchsvolle, tiefer gehende und kritische Interesse an qualitativ hochwertigen Karten, deutlich zugenommen hat. Und zwar sowohl das passive Interesse von reinen Karten-Nutzern als auch das aktive Interesse, selbst Karten zu gestalten. Die Existenz von OpenStreetMap ist ein Ergebnis dieser Entwicklung.
Vor dem Hintergrund entbehrt es natürlich nicht einer gewissen Ironie, dass so viele im OSM-Umfeld denken, dass Kartengestaltung schlicht nicht zum Projekt gehört. Noch viel bedenklicher ist es aber, wenn als Argument angeführt wird, dass es dringenderes gibt. Mit dem Argument lässt sich jede Investition in Kunst und Kultur zurückweisen.
Ich denke nicht, dass der in der öffentlichen Kommunikation in OpenStreetMap oft dominierende Mangel an Wertschätzung für Kartengestaltung und ihre Bedeutung für das Projekt repräsentativ ist für die OSM-Community als Ganzes. Sehr oft, wenn ich mit Leuten aus der OSM-Community mit einem nicht technischen persönlichen Hintergrund spreche, kann ich ein großes Interesse an und oft auch eine erstaunlich tiefe Kenntnis von Karten beobachten. Was oft fehlt ist eine Wahrnehmung davon, was die Schwierigkeiten bei der Gestaltung einer qualitativ hochwertigen automatich-regelbasierten Karte ist. Das hat aber vor allem etwas damit zu tun, dass die Praxis der regelbasierten Kartengestaltung für viele Leute sehr unzugänglich und unverständlich ist (was wiederum zu erheblichen Teil an den zur Verfügung stehenden Werkzeugen liegt). Mangelndes Interesse an Karten ganz Allgemein ist hingegen ziemlich klar nicht das Problem. Sehr viele Leute kommen zu OpenStreetMap, weil sie sich für Karten interessieren, und nicht nur für Vermessung. Für dieses Interesse finden sie in OpenStreetMap jedoch kaum einen ernsthaften Resonanzboden. Das ist eine unglaubliche Vergeudung von Potential.
September 19, 2023 at 17:49
This was a very interesting post and I was pointed here by someone on the OSM slack, specifically a MapLibre channel.
The map production and display pipeline has been on my mind lately as my company was contracted to run an upgrade of the MapLibre Native toolkit. It’s going well and now we’re considering what’s next.
Is this sort of thing next? Probably not. I’m not hearing much appetite for it, though as part of our effort we’re hoping to make it easier to modify this particular map client toolkit in the future. Perhaps that will help.
If there were the urge (and the money) to build a cartographically correct moving map, as it were, I think the low level mobile technology is now widely available. Web probably too.
We’ve done some of these individual features in the past for aviation maps. They often have very specific requirements that you can’t easily get around and so force some of this. It would be interesting to do more.
In any case, it’s great to see someone is thinking about it.
September 19, 2023 at 20:06
Thanks for the comment.
I like to confirm and emphasize one of the the things you say: The low level technological foundations are not an issue. The basic building blocks of what is technically needed to serve the needs of map design as sketched in my ten points exist and are well researched and tested in the realm of computer graphics and computer science in general. I hinted at that previously in my analysis of the basic polygon rendering quality of various frameworks – the deficits observed there would have already generated a sigh with CG professionals back in the days when i was at university.
And that might actually be part of the problem. For software development working on something technologically new and edgy is understandably often more attractive than investing time and energy into a solid implementation of something that – technically speaking – is rather boring for the most part.
September 20, 2023 at 02:42
Erstmal Danke für die ausführliche Antwort.
> Meine Beobachtung ist, dass ganz im Gegenteil das Interesse, und ich meiner hier gerade auch das anspruchsvolle, tiefer gehende und kritische Interesse an qualitativ hochwertigen Karten, deutlich zugenommen hat. Und zwar sowohl das passive Interesse von reinen Karten-Nutzern als auch das aktive Interesse, selbst Karten zu gestalten. Die Existenz von OpenStreetMap ist ein Ergebnis dieser Entwicklung.
Da bin ich wohl in die Blasenfalle getappt. Mein Umfeld ist sehr technisch, und da interessiert vor allem, *was* in der Karte drin ist, und weniger, wie es aussieht. Mit der OpenTopoMap und OsmAnd sind wir schon weitgehend zufrieden.
> Vor dem Hintergrund entbehrt es natürlich nicht einer gewissen Ironie, dass so viele im OSM-Umfeld denken, dass Kartengestaltung schlicht nicht zum Projekt gehört.
Es wird sehr regelmäßig und ausgesprochen lautstark so verlautbart:
OpenStreetMap ist eine Datenbank und keine Karte.™ (*omm*)
> Noch viel bedenklicher ist es aber, wenn als Argument angeführt wird, dass es dringenderes gibt. Mit dem Argument lässt sich jede Investition in Kunst und Kultur zurückweisen.
Bitte seien Sie über das „dringenderes“ nicht verärgert. Ich sehe einfach, dass die Entwicklungs-Kapazitäten im Umfeld von OSM doch sehr begrenzt sind. Ideen gibt es reichlich, Macher zu wenige. Da muss man über Prioritäten nachdenken.
Die Alpenvereinskarte malt Höhenlinien auf Gletschern blau, lässt sie Straßen *senkrecht* und nicht diagonal queren, und Pfade führen nicht durch Baumsymbole durch. Das sieht schon toll aus (so wie Ihre Furten) – nur würde ich nicht Wochen darin investieren wollen, das nachzubauen.
> Ich denke nicht, dass der in der öffentlichen Kommunikation in OpenStreetMap oft dominierende Mangel an Wertschätzung für Kartengestaltung und ihre Bedeutung für das Projekt repräsentativ ist für die OSM-Community als Ganzes.
Ihren Wunsch nach einem (möglichst auch für Laien brauchbaren) leistungsfähigen Werkzeuges zu regelbasierten Kartengestaltung verstehe ich natürlich. Was ich aber nicht verstehe: warum hätte ein solches Werkzeug und damit erstellte Karten eine größere Bedeutung *für das OSM-Projekt*? Denn zum einen wäre ein vernünftig gemachtes Werkzeug nicht auf die Verarbeitung von OSM-Daten begrenzt, sondern würde auch Daten der Vermessungsverwaltung verarbeiten. Und zum anderen würden damit aus OSM-Daten gestaltete Karten es wegen der hohen Anforderungen eh nicht auf die OSM-Startseite schaffen, blieben also praktisch unsichtbar.
> Was oft fehlt ist eine Wahrnehmung davon, was die Schwierigkeiten bei der Gestaltung einer qualitativ hochwertigen automatich-regelbasierten Karte ist. Das hat aber vor allem etwas damit zu tun, dass die Praxis der regelbasierten Kartengestaltung für viele Leute sehr unzugänglich und unverständlich ist (was wiederum zu erheblichen Teil an den zur Verfügung stehenden Werkzeugen liegt).
> For software development working on something technologically new and edgy is understandably often more attractive than investing time and energy into a solid implementation of something that – technically speaking – is rather boring for the most part.
Die leidige Sache mit den Prioritäten … wofür es weder intrinsische noch extrinsische Belohnung gibt, das wird halt nicht gemacht. :-/
September 20, 2023 at 11:11
Ich möchte hier zwei Missverständnisse rausgreifen und klarstellen. Erstens:
ist nicht das selbe wie
Zu der Beziehung zwischen Kartengestaltung und Mapping in OpenStreetMap hab ich auch in der Vergangenheit bereits geschrieben.
Zweiter Punkt:
“für Laien brauchbar” ist hier nicht das Ziel, ganz im Gegenteil. Ein großer Teil des Problems ist es ja gerade, dass viele Laien in Bezug auf Kartengestaltung den Bedarf nicht sehen. Um es ganz plakativ auszudrücken: Die Zahl der Leute, die die von mir als wünschenswert skizzierten Möglichkeiten tatsächlich für die Gestaltung innovativer und hochwertiger Karten produktiv nutzen könnten ist derzeit klein im Vergleich zur Zahl der Leute, die im Prinzip die Fähigkeiten hätten, diese Möglichkeiten als Software-Entwickler bereitzustellen. Aber wie gesagt: Das Potential an Leuten, die zwar noch nicht die Erfahrungen und Kenntnisse in der Kartengestaltung haben (also Laien sind), die aber das Interesse und das Talent mitbringen, sich diese Fähigkeiten zu erarbeiten (so sie denn die technischen Möglichkeiten haben), ist enorm. Solche Leute brauchen keine für Laien brauchbaren Werkzeuge, sie brauchen Mittel und Wege, ihre gestalterischen Ideen und Ambitionen tatsächlich umsetzen zu können, ohne sich bereits nach einigen Wochen mit der ersten harten Grenze von dem, was technisch nicht geht, konfrontiert zu sehen.
September 21, 2023 at 06:44
I wonder what do you think of MapCSS? 🙂
September 21, 2023 at 10:36
MapCSS is interesting in particular because it has not been designed for a specific rendering engine but generically on the drawing board so to speak. I have so far not seen any more sophisticated map styles being implemented with MapCSS and most renderers seem to be either proprietary or unmaintained. I would classify MapCSS neither design centered nor tool developer centered, it is data centered. MapCSS is very closely tied to the low level OSM data model – which comes with two problems:
MapCSS tries to compensate for the latter in terms of tag reinterpretation by providing the possibility to set tags in MapCSS code – which is a concept somewhat difficult to wrap your head around. But beyond that it essentially limits map design to very directly depicting the OSM data on the lowest level. That makes it fairly attractive for use cases like in JOSM or overpass turbo but rather unattractive for actual maps.
MapCSS also seems underspecified regarding blocking of labels and symbols.