From OpenStreetMap Wiki
Jump to: navigation, search

I'm the author and maintainer of the Overpass API. More about me below.

My manifesto for the OSMF board election 2013:

In German see below. The about me in German.

It works

First of all, the project flourishes. That means a big thank you to all who have contributed to this: that are not only the mappers, but also our sysadmins and numerous other people in the background.

This means also that all changes of the way OSM works have to be carefully assessed whether they make the work easier for the above mentioned people.


Diversity is an opaque notation, so I'll start with an outline of my interpretation here: People with a different background will express different needs. In an ideal world, we could satisfy all these needs better than competition, and because people are sane, they would use our tools. In a more realistic world, it is already a challenge to realize what these needs actually are.

Concerning women, the talk of Manuela Schmidt at the Fossgis has pointed out a lot things I even haven't thought about, and from all of them most men would profit too: Some testers have understood the fact that pubs are rendered with higher priority than restaurants as an indication that restaurants are less important than pubs in OSM. Hence they thought they could not contribute much because they know restaurants better than pubs.

Another example are privacy concerns. They were expressed on the German mailing list, and it took a lengthy and painful discussion to distill the problem: People who are used to Twitbook+ may assume that one person shall only have one account, preferably with clear name. This is in particular promoted by the technical limitation that at most one account can be associated to any single email address. In a one-person-one-account setting it would be a privacy issue that the edit meta data is distributed along with the geodata. So to make privacy concerned people become happy mappers it is important to both make clear the accounts are only loosely related to persons and to faciliate having multiple accounts.

To make it clear: Rendering rules for pretty maps as well as a lean account management are nice to have. But building a diverse community that maintains a well-gardened database has priority over such second important goals, so the challenge is to accept that these and similar things can be changed and how they are changed to improve them for the better.

Not an example for diversity issues are pushing the figures: If we want a bigger share of women then this is done most effectively by deterring men, even if they contribute out of passion. But even with men I rather welcome more mappers than to loose mappers.


Does OSM grow? Does it grow exponentially? Do we want it to do so?

The graphs show a strong growth, and for the number of registered users it appear exponentially. For the contributed data, it appears rather linear than exponentially. From this point of view, it is primarly an issue to let the infrastructure grow with the user base and activity such that the quality of experience for the mapper stays at least the same. Our current team of sysadmins has managed this fantastically so far, but of course the OSMF is in charge to support their sysadmins in the future at least as good as today to keep up that excellent user experience.

Another question is from where the additional people come from. This answer leads inevitably to the topic diversity. But don't forget communication: OSM has achieved a size where it has been recognized by almost all proponents. So we have to do more than just tell the mere existence of OSM. It gets more and more important to show what OSM is good for. More people means that we will have to attract mappers that use OSM for a purpose and not only encounter OSM as a purpose on itself. In particular, these potential users prefer a quick and simple interaction with OSM. This in turn may require tools that are more idiot-proof than innovative, which in turn could mean to present to passionate users tools with inacceptably numb user interface. And also: It is much less effective to motivate people to contribute for purpose than by passion. So it remains an open question if further growth is an end or only a mean for OSM.

The city council of OSM

To tackle the above outlined challenges, we must relate them to the capabilites of the Foundation. A lot of important assets of OSM have been developed and are controlled by fellows, not by the OSMF themselves. Examples are JOSM, the Geofabrik downloads, even some of the tile sets on and numerous other tools. Actually, this is an important strength, not a weakness: It is an important incentive for existing and future partners that they can contribute something that matters.

To put this into perspective, think of a city council: The council takes responsibility of keeping up the street grid. But it doesn't take responsibility of keeping up supermarkets. Would the city work better if the city council has to run and organize each and every business in the city?


One of Manuelas key findings were that potential mappers would appreciate very much positive feedback. Actually, the most impressive form of feedback would be careful personal review. We don't have the resources to do that in every case, so the next best solution would be an automated review. I exepect a tool of the form: "You have added two restaurants. Thank you. Look, they now appear on _this map_ (link with lat/lon), and _that_ and further maps. It is by the way the first 'vietnamese' restaurant in this city." Or in other cases: "This is the first restaurant with 'tialian' cuisine. Funny, sounds like 'italian' cusine, isn't it? You could correct that typo with _one click_ (link). Or would you like to say a few words about 'tialian' cusine _in the wiki_ (link to a to-be-created wiki page)?" Or: "Uhm, this edit has disrupted _this bus line_. Could you please help a moment to reassamble the line?"

It is a great opportunity to promote existing tools, so most toolmakers will have an incentive to help. By the way, it is also a wide open architecture to indiscriminately accomodate new tools as well as new tagging schemes: We get rid of all these wiki and mailing list tagging turf wars, because a tagging scheme is in advantage exactly when its plugin produces useful feedback.

The challenge here is not so much of technical nature than more of bringing people together: We need the support of mappers to learn what messages to display. We need the support of editor coders to integrate the ressource in their editors. And we need the support of toolmakers to exhibit and transform their rules such that a plugin can display the feedback in each and every editor.

I hope that the authority of an elected board member can help to evangelize the people for this true piece of collective intelligence.

Improve tool visibility

It is sometimes a surprisingly hard job to perform simple tasks. Some examples are a OSM based bicycle routing software that you would recommend a friend, a simple undo tool, a one-click editor, or a customizable slippy map to show all appearances of a single tag.

For most of these problems and a lot of other problems do exist tools, all between proof of concepts and indsutrial strength perfect solutions. But they are too rarely known in the community. Lists like this are hardly readable, and not even google search always finds a comprehensive list.

So one of the challenges is to actually improve this. I personally would love to develop the wiki in that direction, in presenting a collection of best practices on suitable keywords. But I'm open to better approaches. It is important to do try strategies to better annouce tools and workflows that deserve ackowledgement.

Don't forget: The people that feel their work matters are those that come to stay. Let's attract them. Let's also keep us feel welcome each other.

Please feel free to ask questions. I'll respond best to questions on


OSM funktioniert

Zunächst einmal: OSM funktioniert hervorragend. Daher erst einmal ein großes Dankeschön an alle, dei dazu beitragen: dies sind nicht nur die Mapper, sondern auch gerade die Sysadmins and zahlreiche Andere im Hintergrund.

Dass OSM funktioniert, bedeutet auch die Verpflichtung, alle Änderungen an bewährten Konventionen sorgfältig darauf zu überprüfen, ob der Nutzen den Schaden überwiegt.


Vielfalt ist ein schillernder Begriff. Daher werde ich erst einmal meine Interpretation erläutern: Menschen mit verschiedenen Hintergründen haben verschiedene Bedürfnisse. In einer idealen Welt erfüllen wir alle diese Bedürfnisse besser als jede Konkurrenz, und da Menschen vernüftig sind, nutzen sie unsere Tools. Realistischer ist es bereits eine große Herausforderung, die Bedürfnisse überhaupt zu erkennen.

Zum Beispiel Frauen. Manuela Schmidt hat in einem Vortrag auf der Fossgis eine ganze Menge Punkte gesammelt, von denen ich nicht bemerkt hätte, dass sie für viele Frauen, aber auch einige Männer mehr als nur lästig sind: Einige Testpersonen haben das bevorzugte Rendering von Pubs vor Restaurants so verstanden, dass Pubs wichtiger als Restaurants sind. Da sie Restaurants besser als Pubs kennen, glaubten sie, nichts Wesentliches beitragen zu können.

Ein anderer ist Datenschutz. Das Thema musste einige Tage auf talk-de diskutiert werden bis der Kern des Problems herausgearbeitet war: Wer Twitbook+ gewohnt ist, nimmt an, dass auch OSM erwartet, dass eine Person nur einen Account besitzt. Die Vorgabe, pro eMail-Adresse nur einen Account zuzulassen, hat diesen Eindruck noch bestärkt. Wäre dies jedoch zutreffend, dann wäre die volle Veröffentlichung der Metadaten zusammen mit dem Geodaten in der Tat ein Datenschutzleck. Daher ist es wesentlich, um Datenschutz-bewussten Mappern entgegenzukommen, sowohl klarzumachen, dass Accounts nur lose mit Personen verbunden sind als auch es zu vereinfachen, mehrere Accounts bis hin zu Einweg-Accounts zu eröffnen.

Zur Verdeutlichung: Rendering-Regeln für hübsche Karten sind ebenso wie ein schlankes Account-Management erst einmal erstrebenswert. Aber Menschen auch mit ungewöhnlichem Denkhintergrund trotzdem die Teilhabe zu ermöglichen und so besser kuratierte Daten zu bekommen ist wichtiger. Die große Herausforderung liegt also darin, zu akzeptieren, dass Rendering-Regeln und Account-Management geändert werden müssen und auszuarbeiten, wie sie geändert werden müssen.

Für nicht hilfreich halte ich Erbsenzählen: Wenn wir den Anteil von Frauen erhöhen wollen, wäre es das Effektivste, Männer zu vergraulen. Ich sehe aber auch bei Männern lieber neue Mapper als vorhandene zu verlieren.


Wächst OSM? Wächst OSM exponentiell? Wollen wir das überhaupt?

Die Graphen zeigen tatsächlich ein starkes Wachstum, und die Anzahl der registrierten Benutzer wächst tatsächlich exponentiell. Bei den beigetragenen Daten sieht es eher linear aus. Aus dieser Sicht ist es vorrangig wichtig, dass die Infrastruktur mitwächst und OSM benutzbar bleibt. Unsere Sysadmins haben dies bisher hervorragend geschafft. Daher ist die OSMF in der Verpflichtung, ihre Systemadministratoren auch in Zukunft mindestens so gut wie heute zu unterstützen.

Eine andere Frage ist, woher die neuen Nutzer eigentlich kommen sollen. Das führt zurück zur Vielfalt. Aber es erfordert auch sorgfältige Kommunikation: OSM ist mittlerweile so groß, dass praktisch alle Multiplikatoren es kennen. Daher hilft es nur noch wenig, allein von der Existenz von OSM zu erzählen. Wichtiger wird aufzuzeigen, wofür OSM genutzt werden kann. Das zieht an und soll auch anziehen Nutzer, die OSM für einen Zweck benutzen und nicht OSM als den Zweck betrachten. Solche Nutzer erwarten unmittelbar benutzbare Tools. Das erfordert, dass unsere Tools eher idiotensicher als innovativ werden, was wiederum Poweruser frustrieren kann, denen ein solche Benutzerinterface im Weg steht. Wollen wir solches Wachstum?

Der Stadtrat von OSM

Um alle diese Herausforderunge zu meisten, müssen wir die Rolle der OSMF verstehen. Zahlreiche wichtige Projekte in OSM sind unabhängig von der OSMF entwickelt worden. Beispiele sind JOSM, die Geofabrik-Downloads, einige Layer auf und zahlreiche weitere Tools. Das ist keine Schwäche, sondern eine unserer größten Stärken: Es gibt heutigen und zukünftigen Entwicklern die Hoffnung, etwas wirklich Bedeutendes beizutragen.

Daher das Modell "Stadtrat": Die Stadt besitzt und betreibt zwar ihr Straßennetz, aber sie betreibt keine Supermärkte. Würde eine Stadt besser funktionieren, wenn jedes Unternehmen in der Stadt der Stadt gehörte? Wohl eher nicht.


Eines von Manuelas wichtigsten Ergebnissen ist, dass sich Mapper sehr über positives Feedback freuen würden. Ein persönlicher Review wäre zwar das beste, aber dafür haben wir nicht die Ressourcen. Daher als Alternative ein automatischer Review: Ich denke an ein Tool mit Meldungen wie: "Danke für die zwei neuen Restaurants. Sie werden jetzt auf _dieser_ und auf _dieser_ Karte gezeigt und sind in _diesem_, _diesem_ und weiteren Tools zu finden." Oder: "Dies ist weltweit das erste Restaurant mit Küche der Richtung 'tialian'. Ist es ein _Rechschreibfehler_ (Korrekturlink)? Oder möchstest Du ein paar Worte darüber _im Wiki_ schreiben?"

Es gibt Tool-Autoren eine willkommene Chance, ihr Tool mehr Menschen vorzustellen. Und es erlaubt bequem sowohl neue Tools als auch neue Tagging-Schemata: Die erbitterten Wortgefechte auf den Mailinglisten und im Wiki entfallen, da sich das Schicksal eines Tagging-Schemas dann daran entscheidet, ob es nützliches Feedback produziert.

Es ist weniger eine technische Herausforderung als mehr eine diplomatische: Es muss gut genug sein, um Mappern zu gefallen. Wir brauchen die Hilfe der Editoren-Programmierer, diese Ressourcen dem Mapper anzuzeigen. Und wir brauchen die Hilfe der Tool-Entwickler, ihre Tagging-Schemata offenzulegen und so aufzubereiten, dass ein Plugin im Editor nützliches Feedback leisten kann.

Ich hoffe, dass die Autorität als OSMF-Board-Mitglied hilft, Menschen für dieses Stück wahrhaft kollektiver Intelligenz zu begeistern.

Verbesserte Sichtbarkeit von Tools

Manchmal ist es überrachend schwierig, selbst häufige Aufgaben mit einem perfekten Tool abzudecken. Zum Beispiel ein Fahrradrouting, so robust, dass man es weiterempfehlen kann, ein einfaches Undo-Tool, ein Ein-Klick-Editor oder eine Slippy-Map, die ein ad hoc gewähltes Tag anzeigt.

Für Probleme dieser Kaliber gibt zum Teil exzellente Lösungen, zum Teil immerhin Erprobungstäger. Aber sie sind weniger bekannt in der Community als sie eigentlich verdienen. Listen wie diese sind schwer lesbar, und nicht einmal Google-Recherchen finden immer eine komplette Liste.

Eine der wesentlichen Aufgaben ist, die Lage zu verbessern. Persönlich würde ich dafür gerne das Wiki zu einem Ort entwickeln, in dem Tools und Best Practices bei den passenden Stichworten beschrieben werden. Ich bin aber offen auch für andere Ansätze. Ich möchte nur mindestens einen Ansatz soweit weiterverfolgen, dass er Früchte trägt.

Es bleiben dauerhaft bei OSM schlussendlich nur die Menschen, die merken, dass es auf ihr Engagement ankommt. Lasst uns diese umwerben. Und lasst uns untereinander diesen Geist aufrecht erhalten.

Ich beantworte gerne Fragen. Am zuverlässigsten auf talk-de@.

About me

I'm Roland Olbricht. In OpenStreetMap, I'm most known for the Overpass API. I have developed it and maintain the two public servers that are available now since more than two years.

I'm Dr. rer. nat. since 2008 for my works in Pure Mathematics. Since then I'm a software developer at Fraunhofer SCAI in Sankt Augustin near Cologne in Germany.

Beside living in Wuppertal, Münster, Frankfurt and Bonn in Germany, I have also spent four month in Grenoble in France. So I'll answer mails in French, German and English.

I'm born in 1980. I'm married since this May, with no children yet.

Über mich

Mein Name ist Roland Olbricht. In OpenStreetMap bin ich bekannt für die Overpass API. Ich habe sie selbst entwickelt und betreue die beiden öffentlichen Server seit nun mehr als zwei Jahren.

Ich bin promovierter Mathematiker seit 2008. Mittlerweile arbeite ich als Software-Entwickler bei Fraunhofer SCAI in Sankt Augustin, nahe Bonn.

Gelebt habe ich bisher in Wuppertal, Münster, Frankfurt und Bonn, aber auch vier Monate in Grenoble in Frankreich. Ich beantworte Mails gerne in Französisch, Englisch oder Deutsch.

Geboren bin ich im Jahr 1980, verheiratet seit diesem Mai, noch ohne Kinder.