4 Tipps für automatisierte Grafiken mit DatawRappr

Das Coronavirus hat im digitalen Journalismus viel angeschoben. Zum Beispiel beim Thema automatisierte Grafiken. Ein paar Tipps, wie ich mit Skripten und Datawrapper Grafiken update.

Dieser Blogpost ist schamlose Werbung für mein R-Package DatawRappr. Das hatte ich zufällig Ende 2019 entwickelt, hauptsächlich um die API von Datawrapper aus R heraus nutzen zu können.

Inzwischen nutzen es viele DatenjournalistInnen, um ihre Grafiken für das Coronavirus zu updaten. Seit Beginn der Pandemie habe ich einige Lösungen damit entwickelt, um „fancy“ Sachen zu machen – ein paar davon wollte ich hier teilen. Ein bisschen nerdiger Post diesmal.

1. Viele Grafiken auf einmal erstellen

Ein klassischer Anwendungsfall: Wir haben eine Grafik und hätten die gerne für verschiedene Ausprägungen ausgegeben. Zum Beispiel: Ein Liniendiagramm der Neuinfektionen für alle Länder in der EU. Wie kann ich diese Grafiken – die alle gleich aussehen – am einfachsten hintereinander weg erstellen?

Das geht ganz einfach über einen For-Loop (R-Enthusiasten werden an dieser Stelle darauf hinweisen, dass man dafür doch auf jeden Fall die apply-Familie oder das Package purrr verwenden sollte. Macht auch Sinn, aber vermutlich ist es für Leute aus anderen Programmiersprachen einfacher, wenn wir erstmal bei for bleiben.)

Wie gehen wir vor?

  1. Wir erstellen für ein Land die Grafik in Datawrapper so, wie sie aussehen soll.
  2. Lade die Metadaten dieser Grafik in R: metadata_chart <- dw_retrieve_chart_metadata(chart_id, api_key)
  3. Wir speichern den visualize-Abschnitt der Metadaten lokal ab. Zum Beispiel als visualize.RData:
    visualize <- metadata_chart[["content"]][["metadata"]][["visualize"]]
    saveRDS(visualize, "visualize.RData")
  4. Visualize enthält alle optischen Vorgaben unserer Grafik. Wir können die der API mitgeben, wenn wir eine neue Grafik erstellen.
    Jetzt geht also der Loop los – über einen Vektor mit den Ländern. Grundsätzlich sieht der irgendwie so aus:
    for (Land in Laender_liste) {
    rohdaten %>%
    filter(Staat_in_Rohdaten == Land)
    }
  5. Für jedes dieser Länder erstellen wir eine neue Datawrapper-Grafik mit dw_create_chart(). Die neue Chart-ID bekommen wir direkt von der API zurückgeliefert und können sie im weiteren Verlauf benutzen:
    current_chart <- dw_create_chart(title = paste0("Chart für ", Land),type = "d3-lines")
  6. Damit auch die Visualisierungen richtig angezeigt werden, schicken wir der neuen Grafik direkt noch ein dw_edit_chart() hinterher:
    dw_edit_chart(chart_id = current_chart, visualize = visualize)
    [Eventuell kann man an dieser Stelle auch schon Daten mit dw_data_to_chart() hochladen.]
  7. Praktisch wäre es jetzt noch, wenn wir einen Überblick bekämen über alle Iframes und URLs unserer neu erstellten Grafiken. Dafür nutzen wir die dw_publish-chart-Funktion. Die kann ein Objekt zurückgeben, das die gewünschten Infos enthält und die wir abspeichern.
    Vor unseren Loop erstellen wir dafür eine leere Liste…
    result_list <- list()
    … die wir in jedem Loop-Durchgang (also für jedes Land) weiter befüllen:
    published_chart <- dw_publish_chart(current_chart)

    result_list[[i]] <- data.frame(id = area_id, country = area_name, url = published_chart$publicUrl, iframe = published_chart$iframeCode, chart_id = published_chart[["content"]][["data"]][[1]][["id"]])
  8. Die Grafiken sind erstellt. Damit wir beim Aktualisieren auch alle Chart-IDs beisammen haben, speichern wir result_list am besten irgendwo lokal als Dataframe ab:
    result_df <- dplyr::bind_rows(result_list)
    saveRDS(result_df, "chart_ids.RData")
  9. Für die Aktualisierung loopen wir dann einfach über result_list und verändern die Charts: die Daten mit dw_data_to_chart, die Titel, Introtexte oder Anmerkungen mit dw_edit_chart.

Den gesamten Code für so einen Loop habe ich hier in einem Github Gist verlinkt.

2. Datawrapper-Grafiken als Bilder ausgeben

In einem weiteren Schritt können wir aus den vielen Grafiken auch Bilder erstellen. Zum Beispiel für einen Small-Multiple-Überblick sein. Also viele kleine Grafiken nebeneinander.

Wir können dafür wieder den vorherigen Loop verwenden. Dazu die Funktion dw_export_chart():
png_chart <- dw_export_chart(
chart_id = current_chart,
type = "png",
unit = "px",
mode = "rgb",
width = 200,
height = 300,
plain = TRUE,
scale = 2)

In diesem Beispiel geben wir ein PNG mit 200 Pixeln Breite und 300 Pixeln Höhe aus, doppelt skaliert (scale), Titel und Anmerkungen werden nicht angezeigt (wegen: plain = TRUE). Mit der Funktion image_write aus dem magick-Package können wir die Grafiken dann lokal speichern:

image_write(png_chart, "output.png")

Dann laden wir die Bilder irgendwo hoch, und bauen mit HTML eine Überblicksseite, in die wir alle einbinden.

3. Tooltips über die Datawrapper-API verändern

Karten und Scatterplots in Datawrapper können beim Hovern oder Klicken Tooltips anzeigen. Auch die kann man ziemlich einfach über die API verändern. Das kann zum Beispiel praktisch sein, wenn man bestimmte Daten dynamisch dazugibt oder eben nicht.

Ein Beispiel: Ich scrape für eine Zusatzinfo eine bestimmte Seite. Diese Info will ich eigentlich immer in meiner Grafik anzeigen, aber was, wenn die Seite plötzlich offline ist? Ich könnte auf ein Fallback zurückspringen, ich kann mich aber auch entscheiden, diese Info dann nicht anzuzeigen. Dafür muss ich die Tooltips verändern können.

Am einfachsten ist das Vorgehen, wenn ich die Tooltips über das grafische Nutzerinterface anlege. Ich kann sie dann über dw_retrieve_chart_metadata() ganz einfach abrufen und verändern. Der Tooltip liegt unter: metadata_chart[["content"]][["metadata"]][["visualize"]] und besteht aus drei Abschnitten:

  • body: ist der Haupttext des Tooltipps. Der Inhalt kann mit HTML und CSS strukturiert werden (wie auch im GUI). Um Variablen aus den Daten zu verwenden nutzt man dieses Format: {{ variable_name }}.
  • title: ist – wie der Name vermuten lässt – die Überschrift des Tooltips. Auch hier kann man Variablen verwenden, wie im body.
  • fields: ist eine Liste, die die Zuordnung von Variablen im Tooltip und Variablen in den Daten festlegt. Zum Beispiel so:
    fields = list(
    "variableTooltip1" = "VariableData1",
    "variableTooltip2" = "VariableData2"
    )
    Im einfachsten Fall heißen die beiden Variablen einfach auf beiden Seiten gleich.

Um den Tooltip zu verändern nutzen wir dw_edit_chart():

dw_edit_chart(chart_id, visualize = list(
tooltip = list(
body = "{{ variableTooltip1 }} has value {{ variableTooltip2 }}.",
title = "{{ variableTooltip1 }}",

fields = list(
"variableTooltip1" = "VariableData1",
"variableTooltip2" = "VariableData2"
)
)))

Screenshot einer Datawrapper-Grafik mit einem Tooltip über einer Deutschland-Karte

4. Kartenlegende handy-freundlich

Datawrapper hat inzwischen richtig viele Möglichkeiten, Karten zu erstellen. Gerade bei Choroplethenkarten gibt es aber ein Problem: Auf kleinen Bildschirmen wird die Karte so weit zusammengestaucht, dass die Legend oft Teile der Daten überlagert – und manche Bereich dadurch nur schwer zu lesen sind. Ein Workaround ist es, den Zoom einzuschalten. [Edit: Am 29.09.20 hat Datawrapper ein großes Update veröffentlicht – mit neuer Legende]

Eine andere Variante: Die Legende in die Unterzeile der Grafik zu verlagern. So geht man dafür vor:

  1. Erstelle eine Choroplethenkarte in Datawrapper: Suche eine Basiskarte aus, und verbinde die Karte mit den Daten (über eine gemeinsame Spalte, z.B. die AGS, oder ISO-Codes). Überprüfe dann einmal kurz, ob die Legende auf der Karte richtig angezeigt wird. [Das geht auch mit DatawRappr]
  2. Lade die Metadaten der Karte in einem R-Skript: metadata_chart <- dw_retrieve_chart_metadata(chart_id, api_key)
  3. In metadata_chart finden wir dann alle Infos, die unsere Karte beschreiben. Die Legende finden wir im Abschnitt metadata_chart[["content"]][["metadata"]][["visualize"]][["categories"]]. Der Einfachheit halber können wir diesen Abschnitt auch einfach schnell als Variable rausziehen:
    new_legend <- metadata_chart[["content"]][["metadata"]][["visualize"]][["categories"]]
  4. Diesen Abschnitt geben wir in die neue Funktion dw_legend_to_string. Sie gibt die Legende dann als HTML-Code zurück (alternativ auch als Textstring oder Vektor), die wir einfach als Unterzeile in Datawrapper hinterlegen können:
    intro_text <- dw_legend_to_string(new_legend, return_val = "html")
  5. Wir updaten die Grafik mit:
    dw_edit_chart(chart_id, api_key, intro = intro_text)

So sieht das Ergebnis aus:

Screenshot einer Datawrapper-Karte mit einer Legend, die handyfreundlich ist.

Introducing DatawRappr

Datawrapper ist eines der erfolgreichsten Visualisierungstools für Journalisten. Mit einer neuen Erweiterung können die Daten aus R jetzt auch ohne Umwege in Datawrapper-Grafiken geladen werden.

Nein, dieser Blogpost soll keine Werbung für Datawrapper werden. Und der „Tippfehler“ im Titel ist gar keiner (na, wer hat sich gewundert?). Ich will in diesem Post kurz beschreiben, warum ich eine Bibliothek für die Statistiksoftware R geschrieben habe, die auf die Datawrapper-API zugreift. Und weil viele dieser R-Erweiterungen gerne mit dem Namen der Software spielen (ihr Vorgänger hieß übrigens S), wollte ich dem in nichts nachstehen: DatawRappr.

In vielen meiner Arbeitsstellen wurde Datawrapper eingesetzt. In meinem aktuellen Job visualisieren wir damit alle möglichen Grafiken auf der Homepage, oder erstellen damit schnelle Karten in Breaking-News-Situationen.

Inzwischen tauchen die Grafiken sogar schon in der gedruckten Zeitung auf:

https://twitter.com/Datawrapper/status/1175365864406822912

[/cookie]

In der Regel nutzen wir Datenjournalisten für unsere Auswertungen die Software R. Sie ist frei verfügbar und hat eine riesige Community, die für jeden Anwendungsfall eigene Erweiterungen geschrieben hat. (Vor allem aus der Informatik-Richtung kommt Python, die Sprache kann quasi dasselbe. Manche Leute mögen die eine, andere die andere mehr.)

[Mehr zu R habe ich in einem eigenen Blogpost aufgeschrieben.]

Um die Daten von R in Datawrapper zu bekommen, ist momentan noch ein Umweg nötig:

  • Entweder wir speichern die Ergebnisse für die Grafik als CSV und copy&pasten sie in Datawrapper (oder laden die CSV dort hoch)
  • Oder wir nutzen die Bibliothek clipr, die die Ergebnisse der Berechnungen in die Zwischenablage kopiert:

In einem aktuellen Projekt wollen wir aber automatisiert und regelmäßig Berechnungen durchführen (die Daten verändern sich ständig), und daraus Datawrapper-Grafiken generieren. Wir wollen aber ungern dauernd selbst daran denken müssen, die Grafiken zu aktualisieren. Außerdem müssen wir manchmal nicht nur die Daten, sondern auch die Beschreibungstexte ändern.

Die Datawrapper-API

Zum Glück hat Datawrapper dafür eine Lösung: Die API.

Über diese Schnittstelle können wir auf alle Funktionen zugreifen, die Datawrapper auch über sein Web-Interface anbietet. Gerade wurde die API von Version 1 auf Version 3 geupgradet. (Mehr dazu hat Datawrapper hier gebloggt)

Damit man direkt aus R darauf zugreifen kann, habe ich also die R-Erweiterung geschrieben. Mit ihr kann man zum Beispiel:

Was genau DatawRappr kann – und wie es genau funktioniert, steht in der Dokumentation. Zwar ist die Erweiterung schon in Version 1.0, aber vermutlich wäre 0.9 – also eher eine Beta-Version – angebrachter. Noch ist sie einfach zu wenig getestet, vor allem auf Windowssystemen. Aber: Sie geht! 😉

Infos zu DatawRappr

Der Code von DatawRappr steht auf Github. Es gibt eine eigene Dokumentation dazu.

Installiert wird es ganz einfach in R mit dem Package devtools:

Überstunden-Tracking mit R und IFTTT

Previewbild eines Balken-Diagrams mit meinen Überstunden

Der Europäische Gerichtshof will, dass Arbeitgeber die Arbeitszeit ihrer Mitarbeiter erfassen. Bis das eingeführt wird, behelfe ich mir selbst.

Ein Urteil aus Luxemburg hat die Arbeitgeber ziemlich durchgeschüttelt. Der Europäische Gerichtshof hat entschieden, dass Arbeitgeber die Arbeitszeiten von ihren Angestellten systematisch erfassen müssen. Für die Arbeitgeber das Ende der flexiblen Arbeitszeiten und der Vertrauensarbeitszeit. Für die Angestellten aber wohl die Chance auf mehr Gesundheit. Denn Überstunden machen krank, hat zumindest eine Studie der Unis Halle-Wittenberg und Erlangen-Nürnberg für Angestellte im öffentlichen Dienst herausgefunden.

Nicht nur deshalb, sondern vor allem, weil ich einen Überblick über meine Arbeitszeiten haben wollte, habe ich im Januar begonnen, zu tracken, wann ich meine Arbeit betrete, und wann ich sie verlasse. Das klappt gut, wenn man einen festen Ort hat, den man morgens betritt.

Mein Handy erkennt, wann ich die Arbeit betrete und verlasse

Ich nutze für mein Tracking IFTTT. Das steht für „If This Then That“ – eine Webseite, auf der die Nutzer verschiedene Webanwendungen zusammenbinden können. In meinem Fall benutze ich deren App auf meinem Handy mit einem sogenannten „Geo-Fencing“. Wie der Name andeutet, lege ich einen „umzäunten“ Bereich fest, durch den eine Aktion ausgelöst wird, wenn ich ihn betrete oder verlasse. In meinem Fall schreibt die App dann die Uhrzeit und entered oder exited in ein Google Spreadsheet.

So sieht das Google Spreadsheet mit den Rohdaten aus.

Diese Apps könnte man selbst entwickeln. Bei IFTTT ist die Infrastruktur aber schon vorhanden. Und andere Entwickler haben diese Schnittstellen schon gebaut. Ich konnte sie also ganz einfach wiederverwenden.

So sieht das Applet in IFTTT aus.

Von den Daten zur Auswertung

Die Daten laufen also seit Januar in das Spreadsheet ein. Doch ich wollte ja auch irgendwie davon profitieren, dass ich diese Daten erhebe. Meine Idee: Jeden Freitag bekomme ich eine Übersicht meiner Überstunden für die vergangene Woche per Mail geschickt.

Zunächst habe ich ein Auswertungsskript geschrieben. Dafür nutze ich diese Bibliotheken in R:

In meinem Workflow downloade ich die Daten aus dem Spreadsheet und arbeite dann mit ihnen weiter. Das geht ganz einfach mit einem Spreadsheet, das öffentlich gestellt wurde. Das kann man als CSV herunterladen: https://docs.google.com/spreadsheets/d/[ID zum Spreadsheet]/export?format=csv

In R wandle ich die computer-ungeeignete Datumsangabe in ein Format um, mit dem ich weiterrechnen kann. Außerdem berechne ich Wochentag und Kalenderwoche:

Und dann gibt’s’s auch schon erste Ergebnisse. Ich berechne für jeden Arbeitstag die Differenz zwischen den Soll- und Ist-Stunden. Weil ich 36,5 Stunden in der Woche arbeiten muss, komme ich auf 7,3 Stunden pro Tag (ohne Pausen). Das fasse ich dann nach KWs zusammen:

Das Ergebnis sieht in R so aus:

Die Wochenarbeitszeiten in R

Mit zwei Filterbefehlen kann ich aus diesen Daten schon ein bisschen Text für meine Mail generieren:

berechnet mir, wie viele Überstunden ich in der vergangenen Woche gemacht habe. Mit einem if_else bekomme ich dann eine Aussage, welches Vorzeichen dieser Wert hat – und kann daraus Worte generieren:

Das Ergebnis wird dann zu text_result zusammengebunden und ergibt den veränderbaren Text für meine Mail:

Damit das ganze anschaulicher wird, gebe ich außerdem noch zwei Grafiken aus.

Der E-Mailtext body_text selber ist eigentlich nur ein Zusammenfügen von Bruchstücken in HTML:

Mit der Bibliothek MailR verbinde ich mich dann mit meinem Mailaccount und schicke die Mail ab:

Das Ergebnis sieht dann auf dem Handy so aus:

Screenshot aus der Arbeitszeiten-Mail auf dem Handy

Webscraping in Python 3: Wie ich es mache

Eine alte Datenjournalistenregel besagt: Wenn Du es einem Praktikanten geben willst, schreib einen Scraper. Stimmt nicht immer, aber oft. Denn grundsätzlich geht das sehr einfach. Ein Tutorial.

Mehr lesen

Von einem Ort zum anderen

Distanzmatrix der U6 in München.

Danke, Google Maps. Wer hätte vor zwanzig Jahren gedacht, dass man heute keinen Landkarten mehr lesen können muss, um an sein Ziel zu kommen? Aus journalistischer Sicht lassen sich mit Kartendaten zudem richtig coole Geschichten erzählen. Und damit meine ich nicht, irgendwelche Punkte auf eine Karte zu setzen, hinter denen sich Popups öffnen. Ich meine Geschichten, die mit geografischen Einheiten spielen.

Mehr lesen

Wie ich R gelernt habe

Inzwischen professionalisiert sich der Datenjournalismus. Es gibt immer noch Kollegen, die es schaffen, mit Excel Auswertungen zu machen. Das geht. Aber es geht auch anders. Mit R zum Beispiel.

Mehr lesen

Freie Karte für freie Bürger

Wie oft denkt man über folgende Fragen nach:

  • Wo ist der nächste Briefkasten?
  • Wo ist die nächste U-Bahnstation?
  • Wo ist der nächste Spielplatz?

 

Ganz alltägliche Fragen, für die es zahlreiche Apps gibt, um sie zu beantworten. Aber: Es gibt auch ein Tool, dass alle diese Fragen beantworten kann – und darüber hinaus noch viele mehr. Und das beste: Es bietet die Antworten maschinenlesbar an, unter einer freien Lizenz. Es geht um die Open Street Map.

Das Projekt exisitert seit 2006 und hat sich zum Ziel genommen frei verfügbare Geodaten anzubieten, damit die Nutzer daraus Landkarten bauen, oder per GPS navigieren können. Während die normalen Kartenabieter, wie Google oder Apple, ihre Karten unter Lizenz stellen, können wir die OSM-Daten frei benutzen, nur eine kleine Quellenangabe ist fällig.

Die OSM abfragen

Wie wohl die meisten Geodaten besteht die OSM aus drei Hauptbestandteilen: Punkten (Nodes), Kanten (Ways) und Verbindungen (Relations). Die haben nicht nur Koordinaten, sondern können auch Key-Value-Paare besitzen, die beschreiben, was die einzelnen Bestandteile sind. Telefonzellen heißen zum Beispiel: amenity = telephone, Bahnhöfe railway = station. Diese Kombinationen heißen: Tags. (Zehn nützliche und/oder lustige Tags habe ich hier zusammengeschrieben)
Besagte Telefonzellen können dann aber noch mehr Infos haben: Den Betreiber (operator = Deutsche Telekom AG), eine Angabe, ob sie überdacht sind (covered = yes/no) oder sogar die Telefonnummer. Einen guten Überblick darüber, was ein Punkt für Informationen haben kann, liefert Nominatim (einfach mal nen Ort eingeben).

Mit der API lässt sich alles finden

Über die OSM-Karte kann man sich das anzeigen lassen, zur automatisierten Abfrage gibt es eine API – die Overpass API. Inzwischen hat die so viele Instanzen, dass man damit ordentlich arbeiten kann. (Mein Haupt-Nachschlagewerk dafür ist das Wiki hier, mit vielen Beispielen.) Sehr cool finde ich, dass man mit Query-Forms sogar ohne ein Skript zu schreiben, abfragen kann. Und auch die zahlreichen Exportoptionen (JSON, XML, CSV) reichen voll aus. Wie so eine Beispielquery in R aussehen kann:

 

Der API-Einstieg mit Overpass Turbo

Wer sich nicht so gut mit APIs auskennt, oder ersteinmal experimentieren will: Es gibt einen super Einstieg. Overpass Turbo. Damit kann man sehr schnell ausprobieren, was möglich ist mit der OSM, und wie eine Suchabfrage aussehen kann. Im Idealfall kann man sie über die Overpass Turbo auch gleich ausführen. Ein Beispiel: Wir wollen wissen, wo in München Bahnhöfe sind. Ich weiß nichtmal, in welcher Bounding Box (also von welchen Koordinaten umgeben) München liegt. Die OSM hat aber auch einen Geocoder, der aus Orten Koordinaten macht.

In der Overpass Turbo gibt es einen Wizard, bei dem ich meine Suchanfrage ganz easy eingeben kann:

Es baut daraus die Abfrage – ich muss gar nichts machen.

Natürlich könnte ich hier noch manuell was verändern. In der Overpass API würde ich zum Beispiel ganz oben ein [out:csv(::id,::type,"name")]; einfügen, um eine CSV-Ausgabe zu erzeugen (und ich kann genau festlegen, welche Felder ich gerne hätte. Auch kann ich mit dem Befehl area[name="München"] den Ort händisch festlegen. Es kann sich auch anbieten, für die Bahnhöfe nur nach Nodes zu suchen, oder in anderen Fällen nur nach Straßen.

Overpass Turbo schickt seine Anfrage an die Overpass API und gibt das Ergebnis als Karte zurück.

Das Ergebnis lässt sich jetzt direkt als GeoJSON, GPX oder KML exportieren. Für CSV oder XML kann man die Abfrage für die Overpass API konvertieren lassen. Overpass Turbo hilft auf jeden Fall zu checken, ob die Suchbegriffe die richtigen sind. Für größere Abfragen muss man dann aber die Overpass API nutzen, Turbo hängt sehr schnell.

Die Daten kann ich dann super visualisieren, zum Beispiel mit QGIS. Ich kann sie aber auch als Ausgangspunkt für eine weitere Analyse nutzen. Es gibt auch Anwendungsfälle, in denen mit OSM-Höhendaten 3D-Modelle gebaut wurden. Der Fantasie sind da sehr wenige Grenzen gesetzt.

10 coole OpenStreetMap-Tags

Eine kleine Zusammenstellung von verrückten und hilfreichen Tags der Punkte, Wege und Relationen der OpenStreetMap.

building=yes ist der am meisten verwendete Tag in der OpenStreetMap. Er zeigt an: Das hier ist ein Gebäude.

emergency=fire_hydrant zeigt die Position von Hydranten.

highway = ... Der Klassiker für die Suche nach Straßen. Es gibt zahlreiche Einschränkungen, zu Beispiel residential (Wohngebiet), motorway (Autobahn), pedestrian (Fußgängerzone)

highway=bus_stop zeigt Bushaltestellen.

maxspeed = 50 sucht nach Straßen, bei denen die Höchstgeschwindigkeit (in km/h) hinterlegt wurde.

religion=christian zeigt christliche Gebetsstätten – klappt auch mit anderen Konfessionen.

ice_cream = yes/no gibt an, ob es in einem amenity = restaurant/cafe oder shop = ice_cream Eis gibt.

wheelchair=yes zeigt behindertengerechte Toiletten an.

boundary=administrative + admin_level=2 gibt Verwaltungsgrenzen zurück. In diesem Fall die Staatsgrenze. Geht aber teilweise runter bis auf Stadtbezirksteile. Ein Überblick hier.

name:de:1953-1990=Ernst-Thälmann-Straße Das „de“ und die Jahreszahlen schränken ein, wie die Straße früher hieß. Bietet sich natürlich in Deutschland an, bei den Umbenennungen nach der DDR.

So lassen sich die richtigen Tags finden

Die OpenStreetMap lebt ja von den Tags – deswegen sind sie auch sehr gut dokumentiert. Ich schaue am liebsten hier im OSM-Wiki und hier bei Taginfo. Sehr anschaulich ist auch der Eintrag „How to map a“.

Durch die weitere Nutzung der Seite stimmst Du der Verwendung von Cookies zu. Weitere Informationen

Die Cookie-Einstellungen auf dieser Website sind auf "Cookies zulassen" eingestellt, um das beste Surferlebnis zu ermöglichen. Wenn du diese Website ohne Änderung der Cookie-Einstellungen verwendest oder auf "Akzeptieren" klickst, erklärst du sich damit einverstanden.

Schließen