OpenStreetMap

Diary Entries in German

Recent diary entries

Qualitätskontrolle mit Android-Apps

Posted by monotar on 10 January 2016 in German (Deutsch)

Einführung

Daten eintragen ist das eine, was Apps daraus machen, das andere.

In letzter Zeit teste ich vermehrt mit Osmand und Magic Earth. Osmand wird monatlich aktualisiert, Magic Earth wohl so aller 2-3 Monate. Von daher hat man immer eine recht aktuelle Datenbasis.

Für mein Verständnis haben die Apps für den Normalo 2 Hauptfunktionen:

  • POI-Suche
  • Navigation

Die weiteren Funktionen sind für den Normalo teilweise uninteressant, dafür für den Mapper umso wichtiger.

Tags und Probleme in OSM

POI

Die POI-Suche nach Namen ist teilweise bisschen hakelig, da keine Fehler zugelassen werden, da kann aber OSM nichts dafür. Die allgemeine Suche nach POI funktioniert dafür gut. Interessant ist die Funktion in Magic Earth POI als Kontakt im Telefonbuch abzulegen. Es zeigt sich dann, wie wichtig es ist, dass bei einem POI alle Daten angeheftet sind, d.h. auch Adresse usw. an jedem POI heftet, damit es dann auch in den Kontakten landet. Bei beiden Apps kann man die Website des POI direkt aufrufen, ebenfalls sehr gelungen. Was nur bei Osmand funktioniert: Auswertung der Öffnungszeiten, Aufruf weiterer Kontaktmöglichkeiten (twitter, facebook usw.) - alles in allem auch sehr komfortabel, wenn man unterwegs ist (muss dann natürlich eingetragen sein).

Navigation im Simulationsmodus

Osmand und Magic Earth bieten beide einen Simulationsmodus für die Navigation. So kann man sich in Ruhe anschauen, was die Apps aus den Daten machen.

Aufgefallen ist mir folgendes:

  • turn:lanes bei kleineren Kreuzungen sind kein Problem
  • bei größeren Kreuzungen mit eigenen Fahrspuren pro Fahrbahnrichtung gibts immer mal Probleme beim Anzeigen der Spuren auf welchen man sich bewegen soll. Die Apps verhalten sich auch nicht gleich, ein einheitliches Muster fürs Tagging scheint schwer zu etablieren
  • Die Ansagen "geradeaus", "rechts" und "links" werden bei Hauptstraßen oft mal falsch angesagt. Der Fehler liegt hier in den Daten bei OSM selbst. Aus dem Luftbild werden Hauptstraßen an Kreuzungen rund gemalt. Ob man Kreuzungen rund malt, sollte aber nicht vom Luftbild entschieden werden, sondern der Ausschilderung folgen.Zeigt die Ausschilderung eine abbiegende Hauptstraße, sollte diese Kreuzungsgeometrie auch in OSM zu sehen sein; zeigt die Ausschildung keine abbiegende Hauptstraße, kann und sollte man die Hauptstraße ruhig rund zeichnen
  • Die Routenvorschläge sind immer eine Sache für sich: ob hier etwas richtig oder falsch ist, kann jeder für sich beurteilen. Aber man bekommt ein Gefühl, was letztlich aus den Daten gemacht wird. Eine vollständige Datenbasis (Klassifizierungen, maxspeed, smoothness usw.) sollte in der Zielregion natürlich schon vorhanden sein.

Navigation im Feldmodus

Im realen Feld sollte man die Navigation natürlich auch testen. Ich bevorzuge hier ganz klar Osmand. Das einzige was bei Magic Earth interessant ist, ist die bessere Performance bei Langstrecke und die Abbiegehinweise. Bei Osmand kann man sehr gut die eingetragene Höchstgeschwindigkeit kontrollieren. Notizen kann man über Text und Audio aufnehmen, wobei das als Fahrer trotzdem schwierig ist. Beifahrer zu sein ist schon besser.

Sonstige Funktionen

Osmand bietet viele weitere Funktionen an die zur Qualitätssischerung für mich geeignet sind:

  • Straßenbeleuchtung (lit=yes/no)
  • surface
  • smoothness
  • access-Beschränkungen foot/bicycle

Wer in Osmand dazu ein Beispiel sehen will, der kann sich einmal die Stadt Wurzen anschauen, ich habe diese mit diesen Tags unter Zuhilfenahme von Osmand für die Hauptstraßen weitgehend komplettiert. Lässt sich auch wunderbar sammeln, wenn man unterwegs ist und auf dem Handy sofort sieht, was noch alles fehlt.

Probleme protokollieren

Wenn ich draußen unterwegs bin, schreibe ich mir bei Problemen immer einen Favoriten an die jeweilige Stelle und trage das später am PC ein. Osmand bietet noch Foto, Audio oder Video, auch nicht schlecht.

Andere Apps

EB Dirigo habe ich ebenfalls mal angeguckt. Man kann auch dort simulieren, aber leider kann man den Anfangspunkt nicht wählen, wodurch man immer ein FakeGPS braucht. Für mich nicht praktikabel, von daher verzichte ich darauf. Auch sonst sehe ich der App nichts besonderes, eher ein kleiner Funktionsumfang.

Gibt es noch andere gute Apps, die sich zur Qualitätskontrolle eignen?

Sachsen: landesweite Adressliste und Auswertung

Posted by okilimu on 10 January 2016 in German (Deutsch)

Zusammenfassung

Über die OSM-User Nakaner und malenki (vielen Dank an Beide!) habe ich am Freitag die sächsische Mitteilung über die Veröffentlichung von vier Datensätzen gefunden. Den Datensatz über die 932.727 amtlichen Adressen in Sachsen habe ich mit einigen Nacharbeiten gestern importiert und eine erste landesweite Auswertung (grafisch, tabellarisch) durchgeführt.

Lizenzrechtliches

Die Lizenz ist Deutschland 2.0 mit Namensnennung und leider die Daten wegen der notwendigen Namensnennung nicht für uns direkt in OSM nutzbar. Ein informierter OSM-Kollege wird aber nachhaken, ob wir eine extra Freigabe für OSM bekommen können.

Für meine Auswertung reicht die Lizenz aus, weil ich auf der Auswertungsseite jeder Gemeinde die Lizenzangaben aufführe. Die Geokoordinaten sind zwar in der Auswertungsdatenbank gespeichert, derzeit aber auf der Website nicht verfügbar, um einen Mißbrauch in OSM zu verhindern.

Nacharbeiten zur Datenquelle

Zur Auswertung des Adress-Datensatzes musste ich noch zwei Anpassungen vornehmen:

  • Inverse Geokodierung: von der Geokoordinate einer Adresse habe ich die Gemeinde und den Gemeindeschlüssel in OSM geholt. Eigentlich ist bei jeder Adresse der ORT angegeben, der Wert ist aber bei ländlichen Gemeinden der Ortsteil, ein Siedlungsname oder ähnliches.

  • Nach der inversen Geokodierung traten 41 Adressen auf, die mit ihren Geokoordindaten außerhalb der sächsischen Landesgrenze lagen. Mit der Angabe in ORT konnte die richtige Gemeinde zugeordnet werden. Ob der Grenzverlauf ungenau ist oder die Adressen gültig sind, obwohl sie außerhalb der Gemeinde und des Landes liegen, habe ich nicht geklärt (dürfte eher vor Ort herauszufinden sein). Tabelle mit den besonderen Adressen.

Import und ignorierte Hausnummerlisten

Für die Gemeinden Coswig, Dresden, Flöha, Freiberg und Leipzig lagen bereits Hausnummerlisten vor, daher wurden diese vorab herausgefiltert. In Kürze werden die vorliegenden Listen mit dem jeweiligen Stand aus der Landesliste abgeglichen, um die bessere Liste zu verwenden. Für Leipzig und Flöha ist schon klar, das die Liste aus dem sächsischen Adress-Datensatz verwendet werden.

Von den original verfügbaren 932.727 Adressen sind bisher für die Auswertung inkl. der fünf vorher vorhandenen Listen 917.396 Adressen für 429 Gemeinden verfügbar. Ich prüfe kurzfristig, ob der "Schwund" nur auf den o.g. fünf extra Hausnummerlisten und deren unterschiedlichem Inhalt basieren oder ein weiterer Grund vorliegt.

Ergebnis der ersten landesweiten Auswertung

  • 917.396 Adressen landesweit offiziell vergeben und für Auswertung verfügbar

  • 345.904 in OSM übereinstimmende Adressen zur Landesliste (nur Straße und Hausnummer auf Gleichheit geprüft)

  • 21.462 Adressen nur in OSM vorhanden

das ergibt eine landesweite Abdeckung von 37,71% aller Adressen.

Für ganz Deutschland hatten wir am 31.12.2015 eine Abdeckung von 47,12%.

Zyklische Auswertung

Die Hausnummerauswertung für die deutschen Gemeinden läuft zweimal in der Woche, Montags und Freitags früh um 0:04h los und war bisher um ca. 7h fertig. Durch die zusätzlichen Listen wird Deutschland ab Montag vorauss. um 9h komplett fertig sein.

Sächsische Listen für theoretische Hausnummerauswertung nutzbar

Für die monatliche theoretische Hausnummerauswertung wurden in 2014 die damals verfügbaren 49 Hausnummerlisten verwendet, um Formeln zu Ermittlung der ungefähren Anzahl an Hausnummern je deutsche Gemeinde abzuschätzen. Mit der jetzt verfügbaren, landesweiten Liste kann ich die Formeln vorauss. erheblich verbessern.

Dietmar Seifert aka okilimu

regio-osm.de Betreiber

Location: Innere Neustadt, Neustadt, Dresden, Sachsen, 01097, Deutschland

my lastcheck -> check_date

Posted by Lübeck on 10 January 2016 in German (Deutsch)

Moin !

seit längerer Zeit bin ich Verfechter die Daten in OSM zu prüfen und entsprechend zu kennzeichnen. Es gab hierzu auch mehrere diskussionen. Bis heute habe ich immer lastcheck verwendet.

Gestern ist mir erst bewußt bekannt geworden, dass es auch schon check_date gibt welches im Wiki schon dokumentiert ist (http://wiki.openstreetmap.org/wiki/Key:check_date) und auch von der Syntax besser zu start_data, end_date .... entspricht.

Deshalb werde ich künftig dieses verwenden und soweit es mir möglich war habe ich meine Tags geändert.

Ich poste dieses um auch entsprechend Werbung für die QA zu machen.

gruß Jan

i future i will use check_date instead of lastcheck!!!

regards Jan

Location: Sankt Lorenz Süd, Lübeck, Schleswig-Holstein, Deutschland

OSM braucht ein neues openstreetbugs

Posted by monotar on 9 January 2016 in German (Deutsch)

Einleitung

Zuletzt habe ich in OSM markante POI mit verschiedenen Social-Media-Tags ergänzt. Dass diese sinnvoll sein können, zeigen Apps wie Osmand und Magic Earth die z.B. Telefonnummer, Website auswerten und Osmand auch andere Tags wie contact:facebook auswertet und innerhalb der App verlinkt. Im mobilen Einsatz ist es sehr bequem, wenn diese Tags gesetzt sind, da viele Handys appbasiert am effektivsten arbeiten.

Nun ist es ja bekanntlich so, dass viele Geschäfte inzwischen nur noch eine Facebook-Website besitzen, also kommt man um facebook ohnehin nicht umhin. Andere Tags wie twitter, youtube oder alle sonstigen wie vimeo, pinterest oder instagram habe ich gleich mitgesetzt.

Status quo

Während ich in Magic Earth nach POI wie "Flughafen Dresden" suchte, sah ich, dass dieser nur absolut stiefmütterliche Tags besitzt, nicht einmal eine postalische Adresse. Auch andere Gebäude haben durch das Taggen der Nummer auf den Eingang nicht einmal eine postalische Adresse. Die Datenqualität in OSM kann nur als dürftig beschrieben werden.

Klar kann sich nun der OSM-Mapper hinsetzen, aber das kann ja nicht Sinn der Sache sein tausende POI händisch nach Updates zu untersuchen. Bei unserem Konkurrenten google ist es z.B. so, dass jeder User die Fehler in den Daten melden kann. Bei OSM ist das nur über openstreetbugs möglich. Aber sein wir ehrlich: openstreetbugs ist nur für Leute gedacht, die überhaupt verstanden haben was OSM ist, nicht für App-Benutzer, die vielleicht gar nicht wissen, was OSM ist. Bereits das Beispiel MapDust von skobbler zeigte, wie die Nutzer mit unsinnigen Fehlermeldungen das System fluten können.

Anforderungen

Was braucht OSM also? Unter höchstmöglicher Produktivität stelle ich mir das folgendermaßen vor: OSM erstellt eine Bug-API die alle Apps nutzen können. Der User kann dann in der App jegliche Tags, z.B. das Feld "Website" oder "contact:facebook" usw. als fehlerhaft melden. Dann hat er verschiedene Meldegründe:

  • Wert überprüfen: "Website lässt sich nicht öffnen" (würde den Grund dafür optional lassen, gibt OSM aber Möglichkeit nachzugucken, ob etwas noch stimmt)
  • Wert ändern: Seite umgezogen -> Eingabe der neuen Seite
  • Wert hinzufügen: Eingabe der Seite
  • Wert löschen: Website existiert nicht mehr (z.B. geschlossen) --> im Endeffekt hat der Nutzer so die Möglichkeit, jeden Tag als "überprüfen", "hinzufügen", "löschen" oder "ändern" zu markieren und dazu einen neuen Wert sowie Kommentar zu hinterlassen.

Zusätzlich muss der App-Lieferant zusätzlich 3 Tags zu jeder Fehlermeldung protokollieren:

  • Den App-Lieferant (da schlecht designte Apps u.U. uns mit Bugs überfluten, wo sich die Benutzer über die App auslassen o.ä.)
  • Die App muss uns eine anonyme unique User-ID liefern, damit wir die Validität der Datenlieferanten einschätzen können und Spammer blocken können
  • Die ID des zu bearbeitenden Objekts (Relation, Way, Node)

Bearbeitung durch Mapper

Nun sind diese Daten im OSM-Bug-System. Sie sollten aber nicht nur einfach dargestellt werden, wie das bei MapDust oder openstreetbugs der Fall ist, sondern aufgrund der zu erwartenden hohen Fehlerzahlen, muss die Verarbeitung verbessert werden. Da der Datenlieferant uns die Daten bereits auf das konkrete bezogene Objekt und die zu ändernden Daten bringt, wird es für den versierten OSM-Mapper einfach, indem er in einer Web-Oberfläche entscheidet: Im Grunde hat der OSM-Mapper 4 Möglichkeiten:

  • Bug-Mängelmeldung übernehmen: Nach einem Klick auf "übernehmen" werden die vorgeschlagenen Änderungen instant in die Datenbank gebracht (vorher hat der Mapper noch Möglichkeit, selbst kleine Änderungen an Tags vorzunehmen (z.B. Websiteangabe normieren))
  • Bug-Mängemeldung ablehnen: Die Bug-Meldung wird geschlossen, es werden keine Änderungen vorgenommen (optional Kommentar)
  • Bug-Mängelmeldung selbst übernehmen: der Mapper öffnet selbst einen Editor und ändert das Objekt, danach ist der Bug geschlossen (wenn komplizierter Sachverhalt)
  • Bug-Mängelmeldung benötigt lokales Wissen/Vor-Ort Besichtigung: Der Bug ist nicht geschlossen, aber er wurde bereits durch einen Mapper erfolgreich anfangsgeprüft. (So können wir gewähren, dass VorOrt-Bugs die lange rumliegen können, unser System nicht verstopfen und wir neue Bugs trotzdem filtern können)

Schluss

Das ist mein Vorschlag, er würde OSM extrem in der Breite verbreiten und anschließend eine effektive Abarbeitung ermöglichen sowie sogar Spezial-Apps eine Möglichkeit geben, bestimmte Dinge flächendeckend durch User einzutragen lassen. Durch die Kennzeichnung des App-Lieferanten könnten Spezial Mapper (z.B. Eisenbahninfrastrukturmapper) durch Filterung sich extra dieser Bugs annehmen. Sicher muss man an der einen oder anderen Stelle noch etwas verfeinern, aber das wäre das Grundprinzip.

test

Posted by Ziltoidium on 9 January 2016 in German (Deutsch)

nothing here

Speisung des Umspannwerk Jahnsdorf

Posted by Toliman on 7 January 2016 in German (Deutsch)

Wie wird das Umspannwerk Jahnsdorf, südlich von Chemnitz, gespeist? Über ein Erdkabel? Über eine Freileitung von Stollberg / Erzgebirge? Mit welcher Spannung erfolgt die Speisung?

Location: Pfaffenhain, Jahnsdorf/Erzgeb., Erzgebirgskreis, Sachsen, Deutschland

Straßenlaternen in OpenStreetMap

Posted by mapper999 on 3 January 2016 in German (Deutsch)

Diese Karte zeigt Straßenlaternen und ihre Eigenschaften in den Daten der OpenStreetMap. Es werden Betreiber, Referenznummern und Details zu den verwendeten Leuchtmitteln angezeigt.

Einige Beispiele:

Schweden

Düsseldorf

Lübeck

Testinstallation | Quellcode | flattr

Unterstützte Tags

Es werden zur Zeit die folgenden Tags unterstützt:

  • highway=street_lamp | light_source=lantern|floodlight|*

  • ref|lamp_ref=*

  • operator|lamp_operator=*

  • light:method|lamp_type=high_pressure_sodium|high-pressure_sodium|low_pressure_sodium|low-pressure_sodium|LED|metal-halide|metal_halide|fluorescent|mercury|electric|gas|gaslight

  • light:mount|lamp_mount|support=straight mast|straight_mast|bent mast|bent_mast|cast steel mast|cast_steel_mast|mast|pole|wall_mounted|wall|suspended|ceiling

  • light:count=1|2|3|4

  • light:direction=*

  • light:lit=dusk-dawn|demand|*

  • manufacturer=*

  • model|lamp_model:de=*

Es dürfen gerne weitere Keys oder Values über Pull Requests vorgeschlagen werden.

Hinweis: Da die Karte CSS3-Filter benutzt, ist das Ergebnis im Internet Explorer (und eventuell auch in anderen Browsern) leider nicht ganz so schön.

License

The code for this project is based on OSMfahrkartenautomaten ( Testinstallation | Quellcode | flattr ) by ubahnverleih.

what about symbols for sport-clubs associations or society

Posted by macgillig on 1 January 2016 in German (Deutsch)

I would be glad finding or using as symbol for clubs, association or societies for e.g. dlrg (german life saving society) or a sport-club

looking for a suggution

peter

Location: Moabit, Mitte, Berlin, Deutschland

Anbindung Opel II Flächen an A40 Raststätte

Posted by TeamEnerga on 28 December 2015 in German (Deutsch)

Verlauf einer LKW Transitstrecke. Dortmund nach Bochumer"Werksflächen" Bedarfsgesteuerte Streckenführung mit Anlehnung eines Wrtschaftsweges "Streckenwartung der DB" Die Belastung der Anwohner kann mit einer Beteiligung umgesetzt werden. Selbst eine nötige geänderte Anfahrtsrichtung über die A40 ist mit geringsten Aufwand "Streckeninformation" möglich. Bewohnerbeeinträchtigung ist auf ein Minium beschränkt.

OSM und Linux

Posted by q_un_go on 23 December 2015 in German (Deutsch)

Wenn ich mir so die deutsche Mailingliste anschaue, wer da schreibt und vor allem mit was, so sind das gefühlt gut 50% Linux-Anwender. Ich habe guten Grund zur Annahme, dass die aktivsten Mapper in Deutschland ebenfalls zu einem Gutteil Linux einsetzen - mich würde gar nicht wundern, wenn über die Hälfte aller Einträge in OSM zumindest in D von Linux aus gemacht wurden. (und die Community aus DACH zählt ja zur weltweit aktivsten, gemessen an der Kleinheit des Gebiets ohnehin.

Ob das auch all jenen bewusst ist, die OSM-Dienste für sich verwursten? Dass Mac-User eher selten mappen und Windows-Anwender gemessen an der Verbreitung des System auch?

Ich kann mich noch an die Anfänge so um 2009 erinnern, als man versuchte, Editoren für Betriebssysteme herauszubringen und Linux dabei eher stiefmütterlich behandelte. Das hat sich ja nun wohl geändert.

Was ich in dem Zusammenhang nicht so gut finde: Wenn man Geräte herausbringt, auf die man OSM-Karten draufspielen kann und dabei nicht auch an Linux-Anwender denkt.

Sorry, aber solche Firmen spucken denen ins Gesicht, die die Daten erstellen und pflegen. Garmin machte es früher beispielsweise so und auch jetzt sind ihre Tools nun nicht so Linux-freundlich, vornehm formuliert. Aber immerhin lassen sie es zu, dass man auch anderweitig zum Ziel kommt. Nur ist es halt nicht so bequem.

http://kamagrathebest.com/

Posted by ronaldodack on 23 December 2015 in German (Deutsch)

Kamagra Tabletten wurden von Männern längst für Erektile Dysfunktion eingesetzt. Viele Mediziner und Ärzte empfehlen auch die Verwendung von Kamagra zu bewältigen mit erektiler Dysfunktion. Daher ist das Medikament auf dem Markt verfügbar. Wenn Sie nicht die Droge von regulären Markt aufgrund der Verschreibung oder jedes andere Problem bekommen können, dann können Sie Kamagra online kaufen. Mit einigen grundlegenden Details können Sie Kamagra online bestellen. Kamagra Gelees und Tablets stehen unter verschiedenen Markennamen auf die online-Website zur Verfügung. Daher müssen Sie einige Optionen, wenn Sie Kamagra online kaufen und die Bestellung ohne Angabe der Verschreibung gemacht werden können

http://kamagrathebest.com/

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.

Unterwegs auf Neuen Wegen

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

Blick in Richtung Friesach

Die Bäume vor der untergehenden Sonne

Der alte Steinbruch

Die Sonne wärmt angenehm

Location: Kirchenviertel, Gratkorn, Graz-Umgebung, Steiermark, 8101, Österreich

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.

Digitalcourage - Adventskalender - Openstreetmap

Posted by jaltux on 9 December 2015 in German (Deutsch)

Der Verein Digitalcourage e. V. [1], der sich nach eigener Aussage seit 1987 für Grundrechte, Datenschutz und eine lebenswerte Welt im digitalen Zeitalter einsetzt, hat zur Adventszeit einen digitalen Adventskalender [2] veröffentlicht.

Hinter jeder Tür sind Tipps rund um Themen zum Schutz der Privatsphäre im Internet bzw. Alternativen zu den üblichen Webangeboten versteckt.

Am 9. Dezember [3] findet man einen Beitrag zu OpenstreetMap.

[1] https://digitalcourage.de/ [2] https://digitalcourage.de/support/digitale-selbstverteidigung/adventskalender-2015 [3] https://digitalcourage.de/support/digitale-selbstverteidigung/adventskalender2015/09-openstreetmap-statt-google-maps

Weihnachtseinkäufe für OSM

Posted by malenki on 27 November 2015 in German (Deutsch)

Pünktlich zum Beginn des alljährlichen Jahresend-Kaufrausches ziehe ich wieder ein Fazit zum Stand des Amazon.de-Werbepartner-Programms für OpenStreetMap.

Seit Beginn der Teilnahme an dem Programm wurden bis heute (27.11.2015) über das Amazon-Partnerprogramm 6178 Produkte gekauft, was in einem Umsatz von 174.605,76 EUR für Amazon resultierte.
Die Auszahlungen für OSM summieren sich auf 8.065,74 EUR, mit dem noch auszuzahlenden Beträgen wird eine Summe von 8.723,71 EUR erreicht. (Amazon zahlt den Werbepartner-Anteil drei Monate nach Generierung aus, um Rücksendungen ausnehmen zu können.)

Falls ihr im Dezember noch die eine oder andere Anschaffung tätigen wollt und bei Amazon einkauft, benutzt bitte den Affiliate-Link für Amazon.de oder installiert in Firefox die Amazon-Suchmaschine mit Affiliate-Link, die ihr auf der Spenden-Seite finden könnt. Auch für die Partner-Links für [Amazon.co.uk](Amazon.co.uk ) oder Amazon.com gibt es dort entsprechende Suchmaschinen.

Die Auszahlungen von Amazon.de gehen an den FOSSGIS e.V., der in Deutschland die Interessen von OSM vertritt. Ich durfte bereits zweimal die Unterstützung des FOSSGIS genießen – bei der Anschaffung einer Leinwand für OSM-Stände und kürzlich *hust* bei der Erstattung von Übernachtungskosten, während ich drei Tage einen OSM-Stand betreute.
Jeder – auch jedes Nicht-Mitglied – kann beim FOSSGIS um Förderung von OSM-bezogenen Projekten und auch anderen, den Zielen des Vereins entsprechenden Projekten bitten. Details dazu und eine Liste von Projekten, die der FOSSGIS bereits finanziert hat, findet man in dessen Wiki. (Ich selbst bin auch (noch?) kein Mitglied des FOSSGIS.)

Vielen Dank an alle, die OSM direkt oder indirekt gespendet haben.
Weiterhin Frohes Mappen!

Nachtrag 5. Abenteuertage Glauchau

Posted by malenki on 26 November 2015 in German (Deutsch)

Vom dritten bis zum fünften März hatte ich mit Rockus bei den Abenteuertagen einen OSM-Stand betreut. Kürzlich fiel mir die Quittung für die zwei Übernachtungen in die Hand. Im April meinte jemand, der mit dem FOSSGIS recht vertraut schien, ich solle den Beleg doch einschicken. Auch mit nachträglichen Anfragen gehe man durchaus kulant um. Obwohl mittlerweile acht Monate vergangen waren, schickte ich den Beleg ein.
Und siehe da – die Kosten wurden mir schneller erstattet als gedacht.
Vielen Dank! :)

OSM-Stand

Location: Gesau, Glauchau, Landkreis Zwickau, Sachsen, Deutschland

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

Überlappende Gebäude in Osmose bzw. in .de bzw. in OSM

Posted by MKnight on 6 November 2015 in German (Deutsch)

Achtung, wird möglicherweise etwas länglich. TL:DR: Geht steil!

Schönes Feature - hat mir bisher in anderen Tools gefehlt.

Vorweg, ich (und czubi, ein Thüringer Extrem-häusermapper, der auf eine Anfrage hinzukam) hab mich da die letzten Tage in Thüringen ausgetobt. Hat auch ganz sicher keinen Spass gemacht ;)

Angefangen hat die neue Sucht irgendwann damit, dass ich mir per Overpass sämtliche Buildings aus verschiedenen Thüringer (Land-Kreis-)boundarys geholt hab, und die auf den JOSM-Validator losgelassen habe. Das war aufgrund Speicherverbrauch auf Dauer irgendwie nicht zielführend und irgendwann hab ich rein zufällig (kein Witz) die Option über Umwege bei Osmose endeckt. Bei Osmose gibt es eine Option: "Probleme vom User" und da bisschen rumgeklickt und (natürlich neben etlichen anderen) doch tatsächlich ein paar Jugendsünden gefunden. (Und ja, mittlerweile weiss ich, dass es der erste Punkt auf der Webmap is...)

Lange Rede kurzer Sinn: Im Qat-Script im Osmose-tab geschaut, ob es die (überlappende-Gebäude-)Option gibt; gibt es und losgelegt. Etwa 5000 bzw. gefühlt 50000 Gebäude später: Alternativtext Oben rechts ist Thüringen. Der Screenshot ist so komisch gewählt, weil ich auf noch was anderes hinauswill.

Wenn man mal nach Frankreich schaut, dort ist mit wenigen Ausreissern alles eitel Sonnenschein. Ich tendiere dazu, das an Osmose festzumachen, bei ein paar Stichproben kann ich in .fr nicht erkennen, dass da signifikant weniger oder nur wenig Häuser gemappt werden. Möglicherweise gibt's auch andere Ursachen, wie besser dokumentiertes Wiki zum Thema oder was auch immer, keine Ahnung. (Für Studenten und neu hinzugekommene: Osmose gab es bisher™ nur in Frankreich) Jedenfalls haben wir da "etwas" Nachholbedarf.

Damit ich das übliche Gemecker nicht vergesse:

Die Gebäudeprüfung bei Osmose ist etwas unscharf (top!) eingestellt, die findet auch Gebäude, die sich nicht überlappen, sondern (reale) 10cm (oder was die Baustelle) voneinander entfernt sind. 2 Dinge dazu:

  • Der Josm-validator sollte das auch können
  • ich würde eine noch unschärfere Prüfung bis schätzungsweise 40-50cm begrüssen. Meiner Einschätzung nach gibts so gut wie keine false positive vorher

Weiterführend:

Urlaub auf dem Lande mit Handicap

Posted by 24Balder on 5 November 2015 in German (Deutsch)

Urlaub auf dem Bauernhof mit Pflege

Location: Poolstraße, Esche, Samtgemeinde Neuenhaus, Landkreis Grafschaft Bentheim, Niedersachsen, 49828, Deutschland
Older Entries | Newer Entries