Imagico.de

blog

Panorama des Doms von Münster

March 30, 2025
by chris
0 comments

FOSSGIS 2025 – Impressions

English version based on automatic translation with deepl.

The last few days I was at the FOSSGIS conference again for the first time since many years. And I would like to share a few impressions on various topics here.

Schloss Münster

Talk

I presented a talk on satellite image processing at the conference. You can watch the recording at CCC.

The association will probably publish the slides soon.

Satellite image topics that go beyond more or less standardized analytics (we extract some semantic information from the image and then work with it) are always quite exotic at FOSSGIS. I therefore tried to make the whole thing sufficiently easy to understand, which of course means that you can’t go into depth in 20 minutes. The presentation was well attended on site, but most of the feedback was initially – as you can expect at FOSSGIS – about the gaps in the capabilities of FOSS tools that I mentioned.

What is particularly interesting in this context is that it became clear in discussions as well as in various other presentations how much the funding of FOSS development is geared towards short-term immediate needs and how – especially in the area of basic tools such as GDAL – strategic investments are practically non-existent. I have often remarked on this in the context of OpenStreetMap in relation to map design. However, until now I had not realized how widespread this phenomenon is in the FOSS sector in general. But it is quite understandable. When Esri, for example, invests in the development of GDAL, it is not doing so in order to compete with its own products. The aim is more likely to be the same as with other sponsors: to cover immediate needs for its own products and services in the short term.

Against this background, my idea that there might be potential here for an economically viable cooperation between method development (what I do) and professional open source software development that makes these methods available to other users is perhaps somewhat naive. Because such a cooperation would of course only work economically in context of a strategic investment.

Aus dem Vortrag Verarbeitung offener Satellitendaten mit freier Software für die visuelle Anwendung

Cartography

I also attended a number of events at the conference on map design with QGIS and gained interesting insights into this world of interactive map design.

To understand the background: All of my map design work is based on a non-interactive work paradigm. I develop the rules for the design and the associated data processing in the form of rule descriptions in suitable languages (CartoCSS, PostgreSQL, various general scripting languages and structured file formats). Interactive work steps play a role practically exclusively in the design of image symbols. These design rules are then applied to generic geodata (in most cases OpenStreetMap data).

However, users of QGIS and similar tools work in a completely different way. The usual working paradigm there is based on the first-generation digitization approach that has taken place in many areas of work – including cartography: You transfer the pre-digital workflows one-to-one into interactive digital steps. In the field of cartography, this approach has now been further developed to the extent that – at least partially – rule-based work is also possible, i.e. the processing steps carried out interactively can be automatically applied to changed source data. However, rule development is still done completely interactively via a graphical user interface, so you have to click together your map design with the mouse (or alternatively: control the whole thing completely via a programming interface). There still does not seem to be a representation of the design rules in text form designed for human reading and writing.

But of course there is a lot of overlap in problems and solutions between the two approaches. And it was interesting to see where the focus is currently being placed in the QGIS area.

What I found remarkable was how great the desire seems to be among QGIS users to have all solutions within QGIS. For example, a big topic seemed to be displaying charts in maps and what chart types and display forms are available within QGIS. For me, as a firm believer in the Unix philosophy, this seems rather absurd. There are already a lot of good and powerful tools for creating diagrams – also as open source. So why do you need such a function within QGIS? I have the impression that the focus on interactive operation plays a major role here. The user really wants to design the diagrams interactively – just like the rest of the map – and wants to do this with a user interface that is consistent with the rest of QGIS. Of course, this could also be implemented with external tools for creating diagrams, but would largely negate the benefits of modularization in line with the Unix philosophy.

Annual general meeting of the association

I would also like to mention the annual general meeting of the FOSSGIS association. The most important point here was that FOSSGIS wanted to obtain (and received) approval from its members to raise funds from OSM data users on behalf of OpenStreetMap Deutschland – planned in the form of so-called sponsoring memberships in the association without voting rights.

I don’t want to discuss the topic itself in depth here – that might be something for a separate blog post. However, it was interesting to note that I was the only one who did not vote in favor of the motion. This was despite the fact that there were critical questions about the idea at the meeting. I was approached very positively by several people after the meeting – partly in the form of them explaining their own critical perspective on the topic, partly out of active interest in the reasons for my cautious stance. Of course, the fact that I have not received any negative comments on this may simply be ghosting, but I would like to mention it explicitly here anyway, in case this helps others to develop the courage to openly not align with the dominant majority opinion in such cases.

The development and organization of the German-speaking and international OSM communities was, of course, a frequent topic of the conversations I had. And i noticed a relatively strong contrast in those exchanges. On the one hand, there were conversations based on an active interest in diverse perspectives on the OSM community – especially with various active members of FOSSGIS from the non-OSM sector who are interested in further developing the social structures in the association for better integration of the entire diversity of people that the association wants to represent.

On the other hand, I have also had conversations in which a critical perspective on existing structures was either generally rejected out of hand or I was denied the justification and qualification for a critical perspective as an outside observer.

So far, this is not really surprising and basically to be expected. What I find a pity, however, is that there hardly seems to be any nuance between the two. The value of a productive discourse arises precisely from the fact that different points of view and arguments are received sympathetically and then critically examined.

I do not have the impression that the benevolently open and tolerant attitude is being lost across the board in FOSSGIS – I think I have shown that with the descriptions of my discussions at this conference. But I do see the danger that, especially where short-term economic interests come to dominate, closed interest groups emerge that increasingly develop a categorical rejection of views and ideas that are perceived as jeopardize these interests.

Talk recommendations

I’ve only seen a selection of presentations on site – because at FOSSGIS there is always the very practical and reliable option of watching the presentations later on video. From this selection and from various conversations with other visitors, here is a selection of recommendations:

Harald Hartmann: Wie können OpenStreetMap und QGIS einen Wegewart unterstützen? (How can OpenStreetMap and QGIS support a route maintainer?)

The title may not sound so appealing, but it was one of the few OSM presentations at the conference that dealt with practical questions of the social benefits and social integration of OpenStreetMap without focusing on technical or economic aspects.

Roland Olbricht: Kinder, Karten, Open Source (Children, maps, open source)

Just like Harald’s presentation, refreshingly non-technical. And deals with a really important and interesting topic: how to introduce children to concepts of maps and geodata (and geography) and their practical use. What the talk lacks is a consideration of the wealth of experience of child-friendly cartography and geography didactics for children from even pre-digital times. But highly recommended for a first insight into the topic and to raise awareness.

Frederik Ramm: Overpass Turbo goes PostGIS

Not only practically appealing, but also a nice demonstration of how a small FOSS project can be started with practical benefits. Of course, it should also be critically noted that you first have to be able to afford the infrastructure for such a demo.

Falk Zscheile: Text und Data Mining in der OpenStreetMap-Datenbank aus rechtlicher Sicht (Text and data mining in the OpenStreetMap database from a legal perspective)

I haven’t seen this presentation myself yet, but I spoke to Falk about the topic. About a sub-topic from the spectrum of copyright and database law that many people don’t have on their radar.

Panorama des Dom von Münster

March 14, 2025
by chris
1 Comment

The Musaicum United States

I am happy to announce the availability of the next extension of my Musaicum satellite image mosaic series.

The Musaicum images are a series of regional satellite image mosaics based on Sentinel-2 data started in 2023 that are produced to a high quality standard. They offer unsurpassed quality in visual color depiction of Earth at this resolution range (10m) with a high degree of color consistency and an exceptionally low incidence of clouds.

The newly released image covers the United States of America – including Alaska, Hawaii and Puerto Rico.

The Musaicum United States – Contiguous United States

The Musaicum United States – Contiguous United States – click for larger version

The Musaicum United States – Alaska

The Musaicum United States – Alaska

The Musaicum United States – Puerto Rico

The Musaicum United States – Hawaii The Musaicum United States – Hawaii/Puerto Rico

This substantially extends the range of geographic settings the Musaicum process has been adjusted to and evaluated for. This includes, in particular, one of the most difficult areas outside the tropics regarding cloud free image assembly – the Aleutian islands. Accordingly, some small parts of the image use significantly older data (total range from 2016 to 2024). For most of the coverage area, exclusively image data from 2019-2024 is used though. Color calibration and uniformity have been further improved compared to the second generation mosaics (West Asia and North Atlantic Islands)

The Aleutian Islands

The Aleutian Islands

As already discussed with the North Atlantic Islands image, a shading compensated variant and a fractional vegetation data set are now routinely available for the same coverage area.


Mount Rainier, Washington (large: with shading as recorded, with shading compensation)


Musaicum United States vegetation map visualization

Musaicum United States vegetation map visualization

I produced plenty of sample images to allow you to explore the new image on the product page. If you are interested in using the Musaicum United States in your own projects please get in touch.

French Frigate Shoals, Hawaii

French Frigate Shoals, Hawaii

New York

New York

Zion Canyon, Utah

Zion Canyon, Utah

March 5, 2025
by chris
12 Comments

Knowledge retention and generational succession in OpenStreetMap

I wrote a comment today on the OSM-Carto issue tracker that i think should get some broader exposure:

As many know OSM-Carto has the most sophisticated system of road rendering of all operational OSM based maps. Its complexity allows us – more than most other map styles – to highlight and provide feedback on the semantic and structural details recorded in OSM data about roads. But it also creates a substantial barrier to contributors to the map style and makes any changes to road rendering a challenge.

In light of this, improving documentation of our road rendering system would be of immense value. Not only in the short term for OSM-Carto development, but also in the long term for the future of OpenStreetMap as a whole and for map design in general. There are only a hand full of people at the moment who have an in-depth understanding how road rendering in OSM-Carto works – and for most of them this is already historic knowledge (meaning: they are not active in CartoCSS/Mapnik map style development any more).

Unfortunately, those who would have the economic capacity to do so (companies using OSM data, academic institutions, to a lesser extent the OSMF) have shown no interest in investing in the historic memory of OpenStreetMap. And while we, in OSM-Carto, recognize the immense value of this knowledge for the future of OpenStreetMap and OSM based map design we, of course, lack the economic means to ensure this knowledge is preserved for future generations.

So, if anyone following this issue tracker has the means to support an endeavor to preserve the 1.5 decades of historic knowledge and map design experience around the development of OSM-Carto and to document how the most sophisticated operational OSM based map style works or has the means to lobby those who have these means to invest here, then please feel highly encouraged to become active here.

OpenStreetMap has meanwhile grown older than most digital social endeavors, while staying at least moderately healthy so far. But it has not yet survived a true generational succession. Many people from the early years of OpenStreetMap still cover key functions within the project.

For any community of people to be sustainable in the long term it has to accomplish two important things

  • be able to manage a true generational turnover
  • develop a balance between
    • the need to give new generations of community members the room and the ressources to develop beyond the horizon of the previous generations (and this way becoming capable of true evolutionary development)
    • the need to develop and maintain the collective wisdom and experience across generations (allowing for long term innovative advancement and a conscious selection of the evolutionary path)

The first point is a social matter, OpenStreetMap definitely struggles with the generational turnover. I discussed this in context of the OSMF in the past – where there are, in particular, a few influential people clinging to their influence. But accomplishing this also depends a lot on the balance described in the second point – which is not only a social question but also an intellectual and an economic challenge.

In the context of celebrating the birthday of OpenStreetMap, commenters have, in the past, often used metaphors of youth and coming of age. I think this might be the wrong perspective. In the fast moving digital world 20 years of age might be more like 40 or 60 years in terms of a human life.

Map design is a particularly good example for the challenges OpenStreetMap faces at this stage of its development in my opinion. Not only because it depends so much both on people with a broad perspective and much experience and – at the same time – on new approaches being tried and developed by unprejudiced minds. But also because, even during the short history of OpenStreetMap, we have had already various examples where substantial wisdom and knowledge was lost because those who carried that knowledge dropped out of the project without being given the space, the appreciation and the support that would have been needed to allow them to substantially pass it on (Osmarender and TopOSM just to mention two prominent cases). At the same time, young people with talent and interest in map design do not get the supportive environment they would need to develop their skills – as i have also pointed out in the past.

Some might say: What does it matter? Evolutionary development inherently involves failures and losses. Quite true. But OpenStreetMap does not exist in a vacuum. The world around us evolves as well. And i have doubts that OpenStreetMap can afford to retreat to its island and simply start over with every new generation of map designers.

The Musaicum North Atlantic Islands

February 6, 2025
by chris
1 Comment

The Musaicum North Atlantic Islands

After the larger regional Musaicum satellite image mosaics of Europe and West Asia this further extension of coverage of my Musaicum satellite image mosaic series probably does not look very significant. But it represents a milestone in several aspects i am going to explain here.

The Musaicum North Atlantic Islands

The Musaicum North Atlantic Islands – click for larger version

From past work on local mosaics of the area – Iceland, Jan Mayen and the Faroe Islands i knew that these are the hardest part of Europe as far as producing a quality image is concerned. The short summer season combined with high cloud incidence with very diverse cloud types in summer make this a challenge. That was partly the reason why i did not include these areas in the EU-Plus coverage in 2023 – because that would have meant spending an extraordinary amount of time to make it work in the desired quality back then.

Now, with an additional year worth of data available and the improvements meanwhile made to the assembly process i decided to give it a try. And the results are remarkably good.

Akureyri and North Iceland

Akureyri and North Iceland

Reykjavik

Reykjavik

Stress testing the process

I discussed the difference between classical mosaic production techniques and pixel statistics methods before. With pixel statistics methods you can rely on the simple rule that if you use more data the quality of your results will improve (all other things being equal of course) – if that is not the case the method used is flawed. The rate of convergence, i.e. how much the results improve from using more data, varies, but the very principle that it does is universal.

With classical mosaicing techniques this is not generally the same. Adding more source data will only improve the results when that data is better than the data you already have. Otherwise it is equally possible that the quality of the results will decrease. Avoiding that is one of the primary goals in developing mosaicing techniques.

The North Atlantic Islands are a good test case to evaluate that because you need a large number of source images to ensure that every part of the area is covered with decent quality data. Even if you have a largely cloud free summer image in some area (which is rare in many parts) that might feature fresh snow in the mountains for example (which is common in Iceland even in summer).

The results are quite decent in light of this – the cloud incidence in the mosaic is not measurably higher than in continental Europe and West Asia and the uniformity is good as well. And there is substantially less seasonal snow than in my older manually produced Landsat/Sentinel-2 mosaic.

Without shading and shadows

The other major improvement is about the additional layers generated in the Musaicum production process. I had introduced the shading compensated version of the mosaic already with the Europe image. This offers – as discussed there – substantially better results than the L2A data available from ESA. The process to produce this was adapted from methods previously used in local mosaics – discussed in 2019. But the handling of shadows left a lot to be desired so i spent some time in 2024 on improving these methods. This was already tested at scale in the production of the West Asia mosaic but i did not have the time back then to evaluate the results in more detail.

Again the North Atlantic Islands were a good test case for this because at high latitudes shadows in satellite images are more of a problem than at lower latitudes. The results can be seen here.

Mountains in southern Iceland with shading as recordedMountains in southern Iceland with shading compensation

Mountains in southern Iceland (large: with shading as recorded, with shading compensation)

Eastern Iceland with shading as recordedEastern Iceland with shading compensation

There is some degree of under-compensation of shading (which – at least for visual applications – is much preferable to over-compensation) and shadows are not always reliably detected (in particular shadows on wet snow are notoriously difficult to discern from water surfaces). But apart from that i am quite satisfied with the results here as well.

The other additional layer – the fractional vegetation data set – received an upgrade as well. This improves continuity across the tiles the data is processed in.

Visualization of the Musaicum vegetation data set

Visualization of the Musaicum vegetation data set

Both the shading compensated version of the image and the vegetation data set are not considered experimental any more and are now available for licensing like the regular mosaic. I am also going to make both of these available retroactively for the West Asia mosaic as time permits.

If you are interested in the North Atlantic Islands image please have a look at the product page for more details and samples. If you are interested in additional Musaicum coverage in areas so far not available please get in touch.

Bjargtangar, Iceland

Bjargtangar, Iceland

Tórshavn, Faroe Islands

Tórshavn, Faroe Islands

Pipelines rendering

November 28, 2024
by chris
3 Comments

Drawing the line #4 – Plumbing

This post adds another chapter to my previous series of posts on line signatures in maps.

Back in the first part of the series i explained and illustrated how the sophisticated techniques in using line signatures in pre-digital maps have practically largely been replaced by rather primitive line drawing in digital map production. And i showed some methods how you can, in digital rule based map design, work around these limitations.

Here i want to supplement this collection of techniques with some ideas on line dashing.

Dashing

Interrupted lines with dashing and dotting are one of the techniques that survived the transit to digital map production. Line dashing is available in most digital map rendering frameworks, often including the ability to define complex dashing patterns through dasharrays. This allows, in principle, to digitally reproduce many design concepts developed in pre-digital maps that make use of line dashing. But, if you look closely, the level of quality of drawing with dashed lines in digital maps is often rather low.

Here are a few examples of pre-digital use of dashing in maps:

1947 reprint of 1942 Japanese gaihōzu map of Seoul, Korea

1947 reprint of 1942 Japanese gaihōzu map of Seoul, Korea

Polish 1:25k map sheet M-34-101-A-c (Rysy) from 1960

Polish 1:25k map sheet M-34-101-A-c (Rysy) from 1960

Landeskarte der Schweiz 1:25000 1993 Blat 1268 Lötchental

Landeskarte der Schweiz 1:25000 1993 Blat 1268 Lötchental

Italy 1:50k US wartime map based on Italian 1:25k from 1934

Italy 1:50k US wartime map based on Italian 1:25k from 1934

What these examples demonstrate is how dashing adds another dimension of differentiation to simple line signatures (apart from line width and color) and also how more complex shapes of dashes can be used to highlight specific line element classes – like it is frequently used in case of boundaries.

What you can also see when you look closely is that in practical drawing the dashing is not just a simple mechanical repetition of a certain dash + gap sequence along the line with pre-defined dimensions. The dashing is adjusted to the context, usually in a way that ensures the individual line segments start and end on a dash – or, in case of junctions, that there is no gap directly at the junctions.

Pipelines in OSM-Carto

Digital rule based map styles typically do not do this – they mechanically and blindly repeat the defined dashing pattern along the line. For simple dashings this is often not that much of a problem, but for more complex patterns generated using dashing it frequently is. A good case example for this in OSM-Carto are pipelines.

Pipelines at z18 in OSM-Carto

Pipelines at z18 in OSM-Carto

Pipelines at z19 in OSM-Carto

Pipelines at z19 in OSM-Carto

Pipelines are rendered in OSM-Carto with a somewhat complex dashing pattern that is meant to resemble tube segments with flanges in a simplified form. In principle, this is an intuitive approach to showing pipelines. It even allows visualizing the substance through the choice of fill color at the higher zoom levels. The very mechanical drawing of the pattern, however, causes problems:

  • The drawing starts at an arbitrary position in the pattern (in this case with a flange) at the start of each linestring. This looks odd at junctions and when a pipeline is split in mapping into several segments, for example to apply different secondary tags.
  • Flanges can occur arbitrarily at any position along the line, in particular also at junctions and at sharp corners.
  • In addition, the individual line strings are drawn strictly one after the other with both casing/flanges and fill – leading to junctions not being displayed as connections of the pipelines.

Pipelines improved

Here is how the improved rendering in the AC-Style now displays the same configuration.

New pipeline rendering in the AC-Style at z18

New pipeline rendering in the AC-Style at z18

New pipeline rendering in the AC-Style at z19

New pipeline rendering in the AC-Style at z19

This is primarily achieved by two things:

The dashing pattern is adjusted in length and phase to the line length in a way that they start on a pipe segment in the middle between flanges and end in the same fashion.

Dashing pattern adjustment to the segment length

Dashing pattern adjustment to the segment length

And the pipelines are split at intersections among themselves and with other line features, specifically roads, and at the same time separately mapped pipelines are merged where two of them meet end to end when they share relevant attributes. Furthermore, the dashing is also split at sharp corners.

Dashing adjustments when pipelines intersect with roads

Dashing adjustments when pipelines intersect with roads

In addition, the pipeline rendering is integrated into the road layer so pipelines are correctly layered both relative to each other and relative to roads. And they are shown with a correct drawing order for casing and fill.

Pipeline layering relative to other pipelines and roads

Pipeline layering relative to other pipelines and roads

I also re-designed the use of color to visualize the substance transported in the pipeline.

Different line colors used for different substances at z19

Different line colors used for different substances at z19

The zoom level progression remains similar to that in OSM-Carto with some smaller adjustments.

Zoom level progression of the pipeline rendering

Zoom level progression of the pipeline rendering

Real world examples

Fuel pipelines at z18 at the Frankfurt Airport

Fuel pipelines at z18 at the Frankfurt Airport

Gas and unspecified content pipelines at z18 in St. Petersburg, Russia

Gas and unspecified content pipelines at z18 in St. Petersburg, Russia

Hot water pipelines at z18 in St. Petersburg, Russia

Hot water pipelines at z18 in St. Petersburg, Russia

Conclusions

What i demonstrated here is that use of line dashing with current map rendering frameworks is not strictly limited to the primitive mechanical application of a static dashing pattern, as it is common in automatically rendered maps these days. Achieving high quality dashing with the techniques shown here requires both dynamically adjusting the dashing pattern to the individual geometry and splitting and merging geometries based on their shape, geometric context and topology. The dynamic dashing pattern adjustment also requires a custom modification to Carto that allows defining dasharrays through fields.

The benefit of doing this is a much clearer and much better readable map image with fewer artefacts and a more organic depiction of dashed features.

The implementation of what i described in this blog post can be found in the AC-Style.

More map symbols

November 1, 2024
by chris
11 Comments

More map symbols

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.

October 25, 2024
by chris
8 Comments

Is the OSMF not overly fond of OpenStreetMap?

Just wanted to share an observation about public communication of the OpenStreetMap Foundation from the last year:

OSMF vector tiles visualization

OpenStreetMap Foundation Membership Campaign map 1

OpenStreetMap Foundation Membership Campaign map 2

OpenStreetMap Foundation Membership Campaign map 3

What do these all have in common? That they are not based on OpenStreetMap data.

I have written about the practical problems of creating high quality small scale maps from OpenStreetMap data in the past – see for example here, here and here.

And i want to make clear that the fact that the techniques to use OSM data in such use cases are not in the repertoire of the OSMF is of course not the fault of those who take on the concrete task of producing these maps. What this demonstrates to me is yet another angle on the problem that map design and the needs map designers have to produce high quality maps from OSM data are essentially not on the radar of the Foundation (other angles discussed here and here). The main takeaway should be that this – among other things – leads to what can be observed here, that the OSMF as the organization whose self declared goal is to promote OpenStreetMap is not able to produce decent quality small scale maps using OpenStreetMap data for their public communication.

Rendering of point barriers

October 23, 2024
by chris
3 Comments

Point barriers

I recently worked on a number of map design matters in my OSM-Carto derivative, which i have not discussed here on the blog yet. Much of this is related to point symbols, with – so far – a thematic focus on human physical constructions of various kinds.

In OSM-Carto point symbol rendering got kind of stuck several years ago because we could not reach a consensus strategy on how to deal with a number of fundamental challenges we were faced with – both technically and design wise. I have shown here new methods to overcome these challenges. And i have demonstrated how these methods can be used to expand the differentiation of point features displayed while remaining intuitively understandable. In this post i want to further build on that.

The class of features i am going to look at is point barriers. I have worked on line barriers before – with more differentiated display and ground unit rendering and i have also shown visualization one specific point barrier feature (barrier=entrance) by modifying the display of line barriers and cutting out the entrance from those – showing the point feature purely through the modification of its context. In a similar fashion i have shown contextualized rendering of fords and mountain passes through local modification of the line signature of the road they are located on. And i have shown, among other things, use of symbol variations and context based adjustments for entrance nodes of buildings.

Point barrier rendering through pictorial symbols has been a feature of OSM-Carto since the beginning. The original implementation featured distinct symbols for barrier=gate and barrier=lift_gate:

Rendering of barrier=gate and barrier=lift_gate in OSM-Carto v1 (left) and in current version (right) - links to double resolution rendering

Rendering of barrier=gate and barrier=lift_gate in OSM-Carto v1 (left) and in current version (right) – links to double resolution rendering

These symbols have – with slight modifications – remained trademark features of OSM-Carto. And they have, over the years, been extended with additional symbols, mostly ad hoc and non-systematically, for other point barriers. This created several problems:

  • symbols are very inconsistent in size, sometimes in a counter-intuitive way so that larger symbols are used to depict physically smaller features than those represented by smaller symbols.
  • some symbols have an integrated white halo while others are plain color – leading to very different appearances on backgrounds of different color.
  • some symbols are hard to recognize in situations where it is not clear from context what they mean. This in particular applies to the cycle barrier symbol.
Various point barriers in OSM-Carto with counter-intuitive symbol sizes, inconsistent halos and frequently hard to recognize symbology

Various point barriers in OSM-Carto with counter-intuitive symbol sizes, inconsistent halos and frequently hard to recognize symbology

The lack in stylistic consistency is the main thing i intended to address. Beyond that i added more differentiation in terms of different barrier variants. I also introduced differentiation between restricted access barriers and those that everyone can cross freely for some barrier types.

I maintain the duality in symbol styles with some symbols depicting the barrier in question from top while others showing a profile view. This is hard to avoid since some types of barrier do not have a discernible visual footprint from top while others are most unique in appearance from top (like turnstile, kissing_gate). For the symbols showing the barrier from top i show the symbol rotated by 90 degrees depending on the context of line barriers and roads/paths at the barrier node. For small, pixel aligned symbols like these a free rotation is not possible without largely sacrificing readability. But a 90 degree rotation makes it often much easier to intuitively understand the symbol.

90 degree rotation of symbols according to geometric context, either barrier lines (left) or road/path (right)

90 degree rotation of symbols according to geometric context, either barrier lines (left) or road/path (right)

Here is the full set of new point barrier depictions at the different zoom levels.

New symbols for various point barriers in the AC-Style

New symbols for various point barriers in the AC-Style

The second symbol shown is either the variant for restricted access barriers (top part of the table) or the 90 degree rotated variant.

Many of the symbols have a slightly smaller variant used for the lower zoom levels and a slightly larger version shown on the higher levels

All symbols except those for bollards are consistently shown with a thin white halo that is dynamically generated during rendering.

Three real world examples for the new rendering:

Near Kenzingen, southern Germany at z17

Near Kenzingen, southern Germany at z17

Freiburg, southern Germany at z18

Freiburg, southern Germany at z18

Lago di Garda, northern Italy at z20

Lago di Garda, northern Italy at z20

Conclusions

I showed here how a consistent design paradigm (which builds on the original design concepts of early barrier rendering in OSM-Carto from more than 10 years ago) allows rendering a large variety of different point features with differentiated symbols while remaining largely intuitively readable. I demonstrated 20 different base classes of point barriers with 4 access restricted variants and 7 context dependent 90 degree rotated variants. Nearly all of these symbols, in addition, have a simplified lower zoom level design, in some cases aggregating several similar barrier types into one design.

Technically, this relies on the symbol and label rendering framework i had introduced in the AC-Style previously and that scales much better with a larger number of design variants than hand writing lengthy MSS as it is used in OSM-Carto so far.

October 17, 2024
by chris
1 Comment

A few additional comments on the new OSM-Carto release

We have made a new OSM-Carto release that finally includes a solution for one of our oldest issues – the access restriction rendering on roads. And i want to make a few additional comments here beyond what i wrote in the release announcement.

The issue in question had been open for 11 years and i already presented the timeline of that process in the development discussion:

So what can we learn from this and why did it take that long?

What takes time in map design?

First this timeline as i see it approximately reflects the relative amounts of work required for different tasks in practical map design that tries to be innovative and not just copies ideas and methods developed elsewhere:

  1. 50 percent of work is conceptual design work – a viable and well thought through principal idea how to show something and a conceptual sketch of how the rules need to look like to get from the data to that visualization is already half the way.
  2. 25 percent of the work is developing an initial concrete implementation of the conceptual design. Depending on the problem this consists mostly of algorithm development, symbol and color design.
  3. another 25 percent of the work is spend on refining and adjusting this initial implementation to the practical constraints of the concrete map. This includes technical optimization work, design adjustments based on user feedback and practical testing of the design in its cartographic context.

These percentages are under the assumption that the conceptual design work is of high quality. If it is not you will often end up not being able to finish the second step and need to go back and repeat the conceptual design work with the lessons learned from the unsuccessful first attempt. This is normal, even for experienced map designers. But it makes the whole process take much longer of course and you still end up with similar relative percentages.

The problem is of course that this is hard to sell. And this is not much easier in a volunteer community project like OSM-Carto than in a commercial project. I can’t count how many times i have seen comments on OSM-Carto of someone essentially saying: Just render it in some form, does not matter how.

So to be clear on that: Yes, you can follow that approach. You can essentially cut step 1, reduce step 2 to copying things from elsewhere and making random choices in colors. You will end up with something you might feel fine calling a map. But that is essentially just map design parasitism. Economically, this might even be lucrative because of the time saved. But intellectually and artistically this would be highly dissatisfying. Which is why i don’t think this would be viable as a guiding principle for a volunteer community project.

Attracting talented and skilled contributors

But all of that of course does not explain why it took 11 years for OSM-Carto to address this specific issue. In particular in light of the fact that, in contrast to other problems, this one was technically not particularly challenging.

The vast majority of these 11 years was of course not spend on actual work, most of this was essentially waiting for someone with the necessary skills and the interest in the project finding the time to work on this.

The bottom line is: The resources bottleneck of a community map design project like OSM-Carto is qualified map designers with the capacity and the interest to invest their time into the project. OSM-Carto has been better at this than many other map design projects in the OSM-Community because being the main map for the OSM-Community is a huge incentive for contributors.

But – as i have pointed out in the past – we, the OSM-Carto maintainers, have over many years failed to provide talented and skilled map designers an attractive environment to contribute. The ability to do conceptual design work on concrete cartographic problems depends on there being a clear overall strategy for the map as a whole and we have not been able to agree on such a strategy for OSM-Carto for a long time now.

The other factor is the social context of the project. How non-technical work (which – as outlined above – is more than half of map design) is valued and appreciated in the larger OSM-Community has a huge effect on how much talent and skill in map design OpenStreetMap can muster overall. I have pointed out in the past as well that the OSM-Community is severely lacking here. We have a lot of contributors who show significant latent interest and often also talent in that field but do not find a nurturing environment to develop those.

Conclusions

The bottom line is: There is immense (i would go as far as saying globally unique) potential in the OSM community for talent, skill and interest in high quality map design with a broad range of cultural backgrounds. That potential is currently largely unused because:

  1. Community map design in OpenStreetMap, above all OSM-Carto, lacks the ability (in terms of the human ressources capacity, in terms of the technical tools and – in case of OSM-Carto – also in the form of a common strategy and vision within the project) to provide those people the supportive environment they need to develop their abilities.
  2. The OSM community collectively under-values map design and under-estimates the significance of the ability of OpenStreetMap to be innovative and actively shape the state of the art in that field for the long term future of the project. As a result people do not have the impression that investing in community map design in OpenStreetMap is worthwhile either socially or in terms of their own cartographic ambitions.
OSMF board elections 2024 - delving into the post-truth era?

September 29, 2024
by chris
4 Comments

OSMF board elections 2024 – delving into the post-truth era?

The elections for the board of the OpenStreetMap Foundations are upcoming and the most interesting part of this for the OSMF members has traditionally started with the publications of the self-presentations of the candidates, which happened during the last days.

My impression after the first reading of these is that the OSMF seems to have arrived in the post-truth era. Some might claim this has already happened years ago, but to me – and i have been a keen observer of the OSMF for many years now – it became obvious with this year’s election.

The concept of post-truth does not mean the communication of lies or untrue statements, it refers to the trend of defactualization, where the distinction between false and true becomes meaningless in communication and discourse in a certain social context.

There is an euphemism for this style of defactualized presentation commonly used in corporate PR and marketing these days, that is storytelling. The aim here is to create a certain impression or emotional reaction from the recipient of the communication largely sidestepping the facts surrounding the topic. Or in a nutshell: If the story is compelling it does not matter if it is convincing.

The irony is that originally, the term storytelling referred to something rather different: The development and communication of fictional stories either for the purpose of transporting abstract philosophical ideas and moral values in a practically robust fashion in a culture without writing or for the purpose of communicating ideas and thoughts that are subject to social taboos or otherwise not socially accepted in a non-fictionalized form.

My suggestion to the OSMF members for this year’s board election is therefore: Read the self-presentations of the candidates as fictional stories – like fairytales, mythology etc. And do not regard what you read there as propositions in the philosophical sense. If you do so i think you will be able to derive much more of value from your reading. If that is then helpful for your voting decision is a different matter of course. But you will definitely spare yourself some of the pain i had in my first reading of these.

I had considered analyzing this year’s board candidates’ self-presentations for examples of post-truth era communication techniques. But that does not seem right to me. After all it is not the candidates that are to primarily blame here. It is the OSMF members who are – collectively – too passive to set a higher bar for the candidates they elect for the board. But more than that: I also have the impression that quite a few OSMF members have fully accepted the end of history and simply can’t imagine a different kind of candidate. To use an old metaphor: They drink the sand because they don’t know the difference.

For those i will try here – in the tradition of storytelling in the original sense – to tell the story of a fictional board candidate who stands in contrast with the largely defactualized self-presentations we are seeing in this year’s election.

Manifesto

Dear OSMF members,

i am not actually a candidate in this year’s OSMF board election. Nor am i actually a real person that exists outside the mind of my creator, the author of this blog post, and the minds of you, esteemed readers of these lines. None the less i hope that my fictional candidacy in this year’s election inspires you to imagine the idea that some actual candidates might articulate and pursue some of the thoughts i present here in my fictional candidacy with the same clarity and determination as i do.

Feel free to customize the image that my creator has produced in these lines to your cultural or personal preferences and expectations.

Motivation and Objectives

What i hope to accomplish during my time on the OSMF board i am going to outline in the answers to the questions provided. The reason why i make these things my objectives is because, after years of observation and contemplation, i have come to the conclusion that these are crucial for a sustainable development of the OSMF under the goal of supporting the OpenStreetMap project. I am aware that the practical pursuit of many of these objectives is likely going to see opposition from substantial economic interests around the OpenStreetMap project. If i succeed in pursuit of these will depend on your support and that of the rest of the OSM community. I am going to do my best to accomplish these objectives within the OSMF board, but especially in the long term i will only be successful in that if i have active support for that from the OSMF members and the OSM community.

Conflict of Interest Management

First of all i reject the premise of the question that Conflicts of Interest are something that can be universally managed or mitigated without actually addressing the Conflict of Interest itself.

My personal situation allows me more than many others to pursue the interests of the OSM community even if they are in conflict with weighty economic interests around the project. I am not rich by any measure but my livelihood, my professional career and my personal goals are out of reach for even the most influential financiers of the OSMF or of economic interests around OpenStreetMap. So, even if those would want to put pressure on me personally to put their interests above those of the OSM community, the possibilities for that are very limited.

That being said there are, of course, going to be situations where i am going to have Conflicts of Interest in my work as a board member. I hope that i am going to be able to identify such situations myself in most cases. But i am aware that i cannot expect this to work reliably in all cases, so i will need to resort to other mechanisms as backups, which i will discuss in a second. Before that i am going to outline the three measures i expect to consider when i have become aware of a Conflict of Interest as a board member:

  • Selectively removing myself from the part of my work as a board member where i have the conflict. This only works in cases when the work in question, as well as the Conflict of Interest, are tightly limited in scope. In case of any kind of decision making, removing myself would mean both from the actual formal decision and the complete deliberation process leading up to the decision.
  • Temporarily suspending my work as a board member altogether. This only works in cases where the Conflict of Interest in question is inherently limited in duration.
  • Resigning my position as board member. This is always the ultimate fallback option in cases of Conflicts of Interest where no other measure can reliably ensure that the secondary interest does not affect my work as a board member.

All of these three options are going to be on the table whenever i become aware of a Conflict of Interest as a board member. I am going to transparently and publicly document the reasoning behind my decision of what measure to choose in any such case, so that the OSMF members have the opportunity to check on that reasoning and – if necessary – take the appropriate steps to insist on a different option.

Now back to the problem of reliably identifying Conflicts of Interest. The history of the OSMF board has shown beyond doubt that self-identification does not reliably work and even cross-checking among the board members does not, because the other board members are either equally unable to see the conflict or feel socially inhibited to openly point out the conflict of another board member (see here, here and here.

Therefore, other mandatory mechanisms will need to be introduced and this is going to be one of the things i am going to pursue as a board member. Transparency in decision making processes is going to be a key element of that (see next question). Beyond that, i concretely envision to suggest the following measures to the OSMF membership as binding to the board in their work:

  • Creating a mechanism by which decisions in which a Conflict of Interest has been overlooked are automatically nullified.
  • Introducing mandatory formal reporting of any Conflict of Interest identified as such by a board member to the OSMF membership.
  • Creating a mechanism by which Conflicts of Interest can be reported anonymously by any OSMF member.
  • Creating an oversight mechanism (ethics council) formed by the local chapters that oversees the board’s work with regards to Conflicts of Interest and that reports their findings to the OSMF membership as an additional control mechanism.

Transparency and Accountability

Transparency and Auditability of the work of the OSMF have seen a massive decline during the past years relative to the state after the transparency initiative of the 2015 board:

  • While originally all of the board meetings were public, the meetings are now split into private mid month meetings were actual deliberation of decisions seems to take place and the public meetings where formal decisions are still made but in depth discussion does not typically take place any more.
  • Policy document drafts are now routinely published only in the last minute before the formal decision (either during the meeting or in the day before the meeting) depriving the OSMF members from the possibility to review them and provide input before the decision. This communicates substantial disrespect from the board for the OSMF membership.
  • While some years ago the OSMF board routinely discussed policy development with the OSMF membership at an early stage (both on the board and on members’ initiative) this has almost completely stopped. And if the membership is consulted at all, it is usually about approval of a final draft as a done deal after the main deliberation has already happened in private.
  • The board does not seem to be bound by their own policy – for example the commitment to open channels is rather loosely interpreted – see here.
  • The board’s main method of internal communication and deliberation seems to have moved from channels with a permanent record (email) to volatile channels (IRC/Matrix) preventing both independent auditing of the board’s decision making and the board’s own ability to look up the genesis of past decisions.

This is a highly problematic trend on multiple fronts – in terms of oversight and dealing with Conflicts of Interest (see previous question), in terms of recruitment of competent volunteers (if no information is visible from the outside that massively steepens the learning curve for everyone who wants to get involved because they can only access pertinent information after they have become part of the inner circle) and in terms of public communication (transparency by default spares a lot of work in explicitly and selectively communicating only what is meant to be known to the public). Also the compartmentalized information management in the current OSMF stands in sharp contrast with the way the OSM community communicates otherwise, which creates a substantial culture gap between the two.

As a board member i am going to

  • make sure the OSMF board moves back to channels with a permanent immutable record for internal deliberation by refusing to participate in non-public inner-board communication on channels without such record. The need to be able to look up and refer to past communication in deliberation of the board is so obvious that i feel forcing the hand of the rest of the board this way is warranted.
  • start publicly reporting on developments in the board as soon as they happen even if they would otherwise not be known to the public at that time. I am not going to disclose content of communication without agreement in the board of doing so, but i believe that the OSMF membership and the OSM community as a whole – who the board is meant to serve – have the right to know for example when the board starts to draft policy affecting the OSM community or starts discussing to contract someone to do certain work for the OSMF and i don’t think, as an elected board member, i would be infringing on anyone’s moral or legal rights by reporting in a timely fashion about such things happening as they do.
  • present and argue for the advantages of a public-by-default approach to board work with the other board members and attempt to roll back the roll back of the transparency of board work of recent years. I am aware that this might be an uphill battle against an existing organizational culture of compartmentalization. But the benefits of a more open work culture are difficult to ignore.

Strategic Vision and Sustainability

The strategic planning initiated by Allan Mustard in the OSMF was a significant step and it could have been a good starting point for further work in that direction despite some shortcomings. But what the board then made out of this ambitious start, by essentially removing all the clarity and stringency in the original document and replacing it with soft and vague expressions of wishes, amounted to nothing less than moving back to the muddling through the plan originally aimed to overcome.

As a board member i would aim to re-initiate the strategic planning process, starting with the original work of Allan Mustard. I would aim to

  • Fill the thematic gaps and omissions in the original plan.
  • Move the discussion of further development to a public venue, giving all interested community members the opportunity to read and provide feedback and inviting people with experience in specific fields to provide advice (in public to provide checks and balances against lobbying for special interests).

But i would in particular aim to introduce a strict subsidiarity principle into the strategic planning of the Foundation. The OSMF should not pursue tasks that can be equally or better handled on a local level or by thematically more specialized organizations. The OSMF needs to focus itself on its core functions as outlined by the OSMF mission. This is more than enough of a challenge with the continued growth of the project.

I also consider a move of the OSMF to the EU a strategic necessity, as well as a chance to restructure the organization in a more robust and more scalable way. The necessity stems from the legal protection of the OSM database under the ODbL, which is based on European database rights. And the move would provide the chance to design a new organization with proper formalized checks and balances, because it would not be subject to the tight constraints of UK corporate law. I envision a structure where the operational management of the organization and policy development are separated and where the local chapters have a formal role of oversight over key aspects of the organization (like decisions about the rights to the OSM database, trademarks and the mapper accounts).

The steps taken by the OSMF board so far regarding a move to the EU seem to suffer from a lack of transparency in decision making. In particular the choice of countries to consider moving to seems to be based on behind the scenes lobbying of special interests, rather than an open and transparent selection process. And it also suffers from the lack of ambition with regards to restructuring the organization. As is it seems likely that the board would try to copy the highly disadvantageous structure of the existing OSMF as required by UK corporate law into the EU and this way miss a huge opportunity that is likely never to come again. Bottom line: I think the whole process needs a restart with a more transparent process and a broader discussion how the new organization should be structured.

Decision-Making and Collaboration

I do not plan to collaborate with anyone during my time on the board, but I hope to cooperate successfully with my fellow board members, with the working groups, with the OSMF membership and with the OSM community as a whole. The key to successful cooperation is a basis of shared goals and values to start from. In the case of OpenStreetMap, this cannot be shared cultural values but has to be the basic ideas and values of cooperative collection of local geographic knowledge. Everything else (like the traditional OSMF mission and its interpretation) needs to derive from that. If there are disagreements in the OSMF about how to practically pursue the OSMF mission, i would try to solve that through arguments and reasoning with regards to the basic ideas and values of OpenStreetMap. In other words: I would ask others to try to convince me that what they suggest is in support of these and i would try to convince them that what i suggest is beneficial in that regard.

As far as the organizational structures within the OSMF are concerned – i think the original idea of largely independent working groups is very good. But the board has, in recent years, substantially crippled their development by frequently interfering ad hoc with their independence and by creating board committees with non-board members as a competing, less independent but much more favorably treated organizational structure. This whole concept needs to be re-considered together with reducing the scope of the OSMF’s own activities in favor of the local chapters.

What would definitely end with me on the board is the current practice of keeping inner-board conflicts and disagreements under cover and the attempts to hide such from the membership. This is not a good way of dealing with disagreement and such pretense damages the credibility of the board as a whole to the outside.

Fundraising and Resource Development

According to the self-presentation of the current OSMF in public, fundraising seems to increasingly turn into a goal on its own. That is not a good development. The expenses of the OSMF have quite significantly increased over the past years but the level of actual internal organization of the Foundation has not kept up with that. And that is not a problem caused by the lack of money, it is caused by the lack of determination in ending the muddling through that Allan Mustard has rightfully criticized in his sketch for a strategic plan. If the OSMF would try to address this by raising and spending additional money (or in other words: try to outgrow the problems through financial expansion) the result would be an organizational automaton the de-facto primary goal of which would be to sustain itself and grow as an organization, meaning raising funds for the main purpose of continuing to raise funds.

As a board member i would aim to follow a different approach. I would try to consolidate or even reduce (based on the subsidiarity principle, by ending the OSMFs involvement in activities that are outside its core functions) the current operational scope of the organization and focus on putting that scope on a more solid and robust basis. That involves in particular

  • developing, consolidating and publishing internal policy that is binding for everyone regarding the routine operational activities of the organization. In other words: Writing a comprehensive OSMF handbook covering the current operational scope of the organization.
  • detailing the strategic planning to the level that it provides clear guidance to all the operational activities.
  • opening up to the wider OSM community in operational activities and strategic planning and making supporting the OSMF through volunteer work attractive again for intrinsically motivated grassroots volunteers without a professional motive.

Of course, even with this approach followed with determination, the OSMF will need continuous fundraising to sustain itself. The goal here needs to be IMO to better diversify the funding. I would try to establish the following goals:

  • No more than 10% of the OSMF’s income should at any point of time come from a single source (and indirect funding via proxy would need to be considered here of course)
  • No more than 30% of the OSMF’s income should at any point of time come from a single country (again with indirect funding through dependent organizations in other coutries considered)
  • No more than 30% of the OSMF’s income should at any point of time come from a single thematic class of financiers (currently for example digital technology companies could be a class where this is potentially an issue)

Accomplishing these will likely require cooperation with local chapters around the world. The OSMF therefore needs to find a sustainable way to handle the competitive situation with the local chapters with regards to funding. The idea currently pursued to incentivize a funding dependency of the local chapters on the OSMF by trying to take a proxy and gatekeeper role between big corporate financiers and the local chapters is a very bad one in my opinion. The opposite approach would, in my opinion, be better with the local chapters being the direct contact with local financiers of OpenStreetMap and handling the local financial bureaucracy. This would also conform with the subsidiarity principle i dicussed above, while the current approach does not.

Handling Legal and Political Challenges

A thorough assessment of legal risks faced by the OSMF is quite clearly long overdue. This should be combined with the development of mitigation strategies that avoid the possibility of core assets of the OSMF (the database rights, trademarks and mapper database) to be at risk in case of serious legal challenges. Ideas for that can be implemented in the course of a move to the EU as sketched above.

On the political front, the OSMF still has a lot to do to repair the damage incurred by the infamous Crimea decision in 2018 (where the board overruled standing OSMF policy, community consensus and the data working group in an attempt to pacify some loud voices articulated in the OSM community and political pressure). The board needs to actively reaffirm standing behind the core principles of OpenStreetMap in documenting the observable reality on the ground – even in cases where this is politically not fashionable. A consistent stance based on clear and broadly supported principles in the long term is a much better defensible position than opportunistic adjustment to the wind direction of the day.

State of the Map

The operational planning of the State of the Map conference should remain at the discretion of the SotM working group and i would, as board member, oppose any attempt of ad hoc interference with that as it happened in the past. Strategically, i would encourage the SotM working group to develop the concept of the State of the Map conference in the following directions:

  • supporting predominantly regional conferences in a rotating fashion rather than moving an international conference around the world. This would IMO be more suitable to celebrate the cultural diversity of the OSM community world wide.
  • developing concepts of a decentralized conference with different local meetings of people connecting digitally to the event.
  • developing asynchronous formats where people can watch presentations at a daytime of their chosing and asynchronous discussion afterwards takes place between presenter and audience.

And to be clear: The OSMF cannot and should not aim to ensure that the conference is safe and accessible for all members of the global community. That idea would be completely impractical if global community really means global community – and it would be morally highly questionable if global community means only the wealthy international OSM jet set. The OSMF should be open to support an international conference in any part of the world where there is an active local OSM community willing and able to organize such an event. If, in some years, that happens to be in places which most people from Europe and North America practically won’t want to or are not able to visit, that is to be accepted.

Your Community Contributions

I have contributed to OpenStreetMap on various levels – in mapping, in tagging discussions, in software development, in map design and in public communication to name the most important. But i have no strong focus on any of these fields in particular that would put me at risk of aiming to cater the specific interests of that field.

I have also followed the development of the OpenStreetMap Foundation for many years as far as this is possible from the outside as a normal member who is not part of the inner circles. And i have frequently talked to board members during that time about the OSMF. But i have never been involved in the OSMF myself beyond being a member – hence it is safe to say i have never been socialized in the organizational culture of the OSMF. This gives me a relatively well informed outside perspective.

I am not a native English speaker and besides my native language and English i also have basic knowledge of another language with wider use across different countries (like French, Spanish, Russian, Arabic, Chinese – pick whatever you like most). This helps me realize that by limiting your horizon to English language only (like the OSMF mostly does at the moment) you miss out on significant cultural diversity and loose immense opportunities. This is why the OSMF urgently needs to start embracing more diversity in languages in its organization. That is a challenge practically, but IMO also a strategic necessity.

Promoting Community and Attracting Volunteers

Recruitment of qualified and intrinsically motivated volunteers has become a big problem for the OSMF during the past years. The OSMF has alienated a lot of highly qualified long term volunteers from the OSM community over the past years through the principle of people whose work we know and enjoy as a recruitment paradigm for both paid and unpaid work in the OSMF assigned by the board. This not only urgently needs to end, the OSMF board needs to take substantial steps to win back credibility with the larger OSM community where the do-ocratic principle is highly valued.

The OSMF also has a lot of homework to do with regards to inclusivity. Getting involved in the OSMF without substantial English language communication ability and without embracing the OSMF organizational work culture is next to impossible. And people usually don’t even have the chance to get a good idea of these requirements before actually taking the step to get formally involved because most of the OSMFs activities happen behind closed doors and are only accessible to those who have decided to get formally involved. That is literally the opposite of being welcoming.

Due to the independence of the Working Groups (which is important to hold up) the board has only limited ability to directly top-down change this situation. But we can lead by example and provide helpful recommendations and organizational support for the working groups to reduce the barrier to get involved as volunteers.

There are a number of concrete steps i would like to pursue in that regard as board member.

  • Set up a place where work for the OSMF that can be independently pursued by volunteers is openly advertised for community members to take on without a formal barrier. This of course will require more real time transparency in the work of the OSMF in general (so people understand the context of these tasks). Initially that would be for tasks created by the board but the idea would be that this approach could also be adopted by the working groups.
  • Move more active work from the OSMF website (with top-down control of editing rights) and elsewhere to the OSM wiki (where all OSM community members can get actively involved)
  • Being more transparent in all practical board work as this reduces the barrier and increases the incentive to get involved.
  • When consulting the larger community in a formal or informal way specifically inviting and valuing critical and inconvenient comments and reactions.

The real challenge is going to be breaking the English language dominance. I have no definitive approach how to tackle this at this time. But not accepting the currently dominant paradigm that the English language dominance is inevitable is a start. Revising the so called diversity statement in that matter would be a symbolic first step.

Technology and Innovation

OpenStreetMap relies heavily on technology but is not a technology project itself. That is important to keep in mind for the OSMF. So technology for the OSMF always needs to be a means to the end of supporting the cooperative mapping efforts of the OSM community, not a goal on its own.

The OSMF needs to keep a close eye on the technologies OpenStreetMap relies on in its core functions and their development. But in doing so we also need to keep in mind the basic principle to support, but not to control the project. It is highly doubtful if the OSMF taking over the development of some core tool in operation of OpenStreetMap by paying a professional developer would be of long term benefit for the project. OpenStreetMap has, over its history, so far been able to attract and motivate the developers of the technology it relies on on the operational level and the OSMF’s role here should be to ensure it continues to do so, not to become a substitute motivator.

Beyond these fundamental operational needs lies the field of strategic investment into technologies needed in the long term by the OSM community. The focus of the OSMF board here should lie in supervising and guiding the strategic planning in that regard to provide the necessary guidance for the Engineering Working Group in practical implementation of these strategic investments.

Since strategic investments in technology typically have a significant size, there is going to be a necessity for the OSMF to pursue cooperation with other organizations – like OSGeo, or academic institutions as far as fundamental technological innovations are concerned, or other potential users with overlap in strategic needs.

My own first focus as a board member in this domain would be to keep a careful eye on how technological decisions affect the OSM community on the social level. The important thing here is that technology should have the function to support the OSM community in their needs and their consensus decisions. The technology should not be used to steer the OSM community in a certain direction and it is the board’s task to ensure that this does not happen under the aegis of the OSMF.

My second focus would be to ensure that the decision of where to strategically invest the limited means of the OSMF is not primarily guided by lobbying interests of parties who want to profit from the investment, but by a careful and neutral look at the actual strategic needs of the OSM community for its work. Doing the strategic planning in that regard publicly is going to be key to accomplish that.

Data Quality and Protection

We have here the two fairly separate fields of vandalism (i.e. malicious actions) and quality assurance (i.e. the concern about the quality of well intended edits of the data). The first field is handled on the operational level by the working groups, the board should not get involved here. It would be important to give this point substantial consideration in the strategic planning and to involve the concerned working groups in strategy development there.

Regarding quality assurance – this is primarily a matter for the mapper community and the OSMF should not get involved here beyond this potentially being part of the strategic investment in technology (see previous section). One exception: If quality issues are directly or indirectly caused by organized mapping activities. Here adjustments of existing regulation or new regulation could be required in the future.

I see no acute need for adjustments in policy here, but the current organized editing rules have been in place for quite some time now without changes. So one thing i would do as a board member is to initiate a comprehensive review of the organized editing policy and evaluate the need for adjustments. Quite a bit of research has been published during the past years on organized editing in OSM so there is a substantial data basis for such a review. This data should be supplemented by direct input from local mappers regarding the effects of organized activities on their work.

Perspective on Open Source

The fundamental idea of OpenStreetMap is directly tied to the idea and the philosophy of open data, which in turn is closely related to the idea of free open source software and open technology in general. So, as far as the technology the OpenStreetMap Community relies on in its basic work is concerned, the need for this technology to be open is pretty much a given (although, to be accurate, that principle currently largely ends when it comes to hardware technology).

How the OSMF manages its membership database is fairly unrelated to that so you could argue the same principle does not apply here. But the OSMF has a FOSS policy and that derives not only from the philosophical connection between open data and free open source software, but from practical considerations as well. It is practically beneficial for the OSMF to use FOSS rather than proprietary software for multiple reasons

  • it is less costly because you avoid license costs.
  • it avoids creating a dependency on a proprietary software provider.
  • it has security benefits since you don’t need to run code that you can’t inspect (in particular relevant for use cases involving sensitive personal data).
  • it massively lowers the barrier for volunteer involvement because volunteers can use the same software independently without a license cost hurdle.
  • it creates an additional incentive for volunteer involvement because volunteers can get practice in using software that they can then also use otherwise without additional license costs.

In the specific case of the task of managing the OSMF membership database the following additional argument applies:

As far as i understand it the incident that triggered the recent discussion was caused by a change in the membership signup process being deployed without proper testing – which would have revealed the problem. Such testing is much easier to organize in a volunteer based project if no proprietary software is involved because any volunteer could perform the testing on their own infrastructure independently while with proprietary software licenses the testing would either need to happen on OSMF infrastructure or the tester would need to be contracted by the OSMF (depending on the terms of the license). In other words: FOSS solutions are much better compatible to the openly cooperative and decentralized work culture of the OSM community than proprietary solutions.

The bottom line is: I see plenty of arguments that speak for continuing to use FOSS solutions in managing the OSMF membership database and none that speak for a proprietary solution.

Perspective on Overture Maps

Overture Maps is essentially an OSM data user like anyone else. What distinguishes them from other data users is that their aim is to re-distribute OSM data in a modified form on a large scale – something that is rare among commercial OSM data users so far.

For the OSMF it is important to treat them like any other data users. That means watching over their compliance with the ODbL. Since they distribute combinations of OSM data with other data this in particular concerns the share-alike rules of the ODbL. These have been neglected in the guidelines regarding the ODbL developed by the OSMF so far and it might be advisable to fill that gap.

And we should communicate to them clearly and openly that we expect them to support the project the data of which they use extensively by the Linux foundation becoming a corporate member of the OSMF. Similarly, we should of course look into contacting large scale data users who use OSM data through Overture and equally suggest them to support OpenStreetMap as the original source of the data they use.

Conclusion

That ends the presentation of my fictional candidacy for the OSMF board election. If you like what you have read then don’t vote for me – because you can’t. Instead you should get out of your mapping armchair and start working towards what you like in what i presented above. The truth is that the OSMF will not change for the benefit of the OSM community unless the OSMF members push it with determination to do so. So if you find my analysis of the situation of the OSMF and the suggestions i derive from it convincing on any of the topics discussed, then it is up to you to pursue these ideas. Because no one else will.