OpenStreetMap

Nakaner's diary

Recent diary entries

Videomapping – Erfahrungen, Tipps und Tricks

Posted by Nakaner on 21 December 2015 in German (Deutsch)

Fotos Smartphone in Kfz-Halterung an Fensterscheibe

In meinem letzten Posting habe ich erklärt, wie man aus einem Video Einzelbilder extrahieren und georeferenzieren kann. Vor ziemlich genau zwei Jahren habe ich das erste Mal Videomapping zum Bahnmapping verwendet, ich blicke hier zurück und gebe meine Erfahrungen zum Besten.

Meine ersten Videomapping-Projekte

Lange Zeit habe ich bloß gefilmt. Das Smartphone mit der Kfz-Halterung an die Fensterscheibe montiert und fertig. Da ich nicht parallel einen GPS-Track aufgezeichnet habe, blieb das Verfahren elektrifizierten, mehrgleisigen Strecken vorbehalten. Nur dort stehen nämlich in ausreichend dichten Abständen Oberleitungsmasten, die man auf den Bing-Bildern gut sehen kann. Auf eingleisigen Strecken sind die Oberleitungsmasten zu nahe am Zug (oder auf der anderen Seite), sodass man gar nicht viel sieht. Alle Videos habe ich damals durch das Seitenfenster nach links hinten aufgenommen. In Deutschland fahren die Züge im rechten Gleis, sodass die Oberleitungsmasten des Gegengleises weit genug weg sind und man auch bei 120 km/h noch produktiv mappen kann. Dass ich von Anfang an nach links hinten gefilmt habe, liegt an einer Empfehlung von bigbug21, die sich gar nicht auf das Videomapping bezog, aber sich trotzdem als zutreffend erwiesen hat.

Bei der Auswertung habe ich immer ein Stückchen Video geschaut und dabei die Oberleitungsmasten gezählt. So habe ich mich von Feature zu Feature (Signale, Schilder, Hektometertafeln und andere mappenswerte Dinge) gehangelt. JOSM und der Videoplayer waren gleichzeitig geöffnet, immer ein Stückchen Video, dann wieder ein oder zwei Sachen in JOSM und dann wieder Video. Da man viel zurückspulen muss, war dieses Verfahren seeehr zeitaufwendig.

Es gab mal ein JOSM-Plugin zum Videomapping von !i!, aber das war schon Ende 2012 kaputt.

Erfahrungen

Mit der Zeit habe ich folgende Erfahrungen gesammelt:

  • Bei trübem Wetter leidet die Bildqualität. Bei Sonnenschein kann man bis 160 km/h gut mappen (bei den kleinen Signalnummern – die stehen auf weißen Tafeln am Signalmast – ist schon bei 120 km/h Schluss.
  • Bei viergleisigen Strecken kann man bei trübem Wetter die Objekte drei Gleise weiter links auch bei 200 km/h noch erkennen.
  • Vermeide dreckige Fensterscheiben. Gefühlt sehen die Fahrzeuge die letzten 18 Monate vor einem Betreiberwechsel, die zur Umbeheimatung (d.h. Verlagerung in eine andere Ecke der Republik) oder Abstellung führt, keine Waschanlage mehr von innen. Besonders auffällig war das bei DB Regio Südost und deren alten Reichsbahn-Doppelstockwagen.
  • Richte das Bild so aus, dass du das Nachbargleis nur zur Hälfte im Bild siehst (die näher bei dir gelegene Schiene des Nachbargleises nicht mehr im Video sichtbar ist). Dann kannst du trotzdem noch Weichen im Nachbargleis erkennen (unterstützen die Orientierung), hast aber Bildfläche für wichtigere Sachen.
  • Nimm nicht die Androiod-eigene Kamera-App. Sie ist für diesen Anwendungszweck unbrauchbar. Nimm stattdessen OpenCamera. Dort kannst du den Fokus fix auf Unendlich setzen. Sonst refokussiert die Kamera alle paar Sekunden.
  • Wähle in OpenCamera die SD-Karte als Speicherort (Zahnrad-Symbol → Mehr Kamera-Einstellungen → Speicherort). /storage/sdcard1 ist sowohl auf meinem Galaxy S5 als auch LG Optimus 2X die SD-Karte.
  • Leg eine schnelle und große Karte ein.
  • Schalte die maximale Helligkeit ab. Das Display braucht viel Strom. Bei meinem LG Optimus 2X brauchte das Smartphone bei maximaler Helligkeit mehr Strom beim Filmen, als das Netzteil nachliefern konnte! Stelle vor die Helligkeit so weit herunter, dass du das Display noch gut ablesen kannst. Deaktiviere in OpenCamera Zahnrad-Symbol → Benutzeroberfläche → "Maximale Helligkeit erzwingen".
  • Die Videoaufnahme wird beendet, wenn die maximale Dateigrößere erreicht ist. Bei FAT-formatierten SD-Karten sind das 4GB. Je nach Auflösung und Kompression können das 11 oder 45 Minuten sein. Du musst dann die Aufnahme wieder neu starten. Ich muss mal ausprobieren, wie Android mit ext4-formatierten Karten zurechtkommt. (Mein Linux-Rechner dürfte sich daran nicht stören)
  • Überkopf fallen auch gute Halterungen irgendwann herunter. In Doppelstockwagen (Untergeschoss ist nicht empfehlenswert) muss man daher die Halterung festhalten.
  • Die Halterung, die durch Klebstoff halten (statt durch Saugwirkung), sind ungeeignet. Sie sind lassen sich nicht beliebig oft entfernen und an eine andere Scheibe ankleben.
  • Ein Powerbank ist eine gute Investition.
  • Zum Filmen den Flugzeugmodus aktivieren. Das spart Strom. Man will ja auch nicht beim Filmen gestört werden.

Um auch Signalnummern mappen zu können (und Signale, die ich nur von hinten im Video sehe), habe ich während des Filmens gleichzeitig Signalnummern, Weichennummern und Signalbeschreibungen diktiert.

Beispiel 1 – der ICE wurde über die Güterzugstrecke Opladen–Hilden umgeleitet, da filmte ich trotz nasser Scheibe und trübem Wetter, altes Smartphone

Beispiel 2 – gute Lichtverhältnisse, aber ohne Kfz-Halterung, da daheim liegen gelassen, altes Smartphone

Mit einem Smartphone kann man nicht vernünftig nach hinten durch den unbesetzten Führerstand hindurch filmen, da die Frontscheibe zu weit entfernt ist und man deshalb den halben Führerstand mit filmen würde. Wenn jedoch am Zugschluss ein einfacher Reisezugwagen hängt, kann man durch die abgesperrte Wagenübergangstür heraus auf die Strecke filmen. Dabei entstehen dann Videos wie dieses.

Vorverarbeitung vor dem Upload

Mittlerweile entferne ich bei allen Videos, die ich auf Youtube hochlade, immer den Ton. Das geht mit folgendem ffmpeg-Befehl:

ffmpeg -i originalvideo.mp4 -an -vcodec copy ohne-ton.mp4

Folgendes Bash-Skript verpixelt (per Weichzeichner) einen Bereich des Bildes. Das sollte man tun, wenn sich fremde Fahrgäste in der Fensterscheibe spiegeln, aber man das Video veröffentlichen will. Fahrgäste, die still sitzen, bewegen sich nicht, sodass ein statisches Rechteck genügt.

#! /usr/bin/env bash
# Usage: ./remove-sound-and-blur.sh INPUTFILE WIDTH HEIGHT LEFT_MARGIN TOP_MARGIN
ffmpeg -i $1 -filter_complex "[0:v]split=2[v0][v1];[v0]crop=$2:$3:$4:$5,boxblur=10[fg];[v1][fg]overlay=$4:$5[v]" -map "[v]" -map 0:a -c:v libx264 -c:a copy -an blurred-$1

Bilder extrahieren

Mit einer vernünftigen Kamera (rurseekatze hat die meisten Videos unserer Deutschlandpass-Tour damit aufgenommen) und einem GPS-Logger sind noch ganz andere Dinge möglich. Damit kann man einzelne Frames extrahieren und diese georeferenzieren (siehe vorheriges Posting). Die Fotos kann man direkt in JOSM laden. Der Umweg über Mapillary ist Zeitverschwendung. Mapillary komprimiert die Bilder noch ein bisschen, sodass kleine Details (Signalnummern) flöten gehen und verpixelt gerne die wichtigen Sachen (Signalnummern). Ich habe den Eindruck, dass man bei der Auswertung von georeferenzierten Fotos aus einem Video 30 bis 40 Prozent Zeit einspart.

Folgende Frameraten sind empfehlenswert:

  • Blick nach hinten oder vorne: 1 fps bis etwa 120 km/h, darüber 2 fps
  • Blick schräg zur Seite: 2 bis 4 fps bei etwa 120 km/h

Brücken, die über die Gleise hinwegführen und einen Schatten auf das Gleis werfen, eigenen sich gut, um die Georeferenzierung zu kontrollieren. Beim langsamen Anfahren im Bahnhof fällt ein Fehler von 2 Sekunden in der Zeit kaum auf. Bei schneller Fahrt merkt man das aber.

Georeferenzierte Bilder aus Videos extrahieren – Low-Cost VIS

Posted by Nakaner on 12 December 2015 in German (Deutsch)

Videoaufname-Ausrüstung in einem Talent 2

Zur Erfassung von Eisenbahndaten (insbesondere Signale) haben sich in den vergangenen zwei Jahren selbst aufgenommene Videos als eine sehr gute Quelle herausgestellt. Man fährt die Strecke zwei- bis dreimal ab und kann dann daheim in aller Ruhe das Video auswerten. Somit kann man mit einer Reise kreuz und quer durch Deutschland in kurzer Zeit viele Daten erfassen. (Erfahrungsgemäß braucht man für 5 km 1 Stunde Arbeitszeit zum Auswerten, in Bahnhöfen mit vielen Gleisen und Signalen entsprechend länger)

Auf elektrifizierten Strecken erfolgt die Georeferenzierung anhand der Oberleitungsmasten. Man sieht sie markant im Video und ihren Schattenwurf auf den Bing-Bildern. Dabei zählt man die Oberleitungsmasten ab einem markanten Punkt (z.B. Bahnübergang, Brücken oder andere markante Objekte neben der Strecke). Zwischen zwei Masten wird interpoliert oder – bei Signalen mit hoher Bauhöhe – ist der Schattenwurf des Signalmastens auf dem Luftbild sichtbar.

Auf nicht elektrifizierten Strecken und Strecken, deren Oberleitungsmasten auf den Bing-Luftbildern verschattet sind, gibt es keine leichte Möglichkeit aus den Bildern Positionen abzuleiten. Hier muss man sich mit der Vegetation neben der Strecke und den Schattenwürfen der Signale behelfe. Kleine Signaltafeln neben der Strecke sieht man aber nicht auf Bing (ausgenommen Bilder mit 15 cm Auflösung).

Wenn man während des Filmens einen GPS-Track aufnimmt, kann man einzelne Frames (je nach Geschwindigkeit alle ein bis drei Sekunden) extrahieren und diese mit dem GPS-Track georeferenzieren. Zur Extraktion der Frames habe ich folgenden ffmpeg-Befehl verwendet:

ffmpeg -i km144.4--Abzw-Ribbeck--Rathenow--km228.4.mts -vf yadif,fps=1 -qscale:v 2 extracted_frames/img_%05d.jpg

Der obige Befehl extrahiert ein Frame pro Sekunde und schreibt es als img_00001.jpg in das Verzeichnis extracted_frames/ (bei den weiteren Dateien wird nur die Nummer hochgezählt). Das verwendete Video wurde interlaced aufgenommen, also im Zeilensprungverfahren. Deshalb wird noch ein Deinterlace-Filter verwendet. Wer diesen nicht braucht, kann yadif, weglassen. -qscale:v 2 legt die JPEG-Kompressionsstufe fest, wir haben uns für die zweithöchste Qualitätsstufe entschieden, damit auch kleine Signalnummern noch entziffert werden können. Die resultierenden Frames sind dann etwa 350 kB und 1920x1080 Pixel groß (das ist vom Video bzw. der Kamera abhängig).

Die extrahierten Frames können in JOSM genutzt werden und/oder auf Mapillary hochgeladen werden.

Mapillary stellt zur Vorverarbeitung einige Skripte auf Github bereit. (Es wird Python 2.x verwendet)

  1. Mit python add_fix_dates.py extracted_frames/ '2015-08-23 14:05:01' 1 setze ich den Zeitstempel. 1 steht für ein Bild pro Sekunde.
  2. Mit python geotag_from_gpx.py extracted_frames/ my_gps_track.gpx 0 setze ich dann im EXIF die Position und die Blickrichtung. Letztere wird aus der Position des Bildes und des nächsten Bildes ermittelt.

Anschließend kann man die Bilder in JOSM laden (die Blickrichtung wird dort angezeigt!) oder auf Mapillary hochladen.

Ich habe auch den Video-Upload von Mapillary gestern Abend ausprobiert. Aber bis heute Mittag ist das Video nicht online, meine Fotos haben hingegen nur wenigen Minuten gebraucht, bis sie online waren.

Beim Blick nach hinten oder vorne genügt bei einer Fahrtgeschwindigkeit zwischen 160 km/h und 200 km/h (IC-Reisegeschwindigkeit auf Aus- und Neubaustrecken) eine Framerate von 1 Bild pro Sekunde. Bei 100 km/h genügen 0,5 Bilder pro Sekunde. Beim Blick nach schräg zur Seite heraus ist eine Framerate von 1 Bild pro Sekunde bei 120 km/h gerade noch so brauchbar.

Momentan verwendet meine Toolchain noch für das gesamte Video die gleiche Framerate. Wenn das Video jedoch von einem Bahnhof zum nächsten reicht, ist das ungeschickt, weil man in Bahnhofsnähe langsamer fährt.

Screenshot Foto zur Seite raus

Screenshot JOSM Foto nach hinten

In Anspielung auf das Video-Informations-System (VIS) von DB Netz nenne ich diesen Ablauf Low-Cost-VIS. Das VIS zeigt die Strecken von DB Netz aus der Lokführerperspektive. Die Bilder werden mit Messzügen alle paar Meter aufgenommen und sind georeferenziert. [1] Sie haben jedoch eine geringe Auflösung (deutlich niedriger als HD), was aber durch den geringeren Abstand der Bilder wieder aufgefangen wird. (Messzüge fahren 80 km/h) Würde man statt Smartphones oder Garmins genauere GNSS-Empfänger einsetzen, könnte man auch genauere Koordinaten erhalten. Eine Kombination aus GNSS-Empfänger und einer Consumer-Camcorder samt Akkupack könnte man auch unabhängig von Messzügen einsetzen und dann mit normalen Zügen über das Netz schicken.

[1] Siehe dazu auch "Der neue Lichtraummesszug LIMEZ III der Deutschen Bahn AG" von Holger Wirth, erschienen in der ZfV 3/2008.

Analyse des Open-Data-Angebots der DB

Posted by Nakaner on 14 November 2015 in German (Deutsch)

Die Deutsche Bahn hat vor einigen Tagen ihr Open-Data-Portal eröffnet und ein paar erste Datensätze eingestellt. Ich mir diese Datensätze jetzt mal angesehen und mit eigenem Wissen und OSM-Daten verglichen.

Die meisten Datensätze stehen unter der CC-BY 4.0. Da die CC-BY eine Namensnennung verlangt, dürfen diese Daten derzeit noch nicht für OSM genutzt werden. Die DB ist gewillt, uns eine Ausnahmegenehmigung zu erteilen. Ich rechne damit, dass wir diese im Laufe der kommenden Woche erhalten.

UPDATE: Die Erlaubnis liegt uns NOCH NICHT VOR. Bitte die Daten nicht in OSM nutzen!

Stuttgart 21

Die Datensätze von DB Projekt Stuttgart–Ulm GmbH sind die einzigen Datensätze, die derzeit unter der CC-0 verfügbar sind (und deshalb rechtlich keinerlei Beschränkungen unterliegen). Es stehen drei Datensätze zur Verfügung. Sie sind derzeit die einzigen echten Geodaten, alle anderen Datensätze im Portal sind reine Sachdaten.

  • "Geodaten der Tunnelachsen"
  • "Geodaten der Gleisanlagen"
  • "Geodaten der Webcam-Standorte"

Alle drei Datensätze werden als Shapefiles mit EPSG:3857 (Web Mercator) bereitgestellt. Es ist davon auszugehen, dass bei der DB selbst ein andere Bezugssystem zur Planung verwendet wird – höchstwahrscheinlich das DB-Ref, eine Gauß-Krüger-Abbildung, die jedoch von den Gauß-Krüger-Systemen der Vermessungsverwaltungen abweicht [1]. Wie die Daten in Web Mercator transformiert wurden (das ist keine einfache Umrechnung, sondern ein Datumsübergang) wird nicht offengelegt. Diese Frage muss geklärt sein, bevor die Daten in OSM übernommen werden.

In den Datensätzen sind nur die Planfeststellungsabschnitte enthalten, die auch schon planfestgestellt sind. Der Abschnitt um den Flughafen herum fehlt. Hier läuft noch immer das Planfeststellungsverfahren.

Der Datensatz "Geodaten der Gleisanlagen" enthält bei den Tunnel die Flächen der Tunnel, der Querschläge, der Rettungszufahrten, die Rettungsplätze an den Portalen, die Stollen der Zwischenangriffe sowie einige oberirdische Streckenabschnitte (viele sind es ja nicht). Auch die neuen Tunnel der Stadtbahnstrecken um den Hauptbahnhof, die verlegt werden, sind enthalten.

Der Datensatz "Geodaten der Tunnelachsen" enthält die Achsen der Tunnel. Hier sind nur die Tunnel mit Gleisen enthalten (also keine Querschläge und Zwischenangriffsstollen). Beim Fildertunnel fehlt die Oströhre, welche im Datensatz "Geodaten der Gleisanlagen" enthalten ist. Bei der Stadtbahntrasse unter der Heilbronner Straße fehlt auch ein Teil einer Röhre, der im anderen Datensatz als Fläche enthalten ist. Zwischen Bad Canstatt und Untertürkheim sind auch oberirdische Abschnitte enthalten, die im anderen Datensatz fehlen.

"Geodaten der Webcam-Standorte" enthält die Webcam-Standorte als Punkte. Dieser Datensatz ist nur bedingt brauchbar. Er enthält Links auf die Bilder der Kameras. Die Punkte befinden sich nicht am Standort der Kamera, sondern mitten im Blickfeld der Kamera. Dieser Datensatz ist ungeeignet.

Aufgrund der fehlenden Informationen zum Datumsübergang treffe ich hier keine Aussagen über die Lageunterschiede zwischen den bestehenden OSM-Daten und den Daten der DB.

Stationsdaten

Die Datensätze "Stationsdaten" und "Bahnsteigdaten" sind nach DB Station & Service AG und DB Regionetz Infrastruktur (RNI) getrennt. RNI ist eine Tochter der DB, die in einigen Netzen regionaler Bedeutung die Gleise und Bahnhöfe betreibt. Der Rest (der Großteil aller DB-Stationen) wird von DB Station & Service AG betrieben.

Diese Datensätze stehen als CSV und XSLX zur Verfügung. Die Tabelle Stationsdaten enthält folgende Spalten:

  • Bundesland
  • BM (Bahnhofsmanagement) – enthält einen der folgenden Werte: Aachen, Augsburg, Bamberg, Berlin, Berlin Hauptbahnhof, Bielefeld, Bonn, Braunschweig, Bremen Hbf, Chemnitz, Cottbus, Darmstadt, Dortmund, Dresden, Duisburg, Düsseldorf, Erfurt, Essen, Frankfurt (Oder), Frankfurt a.M., Freiburg, Friedrichshafen, Gera, Gießen, Göttingen, Hagen, Halle (Saale), Hamburg, Hannover, Kaiserslautern, Karlsruhe, Kassel, Koblenz, Köln, Leipzig, Magdeburg, Mainz, Mannheim, München, Münster (Westf), Nürnberg, Osnabrück, Potsdam, Regensburg, Rosenheim, Rostock, Saarbrücken, Schleswig-Holstein, Schwerin, Stralsund, Stuttgart, Ulm, Würzburg
  • Bf. Nr. (Bahnhofsnummer) – eine ein- bis vierstellige Nummer für jeden Bahnhof, Nr. 1 bis 7079 sind anscheinend alphabetisch vergeben, neuere Stationen haben Nummern ab 7081 erhalten. Die Nummer wird im Datensatz Bahnsteigdaten verwendet, in der Reiseauskunft kann man sie nicht verwenden.
  • Station – der Name der Station (Kommentar siehe unten)
  • "Bf DS100 Abk." – Betriebsstellenkürzel nach DS100, ein alphabetischer Code (gelegentlich mit Leerzeichen), bei Stationen, die aus mehreren Betriebsstellen bestehen (z.B. Berlin Hbf) ist nur ein Kürzel angegeben
  • Kat. Vst – Kategorie der Verkehrsstation. Die DB hat für jede Station eine Bahnhofskategorie festgelegt (siebenteilige Skala). Danach werden die Stationsgebühren berechnet, die ein Eisenbahnverkehrsunternehmen bei einem Halt dort zu entrichten hat. Eine Liste in PDF-Form dürfen wir schon seit 2008 nutzen, getaggt wird das mit railway:station_category. Derzeit besteht jedoch der Trend bei den Bahnmappern, diese Daten durch ein selbstkreiertes internationaleres Schema zu ersetzen, welches näher an der Fahrplanrealität ist und von kaufmännischen Interessen befreit ist.
  • Straße
  • PLZ
  • Ort
  • Aufgabenträger – die Gesellschaft, die dort den Schienenpersonennahverkehr bestellt
  • Verkehrsverbund – "0", falls keiner existent
  • Fernverkehr – "ja" oder "nein" (siehe unten)
  • Nahverkehr – dto.

In der Spalte "Station" kommen Abkürzungen vor. Regionen, die als Namenszusatz verwendet werden (z.B. "Württ") sind abgekürzt. Ortsnamen sind ausgeschrieben. In Berlin scheint sich die Schreibweise des Stationsnamens meist an die Beschilderung vor Ort zu halten. Außerhalb Berlins stimmt das nicht. In den Daten steht "Wolfgang (Kr. Hanau)", vor Ort steht aber nur "Wolfgang". Selbiges gilt für "Forchheim (b Kalrsruhe)", welche auf den Schildern auf dem Bahnsteig "Forchheim", auf dem gelben Aushangfahrplan vor Ort "Forchheim (b Karlsruhe)" heißt. Die zum Fahrplanwechsel im Dezember 2014 erfolgte Umbenennung von "Bad Friedrichshall-Jagstfeld" in "Bad Friedrichshall Hbf" ist enthalten.

Die Daten in den Spalten Straße, PLZ und Ort sind mit denen auf bahnhof.de identisch. Diese stammen aus Geocoding. Man sieht das ganz schön an Haltepunkten, in deren Umgebung keine Gebäude (also Objekte mit Hausnummer) stehen. Für Seddin wird als Adresse "Kunersdorfer Str. 1, 14554 Seddin" geführt. Dieses Gebäude steht aber auf der anderen Seite des Güterbahnhofs und ist 380 bis 390 Meter vom Haltepunkt entfernt! Desweiteren sind diese Daten veraltet. Aufgrund einer Kommunalreform heißt die Gemeined mittlerweile "Seddiner See", Ortsteil Neuseddin. Mit dem Haltepunkt Baitz ist es sogar noch schlimmer. Hier wird als Adresse "Bahnhofstr. 1, 14822 Brück" genannt. Das ist 5,2 km Luftlinie entfernt! Ok, wer dort landet ist nur noch 760 m Luftlinie vom Bahnhof "Brück (Mark)" entfernt, der an derselben Strecke eine Station weiter Richtung Berlin liegt. ;-)

Interessant ist, dass bei den neuen Stationen entlang der Strecke Bad Friedrichshall Hbf–Sinsheim-Steinsfurt, die erst seit Anfang Mai bedient werden, die Adresse fehlt. Auf bahnhof.de steht hingegen eine.

Ich frage mich, weshalb DB Station & Service AG die Adressdaten überhaupt unter der CC-BY 4.0 veröffentlicht hat. Hat man dort keine Kenntnis vom Datenbankschutzrecht?

Fazit: Wer sich auf die Adressen in diesen Daten und auf bahnhof.de verlässt, ist verlassen. In OSM gehören die Daten auch nicht. Sie sind erstens urheberrechtlich unsauber und zweitens verschlechtern sie die Datenqualität von OSM.

Die Spalten Aufgabenträger und Verkehrsverbund habe ich nicht geprüft. Bei der Spalte "Fernverkehr" gab es wieder Anlass zum Lachen. In weiten Teilen ist die Spalte "Fernverkehr" zwei Jahre alt, stellenweise fünfzehn.

  • Dillenburg, Haiger, Herborn (Dillkreis) (vor zwei Jahren ein EC-Zugpaar)
  • Bad Nauheim (letztes Jahr einzelne Züge in der Tagesrandlage),
  • Bullay DB, Cochem, Wittlich Hbf, Trier Hbf (seit einem Jahr fahren keine Fernzüge mehr nach Trier)
  • Bremerhaven Hbf, Bremerhaven-Lehe Pbf
  • Lehrte
  • Tarp
  • Munster (Örtze)
  • Klinge, Forst (Lausitz)
  • Kronach
  • Pegnitz
  • Schweinfurt Hbf
  • Lutherstadt Eisleben, Sangerhausen, Nordhausen, Leinefelde, Heilbad Heiligenstadt
  • Magdeburg-Buckau
  • Kehl
  • Eberbach (da ist bestimmt niemand in der Zeile verrutscht, weder Dallau noch Eicholzheim haben/hatten Fernverkehr)
  • Heilbronn Hbf (schön wär's, den IR Rennsteig hat man uns 2001 genommen. Oder glaubt DB Station & Service AG an den Erfolg von Der Schnellzug?)

Dessau Hbf hat der Tabelle zufolge keinen Fernverkehr. Das stimmt leider nicht. Freitags hält gegen halb fünf nachmittags der IC 1933 (hat keinen Gegenzug). Er tat das auch schon zeitweise im Fahrplanjahr 2014. Auch Hünfeld fehlt. Dort hält der Mo-Fr IC 1950 Berlin–Leipzig–Bebra–Frankfurt (Di-Fr nur ab Bebra). Der Gegenzug dazu, der IC 2398 hält nicht in Schlüchtern.

Bahnsteigdaten

Auch dieser Datensatz ist nach DB Station & Service AG und RNI getrennt. Wie schon in den Kommentaren im Open-Data-Portal von anderen Usern kritisiert, werden Kommata als Dezimaltrenner verwendet. Folgende Spalten sind vorhanden:

  • bf_nr (Bahnhofsnummer, siehe dazu das Stationsverzeichnis)
  • bahnsteig – Bahnsteigbezeichnung (ein Bahnsteig hat mehere Kanten!), z.B. B01 für Gleis 1, B02 für Gleis 2+3
  • bahnsteigkante_bw_auf_bs – wie vor Ort angeschrieben, z.B. "1", "2", "3"
  • örtliche_bezeichnung – z.B. "Gleis 1", "Gleis 2"
  • nettobaulängen_m – Länge der Bahnsteigkante. Die nutzbare Bahnsteiglänge ist kürzer, das merkt man an Stumpfgleisen, da hier noch ein paar Meter für den Prellbock verlorengehen
  • höhe_bahnsteigkante_cm – Höhe über Schienenoberkante

Bei all meinen Stichproben mit Bahnhöfen, die kürzlich neue Bahnsteige erhalten haben, waren die Bahnsteighöhen aktuell: Weinheim (Bergstraße), Bad Friedrichshall Hbf, Crivitz, Roßlau (Elbe) Pbf, Coswig (Anhalt). Wie es mit Höhen im Altbestand aussieht, habe ich nicht geprüft.

Ein Problem sind hingegen die Bahnsteige, die in ihrer Länge unterschiedlich hoch sind. In Osterburken ist der Bahnsteig an Gleis 1 südlich des Reisendenübergangs 76 cm über Schienenoberkante hoch (S-Bahn-Standard), nördlich davon sind es unter 40 cm. In den DB-Daten steht der Bahnsteig sei 76 cm hoch und 235 m lang. Verschwiegen wird, dass ca. 90 m davon nicht 76 cm hoch sind. An Gleis 2 ist es genauso.

An ausgewählten Stationen habe ich die Bahnsteiglängen mit denen in OSM verglichen. Die OSM-Bahnsteiglängen sind nicht immer verlässlich. Oft sind Bahnsteige von Bing abgezeichnet. Gerade bei unbefestigten Bahnsteigen, deren Oberfläche wie eine gemähte Wiese aussehen, kann man auf dem Luftbild schlecht Anfang und Ende ermitteln. Daher habe ich Bahnsteige verglichen, an denen ich schon vorbeigefahren bin und sie dabei per Videomapping erfasst habe. An allen Bahnsteigen lagen die Unterschiede im Bereich der Messgenauigkeit. Diese Daten sind ok (und aktuell).

Betriebsstellenverzeichnis

Dieser Datensatz enthält die DS100-Kürzel für Betriebsstellen. Auch nicht bundeseigene Eisenbahnen und ausländische Betriebsstellen sind enthalten. Unter Betriebsstellen versteht man Bahnhöfe, Anschluss-, Ausweichanschluss-, Abzweig-, Überleitstellen, Haltepunkte, Blockstellen, Streckenwechsel, Betreiberwechsel usw. Der Datensatz hat folgende Tabellen:

  • Abk (Abkürzung)
  • Kurzname
  • Ländercode
  • Locationcode
  • Gültig ab

Kurzname ist wirklich ein Kurzname. Für maschinelle Anwendungen ist er nur sehr eingeschränkt geeignet. Den Langnamen kann man sich leider nicht einfach aus dem Stationsverzeichnis holen (in beiden steht das DS100-Kürzel), da erstens nicht alle Betriebsstellen Bahnhöfe oder Haltepunkte des Personenverkehrs sind und zweitens eine Station (von DB Station & Service AG) aus mehreren Betriebsstellen bestehen kann.

Bei den Nicht-DB-Betriebsstellen sind die Spalten "Ländercode", "Locationcode" und "Gültig ab" nicht ausgefüllt. Ausländische Betriebsstellen kann man aber an einem X als ersten Buchstaben im Kürzel erkennen.

Der Ländercode entspricht nicht dem politischen Land entspricht, in dem die Betriebsstelle liegt. Er ist vielmehr eine Kennzeichnung, dass die Betriebsstelle von der DB betrieben wird. DB-Bahnhöfe auf Schweizer Staatsgebiet, die aufgrund des Staatsvertrags von 1852 von der DB betrieben werden, tragen ein deutsches Kürzel (R* für Direktion Karlsruhe) und haben den Ländercode "DE".

Netzradar

Den Netzradar-Datensatz habe ich mir nicht genauer angesehen, da er für OSM nicht interessant ist.

[1] Da Vermessung Ländersache ist, gab/gibt es in Deutschland 16 verschiedene geodätische Bezugssysteme. An den Ländergrenzen gibt es Spannungen zwischen den Systemen von bis zu 2 Meter! Aus diesem Grund pflegt die DB ihr eigenes geodätisches Bezugssystem, da ihre Trassen eben des Öfteren über Bundesländergrenzen hinweggehen.

EDIT: Typo

A Review of the Manifests of all OSM US Board Election Candidates

Posted by Nakaner on 12 October 2015 in English (English)

As a part of my work for the German Wochennotiz and multilingual weeklyOSM, I have stumbled across the manifestos of the candidates of the OSM US Board elections this week. Because a summary of all nine manifestos would be too long for a posting at weeklyOSM and Wochennotiz, I decided to write it down at my user diary .

Disclaimer

This posting contains my own opinion which is not neutral. Please read the mainfestos on your own.

I am not a member of OSM US and I do not want join. My home is Germany and my main mapping is done there.

I am not a lover of HOT and remote mapping in area where you have never been before.

Martijn van Exel

Martijn van Exel is a long time ("addicted") OSM contributor and member of the current OSM US Board. He brings up a painful subject – the community size. According to graphs at his posting, the number of active mappers in the U.S. stopped increasing about 1 1/2 years ago. These are no good news.

graph showing the zero growth of OSM in the U.S.

Figure: Zero growth of OSM in the U.S., graph by OSMStats/Martijn van Exel

He think that big conferences [like the SotM US this year in New York] will not help increasing the number of active contributors. He would like to supports smaller, local events at the places where the people live.

His manifesto looks well. I suggest you to elect him. He might change OSM US the positive way.

Elliott Plack

Elliot Plack is a very experienced ("addicted") mapper, too. He wants to work on the cooperations between OSM and the government organizations (on local level) and make them donate their data to OSM.

I think that his way cannot address the zero-growth problem shown by Martijn. He tries to compensate the missing contributors by importing data. I think that the US community has tried this already several times and it does/did not really work (see TIGER). No imported data is perfect. Imported data has to be kept up to date, this can only be done by a large active community. And how to explain someone that there are no buildings beyond the boundary of New York City?

You might vote for Elliott but I myself would not give him my first vote.

Alyssa Wright

Alyssa is no active OSM contributor. She did (account 1, account 2) mainly HOT stuff in Harare and Kathmandu, and only added a few POIs in New York City. HDYC could not find her first account and described her second account as "casual mapper". To summarize: Her editing experience is, compared to Martjin and Eliott, very low, and that is from my point of view a big contra-argument. She is the president of the current OSM US Board.

She mainly praises herself and her work for SotM-US 2015 in New York at her manifesto and wrote only one paragraph about the next year. She says that she wants to support the growth of OSM in the U.S. (If you read Martijn's manifesto, you might have noticed that this is wrong. OSM does not grow in the U.S. anymore.) She wants to help hosting a second great SotM-US and make the community grow this way.

I think that she has a totally different understanding of the word "community" than Martijn. Her community are the users at Twitter, the press and other organizations but not the real community which made OSM to be so large and great (see Europe).

I have had lots of conversations with other OSM contributors over the last years. Most people started mapping because they needed a map or already used OSM and wanted to give something back. A nice blog of the OSM Foundation (or its local chapters) or a Twitter account tweeting all day long did not make them joining OSM.

I suggest not to vote for her. I think that she has not realized the bad situations OSM (US community) is in.

Eric Theise

Eric is, according to HDYC, an OSM newbie (46 changesets, 40 times iD, 6 times Potlatch¹). I doubt that a newbie is the right person for such a position.

I still summarize and evaluate his manifesto. He wants to increase the awareness of open data and open source and get OSM in peoples' minds. He focusses on communication and not on the community. He himself says that he is a minor mapper and a minor developer. Having a look at his Github profile (two clicks away from his manifesto) I only see few OSM-related code. He contributed a little bit to the OSM website (rank #46 of 85, 4 commits, +280 lines of code!). He mentions his contributions to the programming committee of SotM US 2014 in Washington DC. In contrast to other manifestos, his manifesto has a "Qualifications and Experience" section which looks – sorry – strange. He says "[he has] been involved in a number of quarterly mapathons". I cannot believe this looking at his osm.org profile because he has too few edits. What's the name of his second account he has used for these mapathons?

Some parts of my writing about Alyssa apply here, too. He also has not realized the bad situation OSM US is in.

I think that he has too litte experience at OSM. I would not give him my vote.

Ian Dees

Ian (wiki user page) is a very very long time contributor to OSM, he started contributing to OSM in 2006! HDYC says that he is a "heavy mapper 2.0", i.e. experienced. (Getting "addicted mapper" with 9 years experience might be difficult)

He is already the board's treasurer. His manifesto agrees with the manifestos of Martijn, Drishtie and Alex. He also says that the number of contributors has to be increased. The board has made a great job organizing multiple great SotM US conferences but it failed increasing the community. The board should fund and support local events (e.g. mapping parties). He mentions that the current and past boards wanted to start sending a monthly newsletter but nothing happened. Short summary: Improve the basis all over the country and don't focus too much on large events.

He seems to be a suitable person for OSM US board. I suggest to give him your vote.

Jonathan Witcoski

Jonathan is a "Heavy Mapper 2.0" but started editing last year and still uses an editor which I call "the newbie editor".

His manifesto is located here. He has joined OSM at a HOT event. Scrolling through his recent changesets, I can only see remote mapping (humanitarian editing) and mapping from aerial images but less or no mapping on the ground. I doubt that this user has really experience how OSM works.

Two thirds of his manifesto are just her bio and a praise of his experience at a government project. I doubt this will really be of use for OSM. He wants to "encouragi[e] participation from colleges and universities". Does he really knows what he is writing about? Has he ever observed edits by students of a university or school course at OSM? If he had, he would noticed the noteworthy amount of changeset by students which are either vandalism and edits which need to be corrected.

He writes that future professional geographers should know that there are not only commercial data sources. I agree but I have to note that students get teached the existence of OSM as a usable data source if OSM is a usable data source. I can observe this during my own studies², I knew OSM before my studies and I did not make much advertisement for OSM at university. OSM was mentioned at university without my advertisment.

That's why I suggest you not to give Jonathan your vote.

Lauren Jacobson

HDYC labels Lauren as a "Hit and Run mapper" (24 changesets, only iD, but 7 times more nodes than Eric) –
That's just a little step above "newbie". I have had a look at her Github profile which is linked from her Wiki user page. I could not find noteworthy code contributions at all (including non-OSM repositories). I really ask myself why she candidates.

Her manifesto is long. The first and second paragraph are a bio of herself. She mentions her presence at some OSM conferences and mentions the gender diversity events and programs. She writes that she is working on an building import in Zambia and participated at some HOT events.

She wants to "promote local project creation and involve more community leaders with OSM projects", "encourage diverse participation at State of the Map US" (i.e. gender-related scholarships and such stuff) and "enhance the benefits of joining the OSM US Foundation". All this sounds good but she does not address the main concerns and problems OSM has in the U.S. at the moment.

I cannot suggest you to give her your vote due to her missing experience with OSM.

Drishtie Patel

Drishtie is a newbie and has edited mainly outside the U.S. Her edits are mainly HOT-related.

Her manifesto seems to be the longest of all manifestos. She write very much about her work all aroung HOT and humanitarian mapping and uses photos to attract votes. She wants to increase cooperation between humanitarian orangizations and universities to get the student map if there is a crisis.

What me really shocks are following two sentences:

I would use this opportunity to be more connected with the OSM community in the United States. There is a vast amount of talented OSM’ers in the country using open data in different ways and I am excited to learn more and expand my knowledge.

This means that she has at the moment no or only little knowledge about the active community in the U.S. and wants to get in touch with the community after getting elected! Sorry, please go to a local community meeting or organize one yourself (just an evening at a pub).

If you give your vote to her, you waste your vote. Sorry.

Alex Barth

Alex (wiki) works at Mapbox and leads Mapbox's data team (the people getting payed for editing at OSM). He started editing in 2012, HDYC says he is a "Heavy Mapper 2.0". He is the vice president of the current OSM US board.

His manifesto is located at his user diary. Like most candidates, he first introduces himself shortly summarizing his work and Mapbox's editing-related tools. Afterwards he describes the work of the current and past OSM US boards and the success of SotM US.

But the succes of SotM US is no real success

While some of these numbers [of attendants at SotM US] are impressive and the seeds we have planted are developing, the people we haven't reached yet are still in the majority.

Alex wants to connect OSM to people who either may have a benefit from using OSM or may be good OSM contributors. He wants to "tap into existing networks" and to strengthen local communities by mini grants, mapping events and bringing OpenStreetMap to other conferences.

In difference to some of his competitiors, he is no newbie and well known inside the community.

Summary

You can vote for up to five candidates. My personal rank is

  1. Martijn van Exel
  2. Ian Dees
  3. Alex Barth
  4. Elliott Plack

I would throw my fifth vote away because all other candidates are not suitable for OSM US board.

Footnotes

¹ Potlatch is not a newbie editor. I know some experienced mappers which still like and use this editor.

² I study geodesy and geoinformatics.

Reverse Engineering von Fahrscheinentwerter-Nummern

Posted by Nakaner on 7 October 2015 in German (Deutsch)

Symbolbild eines Fahrscheinentwerters

Abbildung: Fahrscheinentwerter (Symbolbild, reverent @ pixabay, CC-0)

Manches mappt man nur des Mappens wegen. Getreu diesem Motto, habe ich kürzlich bei einem Besuch in Berlin begonnen, gezielt die Nummern von Fahrscheinentwertern zu mappen. Man könnte sich jetzt fragen, was daran besonders sei. Einfach Nummer aufschreiben und fertig? Nein, so einfach ist es nicht. An manchen Entwertern steht außen keine Nummer angeschrieben oder es ist – wie bei der S-Bahn Berlin – nur eine örtliche Nummer angeschrieben, nur innerhalb der jeweiligen Station eindeutig und einmalig ist.

Um an die wahre Nummer des Entwerters zu gelangen, habe ich einfach einen langen Papierstreifen, der etwa so breit wie ein VBB-Fahrschein ist, in den Entwerter geschoben und abstempeln lassen. Danach habe ich den kleinen, bedruckten Teil abgeschnitten und mit den verbleibenden Papierstreifen von einem anderen Entwerter abstempeln lassen.

Foto der vier Entwerterstempelabdrücke aus Berlin-Hermsdorf Abbildung: Vier Entwerterstempelabdrücke habe ich in Berlin-Hermsdorf gesammelt

Neben Berlin-Hermsdorf habe ich auch in Berlin-Tegel die Nummern der Entwerter ermittelt. Auch dort ging bei mindestens einem Entwerter die Uhr nennenswert vor. (Für Fahrgäste ist das von Vorteil, denn Einzelfahrscheine gelten in Berlin ABC zwei Stunden lang)

Die Entwerter tagge ich wie folgt:

  • amenity = ticket_validator
  • loc_ref = (außen angeschriebene Nummer, wenn diese nicht regional einmalig zu sein scheint)
  • ref = (Nummer laut Stempelwerk, wenn die äußere Nummer in loc_ref=* landet)

Newbies finden, die ein bestimmtes Thema mappen

Posted by Nakaner on 5 August 2015 in German (Deutsch)

Heute stellte sich mir die Frage, auf die die Overpass-API eine Antwort weiß.

Wie viele Newbies gibt es eigentlich in einem Gebiet, die Eisenbahnsignale mappen? Der Begriff "Newbie" stimmt nicht ganz, eigentlich erhält man alle Nodes, die nicht von einer vorher definierten Menge an Mappern zuletzt editiert wurden.

In den OSM-Daten sind neben den Tags nämlich auch ein paar Metadaten enthalten:

Beispiel:

<node id="3515197709" lat="48.8605008" lon="9.3274573" version="5" 
timestamp="2015-07-21T19:02:45Z" changeset="32785733" uid="2450569" 
user="regedemu">
    <tag k="railway" v="signal"/>
    <tag k="railway:signal:direction" v="forward"/>
    <tag k="railway:signal:main" v="DE-ESO:hp"/>
    <tag k="railway:signal:main:form" v="light"/>
    <tag k="railway:signal:main:height" v="normal"/>
    <tag k="railway:signal:main:states" v="DE-ESO:hp0;DE-ESO:hp1"/>
    <tag k="railway:signal:position" v="right"/>
    <tag k="ref" v="N501"/>
    <tag k="source" v="survey"/>
</node>

Wir sehen in obigen XML-Listing folgende Metadaten:

  • Version des Objekts (version)
  • Zeitstempel (timestamp)
  • Änderungssatz-ID (changeset). Dieser Änderungssatz hat das Objekt zuletzt bearbeitet.
  • User-ID (uid). Dieser User hat das Objekt zuletzt bearbeitet. Diese bleibt gleich, auch wenn der User sich umbenennt.
  • User (user). Dieser User hat das Objekt zuletzt bearbeitet.

Uns interessieren timestamp uind user. Mit dem Zeitstempel filtern wir nur die neusten Änderungen, mit User filtern wir alle Objekte weg, die von Eisenbahn-Powermappern geändert wurden.

Das ist die Overpass-Abfrage dazu:

// Datum ggf. anpassen
node
  [railway=signal](newer:"2015-05-01T07:00:00Z")
  ({{bbox}})->.newnodes;

// Liste aller User, die man schon kennt und nicht in den Ergebnissen haben möchte
// i.d.R. sind das Poweruser
(.newnodes; - node.newnodes(user:Nakaner);)->.newnodes;
(.newnodes; - node.newnodes(user:"Nakaner-repair");)->.newnodes;
(.newnodes; - node.newnodes(user:bigbug21);)->.newnodes;
(.newnodes; - node.newnodes(user:mapper999);)->.newnodes;

// Ausgabe
.newnodes out meta;

Die Abfrage muss man für jede Region anpassen. Denn Eisenbahnmapper haben meist eine Mappingregion, in der sie aktiv sind. Tut man das nicht, erhält man zu viele False Positives, d.h. unter Umständen alle Signale einer Strecke, weil diese von einem User innerhalb weniger Tage eingetragen wurden.

Diese Abfrage habe ich zur Overpass-Beispielsammlung ergänzt.

Mappen mit dem Deutschlandpass – Schlafplätze bei Mappern gesucht

Posted by Nakaner on 12 July 2015 in German (Deutsch)

Bauarbeiten zwischen Leipzig Hbf und Leipzig-Sellershausen Bild: Bauarbeiten zwischen Leipzig Hbf und Leipzig-Sellershausen, Foto: Falk2, Wikimedia Commons, CC-BY-SA 1.0–3.0

Auch diesen Sommer bietet die Deutsche Bahn wieder den Deutschlandpass an. Da ich diesen Sommer die Zeit dazu habe, werde ich etwa ein bis zwei Wochen lang mit User rurseekatze Ostdeutschland bereisen, um Eisenbahninfrastruktur zu mappen. Unsere Ziele: Bahnhöfen und Streckenabschnitte, wo - seit 2012 ein ESTW (elektronisches Stellwerk mit neuen Signalen) in Betrieb ging, - seit 2012 größere Um-/Ausbauten stattfanden, - in den nächsten zwei Jahren ein ESTW in Betrieb gehen wird oder ein Umbau ansteht.

Eine Karte mit den Zielen und den Gründen habe ich auf der französischen uMap-Instanz veröffentlicht.

Das Jahr 2012 ist als Grenze festgelegt, da die meisten Bing-Luftbilder in diesem Jahr oder später aufgenommen worden sind. Die Bing-Luftbilder eignen sich zum Mappen der Gleisanlagen. Derzeit läuft noch eine Zielsuche im Eisenbahnforum Drehscheibe-Online.

Die Reise wird zwischen dem 14. und 31. August stattfinden. Der genaue Zeitraum und Reiseweg ist noch nicht festgelegt.

Wenn neben dem Umbaumapping noch Zeit bleibt, möchten wir von diverse Nebenbahnen in der Gegend Signale und Höchstgeschwindigkeiten mappen (das wäre dann eine Neuerfassung und keine Aktualisierung).

Da wir wahrscheinlich nicht dazukommen werden, alles selbst in OSM einzutragen, werden wir die Videos (ggf. ohne Ton), Fotos, Feldbücher, GPS-Tracks und Wegpunkte veröffentlichen.

Da das Budget begrenzt ist, sind wir als Studenten auf Übernachtungsangeboten bei Privatleuten angewiesen, die uns (wir bringen Schlafsäcke + Isomatten mit) eine Nacht lang beherbergen möchten. Da wir während der Reise keine festen Termine haben, sind wir über jedes Angebot froh und werde die Reise anhand der angebotenen Übernachtungsmöglichkeiten ausrichten. Wir sind auch an Übernachtungsangeboten interessiert, die nicht direkt in der Nähe unserer Ziele liegen. Ein bis zwei Stunden Anreise von der Übernachtung zum Mappingort sind kein Problem, schließlich haben wir den Deutschlandpass und können so oft IC/EC/ICE fahren, wie wir wollen.

Im Voraus vielen Dank für alle Übernachtungsangebote.

Mapillary-Straßenbahnmapping

Posted by Nakaner on 13 May 2015 in German (Deutsch)

In den vergangenen Tagen habe ich mich der fotografischen Erfassung des Karlsruher Straßen- und Stadtbahnnetzes gewidmet. Da alle Straßenbahnen und 3 Stadtbahnlinien mit Einrichtungsfahrzeugen bedient werden, geht das mit einem Smartphone relativ einfach. Da in sämtlichen Karlsruher Fahrzeugen (auch die allerneusten Ein- und Zweisystemfahrzeuge) GPS-Empfang besteht, steht dem Mapillieren nichts im Wege.

Mapillierendes Smartphone in einer Karlsruher Stadtbahn

"Einfach ganz hinten reinsetzen und Mapillary starten" ist die Kurzfassung der Tätigkeitsbeschreibung. Die Langfassung erhält zusätzlich noch folgende Kommentare:

  • Wenn dein Smartphone keinen guten GPS-Chipsatz hat, dann verwende einen externen GPS-Logger, wie ich z.B. einen Holux M-241, der per Bluetooth gekoppelt wird.
  • Schalte den GPS-Logger fünf bis zehn Minuten vor Fahrtbeginn ein, verbringe innerhalb dieser Zeit mindestens drei Minuten an einem Ort mit geringer Abschattung.
  • Steig an einer Station ein, wo die Bahn noch relativ gering gefüllt ist. Vermeide den Berufsverkehr, steig bei radialen Linien vor der Durchquerung der Innenstadt ein.
  • Stelle dein Smartphone auf das Brett vor der Heckscheibe (darunter befinden sich die Bedienelemente zum Rückwärtsfahren), lehne dein Smartphone möglichst an die Scheibe. Eine sockenartige Handyhülle ist empfehlenswert als Antirutschmatten-Ersatz.
  • Sichere mit einem Finger das Smartphone, sonst kippt es bei einer ruppigen Bremsung oder einem Gleislagefehler um. (Das obige Foto wurde während des Halts in Rüppurr Battstraße aufgenommen)
  • Behalte das Bild im Auge. Der Horizont im Kamera-View sollte mit dem Horizont übereinstimmen. In scharfen Kurven musst du das Smartphone um die z-Achse drehen, wenn du Wert auf gute Bilder legst. (In extrem scharfen Kurven wie der Wendeschleife in Bad Herrenalb bis zu 45°)
  • Vermeide den NET 2012. Der GPS-Empfang ist zwar nicht erheblich schlechter, aber die Luftfederung hat ein Aufschaukelverhalten (v.a. zwischen Hauptfriedhof und Hirtenweg/Technologiepark). Außerdem ist dort die Ablagefläche vor dem Fenster recht tief.
  • Halte dich während der Fahrt fest.
  • Vermeide Gegenlicht. Falls es doch auftritt – fahr in die anderer Richtung, warte auf bewölkten Himmel oder versuche es morgens, wenn das Gegenlicht abends auftritt.

Beispiele:

EDIT: Beispiele und Gegenlicht ergänzt

Location: Südweststadt, Karlsruhe, Regierungsbezirk Karlsruhe, Baden-Württemberg, Deutschland

Stirbt Talk-de?

Posted by Nakaner on 8 April 2015 in German (Deutsch)

Warum?

Die deutsche Community hat "traditionell" zwei Kommunikationskanäle, die Mailingliste talk-de (seit August 2006) und das Forum. Da ich im Wochennotizteam die Mailinglisten lese, habe ich das Gefühl, dass Talk-de stirbt und Tagging gerade explodiert. Das Gefühl scheinen auch andere zu haben.

Persönlich bin ich der Meinung, dass es bei einer Community, die ein Bindeglied zwischen beiden Kanälen in Form der Wochennotiz hat, genügt, eine Sache nur einmal zu melden (amtsdeutsch "anzeigen"), wenn sie diskussionspflichtig ist, z.B. meinen mechanischen Edit von Eisenbahnsignalen. Andere sehen das anders und so habe ich mir die Statistik für meine Meinung gemacht.

Ergebnis

Alle Zahlen sind auf 30 Tage normiert. Damit der der Graph glatter aussieht, habe ich die Zahl eines Monats immer mit dem Vor- und Nachmonat gemittelt.

Diagramm

Deutung

Talk-de hat anscheinend seine besten Zeiten hinter sich. Letztes Jahr (2014) gab es pro Monat meist nur etwa halb so viele Mails wie davor (2013). Die Talk-Liste hat zwar, über mehrere Jahre hinweg gesehen, auch nachgelassen, scheint jetzt aber stabil zu sein. Tagging reißt es raus. Seit Herbst explodiert die List förmlich. Im März 2015 waren es 1234 Mails. Das ist zwar wenig, wenn man bedenkt, dass Talk-de 3167 Mails im Juni 2008 hatte. Der gefühlt längste Thread damals war "Potlach ist ein Problem!". Bei Tagging diskutierte man in den 1234 März-Mails u.a. über "Tagging method of amenities at camp_sites", "Fuel shops", "Accepted or rejected?" und weitere Themen.

Mein Eindruck scheint, dass sich die deutsche OSM-Community mehr und mehr im Forum versammelt. Alte Hasen scheinen entweder in beidem zu Hause zu sein oder auf Talk-de geblieben zu sein. Aber die große Zahl an neueren Usern und auch die meisten Newbie-Anfragen sorgen im Forum allein heute für über 15 Threads, in denen heute mindestens ein Beitrag geschrieben wurde. Da meistens aber mehr als ein Beitrag pro Tag geschrieben ist, dürfte das Forum Talk-de überholt haben (ich habe nicht genau nachgezählt).

Der Weg zum Ziel

Folgende Tools wurden für diese Grafik verwendet:

  • wget
  • grep (ich habe nach die Zeichenfolge "NAME" pro thread.html gezählt)
  • ein Texteditor
  • LibreOffice Calc

Siehe auch

Signals and Noises: A Look at OpenStreetMap Through its Mailing Lists, ein Vortrag von Frederik Ramm auf der State of the Map 2013 in Birmingham

Rückblick auf die FOSSGIS 2015 in Münster und Ausblick auf die Zukunft der FOSSGIS

Posted by Nakaner on 15 March 2015 in German (Deutsch)

Interessante Vorträge

Die folgende Auflistung basiert auf meiner persönlichen Präferenz und ist auf OSM zentriert. Es gibt (dem Programm zufolge) zwar auch im GIS-Track einige interessant klingende Vorträge, diese Videos habe ich jedoch noch nicht angesehen (während der Konferenz war ich am Donnerstag und Freitag im OSM-Track als Kameramann/Mixer).

Für Mapper eher uninteressant, aber als Einführungsvortrag für OSM-Neulinge ist Frederiks Keynote Nicht zuschauen – mitmachen! empfehlenswert.

Robert Klemm stellte seine Bachelorarbeit Automatisierte OSM Aufbereitung & Analyse von LKW-Mautstrecken in Deutschland vor.

Wer OSM-Daten analysiert, für den ist Claas Leiners Vortrag Daten aus OSM extrahieren und in QGIS weiterverarbeiten einen Blick wert.

Thomas Jakubicka von Mentz DV stellte in seinem Vortrag Indoor Routing in Gebäuden des öffentlichen Verkehrs auf Basis von OpenStreetMap-Daten vor, wie Mentz DV im Bereich des Indoor-Routings und der Indoor-Kartographie OSM nutzt.

Uneinigkeit im Publikum herrschte am Ende von Robert Buchholzs Vortrag FlatMatch – Online-Wohnungssuche mit OSM-Daten, ob eine Plattform, die Wohnungen in 3D in ihrer 3D-gemappten Umgebung darstellt, wirklich dazu führen würde, dass Vermieter ihre Umgebung mappen.

BRouter-Maintainer Arndt Brenschede berichtete in einem Lightning Talk über das intermodale Routing, welches er für BRouter implementiert hatte. In seinem Vortrag Neues zu BRouter ging er näher auf seinen Router und die Einbindung von BRouter in OsmAnd ein.

Für die Freunde freier Spiele präsentierte Tobias Knerr, der Maintainer von OSM2World, einen Workflow, wie man aus OSM-Daten mit OSM2World und Blender eigene Rennstrecken für das Open-Source Rennspiel SuperTuxKart erstellt.

Jochen Topf stellte neue Features in Taginfo vor und Roland Olbricht zeigte, wie man mit ein paar Overpass-API-Abfragen auf Schatzsuche in OpenStreetMap gehen und Tagging- und Mapping-Kuriositäten entdecken und daraus einen Reiseführer der anderen Art erstellen kann.

Da es zahlreiche Anwendungen gibt, die auf hoch aufgelöste Geländemodelle angewiesen sind, stellte Peter Barth seine Versuche zu Crowd-Sourced Elevation vor. Dabei geht es darum, wie man mit den Barometern in Android-Smartphones Geländehöhen ermittelt und somit horizontal besser aufgelöste Modelle als SRMT erstellen kann.

Alexander Lehner berichtete von seinen Versuchen, mit einem Kopter zu mappen.

Alle Vorträge gibt es auch als Dateidownload (HTTP, FTP auf den GWDG-Servern (Benennung erfolgt nach der Vortrags-ID). Die Videos (Youtube und Dateidownload) sind auch im Programm bei den einzelnen Abstracts verlinkt.

Zukunft der FOSSGIS-Konferenz aus OSM-Sicht

Die FOSSGIS ist eine Konferenz für zwei Themen – auf der einen Seite das dominante Thema Open-Source-GIS, auf der anderen Seite das Thema OpenStreetMap. Auf dieser FOSSGIS hat sich gezeigt, dass die FOSSGIS eigentlich keine Konferenz für die OSM-Community ist. Geschätzt waren von den über 410 Teilnehmern nur etwa 50 der OSM-Community zuzuordnen und dementsprechend leer waren auch die meisten Vorträge des OSM-Tracks. In Berlin waren gefühlt mehr OSMler auf der FOSSGIS, in Münster habe ich jedoch überwiegend nur noch alte Bekannte getroffen, die mir sonst auf Hackweekends begegnen. Es gibt mehrere Gründe dafür.

Zum einen spricht die Konferenz schon vom Namen her OSM-Aktive nicht besonders an. Bei allen Ablegern der State of the Map ist OSM das einzige und Hauptthema, bei der FOSSGIS kommt OSM nicht einmal im Namen vor. Dies hat auch mich 2012 und 2013 davon abgehalten, die FOSSGIS zu besuchen. Terminlich liegt die FOSSGIS auch sehr ungünstig für OSM-Aktive, die das meist als Hobby in ihrer Freizeit tun. Da geht man dann nicht einfach auf eine Konfernz, auf der OSM eine Randrolle hat und die auch noch von Mittwoch bis Freitag (früher Dienstag bis Donnerstag) stattfindet. Aus GIS-Sicht ist es verständlich, denn die meisten Teilnehmer der FOSSGIS ohne OSM-Bezug kommen aus beruflichen Gründen, sei es als Entwickler oder Nutzer (u.a. Behörden). Ein Community-Mitglied kostet solch eine Veranstaltung jedoch drei Urlaubstage!

Ein dritter und nicht zu vernachlässigender Punkt ist auch die thematische Ausrichtung der OSM-Vorträge. Viele Vorträge richten sich an Entwickler, Mapper sind aber häufig keine Entwickler. Dieses Problem haben auch die SotM-XX-Konferenzen. Ich selbst kann die "normalen Mapper", die ich auf der SotM-EU in Karlsruhe getroffen habe und nicht direkt zum Orgateam gehörten, an einer Hand abzählen.

Nächstes Jahr wird es voraussichtlich keine FOSSGIS im herkömmlichen Format geben, denn der FOSSGIS hat den Zuschlag für die Ausrichtung der FOSS4G 2016 in Bonn bekommen. Die FOSS4G ist eine Konferenz zum Thema frei Software für GIS (also eine globale FOSSGIS ohne OSM-Track). Es handelt sich dabei schon aufgrund des Eintrittspreis nicht um eine Community-Konferenz (750 Dollar bei FOSS4G 2014 in Portland, in Bonn wird der Eintrittspreis auch im mittleren dreistelligen Eurobereich liegen).

Möglicherweise (?) wird es, angedockt an die GIS-Konferenz Agit in Salzburg, eine kleine FOSSGIS geben. Dort wird OSM jedoch noch exotischer sein als jetzt schon. Die Agit ist nämlich eine wissenschaftlich-proprietäre GIS-Konferenz.

Daher ist es an der Zeit, dass die OSM-Community im deutschsprachigen Raum sich veranstaltungstechnisch selbstständig macht und eine eigene Veranstaltung auf die Beine stellt. Nach sechs Jahren OSM+GIS auf der FOSSGIS hat sich jetzt meiner Meinung nach gezeigt, dass die Idee OSM@FOSSGIS aufgrund der oben genannten Gründe als gescheitert zu betrachten ist.

Eine OSM-Konferenz sollte sich jedoch nicht nur an Entwickler, sondern auch an unseren größten Schatz, die unzähligen Mapper richten. Das könnte zum Beispiel ein OSM-Barcamp sein oder ein Konferenzformat mit hohem Workshop-Anteil sein, denn ein Mapper möchte auch etwas praktisches von der Veranstaltung mit nach Hause nehmen. Ihn interessieren vermutlich nicht, wie man eine PostGIS-Datenbank optimiert, sondern, so glaube ich, eher für Workshops/Vorträge wie "Einführung in 3D-Mapping", "ÖPNV für Mapper", "Vier Editoren in zwei Stunden" oder "Wie erstelle ich ein erfolgreiches Proposal?".

Disclaimer: Die Idee eines OSM-Barcamps stammt übrigens nicht von mir.

EDIT: Videolinks sind jetzt im Programm intergriert. EDIT 19. März 2015: Links zu Youtube-Videos korrigiert

Gebäudemapping in Neubaugebieten mit GPS und ohne Luftbilder

Posted by Nakaner on 1 February 2015 in German (Deutsch)

Da die Gemeinden in meiner Umgebung fleißig alle zwei bis drei Jahre ein neues Neubaugebiet ausweisen, komme ich in "Genuss" regelmäßig etwas zum Mappen zu finden. Das nehme ich natürlich gerne als Herausforderung an, denn da kann man zeigen, dass man kein reiner Luftbild-Abpinsel-Mapper ist. Am Hand des Neubaugebiets "Am Schulzentrum" in Brackenheim zeige ich in diesem Blogpost, wie man Gebäude nur mit GPS mappt.

Neubaugebiete haben, nachdem sie erschlossen sind (d.h. Ver- und Entsorgungsleitungen verlegt und die Straßen befahrbar sind) eine Zeit lang den Vorteil, dass die Bautätigkeit erst beginnt und eine sehr geringe Abschattung besteht. Dadurch kann man mit einem normalen Garmin noch akzeptable Genauigkeiten erzielen.

Da eine Neuauflage der Bing-Bilder nicht absehbar ist und die Landesregierung Orthophotos nicht für OSM zur Verfügung stellen möchte, muss man eben zu den "klassischen" Methoden greifen, die in der Prä-Bing-Ära noch ganz normal waren.

Vorbereitung

Um Gebäude mit GPS einzumessen, empfiehlt es sich, das Baugebiet in dem Moment aufzusuchen, indem noch keine oder nur sehr wenige Eigentümer eingezogen sind. Der Sonntagenachmittag ist kein guter Tag, denn da besichtigen die Bauherren meistens ihre Baustelle. :-) Zufällig als sehr geeignet hat sich der Heiligabend 2014 erwiesen. Es hat nicht geregnet und die einzigen Personen, die mir begegnet sind, waren eine Streifenwagenbesatzung, die, ohne zu bremsen, an mir vorbeigefahren ist. Das Baugebiet war zu diesem Zeitpunkt noch unbewohnt, d.h. noch kein künftiger Bewohner war eingezogen.

Ein Paar stabile Stiefel (ich bin dank meines dualen Studiums in der Vermessung mit zwei Paar Sicherheitsschuhen ausgestattet), die schmutzig werden dürfen, sollte man auch nicht vergessen. Eine Warnweste vermittelt einen offiziellen Eindruck. Sie kann dazu führen, dass ihr gefragt werdet, ob ihr als Mitarbeiter des Bauordnungsamts kontrolliert, dass keiner zu hoch baut. :-)

Außendienst

Vor Ort angekommen, sollte man das GPS-Gerät, nachdem es einen Fix bekommen hat (also eine Position berechnen kann), erst einmal etwa fünf Minuten "warm laufen lassen". Während dieser Zeit empfängt es die aktuellen Bahndaten und muss nicht auf die ungenaueren vorherberechneten Bahndaten zurückgreifen, die auf dem Zeitpunkt basieren, an dem das Gerät zuletzt eingeschaltet war. Wenn man sich in Süddeutschland auf einer Hochebene oder an einem Südhang befindet, kann man auch noch "WAAS" (damit ist EGNOS gemeint) einschalten. Der Garmin empfängt dann Korrekturdaten von einem geostationären Satelliten über dem Äquator, der bei uns sehr niedrig steht.

Während das Gerät noch "warm läuft", kann man schon durch das Baugebiet laufen und sich ein Bild machen. Währenddessen kann man auch schon die Gebäude und Straßen skizzieren.

Nachdem der Garmin nun brauchbar ist, begibt man sich in die Achse der Außenkante des ersten einzumessenden Gebäudes. Man speichert einen Wegpunkt ab und notiert in der Skizze den Ort, an dem man sich befindet (Kreuzchen setzen) und schreibt die Nummer des Wegpunkts daneben. Nun bewegt man sich in der Achse der Gebäudeaußenkante weiter weg. Nach einigen Metern bleibt man stehen und speichert einen zweiten Wegpunkt. Wer die eigenen Messung kontrollieren will, speichert noch einen dritten Punkt. Nun ist eine der vier Gebäudeaußenkante festgelegt.

Für alle parallel zu dieser Achse verlaufenden Gebäudeaußenkante genügt es, einen Punkt in der Achse der Gebäudekante zu messen.

Bei einem Gebäude mit rechteckigem Grundriss wiederholt man diese Schritte für die übrigen Gebäudeaußenkanten, die nicht parallel zur ersten Kante verlaufen.

Ein Aufzeichnen des Tracks während der Messung ist nicht unbedingt notwendig, schadet aber auch nicht. Er legt Multipath-bedingte Ungenauigkeiten in Gebäudenähe auf, wenn der Track plötzlich zur Seite springt, obwohl man geradeaus weitergelaufen ist.

Wenn man schon vor Ort ist, kann man auch gleich, falls der Bau schon so weit fortgeschritten ist, die Geschossanzahl und Dachform notieren und später in OSM einpflegen.

Tipp für Mapper, denen Gesetze egal sind: Wenn euch niemand beobachtet, wird eure Messung genauer, wenn ihr die Stützpunkte nicht nur auf der Straße messt, sondern dazu auch benachbarte, unbebaute Grundstücke betretet. Ihr seid dann weiter vom Gebäude entfernt, was einerseits der GPS-Genauigkeit gut tut, andererseits wirkt sich ein Messfehler quer zur Richtung der Achse weniger stark aus, da sich die Richtung der Achse dann nicht so stark ändert.

Innendienst

Nachdem man nun wieder daheim am Rechner angekommen ist, startet man JOSM und lädt die Wegpunkte und Tracks. Von der OSM-API lädt man sich die aktuellen Daten, über Datei -> Neue Ebene legt man eine zweite Datenebene an, die wir für Hilfslinien während der Konstruktion verwenden. In diese Hilfsebene wechseln wir nun (grünes Häckchen an den entsprechenden Eintrag im Ebenebereich setzen).

Zeichnen der Gebäudeachsen in JOSM

Alle Wegpunkte, die eine Achse bilden sollen, verbindet man mit einer Linie. Damit die Linie auch eine Achse und keine Zick-Zack-Linie ist, drückt man die Taste A nicht einmal, sondern zweimal. Dann ist der 90-/180-Grad-Punktfang eingeschaltet. So zeichnet man die erste Flucht. Mit Strg+C und Strg+V kopiert man die gezeichnete Linie und schiebt sie auf den Wegpunkt, der die zweite, parallele Gebäudeflucht festlegt. Selbiges wiederholt man für die anderen Gebäudkanten, die nicht parallel zur Kante 1 sind.

Das Plugin utilsplugin2 hält die Funktion "Punkt an Schnittpunkten einfügen" bereit. Dazu markiert man alle vier Achsen und drückt Shift+I. Anschließend kann man die überstehenden Teile der Achsen entfernen und mit C die Linien zu einer Linie vereinigen.

Nun kann man die Hilfsebene mit der Hauptebene vereinigen, indem man im Ebenenbereich rechts auf die Hilfsebene klickt und auf "Vereinen" klickt.

Bitte nicht vergessen, das Gebäude zu taggen und beim Hochladen im Feld "Quelle" "GPS survey" anzugeben. Gerade das "GPS" ist wichtig, damit andere Mapper nachvollziehen können, warum das Gebäude nicht zum Luftbild passt.

Ausblick

Für die kommenden Monate plane ich im selben Baugebiet (es wird mein Übungsgelände) noch Methoden der terrestrischen Photogrammetrie anzuwenden. Mit meiner Spiegelreflexkamera (Nikon D90) und einem 35 mm-Festbrennweitenobjektiv habe ich vor eine dreistellige Anzahl an Fotos zu machen und daraus dann mit VisualSfM eine Punktwolke berechnen. Einige bekannte Objekte, die man auch auf den Bing-Bildern sieht werde ich zur Maßstabsberechnung verwenden, denn die originale Punktwolke ist maßstabslos (d.h. ohne Längeninformation). Mit der Annahme, dass die Hauswände senkrecht sind, und einigen bekannten Punkten, von denen ich 2D-Koordinaten habe, möchte ich die Punktwolke dann georeferenzieren.

Anschließend habe ich vor, einen Horizontalschnitt der Punktwolke zu berechnen (dürfte mit CloudCompare gehen) und diesen als Rastergrafik in JOSM abzuzeichnen.

Wenn jemand eine Drohne sein eigenen nennt, darf er mir auch gerne zum Experimentieren Aufnahmen zukommen lassen. Jeder Punkt sollte auf mindestens drei Aufnahmen zu sehen sein. Die Aufnahmen sollten möglichst nicht verlustbehaftet komprimiert sein.

Location: Am Schulzentrum, Botenheim, Brackenheim, Verwaltungsgemeinschaft Brackenheim, Landkreis Heilbronn, Regierungsbezirk Stuttgart, Baden-Württemberg, 74336, Deutschland

Schwäbisch für Babel m OSM-Wiki

Posted by Nakaner on 29 September 2014 in German (Deutsch)

Heut Oabend hats me in d Finger gjuckt. Jedes Moal, wenn i uf mei Benutzerseita im Wiki guck, denk i, da fehlt doch ebbes. Da stoat "DE-4, EN-3", abber was isch mit deiner Mudderspoach? Ja, fürs Schwäbische hat s bisher im OSM-Wiki noch kein Vorlag gebba. Hat halt no koiner gmacht.

Aber jetzt gibt s oine. Wer Schwäbisch spricht oder versteht, kâ jetzt in sei Benutzerseita oina von de folgende Vorlaga eibinda:

  • Bei Mudderschproachler wird des azeigt.
  • Bei Leid die fast so guat wie Muddersproachler Schwäbisch schwätza, wird des azeigt.
  • Die übrige Stufe 3, 2 und 1.
  • (kam mr hier weglassa) :-)

Wenn ihr in eurer Benutzerseita scho Babel nutza dehnd und es so aussieht, wie bei mir bis heut Oabend

{{Babel|de-4|en-3}}

Wenn ihr Mutterschproachler seid, dann ergänzet des oifach zu

{{Babel|swg|de-4|en-3}}

Ansonschta

{{Babel|swg-4|de-4|en-3}}

oder swg-3, swg-2, …, je nach dem auf was vor m Nivo ihr Schwäbisch verschtehât.

Mei Benutzerseita im OSM-Wiki (bloß uf Englisch und Hochdeitsch)

Für die viele Schreibfähler bitt i eich um Vergäbung. S letschte Moal Schwäbisch han e im Abibuch gschrieba, wo e Sprüch von Schüler und Lehrer ufgschrieba han. Wenn ihr des da oba ganz andersch gschriebe hättet, kann s sei, dass ihr oifach z weit von mr weg wohnat.

Im OSM-Wiki kann man nun auf seiner Benutzerseite angeben, dass bzw. wie gut man Schwäbisch versteht. Bisher gab es im OSM-Wiki dazu keine Vorlage, aber ich habe sie heute Abend angelegt. Die Vorlagen sehen wie folgt aus:

Wenn ihr auf eurer Benutzerseite schon Babel zur Anzeige der Sprachkenntnisse benutzt, dann dürfte etwas ähnlich folgendem Codeschnipsel auf eurer Benutzerseite zu finden sein

    {{Babel|de-4|en-3}}

Wenn ihr Muttersprachler seid, dann ergänzt das einfach zu

{{Babel|swg|de-4|en-3}}

oder swg-3, swg-2, …, je nach dem auf welchem Niveau ihr Schwäbisch versteht.

Meine Benutzerseite im OSM-Wiki

Verkehrszeichenzählung in Bayern

Posted by Nakaner on 21 July 2014 in German (Deutsch)

Laut dem Twitteraccount von Skobbler soll in Bayern der Schilderwald gelichtet werden. Na gut, habe ich mir gedacht, warum zählen wir nicht mal selber, was denn schon alles gemappt ist. Dazu gibt es die Overpass-API und den Overpass-Turbo als GUI dazu. Die Abfrage war folgende:

node(area:3602145268)["traffic_sign"]; out meta;

Das Ergebnis waren gerade eben 17082 Nodes. Als Ways gemappte Schilder (wozu eigentlich) habe ich nicht gezählt, da diese meistens zur Dokumentation der Access-Beschränkungen verwendet werden, wie es das Verkehrszeichen-Tool vorschlägt.

Das ist der Link zur Abfrage. Ich rate davon ab, auf "Ausführen" zu klicken, da die Abfrage ein Weilchen dauert und 3 MB Daten liefert. Das ist für manchen schwachen Rechner vielleicht zu viel.

Kleinere Gebiete kann man jedoch schon abfragen, z.B. das Stadtgebiet von München. Dazu trägt man einfach die ID der Boundary-Relation addiert um 3600000000 ein. Diese ID bekommt man, indem man auf osm.org nach dem gewünschten Gebiet sucht. Das wäre die Abfrage für München (178 Schilder):

node(area:3600062428)["traffic_sign"]; out meta;

OpenRailwayMap-Mappingwochende 1

Posted by Nakaner on 14 July 2014 in German (Deutsch)

Vom Freitag, den 11. bis Sonntag, den 13. Juli 2014 fand in Köln das erste OpenRailwayMap-Mappingwochenende (mit Taggingdiskussion) statt. Es diente dem Austausch der Eisenbahnmapper und der Diskussion über Ergänzungen und Veränderungen am Eisenbahn-Taggingschema. Mit Emrah Kutlu war auch ein Vertreter von Mentz DV dabei.

Der Freitagabend begann locker im Lokal K in Köln-Ehrenfeld mit dem Eintrudeln und einer Vorstellungsrunde der Teilnehmer. Wir redeten über die Öffentlichkeitsarbeit der OpenRailwayMap und der Gewinnung neuer Mapper (insbesondere von bahninteressierten Nichtmappern als Bahnmapper). Im Anschluss stellte jeder seine Mappingtechniken vor.

Der Samstagvormittag begann mit dem Frühstück im Lokal K, welches in eine Vorstellung von Mentz DV und deren Nutzung von OSM-Daten überging. Wir erkannten, dass manches, was man bisher eher aus Spaß mappte, doch sinnvoll war. Emrah klärte darüber auf, dass auch das Mappen von Sitzbänken sinnvoll ist. Es ermöglicht ein besseres Routing im Rollator-Modus, wo die Existenz von Sitzbänken zum Ausruhen die Routenfindung beeinflusst.

Als er diverse Eisenbahnroutingfehler vorstellte, erklärten wir ihm die Tags service=*, usage=* und maxspeed=*. Wir erkannten den Bedarf des Einführens eines Tags für die Regelfahrtrichtung. Die Regelfahrtrichtung ist die Richtung, in die ein Gleis normalerweise befahren wird (bei zweigleisigen Strecken in Deutschland in der Regel das rechte Gleis in Fahrtrichtung). Wenn auf einer zweigleisigen Strecke vor und nach einer Kurve die Möglichkeit besteht, das Gleis zu wechseln, so könnte ein Router über das kurveninnere Gleis routen, auch wenn das das Gegengleis ist und mit dieser Fahrt andere Zugfahrten blockiert werden würden. Deshalb werden Gegengleisfahrten in der Praxis in der Regel nicht geplant.

Am Samstagnachmittag unterbrachen wir die Diskussionen und gingen, wie es der Name der Veranstaltung sagte, mappen. Von Köln West aus fuhren Consti, Alex, Michael und Emrah nach Euskirchen. Emrah verlies die Gruppe dort und fuhr zwecks Heimreise zum Flughafen, der Rest fuhr weiter nach Bad Münstereifel und über Euskirchen wieder zurück nach Köln. Zwei Mapper spazierten von Köln West über die Südbrücke und die Hohenzollernbrücke zum Hauptbahnhof.

Die Fahrt von Köln nach Euskirchen fand in einem Dieseltriebwagen der Baureihe 628 der Südostbayernbahn statt. Mangels GPS-Empfang (außer direkt an der Tür und am Faltenbalg) wurde reines Video- und Fotomapping ohne Georeferenzierung betrieben, auch wenn die Strecke ab Hürth-Kalscheuren nicht elektrifiziert ist. In Euskirchen stiegen wir in die Regionalbahn nach Bad Münstereifel um. Die Strecke nach Bad Münstereifel ist eine nicht elektrifizierte Nebenbahn. In Bad Münstereifel blieben wir sitzen und fuhren mit demselben Zug zurück nach Euskirchen. Diese Fahrt fand in einem Diesel-Talent (Baureihe 644/944 und 643.2) statt, in dem überall sehr guter GPS-Empfang bestand. So war es möglich, georeferenzierte Fotos aufzunehmen. Alex fotografierte fast jedes Signal und Consti ging seiner Leidenschaft nach – Fahrscheinautomaten samt Automatennummer für seine Fahrkartenautomatenkarte. Beim Wenden in Bad Münstereifel lies der Triebfahrzeugführer freundlicherweise den Vorhang zum Führerstand offen, sodass wir nach hinten durch den Führerstand fotografieren konnten.

In Euskirchen nahmen wir nicht den RE, sondern die 30 Minuten später fahrende RB nach Köln. In der Zwischenzeit fotomappten wir den Bahnhof und seinen Vorplatz. Alex fotografierte mit einem 70–300 mm-Teleobjektiv vor allem Signale, Signalnummern und entfernt liegende Objekte im Gleisvorfeld, während ich mit einem 18–105-mm-Objektiv Übersichtsfotos erstellte. Auch das Bahnhofsgebäude und der Vorplatz wurden gemappt. Zum Leidwesen von Consti hatten die zwei Automaten der Stadtwerke im Busbahnhof keine Nummer.

Der Bahnhof Euskirchen bekommt gerade neue Ks-Signale und ein Elektronisches Stellwerk (EStW). Die neuen Signale sind noch nicht alle aufgestellt, die schon aufgestellten, sind noch mit Ungültigkeitskreuzen gekennzeichnet. Wir werden nur die neuen Signale in OSM eintragen, da die alten nicht mehr lange stehen werden. Die Ergebnisse der Mappingtour in die Eifel sind derzeit noch nicht in OpenStreetMap eingetragen. Das folgt noch. Nach der Ankunft im Lokal K fuhren wir mit den Taggingdiskussionen fort. Die Ergebnisse können dem Protokoll entnommen werden. Gegen 20:00 Uhr stieß mit jotpe ein lokaler Mapper hinzu. Kurz nach Mitternacht beendeten wir die Taggingdiskussionen und fuhren in die Ferienwohnung ins Belgische Viertel.

Consti und Peter reisten am nächsten Morgen direkt von der Ferienwohnung aus ab, Alex und Michael fuhren wieder ins Lokal K, wo sie auf spth aus dem Raum Frankfurt (Main) trafen. Zu dritt arbeiteten wir einen Großteil der Taggingdiskussionsthemen ab. Hervorzuheben ist hier die ORM-Meinung zum Mappen von Bahnhöfen als Fläche. Wir entschieden uns für die Umstellung diverser Eisenbahninfrastruktur-Tags, die derzeit noch kaum verwendet werden und deren Key- oder Valuewahl sehr ungünstig war.

Die Taggindiskussionen gingen dann noch bis etwa halb Sechs am Abend.

Das ausführliche Protokoll ist im OSM-Wiki zu finden.

Das Lokal K ist unserer Ansicht nach ein für solche Treffen geeignete Örtlichkeit. Wir bedanken uns hiermit bei den Kölner Wikipedianern für die Gastfreundschaft und empfehlen es hiermit weiter. Wenn es eine Dusche hätte, könnte man sogar dort übernachten.

Es ist geplant ein zweites Treffen zu veranstalten, um noch offene Fragen zu klären. Dieses Treffen wird vermutlich etwas zentraler in Deutschland oder im Raum Frankfurt am Main stattfinden.

Location: Ehrenfeld, Köln, Regierungsbezirk Köln, Nordrhein-Westfalen, 50667-51149, Deutschland

Wie gut sind die Öffnungszeiten in meinem "Revier" erfasst?

Posted by Nakaner on 14 February 2014 in German (Deutsch)

Viele Mapper sind bestrebt die nähere Umgebung um das eigene Heim, möglichst gut zu erfassen. Auch ich bin so. Doch einer Frage wollte ich auf den Grund gehen: Wie gut sind die Öffnungszeiten erfasst?

Öffnungszeiten sind etwas, was man mal so nebenbei erfassen kann. Wenn man irgendwo hin laufen oder Rad fahren möchte, kann man, ausreichend Zeit vorausgesetzt, Zwischenstops einlegen und dabei die Öffnungszeiten von Ladengeschäften und Gastronomiebetrieben erfassen.

Ich habe mich jetzt mal eine Stunde hingesetzt und mich intensiver mit der Overpass-API und den MapCSS-Fähigkeiten des Overpass-Turbo auseinander gesetzt. Möchte man für einen kleineren Bereich die Öffnungszeiten-Abdeckung grafisch darstellen, so genügt folgender Code:

<osm-script>
    <union>
        <query type="node">
            <has-kv k="shop"/>  <bbox-query {{bbox}}/>
        </query>
        <query type="way">
            <has-kv k="shop"/>  <bbox-query {{bbox}}/>
        </query>
        <query type="node">
            <has-kv k="amenity" regv="^(restaurant|pub|bar|fast_food|food_court|ice_cream|cafe)$"/>  <bbox-query {{bbox}}/>
        </query>
        <query type="way">
            <has-kv k="amenity" regv="^(restaurant|pub|bar|fast_food|food_court|ice_cream|cafe)$"/>  <bbox-query {{bbox}}/>
        </query>
        <recurse type="way-node" />
    </union>
    <print/>
</osm-script>

{{style:

    node[opening_hours!=.],way[opening_hours!=.]
        { color:red; fill-color:red }

    node[opening_hours],way[opening_hours]
        { color:blue; fill-color:blue; }

}}

Beispiel-Abfrage aus Karlsruhe

Hat ein POI Öffnungszeiten, ist er blau, andernfalls rot. Ob die Öffnungszeiten-Syntax eingehalten wurde, wird nicht geprüft.

Der obere Teil der Abfrage (osm-script) fragt die Objekte von der Overpass-API ab, der untere Teil rendert sie entsprechend.

Dieser Blogpost basiert auf einem Blogpost von tyr_asd.

EDIT: Overpass-Abfrage korrigiert und Link auf korrgierte Abfrage eingefügt.

Wo sind die über 110 Überwachungskameras in Düsseldorf?

Posted by Nakaner on 13 January 2014 in German (Deutsch)

Die Verbrauchersendung Markt im WDR-Fernsehen (montags 21:00 Uhr) wurde heute gezählt, wie oft das Kamerateam bei einem Bummel durch die Düsseldorfer Innenstadt gefilmt wurde. Fazit mindestens 110 mal. (Nachzulesen im Transkript der Beitrags im letzten Absatz)

Diese Zahl hat mich neugierig gemacht und ich habe mal die Overpass-API befragt (via [Overpass-Turbo(http://overpass-turbo.eu/)). Mit folgender Abfrage kam ich nur zu einem enttäuschenden Ergebnis – nur 12 Nodes mit man_made=surveillance. Dabei habe ich gleich auch noch nach Ways gesucht, die mit man_made=surveillance getaggt sind:

node(area:3600062539)["man_made"="surveillance"]; out meta; way(area:3600062539)["shop"="supermarket"]; out meta;

Abfrageergebnis (dem Link folgen, auf Ausführen klicken und ein Weilchen warten)

Nur mal zum Vergleich: Der Erzfeind Köln (Relations-ID 62578) hat hat 51 Nodes und 1 Way mit man_made=surveillance, das ergibt somit ca. 20.000 Einwohner pro Kamera. (Düsseldorf hat 49.500 Einwohner pro Kamera) Deutlich besser sieht es in Karlsruhe aus, dort sind 81 Nodes mit man_made=surveillance eingetragen, das ergibt "nur" 3650 Einwohner pro Kamera.

Eines muss man jedoch beim OSM-basierten Kamerazählen beachten. Wenn in einem Ladengeschäft mehrere Kameras hängen, wird diese Information meist nur an den Node bzw. den Way, der das Geschäft repräsentiert getaggt. Hinter einem shop=supermarket, man_made=surveillance, surveillance=indoor kann sich also auch ein Dutzend Kameras verstecken.

Mein persönliches Fazit meiner Overpass-API-Abfrage ist, dass ich künftig in jedem Ladengeschäft, das ich betrete, einen Blick nach oben werfe. Daheim oder schon unterwegs mit Vespucci auf meinem Android-Smartphone werde ich dann meine Erkenntnis in OpenStreetMap eintragen. Nachdem ich jetzt langsam bei alle Ladengeschäfte in meiner Umgebung die Öffnungszeiten erfasst habe, muss ich mich beim Einkaufen ja irgendwie beschäftigen. :)

Übrigens, mein Dank geht an Roland Olbricht für dieses tolle Abfragetool und User a_peter für die Erklärung, wie man innerhalb einer Grenzrelation abfragt.

Location: Stadtmitte, Stadtbezirk 1, Düsseldorf, Regierungsbezirk Düsseldorf, Nordrhein-Westfalen, Deutschland

Bahnhofsmapping – ein Lückenfüller

Posted by Nakaner on 7 April 2013 in German (Deutsch)

"Folgende Anschlusszüge können leider nicht warten …", meistens erzeugt dieser Satz Frust und häufig eine lange Wartezeit auf den nächsten Zug. Doch diese Wartezeit kann man, nachdem man sich ein Fahrgastrechteformular besorgt hat, sinnvoll für OSM nutzen. Bahnhöfe (vor allem Hauptbahnhöfe, nicht die Haltepunkte mitten in der Pampa) sind meistens voller POIs und ein Paradies für Detailmapper. Außerdem kann man fast ohne Vorbereitung (ein Blick mit dem Smartphone auf openstreetmap.org bzw. in OsmAnd) loslegen. Bahnhofsmapping kann man in drei Teile aufteilen:

Teil 1: Verkehrswege

In den meisten Umsteigebahnhöfen sind zwar schon alle Bahnsteige und die dazu gehörigen Gleise erfasst, aber an den Fußwegen, insbesonder im Bahnhofsgebäude findet man bestimmt noch etwas zum Mappen. Hierzu zu nimmt man einfach ein Blatt Papier oder einen Notizblock und skizziert den Grundriss der Bahnhofshalle und die Bahnsteigzugänge. Später kann man dann am Notebook mit JOSM die erfassten Informationen ins Indoor-Mapping-Schema pressen. Wichtige Tags habe ich am Ende dieses Blogpost zusammengestellt.

Teil 2: POIs/Ladengeschäfte

Die Skizzen aus Teil 1 kann man anschließend mit sichtbaren allen POIs füllen. In einem Bahnhof gibt es viele mappbare Dinge: Läden, Telefonzellen, Verkaufs-/Fahrscheinautomaten, Fahrkartenschalter, Sitzbänke. Bei Ladengeschäften kann man auch noch gleich die Öffnungszeiten eintragen. Gebräuchliche Tags habe ich am Ende dieses Blogpost gesammelt.

Zwei Ebenen hat fast jeder Bahnhof. Die Bahnsteighalle und die Bahnsteige bilden meist die eine Ebene, darunter bzw. darüber gibt es oft noch eine Unter- oder Überführung, in welcher sich auch noch mehr oder weniger viele Läden befinden.

Teil 3: Bahnsteigdetailmapping

Ein Bahnsteig ist nicht nur einfach ein Bahnsteig. Meistens hat er noch ein Dach oder Unterstände für die Reisenden, dazu kommen noch Sitzbänke, Mülleimer, Fahrscheinautomaten (bei S-Bahn-Stationen und kleineren Bahnhöfen) usw. Hier kann man sich als Detailmapper richtig austoben. Auch hierfür habe ich gebräuchliche Tags gesammelt.

Der Vorteil des Bahnsteigdetailmapping ist, dass man dazu auch auf dem Nachbarbahnsteig stehen kann und so seinen Zug nicht so leicht verpasst.

Zeitbedarf

Abhängig von der Bahnhofsgröße und Wartezeit kann man meistens nicht alles erfassen. Ich habe mit Bahnhofsmapping mal Wartezeiten in Dessau Hbf, Würzburg Hbf und Heilbronn Hbf überbrückt. Die drei sind mittelkleine Hauptbahnhöfe (7 bis 11 Gleise, eine Unterführung, eine Bahnhofshalle). In Heilbronn habe ich für Bahnsteighalle, POIs und Bahnsteigmapping etwa 40 Minuten benötigt.

Wo gibt es noch etwas zu tun?

Ich habe nach dem Zufallsprinzip mir einfach ein paar Bahnhöfe ausgesucht und die verbesserungswürdigen aufgelistet:

  • Frankfurt (Main) Hbf: Ladengeschäfe in Prellbocknähe, Bahnsteigzugänge, Bahnsteigdetailmapping
  • Köln Hbf: Ladengeschäfte, Bahnsteigzugänge, Bahnsteigdetailmapping
  • Dortmund Hbf: Ladengeschäfte, Bahnsteigdetailmapping
  • München Hbf: Ladengeschäfte, Bahnsteigdetailmapping
  • Uelzen: Bahnsteige (derzeit nur teilweise vorhanden), Bahnsteigzugänge, Ladengeschäfte
  • Memmingen: Bahnsteigzugänge, Ladengeschäfte, Bahnsteigdetailmapping
  • Singen (Hohentwiel): Bahnsteigzugänge, Ladengeschäfte, Bahnsteigdetailmapping
  • Köthen: Bahnsteigzugänge, Ladengeschäfte, Bahnsteigdetailmapping

Meine Fazit ist, dass man selbst in ganz großen Verkehrsknoten (z.B. Frankfurt (Main) Hbf) noch einiges tun kann.

Vorbilder für das Bahnhofsmapping gibt es natürlich auch:

  • Hannover Hbf (sehr viele Ladengeschäfte vorhanden)
  • Stuttgart Hbf (nur DB-Teil, Aktualität wegen Stuttgart 21?)
  • Würzburg Hbf (nur Bahnhofshalle und Bahnsteigzugänge)
  • Heilbronn Hbf (Ladengeschäfte, Bahnsteigzugänge, Bahnsteigdetailmapping)
  • Dessau Hbf (Ladengeschäfte, Bahnsteigzugänge)

Tagsammlung

Die Zuordnung zu Stockwerken kann mit layer=* und im Gebäude mit level=* erfolgen. Für Öffnungszeiten gibt es den Schlüssel opening_hours=*. Die Syntax muss unbedingt eingehalten werden!

Bei fast allen Objekten außer Treppen und Rolltreppen kann man auch noch die Rollstuhltauglichkeit erfassen (wheelchair=yes/no).

Bahnsteig

  • Bahnsteig: public_transport=platform railway=platform rail=yes ref=(Gleisnummer) wheelchair=yes/no, ggf. area=yes
  • Sitzbank: amenity=bench
  • Mülleimer: amenity=waste_basket
  • Bahnsteigüberdachung: building=roof (ggf. 3D-Tagging)
  • Unterstand: amenity=shelter shelter_type=public_transport, ggf. building=yes und 3D-Tagging
  • Videoüberwachung: man_made=surveillance surveillance=outdoor/indoor/public
  • Snack-/Getränkeautomat: amenity=vending_machine vending=food/drinks

Bahnsteigzugang

  • Treppe: highway=steps incline=up/down step_count=(Stufenzahl)
  • Aufzug: highway=elevator (auf Node)
  • Rolltreppe (mit Stufen): highway=steps conveying=yes/forward/backward/reversible incline=up/down
  • Laufband (Rolltreppe ohne Stufen): highway=footway conveying=yes/forward/backward/reversible incline=up/down
  • Unterführung: highway=footway layer=-1 tunnel=passage level=(Stockwerksnummer, z.B. -1 oder 0) lit=yes/no passage_type=T01/T02/...
  • Überführung: highway=footway layer=1 bridge=yes level=(Stockwerksnummer, z.B. 1 oder 0) lit=yes/no
  • ebenerdiger Zugang: railway=crossing (auf Node)

Bahnhofshalle

  • Haupteingang: entrance=main (auf Node)
  • anderer Eingang: entrance=yes (auf Node)
  • Telefonzelle: amenity=telephone operator=Deutsche Telekom ref=(Nummer, steht auf dem Telefon) payment:coins=yes/no payment:telephone_cards=yes/no
  • Fahrkartenautomat: amenity=vending_machine operator=Deutsche Bahn payment:coins=yes payment:notes=yes payment:electronic_purses=yes payment:debit_cards=yes vending=public_transport_tickets
  • Fahrkartenschalter/Reisezentrum: shop=ticket operator=Deutsche Bahn name=Reisezentrum opening_hours=(Öffnungszeiten)
  • Blumenladen: shop=florist
  • Bäcker: shop=bakery
  • Zeitschriften/Kiosk: shop=kiosk
  • Fast-Food: amenity=fast_food cuisine=burger
  • Manche Läden kann man schwer einer Kategorie zuordnen, z.B. Le Crobag. Ich denke amenity=cafe passt am besten.
  • Bahnhofsminisupermarkt: shop=convenience name=Yorma's
  • Toiletten: amenity=toilets fee=yes/no wheelchair=yes/no opening_hours=* operator=*
  • Schließfächer: Hierfür gibt es noch kein Tag. Laut Taginfo wird amenity=lockbox achtmal verwendet, dazu fee=yes operator=*
  • Restaurant: amenity=restaurant cuisine=german/burger/... smoking=no/dedicated/...

EDIT: Rolltreppen ergänzt, richtiges Tag für Schließfächer (amenity=lockbox statt amentiy=lockers) und wheelchair=* ergänzt

Vier Verfahren zum Adressmapping im Vergleich

Posted by Nakaner on 19 March 2013 in German (Deutsch)

Nachdem ich vor etwa einem Monat von meinen Erfahrungen vom Adressmapping mit dem Auto berichtet habe, bin ich von User Markus59 auf die Android-App Keypad-Mapper 3 hingewiesen worden. Den Hinweis habe ich zum Anlass genommen, mal drei gebräuchlichsten Adressmappingverfahren und Keypad-Mapper 3 einem gemeinsamen Test zu unterziehen. Folgende Techniken werden verglichen:

  1. GPS-basiertes Verfahren
  2. Walking Papers mit Cadastre Style
  3. Keypad-Mapper 3
  4. Audiomapping

Die Aufnahme georeferenzierter Fotos habe nicht in Betracht gezogen, da das andauernde Fotografieren von Häusern als Fußgänger Anwohner vermutlich zum Ansprechen des Mappers verleiten würde, selbst wenn man eine Warnweste mit dem Aufdruck "VERMESSUNG" tragen würde.

Das Testgebiet

Den Test habe ich im Dessauer Stadtteil Törten durchgeführt. Törten ist dörflich geprägt. Der Ortskern ist, für anhaltinische Dörfer typisch, locker mit Einfamilienhäusern und Nebengebäuden bebaut. Im Ortskern habe ich mein Walking Paper getestet. An den Ortskern grenzt ein Wohngebiet mit Doppelhaushälften, alle in Reih und Glied entlang der Straße angeordnet. Dort kamen die drei anderen Verfahren zum Einsatz.

GPS-basiertes Verfahren

Wie geht das?

Mit dem GPS-basierten Verfahren habe ich vor etwa eineinhalb Jahren mit dem Adressmapping begonnen. Beim GPS-basierten Verfahren setze ich mit einem GPS-Gerät (bei mir Garmin Dakota 20) einen Wegpunkt vor mittig auf die Straße vor das Haus und notiere auf einem Formular (PDF, 35 kB) Wegpunktnummer, Hausnummer und die Straßenseite (rechts/links). Wenn die Hausnummern geordnet sind und die Bebauung homogen ist (bei Baugebieten der Fall), genügt es bei einer Hausnummernreihe, wie z.B. 18 16 14 12 10, nur vor der 18 und der 10 einen Wegpunkt zu setzen. Neben den Hausnummern notiere ich auch noch jedes mal, wenn sich der Straßenname ändert (z.B. beim Abbiegen) den Straßennamen und die Fortbewegungsrichtung (z.B. Richtung Norden, abgekürzt "Ri. N").

ausgefülltes Walking Paper, gerendert mit Maperitive und Cadastre Style

Vor- und Nachteile

Das GPS-basierte Verfahren ist gut für Gebiete geeignet, in denen keine hoch aufgelösten Luftbilder vorliegen, d.h. Gebiete, in denen man keine Gebäude vernünftig abzeichnen kann. Das war in Deutschland bis vor einigen Monaten fast flächendeckend der Fall. Zum Abzeichnen sollten die Bilder eine Auflösung von mindestens 30, besser 20 cm aufweisen.

Das Verfahren hat den Nachteil, dass man recht lange für die Auswertung in JOSM benötigt, wenn die Gebäude nicht einfach 3–5–7–9 durchnummeriert sind. Dann muss man vor jedes Gebäude einen Wegpunkt setzen und dessen Nummer sowie die Hausnummer und Straßenseite (rechts/links) notieren. Das frisst viel Zeit und man kommt nur langsam voran. Ungenauigkeiten bei der Positionsbestimmung erschweren die Zuordnung der Wegpunkte zu den Gebäuden. Diese ist gerade dann schwer, wenn die Luftbilder zu schlecht zum Abzeichnen der Gebäude sind. Man muss dann nämlich den GPS-Track in JOSM über den Layer mit den Bing-Bildern legen. Die dünne, graue Schrift kann man jedoch auch als Nicht-Farbenblinder nur schwer auf dem bunten Bing-Bild, vor allem auf grauem Asphalt, lesen.

Im Wohngebiet in Törten, wo die Bebauung homogen ist (vgl. Mapnik-Karte und Bing-Bilder), habe ich in 16 Minuten 106 Hausnummern erfasst. Das Mappen ging außergewöhnlich schnell voran, weil ich nur am Anfang und Ende der Straße einen Punkt setzen musst. Es gab nämlich keine Sprünge und Lücken in der Nummerierung. Die Auswertung dauerte 14 Minuten, insgesamt also 3,5 Hausnummern pro Minute Arbeitszeit (Summe Messung und Auswertung). Normalerweise bin ich höchstens halb so schnell.

Walking Papers

Wie geht das?

Walking Papers waren bisher mein Lieblingsverfahren zur Adresserfassung. Auf http://walking-papers.org/ habe ich mir mein Arbeitsgebiet ausgedruckt und bin mit diesen Zetteln und einem Klemmbrett losgezogen. Das Mappen selbst ist ziemlich simpel: Einfach die Hausnummern in die Hausumrisse schreiben, mehr nicht.

ausgefülltes Formular

Vor- und Nachteile

Walking Papers sind vor allem dann interessant, wenn man keinen GPS-Empfänger hat oder der GPS-Empfang, wie in Innenstädten/Straßenschluchten üblich, schlecht ist. In Innenstädten, wo die Bebauung oft kreuz und quer ist, sind Walking Papers auch deshalb vorzuziehen, weil man die Zuordnung der Hausnummer zu dem Gebäude gleich vor Ort vornehmen kann. In Wohngebieten kann man meistens das Hauptgebäude eines Grundstücks leicht erkennen: das Wohnhaus, in Innenstädten, wo alles aneinander gebaut ist, geht das nicht so leicht.

Ein Walking Paper lenkt einen jedoch leicht vom Adressmapping ab. Hier sieht man noch einen Fußweg, der fehlt, da noch einen Briefkasten und am Ende notiert man noch alle Straßenbeläge. Normale Walking Papers sind ein universell geeignetes Mapping-Hilfsmittel. Wenn man aber nur Hausnummern und vielleicht noch die Gebäudenutzung erfassen will, greift man am besten zu selbst gerenderten Walking Papers.

Im Ortskern von Törten habe ich in 34 Minuten 68 Hausnummern erfasst. Die Auswertung dauerte 14 Minuten, insgesamt also 1,5 Hausnummern pro Minute Arbeitszeit (Summe Messung und Auswertung). Der Wert ist eigentlich nicht mit den anderen Verfahren vergleichbar, da nicht dieselben Rahmenbedingungen gegeben sind.

Keypad-Mapper 3

Was ist Keypad-Mapper 3 und was kann das?

Keypad-Mapper 3 ist eine Android-App zur Erfassung von Hausnummern mit einem Android-Smartphone. Wie beim GPS-basierten Verfahren setzt man einen GPS-Punkt vor das Haus (das Abspeichern übernimmt die App) und gibt Hausnummer und Straßenseite (Links/Rechts/Vorn) ein. Keypad-Mapper 3 erzeugt eine .osm-Datei, die die Nodes mit den addr:*-Tags enthält und mit JOSM geöffnet werden kann. Außerdem wird der gelaufene Weg als .gpx-Track gespeichert. Die App setzt die Adress-Nodes um einen vom Nutzer angegebenen Abstand neben die Straße. Wenn in der Gegend schon die Gebäude abgezeichnet wurden, ist dieser Abstand eigentlich unbedeutend, da man (ich mache es zumindest so) die Tags der Adressnodes auf den Gebäudeumriss kopiert und den Node löscht.

Screenshot Keypad-Mapper 3

Meine Meinung, meine Erfahrungen

An der App gefällt mir, dass man damit sehr unauffällig mappen kann. Alle anderen Verfahren sind auffällig, weil man entweder ein Klemmbrett oder Feldbuch mit sich führt und auffällig umherschaut oder weil man "wie ein Bekloppter" :-) Nummer in ein Handy spricht. Gegenüber dem GPS-basierten Verfahren spart man sich das Aufschreiben von Wegpunkt- und Hausnummer. Weil man keine großen Möglichkeiten hat, Notizen zu machen, wird man nicht durch andere mappbare Sachen (POIs, Straßenbeläge, Hundekottütenspender usw.) abgelenkt. In kniffligen Situationen kann man aus der App heraus georeferenzierte Fotos aufnehmen.

Es wäre schön, wenn man aus der App heraus mehrere Fotos auf einmal aufnehmen könnte. Ich nutze Android 2.3, welches keine Panoramafotofunktion hat. Wenn ich eine georeferenzierte Rundumansicht möchte, muss ich jedes Bilder einzeln aufnehmen und anschließend wieder zurück zu Keypad-Mapper 3, dann wieder ein Bild aufnehmen usw. Wie ich dem Markus59 schon geschrieben habe, vermisse ich eine aktustische Warnung, wenn der GPS-Empfang schlecht wird. Als Vermesser bin ich es gewohnt, dass meine (Profi-)Empfänger "Schlechter PDOP!" über einen Lautsprecher ausgeben.

Außerdem vermisse ich die Angabe des HDOP oder PDOP in den .gpx-Dateien. Der HDOP eignet sich gut, um die Zuverlässigkeit der GPS-Positionierung beurteilen zu können. JOSM kann sogar um die einzelnen Trackpoints herum Kreise zeichnen, deren Radien von den DOP-Werten abhängen. Großer Radius heißt hoher DOP-Wert, was ein Indiz für eine schlechte Positionierung ist.

Beim Mappen sollte man nicht bummeln, lieber etwas zügiger gehen, damit der Track schön gerade ist. Die Adressnodes werden nämlich rechtwinklig zur Fortbewegungsrichtung in der vorgegebenen Entfernung zum Track (Position des Smartphones) abgelegt. Läuft man langsam, ist der GPS-Track mehr zick-zack als gerade und die Punkt landen im Nachbargebäude und/oder zu nahe an der Straße.

Im Ortskern von Törten habe ich in 16 Minuten 74 Hausnummern erfasst. Die Auswertung dauerte 15 Minuten, insgesamt also 2,4 Hausnummern pro Minute Arbeitszeit (Summe Messung und Auswertung). Der Wert ist eigentlich nicht mit den anderen Verfahren vergleichbar, da nicht dieselben Rahmenbedingungen gegeben sind.

Audiomapping

Was ist Audiomapping und wie geht das?

Beim Audiomapping nimmt man fortlaufend während des gesamten Mappens eine Tonspur auf und lässt gleichzeitig einen GPS-Logger laufen. Das kann eine Smartphone-App, wie z.B. GPSLogger (Android), oder, wie bei mir, ein eigenständiges Gerät (Garmin Dakota 20) sein. Wie beim GPS-basierten Verfahren koordiniert man die Häuser über ihre Lotfußpunkte auf die Straße. Mittig vor dem Haus sagt man die Nummer und die Straßenseite, also "Siebenundzwanzig a links".

WICHTIG: Der GPS-Track sollte zeitlich nach der Audiodatei beginnen. Dazu schneidet man mit GpsPrune einfach den Anfang des Tracks so weit ab, bis man sich an einem markanten Punkt befindet, den man gesprochen hat (z.B. die erste Hausnummer). JOSM kann zwar auch GPS-Tracks bearbeiten, man muss dabei aber aufpassen, dass der Zeitstempel erhalten bleibt. In JOSM lädt man nun den Track, anschließend klickt man im Ebenenmanager rechts auf die Ebene des GPS-Tracks und wählt "Audio importieren". Mit der Punkt-Taste kann man das Abspielen starten bzw. anhalten, mit F6 zurückspulen. Man lässt den Ton nun so lange laufen, bis man den Moment erreicht, an dem der Track beginnt. Nun drückt man [.], dann F6, um zurückzuspulen und klickt rechts auf die Audio-Ebene im Ebenenmanager und wählt "Ton synchronisieren". Wenn die Synchronisation nicht genau genug ist, kann man sich nun langsam an die optimale Synchronisation herantasten.

Meine Meinung, meine Erfahrungen

Audiomapping ist umständlich. Beim Eintragen der Adressen in JOSM bin ich mit Maus und Tastatur schneller, als die Tonausgabe abläuft. (Ich weiß, man kann die Abspielgeschwindigkeit erhöhen.) Das Synchronisieren ist stets eine Fummelei. Wenn man es nicht tagtäglich macht, vergisst man es leicht wieder. Für 107 Adressen habe ich 20 Minuten zum Mappen benötigt und 35 Minuten zur Auswertung. Zur Auswertung gehört auch das Abschneiden des Anfangs des Tracks und das Konvertieren der Tonspur in das WAV-Format, die mein Smartphone im .3gp-Format speichert, da JOSM nur WAV lesen kann. Man schafft mit Audiomapping also nur etwa 1,9 Adressen pro Minute Arbeitszeit, der niedrigste Wert

Fazit

In Gebieten mit sehr enger oder unübersichtlicher Bebauung sind Walking Papers das Mittel der Wahl. Ansonsten kann man stattdessen, wenn man ein Android-Smartphone nutzt, Keypad-Mapper 3 verwenden. Audiomapping hat sich in diesem Test als nicht so praktikabel herausgestellt. Ich habe den Eindruck, dass es nicht sehr verbreitet ist. In JOSM wird es deutlich schlechter unterstützt (umständlicher in der Anwendung) als die Verwendung georeferenzierter Fotos.

Abschließende Bitte

Unter meiner Nutzerseite habe ich im OSM-Wiki eine Seite zur Sammlung der Techniken zum Adressmapping angelegt. Wer andere Verfahren als die hier beschriebenen kennt, möge doch bitte dort eine (kurze) Beschreibung des Verfahrens hinterlassen. Später könnte man die Beschreibungen dann auf die Seite des Karlsruher Schemas verschieben und ins Englische übersetzen.

Nachtrag

Changeset GPS-Wegpunkte-Verfahren: 15421678

Changeset Walking Papers: 15421830

Changeset Keypad Mapper 3: 15421297

Changeset Audiomapping: 15424733

Location: Törten, Dessau-Roßlau, Sachsen-Anhalt, 06842, Deutschland

Versuche mit motorisiertem Adressmapping in Dessau

Posted by Nakaner on 23 February 2013 in German (Deutsch)

Die Erfassung von Hausnummern ist eine zeitintensive Arbeit, für die oft mehrere Möglichkeiten gibt. Die einen zeichnen zuerst von Bing alle Gebäude ab und schreiben dann vor Ort die Hausnummern auf Walking Papers oder Field Papers, andere setzen mit einem GPS-Gerät einen Wegpunkt vor jedes Haus auf die Straße und notieren Wegpunktnummer, Hausnummer und Straßenseite (rechts oder links). Wieder andere nutzen für das Adressmapping die Android App Keypad-Mapper 3

Ich selbst habe in der Vergangenheit Walking Papers und dem GPS-basierten Verfahren gearbeitet, bin jedoch aufgrund seiner Einfachheit auf die Technik mit Walking Papers umgestiegen, da man damit Zeit spart. Setzt man GPS-Wegpunkte, so weisen diese je nach Abschattung und Multipath-Effekten Ungenauigkeiten von bis zu 15 Metern auf, was eine Zuordnung zu den Gebäude in JOSM deutlich erschwert und Zeit frisst. Wenn jedoch, wie in Dessau bis zum 21. November 2012, nur alte, schlecht aufgelöste Bing-Bilder vorliegen, kann man nur das GPS-basierte Verfahren verwenden.

Um schneller in der gesamten Kernstadt von Dessau (d.h. Dessau-Nord, Dessau-Mitte, Dessau-Süd, Alten und Ziebigk) alle Adressen erfassen zu können, kam mir im Herbst letzten Jahres das Studienmodul Projektmanagement in meinem Studium des Vermessungswesens gerade recht. Die Aufgabenstellung "Messen Sie irgendetwas!" interpretierte ich gemeinsam mit den Usern (Kommilitonen) weltvermesserer89, 2170martin und BW12 sehr frei und nutzte sie für die Erprobung einer neuen Mappingtechnik, dem motorisierten Adressmapping.

Dazu fuhren wir vier Ende November 2012 insgesamt drei Stunden mit dem Auto durch Dessau-Ziebigk und Dessau-Siedlung und erfassten mittels Audiomapping alle sichtbaren Hausnummern. In dem Moment, in dem das Auto ein Gebäude mit einer sichtbaren Hausnummer mittig passierte, sprach der zuständige Ansager "Piep" gefolgt von der Hausnummer, wenn es auf der rechten Straßenseite lag, bzw. "Pup" gefolgt von der Hausnummer, wenn es auf der linken Straßenseite lag. Die aufgezeichnete Tonspur wurde mit einem GPS-Track (Garmin Dakota 20, Aufzeichnungsfrequenz 1 Punkt/Sekunde) in JOSM synchronisiert. Gleichzeit wurde ein Video (Blickrichtung nach vorn) aufgezeichnet, aus dem Straßenbeläge, Tempolimits und POIs (meist Zebrastreifen, Briefkästen, Durchfahrtsverbote, Abbiegebeschränkungen und Einbahnstraßen) erfasst wurden. Weil wir mit nur 20 km/h unterwegs waren, konnte fast jeder Piepton einem Gebäude zugeordnet werden.

Die Aufgaben waren wie folgt verteilt und wurden zwischendurch getauscht:

  • Fahrer: nur für das Fahren zuständig
  • Beifahrer: Videoaufnahme und Aufzeichnung des GPS-Tracks
  • hinten rechts: Ansagen der Hausnummer der rechten Straßenseite wie im Folgenden beschrieben und Starten und Stoppen der Tonaufnahme (Smartphone)
  • hinten links (meistens ich): Planung der Fahrtroute, Abbiegeanweisungen für den Fahrer, Ansagen der Hausnummern der linken Straßenseite

In JOSM wurde die Tonspur mit dem GPS-Track synchronisiert und ein Node mit den addr:*-Tags mittig auf jedes Gebäude gesetzt. Auf ein Abzeichnen der Gebäude wurde zu Projektbeginn (Anfang November 2012) verzichtet, da die Bing-Bilder in Dessau damals zu schlecht aufgelöst waren. Man hätte nämlich die Gebäudeumrisse nach Erscheinen der neuen Bing-Bilder (damals nur noch eine Frage der Zeit) alle verbessern müssen und somit unnötige Arbeit geschaffen.

Das Erscheinen der neuen Bing-Bilder am 21. November 2012 brachte die gesamte Projektplanung durcheinander. Die neuen Bilder wiesen eine Auflösung von 15 cm auf, sodass ein Abzeichnen der Gebäudeumrisse und Anbringen der addr:-Tags an den building-Way angeraten war. Es war in meinen Augen der Community gegenüber nicht verantwortbar, weiter nur Nodes zu setzen. Im gesamten Messgebiet, auch dort, wo wir schon fertig waren, zeichneten wir daher alle Gebäude ab und kopierten die addr:-Tags auf den building-Way.

Wie zu Projektbeginn geahnt und eingeplant, waren Nachmessungen nötig. Im Rahmen der Nachmessungen wurden widersprüchliche und uneindeutige Aufzeichnungen geklärt sowie die Adressen in kleinen Stichstraßen erfasst, welche der Wirtschaftlichkeit halber nicht befahren wurden.

Es wurden nur wenige neue POIs und Einbahnstraßenregelungen bei diesem Mappingprojekt erfasst, da diesbezüglich das Gebiet schon recht gut gemappt war.

Zu Präsentationszwecken und einer guten Benotung wegen renderte ich nach dem Projekt noch einen Stadtplan im Maßstab 1:5000 (Format DIN A1) mit einem angepassten Style mit Maperitive.

Mein Fazit

Unabhängig davon, ob brauchbare Luftbilder vorliegen oder nicht, ist eine motorisierte Erfassung von Adressen nicht sinnvoll, da sie gegenüber dem klassischen Adressmapping mit Walking Papers oder GPS keine Zeit- und Genauigkeitsvorteile liefert. Kommerzielle Geodatenanbieter erfassen Adressdaten teilweise zwar auch motorisiert, nehmen jedoch nicht jede einzelne Hausnummer auf und ermitteln die übrigen Hausnummern durch Interpolation. Das ist meiner Meinung nach mit dem Qualitätsanspruch von OSM nicht vereinbar. Wenn hoch aufgelöste Orthophotos vorliegen, ist die motorisierte Erfassung gänzlich ungeeigent, da man zu Fuß genauso schnell ist. Man kann nämlich nebenbei noch die Gebäudenutzung (z.B. Wohnhaus oder Garage) erfassen und man stößt bei der Auswertung seltener auf Widersprüche, wodurch die Nachmessungen eingespart werden.

Die motorisierte Erfassung eignet sich somit nur für kaum kartierte Gebiete, in welchen nicht einmal die Straßenverläufe vorhanden sind, und für Überlandfahrten, bei denen Tempolimits, Durchfahrtsverbote, Straßenbeläge usw. erfasst werden sollen.

EDIT: Keypad Mapper 3 ergänzt EDIT2: Aufzählung besser formatiert

Ein Hauch Liegenschaftskarte mit Maperitive

Posted by Nakaner on 16 February 2013 in German (Deutsch)

Seit ich beim Mappen von Hausnummern die Gebäudenutzung (z.B. Wohnhaus, Garage) miterfasse, ärgere ich mich darüber, dass es keine Kartenstil gibt, der die Gebäudenutzung rendert und gleichzeitig wenig Toner/Tinte verbraucht. Deshalb habe ich jetzt Cadastre Style, einen schwarz-weißen Stil für Maperitive, entwickelt. Cadastre Style (deutsch: Kataster-Kartenstil) lehnt sich an die amtliche Liegenschaftskarte an.

Hausen an der Zaber mit Cadastre Style gerendert

Abbildung: Hausen an der Zaber mit Cadastre Style und Maperitive gerendert

Cadastre Style verzichtet größtenteils auf Flächenfarben und verwendet stattdessen Schraffuren, um Toner zu sparen. Außerdem kann man dadurch mittels Farbstiften seine Notizen hervorheben, was beim Standard-Mapnik-Stil nicht funktioniert, da er recht bunt ist. Weil auf Flächenfarben weitestgehend verzichtet wird, kann man mit harten Bleistiften auch einfacher die Hausnummern auf die Gebäude schreiben (und diese Hausnummern auch leichter lesen).

Die Gebäudenutzung wird durch drei verschiede Schraffurarten und noch viel mehr (baden-württembergische) Abkürzungen angegeben. Wie in manchen Liegenschaftskarten werden Wohnhäuser aufsteigend schraffiert. Ist die Nutzungsart eines Gebäudes angegeben (z.B. building=garage), aber das Gebäude kein Wohnhaus, wird senkrecht schraffiert. Horizontal wird schraffiert, wenn keine Nutzungsart (building=yes) angegeben ist. Handelt es sich um eine Nutzung, die kein Wohnen ist (z.B. Lagergebäude) wird sie abgekürzt angegeben.

Bestimmte Nutzungsarten wie Schule und Kindergärten werden auch erkannt, wenn sie "falsch" getaggt sind. Ein Kindergarten muss entweder building=kindergarten oder building=yes + amenity=kindergarten getaggt sein.

Hat das Gebäude schon eine Hausnummer, wird diese mittig in das Gebäude geschrieben, wenn der addr:housenumber-Tag am Gebäude-Umriss hängt. Hängt der Tag an einem einzelnen Node (z.B. Eingang), wird die Hausnummer an der Stelle des Nodes gerendert.

Auf Landnutzung wird vollständig verzichtet. Straßen werden in vier Kategorien eingeteilt, die man anhand ihrer Breite und ihres Grautons unterscheiden kann. Als Flächen gemappte Straßen und Wege werden nicht unterstützt. Seen sind die einzigen Objekte, die eine Flächenfarbe bekommen. Weil man Adressmapping beitreibt, werden POIs der Übersichtlichkeit nicht gerendet, es sei denn, es handelt sich um eine Gebäudenutzung, wie z.B. eine Schule.

Ganz zufrieden bin ich mit dem Stylesheet noch nicht. Die Positionierung der der Gebäudenutzung und Hausnummern stimmt noch nicht ganz. Außerdem weiß ich nicht, wie ich die Umrisslinie der Gebäude dünner zeichnen kann.

Unter http://wiki.openstreetmap.org/wiki/User:Nakaner/Cadastre_Style sind alle Abkürzungen und Schraffuren beschrieben. Das Stylesheet selbst ist CC-BY-SA 2.0-lizensiert und liegt auf Github.

Location: Dürrenzimmern, Brackenheim, Verwaltungsgemeinschaft Brackenheim, Landkreis Heilbronn, Regierungsbezirk Stuttgart, Baden-Württemberg, Deutschland
Older Entries | Newer Entries