Imagico.de

blog

More map symbols
More map symbols

More map symbols

| 11 Comments

In addition to the point barrier symbols i also re-designed and extended quite a few of the existing symbols in the style for human built structures of all kinds.

Starting point was that i wanted to port back some of the changes in OSM-Carto that happened after i created the AC-Style. But i did not want to use these designs as is. Instead i wanted to re-evaluate the design decisions made in the process.

Waste and recycling

First part is the display of waste/recycling related features. OSM-Carto uses three different symbols here – for amenity=recycling, amenity=waste_disposal and amenity=waste_basket:

Waste and recycling related symbols in OSM-Carto - link goes to double resolution rendering

Waste and recycling related symbols in OSM-Carto – link goes to double resolution rendering

This approach has a number of issues:

  • amenity=recycling is used for a large number of different recycling related facilities of very different size and scope. Showing them all with the same symbol is not a very good approach.
  • Differentiating amenity=waste_disposal and amenity=waste_basket through generic waste bucket symbols of different size is not very intuitive. Map users will often not see both together and when seeing just one of them you don’t have the necessary context to interpret the size of the symbol as it is meant.
  • The recycling symbol is poorly readable at normal resolution
  • The lid of the waste_disposal symbol is oddly far from the bucket
  • The choice of different colors for recycling and waste_disposal/waste_basket is not intuitively understandable
  • The display of access restricted variants is not very consistent

Here is the new design schema i have developed now:

New design schema for waste and recycling related features in the AC-Style

New design schema for waste and recycling related features in the AC-Style

Concrete changes are in particular:

  • uniform color for all symbols
  • new design for amenity=waste_disposal and amenity=recycling + recycling_type=container. This depicts a classic movable waste container with wheels and hinged/sliding cover. Of course design of recycling containers varies but the basic wheeled waste container is probably known very widely and facilitates a clear intuitive distinction form amenity=waste_basket.
  • re-designed recycling symbol for better readability at small sizes
  • distinct symbols for generic amenity=recycling and amenity=recycling + recycling_type=centre
  • more harmonic lid gap size on amenity=waste_disposal and amenity=waste_basket

Towers and masts

Towers and masts in OSM-Carto already use a systematic symbol design to visualize the different variants of construction and purpose. But this set of designs has substantial gaps. More advanced in that regard is the Röntgen icon set by Sergey Vartanov – which partly served as inspiration for the work presented here.

For better understanding: The difference between man_made=mast and man_made=tower is not completely agreed on in OpenStreetMap. As a rule of thumb: A structure that qualifies as a building (i.e. that has a human walk-able inside) is generally a tower. So is a structure that has integrated steps to walk up. Something that can only be climbed up tends to be a mast.

Here is the set of designs i use for man_made=mast:

Rendering variants of man_made=mast based on tower:type and tower:construction

Rendering variants of man_made=mast based on tower:type and tower:construction

In terms of construction that includes the four main variants (with guyed_tube being the least common). In terms of function i added designs for radar and siren.

For man_made=tower the set of symbols is more extensive:

Rendering variants of man_made=tower based on tower:type and tower:construction

Rendering variants of man_made=tower based on tower:type and tower:construction

For the main functional types (observation, communication, lighting, radar and siren) there are now distinct variants for all the main construction types – as far as they are sensible combinations. And i added rendering of tower:type=minaret.

As additional detail i introduced depiction of roof:shape to bell towers. This might be considered too detailed semantically – but it is a good demonstration how subtle design differences can be used to transport additional information.

roof:shape based variants of bell tower depiction - with lattice construction on bottom and other constructions (including none specified) on top

roof:shape based variants of bell tower depiction – with lattice construction on bottom and other constructions (including none specified) on top

Symbol abstraction levels

With the tower symbols you can also see that i moved the design of some of the symbols away from the solid color paradigm in OSM-Carto to a shaded depiction. Original motivation was that the OSM-Carto symbols are too variable in visual weight – leading to the heavier symbol appearing as more important in the map than the lighter ones (without there being a good reason for that).

Substantially different visual weights of symbols in OSM-Carto

Substantially different visual weights of symbols in OSM-Carto

The other reason is that the symbol design paradigm of OSM-Carto currently puts a strong emphasis on geometric clarity and simplicity of shape – up to the point that the level of abstraction severely affects intuitive understanding. Adding shading to the symbol design, limiting the level of abstraction and allowing sub-pixel details to be used where helpful can aid substantially in resolving visual ambiguities and communicating additional information in very limited space. This of course increases the demands on symbol design work.

Shading is implemented without transparency using half-toning techniques.

Half-toning patterns to implement shading effects in single color symbols

Half-toning patterns to implement shading effects in single color symbols

Other engineered structures

Here are a number of further new symbol design either newly added or as replacement for existing symbols:

Various re-designed and added symbols for engineered structures

Various re-designed and added symbols for engineered structures

The non-solid, shaded symbol designs also give room to illustrate substances stored/processed by a feature through the use of color. This has to be done carefully because color is already used for differentiating different broader categories of symbol so adding more use of color in point symbols can severely reduce map readability.

Storage infrastructure symbols with different substances indicated by color

Storage infrastructure symbols with different substances/content indicated by color (with industrial background color)

Cranes are shown in different designs depending on crane:type:

Symbol variants for different crane types

And lighthouses are, by default, rendered without the light visualization – that is only shown with the appropriate seamark tags. And for non-continuous lights a subtle variation is used.

Variation of lighthouse rendering depending on seamark tagging

Variation of lighthouse rendering depending on seamark tagging

Petroleum wells

I also added display of petroleum wells (man_made=petroleum_well) in a design derived from that of water wells. Wells tagged with pump=yes are shown with a traditional oil pump symbol. Disused wells get a symbol variation and substance (oil or gas) is differentiated by use of color.

Petroleum wells - how they are shown depending on different secondary attributes

Petroleum wells – how they are shown depending on different secondary attributes

Planters

In terms of less technical features i added rendering of man_made=planter for both nodes and polygons:

Rendering of man_made=planter - mapped with node or polygon

Rendering of man_made=planter – mapped with node or polygon

The design for polygon is derived from that of retaining walls and is simplified for small geometries. In addition, i show a hint of a shadow towards the bottom right to show the elevated nature of the feature.

Benches

I am going to close this list of new symbol designs with another one i had already developed some time ago – a new design for benches.

Benches are rendered in OSM-Carto at z19 with a uniform symbol. I extended this both in terms of zoom levels and in terms of differentiation based on additional attributes – and with support for amenity=lounger in addition.

Rendering of benches at z20 - link goes to double resolution version

Rendering of benches at z20 – link goes to double resolution version – z19, z18

At z18 the benches are all shown with a uniform symbol just like on OSM-Carto – but significantly smaller. This is recognizable – yet small enough to not overcrowd the map at z18 in most cases. At z19, benches with backrest get differentiated – as well as loungers. They are still shown with a smaller symbol than in OSM-Carto. At z20 and above i then show the full size symbol with

  • three different symbols based on backrest=yes/no/unknown – the unknown design being inspired by Röntgen again.
  • heavier and less heavy symbols based on the material – stone, concrete and metal get the heavy design, wood and plastic the lighter one. This difference is very subtle to not limit the recognizability of the symbols to be the same type of feature in principle.

Real world examples

That were a lot of different symbols so i am not going to be able to demonstrate all of them in a real world context. So just a few select examples:

Planters and benches in Heidelberg, Germany at z18

Planters and benches in Heidelberg, Germany at z18

Water tanks on a farm in northern Italy at z18

Water tanks on a farm in northern Italy at z18

Cranes at the shore of Lago di Garda, northern Italy at z18

Cranes at the shore of Lago di Garda, northern Italy at z18

Harbor crane in Strasbourg, France at z17

Harbor crane in Strasbourg, France at z17

Water mill near Freiburg, Germany at z18

Water mill near Freiburg, Germany at z18

Benches in Lyon, France at z20

Benches in Lyon, France at z20

Silos in northern Italy at z19

Silos in northern Italy at z19

Petroleum well near Strasbourg at z18

Petroleum well near Strasbourg at z18

Discussion

I have presented here a large number of symbol design changes and additions. Many of them are not really revolutionary but rather simple. None the less i want – in summary – point out a number of patterns in those changes and lessons to be learned here.

Designing maps for a global audience is hard because many elements that are common in some part of the world are rare or even completely unknown in others. The most obvious example from what i presented above is the minarets. But there are other things where this applies as well – siren towers/masts or petroleum wells for example. Even something like a lighthouse will be familiar to people in coastal settings while fairly unknown for those living far away from the coast. Developing a good design for those depends on real world familiarity with the various settings where these things occur. That is why a map design project with global scope heavily depends on designers with diverse geographic and cultural backgrounds and familiarity with the global geography. While OSM-Carto aims in that direction i think i have demonstrated here a bit – in the past as well as in this post – how much the choices in OSM-Carto still reflect an urban/near urban European/North American perspective. This is of course not fully the fault of OSM-Carto – mapping and tagging in OSM itself still has a similar bias.

OSM-Carto has struggled not only technically with handling a huge number of different point symbol classes. The approach to add – one by one – new primary feature classes, each with an independently developed design, had reached its limit quite some time ago. I had already shown a number of techniques that can be used to overcome this problem in the past (see links above). Methods demonstrated here are in particular:

  • Aiming for depth instead of breath in terms of feature classes shown. Having recognizable base designs for broader categories of features and using subtle variations of symbols to differentiate further helps a lot in keeping symbology intuitively readable.
  • Using smaller and simplified symbols at the lower zoom levels can help to avoid having too much noise in the map while maintaining the in depth differentiation at the higher zoom levels.
  • Carefully using color for secondary differentiation (here: substance/content in storage structures) can help transporting additional information.
  • Shading and sub-pixel design in symbols can improve readability and allows additional differentiation of symbols with limited space.

All the changes presented here can be found in the AC-Style now.

11 Comments

  1. Do you ever thought of doing a comparison on the impact in rendering times?

    • Well – the question is of course what to compare and with what purpose. Much of what i implemented in the AC-Style is slow, some things so slow they are non-feasible in a real time rendered map.

      What is discussed here – the point symbol rendering and the underlying framework – analyzing how well this scales with additional symbol classes is indeed something that would be interesting to look at. I had already added some optimization to the (script generated) queries. But this is technical details that are not a primary interest for me in my work on the AC-Style.

  2. It is striking that your views on OSM-Carto sometimes seem a bit frustrated.
    Without having too much to do with Carto, but you are a maintainer of the project, you obviously have good ideas and the necessary skills, so what is stopping you from implementing the ideas in Carto? Of course there is a lack of support from OSMF, but the OSMF in general has a lack of presence, money and strategy – and yet the community manages to make OSM better every day.

    • I have pointed out in other posts that the OSM Community in terms of map design is kind of squandering its potential at the moment because of various (technical, social and economic) factors. The differential between what me an other map designers demonstrate individually regarding what can be done map design wise with OSM data and what collective projects like OSM-Carto do (and can do) is a manifestation of this. I want to do my part in changing that from the social side (through communication, like in this blog post). But that can only ever be a support role. The OSM-Community needs to bring up the will and the ability to actually remove the obstacles.

      Me using the technical power i have as an OSM-Carto maintainer to selectively push for things as far as they are technically viable without substantial software development work would not only be questionable under the premises of the project, it would also be kind of pointless in the long terms, because (a) it would not address the most fundamental issues and (b) it would create a dependency of the OSM Community on me individually.

      • Ich suche seit vielen Jahren nach einem neuen technischen Betreuer für die Historic.place und bin dabei eben so erfolglos wie Sie bei Ihrem Einsatz für freie und quelloffene Werkzeuge für Kartendesigner, die substanzielle Innovationen im eigentlichen Kartendesign ermöglichen. Erfolgreich war ich im Gegensatz dazu bei der Anwerbung von weiteren Geodaten-Erfassern, auch wenn leider keiner sich zu einem Power-Mapper entwickelt hat.

        Nun sind die Voraussetzungen für die Betreuung eines aus Geodaten gespeisten Webangebotes oder für die Entwicklung einer Karten-Render-Toolchain deutlich höher als die zur Eingabe einer Imbissbude mit dem ID-Editor.

        Der Hauptunterschied ist jedoch, so denke ich, ein anderer: Der Geodaten-Erfasser arbeitet *für sich*, die Belohnung für die Eingabe der Imbissbude ist die Darstellung der Imbissbude in der Karte.

        Warum aber sollte jemand eine weitere Render-Toolchain entwickeln (oder in meinem Fall die Filterung von OSM-Daten für eine Themenkarte überarbeiten)? Die bisherigen Tools sind entstanden, weil jemand ein eigenes Interesse an den erzeugten Karten hatte. Und diese Karten sind mittlerweile – auch durch Ihre Arbeit – ziemlich gut. Auf jeden Fall *gut genug* aus der Sicht der Mehrzahl der Nutzer.

        Was zum Nachteil wird (das Gute ist der Feind des Besseren): denn es ist ein sehr hoher Aufwand für neue Tools erforderlich; dem steht aber nur eine graduelle Verbesserung des erzeugten Produktes „Karte“ entgegen. Die meisten Kartennutzer werden die Änderung überhaupt nicht wahrnehmen, geschweige denn diesen einen Wert zumessen. Niemand zahlt (im weitesten Sinne) für eine Verbesserung von etwas, das schon gut genug war.

        Und wenn doch jemand eine schöne Karte bewundert (wie ich andernorts schrieb: mit auf Gletschern blauen Höhenlinien, die Straßen senkrecht queren, und Pfaden, die nicht durch Baumsymbole führen), ist es der Kartendesigner, der Ruhm und Ehre einheimst und für die Bewerbung des eigenen Unternehmens nutzen kann, nicht der Erbauer der Tools.

        Anders als eine Routing-Engine, die Sie an GLS vermieten oder an Tesla verhökern können, bietet eine neue Render-Engine auch keine Möglichkeit zur wirtschaftlichen Nutzung. Ein Anbieter von damit gerenderten Tiles wird eher nicht den Tool-Erbauer an den Einnahmen beteiligen. Ist ja Open Source.

        Langer Schreibe kurzer Sinn: Die Aufgabe, die Sie zu vergeben haben, ist für die meisten unattraktiv; lohnend ist sie nur für denjenigen, den die damit erzeugten besseren Karten persönlich interessieren. Und das sind Sie. Damit wird, so meine Befürchtung, diese Aufgabe an Ihnen hängen bleiben.

        So wie die Überarbeitung der technischen Basis der Historic.place an mir.

        • Und wenn doch jemand eine schöne Karte bewundert (wie ich andernorts schrieb: mit auf Gletschern blauen Höhenlinien, die Straßen senkrecht queren, und Pfaden, die nicht durch Baumsymbole führen), ist es der Kartendesigner, der Ruhm und Ehre einheimst und für die Bewerbung des eigenen Unternehmens nutzen kann, nicht der Erbauer der Tools.

          Da ist meine Beobachtung genau anders herum. Und ich würde so weit gehen, dass ich kein einziges Beispiel kenne, wo im Bereich digitaler regelbasierter Kartengestaltung dem Gestalter Ruhm und Ehre zu Teil wird, während die digitalen Werkzeuge, mit denen die Gestaltungs-Arbeit erfolgt ist, unerwähnt bleiben. Es ist ja fast schon ein running gag, dass OSM-Carto im allgemeinen Sprachgebrauch von Karten-Nutzern oft mit ‘Mapnik’ betitelt wird. Regelmäßig werden irgendwelche Karten-Apps gehypt, während die Gestalter der Karten in diesen Apps nirgendwo Erwähnung finden. Mich würden natürlich Beispiele interessieren, wo das auch nur Ansatzweise andersherum ist.

          Und die Idee von den notleidenden Open-Source-Entwicklern finde ich hier dann doch ein bisschen lächerlich, Nicht nur, dass viele Open-Source-Projekte, gerade auch im Bereich Geodaten-Verarbeitung, direkt von Unternehmen gesponsert werden, da werden auch gerade erhebliche Mengen an öffentlichen Geldern auf die Straße geschmissen (z.B. Prototype Fund, Sovereign Tech Fund). Im Vergleich sieht das bei offenen Design-Projekten eher düster aus, insbesondere, wenn diese (wie bei kooperativer regelbasierter Kartengestaltung wie OSM-Carto) für klassische Kunst-Förderung praktisch nicht in Frage kommen.

          • viele Open-Source-Projekte, gerade auch im Bereich Geodaten-Verarbeitung, direkt von Unternehmen gesponsert

            werden auch gerade erhebliche Mengen an öffentlichen Geldern auf die Straße geschmissen

            Damit sind Sie in einer besseren Position als ich: Sie können Fördergelder beantragen und einen Programmierer einstellen, der ihre neue Toolchain programmiert.

            Ein Skript zum Preprocessing von OSM-Daten für eine Themenkarte werde ich dagegen mangels allgemeinem Interesse wohl kaum gefördert bekommen. 🙄

          • Natürlich könnte ich theoretisch ein Software-Entwicklungs-Unternehmen gründen und etwas in der Richtung entwickeln. Das steht jedoch im Widerspruch zur Idee einer hoch entwickelten arbeitsteiligen Gesellschaft. Wenn die einzige Möglichkeit in der OSM-Community zur Kartengestaltung auf einem Niveau, welches konkurrenzfähig zur Entwicklung außerhalb von OSM ist, darin besteht, dass man gleichzeitig Karten-Designer und Softwareentwickler auf Weltklasse-Niveau ist, dann bleibt die OSM-Community zwangsläufig hinter den Teilen unserer Gesellschaft zurück, wo Arbeitsteilung funktioniert.

          • > dann bleibt die OSM-Community zwangsläufig hinter den Teilen unserer Gesellschaft zurück, wo Arbeitsteilung funktioniert

            Ja, leider. OSM hat die besten Zeiten hinter sich und ist jetzt „der billige Jakob“ für Geobasisdaten.🙄

            (OT: Es wäre gesünder, wenn mir das völlig egal wäre; nur nagt da die Wehmut, die Erinnerungen an die besseren Zeiten.)

  3. Pingback: weeklyOSM 746 – weekly – semanario – hebdo – 週刊 – týdeník – Wochennotiz – 주간 – tygodnik

  4. A minor remark: I don’t see the added value for +offshore=yes, as the location shows if it’s offshore or not.
    Nevertheless, a lot of improvments.

Leave a Reply

Required fields are marked *.



By submitting your comment you agree to the privacy policy and agree to the information you provide (except for the email address) to be published on this blog.