(English version below)
Liebe Mitstreiter,
nach der Umstellung auf Augmented Diffs, die eine Verkürzung des
Update-Zyklus auf ein paar Stunden erlauben, verhindert ein Bug [1] in
der Overpass-Api seit Anfang Oktober die Aktualisierung der Karte. Wir
hoffen auf eine schnelle Lösung des Problems und melden uns dann wieder.
Viele Grüße
Peter
***
To all OpenRailwayMap fans:
Since ORM switched to augmented diffs lately which allow more frequent
map updates. However, a bug [1] in Overpass Api prevents the map to be
updated ever since early October. We are hoping for a quick solution to
this issue and will get back to you the moment it is fixed.
All the best
Peter
[1] https://github.com/drolbr/Overpass-API/issues/139
Hallo Tracy,
ich erlaube mir mal, die OpenRailwayMap-Liste ins CC aufzunehmen.
Am 2014-10-23 um 16:28 schrieb Tracy Kasperczyk:
> Hallo Michael,
>
> ich meinte mit der Priority-Geschichte ehr folgendes Thema:
>
> Key: priority
>
> - priority <http://wiki.openstreetmap.org/wiki/Key:priority>=primary
> <http://wiki.openstreetmap.org/w/index.php?title=Tag:priority%3Dprimary&ac...>
> -
> These are the rails that are used for long-distance-connections between
> cities. There are often two or more tracks. Each track is often oneway.
> Then they should be tagged separately (as dual / multi - carriageway on
> highways).
> - priority <http://wiki.openstreetmap.org/wiki/Key:priority>=secondary
> <http://wiki.openstreetmap.org/w/index.php?title=Tag:priority%3Dsecondary&...>
> -
> These are the sub-net-rails where mostly short-distance-connection rides.
> The trains stop at nearly every stop and often there is only one track for
> both directions. On a simple subway/metro/cityline-network there is no
> secondary network.
> - priority <http://wiki.openstreetmap.org/wiki/Key:priority>=yard
> <http://wiki.openstreetmap.org/w/index.php?title=Tag:priority%3Dyard&actio...>
> -
> These rails are only used for rails that goes to a depot, a yard or an
> engine-house.
> - priority <http://wiki.openstreetmap.org/wiki/Key:priority>=switch
> <http://wiki.openstreetmap.org/w/index.php?title=Tag:priority%3Dswitch&act...>
Das Tag kannte ich bisher noch gar nicht.
Diese Tags stammen aus einem Proposal von 2008, das eingeschlafen ist.
Manche Konzepte sind heutzutage so wichtig, wie highway=primary im
Straßennetz, aber das Priority-Tag stammt aus einer Zeit, als man noch
kaum Fernverkehrslinien als Relation gemappt hat.
priority=* + railway=* kommt laut Taginfo 9.782 mal vor. 0,4 Prozent des
weltweiten OSM-Bahnnetzes sind mit priority=* getaggt.
usage=* + railway=* kommt laut Taginfo 310.650 mal vor. 12,57 Prozent
des weltweiten OSM-Bahnnetzes sind mit usage=* getaggt (viel mehr dürfte
auch nicht drin sein, da es auch viele Nebengleise in OSM gibt, die
dieses Tag nicht bekommen dürfen).
Ich persönlich sehe keinen Bedarf für ein priority-Tag, das in die drei
Klassen Fernverkehr, Nahverkehr und Abstellung einteilt.
Fernverkehrsgleise sind häufig Mitglied einer Fernverkehrsrelation. Für
Nahverkehrsgleise gilt selbiges. Fernverkehr fährt meistens nur auf
Hauptbahnen (usage=main), von Ausnahmen wie dem CNL Hamburg–Kopenhagen,
der manchmal über Deutschlands schnellste Nebenbahn (Kiel–Flensburg, 120
km/h) fährt, abgesehen.
Es hat sich in OSM eingebürgert, dass die Transport-Infrastrukturen
(what's on the ground) an Nodes und Ways getaggt wird, während die
Nutzung der Infrastruktur über Relationen abgebildet wird. Wir taggen
highway=secondary, surface=asphalt, maxspeed=70 und mappen die Buslinie,
die darüber fährt als Relation.
Bei Routenrelationen für Zuglinien gibt es:
route=train + service=regional/high_speed/night für
Regionalzüge/Hochgeschwindigkeitszüge/Nachtzüge
und
route=light_rail ohne service=* für light_rails (nicht eindeutig definiert.
Außerdem enthalten die Relationen auch ein ref=<Liniennummer>. Wenn ihr
davon den Anfang parst, habt ihr den Routentyp. ICE-Relationen sind
immer mit ref=ICE<Liniennummer> getaggt, analog gilt dasselbe für die
anderen Zuggattungen.
Ich persönlich würde priority=* aus folgenden Tags ableiten:
highspeed=yes -> priority=primary
service=yard -> priority=yard (man fährt nicht durch den Abstellbahnhof)
Teil einer Relation …
ICE.* oder IC.* oder EC.* oder IR[^E]*.* -> primary
CNL.* oder EN.* oder D.* -> primary
R.* -> secondary
Obige reguläre Ausdrücke gelten sind nur in Deutschland anwendbar. Ich
hoffe, dass sie richtig sind. In Tschechien ist die Zuggattung R ein
IC-artiger Schnellzug.
Man sollte also die Wichtigkeit einer Strecke von den Relationen
ableiten können.
Stören tun mich die priority-Tags nicht, da sie mit nichts anderem in
Konflikt stehen. Aber sie sollten halt gepflegt werden.
> Etwas anderes liegt uns noch sehr am Herzen, wie funktioniert die
> Modellierung der Bahnhöfe nach deinem Modell Euskirchen. Wäre es hier
> möglich die Bahnsteighälften in verschiedenen Sektoren zu unterteilen.
> Meinst du das würde so funktionieren, wenn man die einzelnen
> Bahnsteigabschnitte auf diese einzelnen Kante einzeichnen würde?
>
> [image: Inline-Bild 1]
Im Protokoll vom letzten Treffen finde ich nur
> "Vorgeschlagen wird, dies mit Punkten auf der Bahnsteigfläche. Da es
> eine solche Eintteilung nicht nur an Bahnsteigen gibt, wird eine
> Ergänzung des public_transport-Schemas angeregt."
Wir meinten damit Nodes in die Bahnsteigkante, mit einem noch zu
erfindenden Tag. Da die Sektoren meist als Punkte auf Bahnhöfen
ausgeschildert sind (niemand kann sagen "Einen Schritt weiter und sie
stehen in C!"), ist eine Erfassung als Punkte sinnvoller. Ich kenne nur
Stuttgart Hbf (tief), wo man an der Decke alle paar Meter A, B oder C steht.
> Die Unterscheidung der Tramhaltetsellen zwischen Bahnhöfe und Haltestellen
> finde ich sehr gut.
Rechtlich gibt es da ja gar nicht. Meint ihr den Unterschied
Umsteigehaltestelle vs. 08/15-Haltestelle.
Viele Grüße
Michael
> Am 21. Oktober 2014 12:32 schrieb Michael Reichert <nakaner(a)gmx.net>:
>
>> Hallo Tracy,
>>
>> Am 2014-10-21 um 09:21 schrieb Tracy Kasperczyk:
>>> sorry das ich erst so spät antworte. Ich war letzte Woche ziemlich viel
>>> unterwegs und hatte daher leider nicht die Gelegenheit mich mit meinem
>> Chef
>>> abzusprechen. Ich danke dir das du uns mit einbezogen hast und uns
>> bescheid
>>> gegeben hast. Momentan beschäftigt uns eigentlich, das Thema Priority
>> Tags
>>> auf Schienen. Das ist so unser Hauptthema. Hast du den bestimmte Sachen
>> die
>>> uns fragen möchtest vorher, wo wir dir noch rede und Antwort stehen
>> sollen.
>>
>> Meint ihr damit folgende Themen?
>>
>> Was ist eigentlich light_rail und wann ist es tram, rail oder subway?
>> Hierzu siehe auch die Diskussion im Forum unter
>> http://forum.openstreetmap.org/viewtopic.php?pid=454509
>>
>> Wann ist eine Strecke highspeed=yes und auf welchen Abschnitten nicht?
>> Hierzu siehe auch das Protokoll vom letzten Treffen unter
>>
>> https://wiki.openstreetmap.org/wiki/DE:OpenRailwayMap/Mappingwochenende_2...
>> und
>>
>> https://wiki.openstreetmap.org/wiki/DE:OpenRailwayMap/Mappingwochenende_2...
>>
>> Sollen Straßen-/Stadtbahnhaltestellen nur als railway=tram_stop getaggt
>> werden, oder soll auch hier zwischen Bahnhöfen und Haltepunkten
>> unterschieden werden? Siehe hierzu die Diskussion unter
>>
>> https://wiki.openstreetmap.org/wiki/DE:OpenRailwayMap/Aktiventreffen_2014...
>
>
>
>
>>
>>
>> Bahnhöfe, die eigentlich mehrere Bahnhöfe sind. Da diese Doppelbahnhöfe
>> und Tripelbahnhöfe (z.B. Köln Messe/Deutz oder die Regionalbahnhöfe an
>> der Berliner Stadtbahn und die Umsteigebahnhöfe an der Berliner
>> Ringbahn) vermutlich weiterhin eine gemeinsame stop_area-Relation haben,
>> dürfte das für eure Zwecke kein Problem darstellen.
>>
>> Bahnsteige mit verschiedenen Oberflächen
>>
>> https://wiki.openstreetmap.org/wiki/DE:OpenRailwayMap/Aktiventreffen_2014...
>>
>> Wenn ihr Anmerkungen als Datennutzer habt, dann schreibt die einfach an
>> die passende Stelle auf der Wiki-Seite. Wenn ihr euch mündlich äußern
>> möchtet, können wir die Diskussion bestimmt auch an einen für euch
>> passenden Zeitpunkt des Wochenendes legen und euch telefonisch oder per
>> IRC einbinden.
>>
>>> Das Thema Bahnübergänge finde ich noch ziemlich spannend bei euch auf der
>>> Liste.
>>
>> Ich habe gerade eben auch einen Tag-Vorschlag für die Schließzeiten
>> ergänzt, da das für das Routing wichtig ist. Es sieht einen Wert für die
>> durchschnittliche Schließzeit (Zug mit Höchstgeschwindigkeit) und die
>> Standardabweichung vor. Wenn mir die Fahrplanauskunft auf dem Smartphone
>> sagt, ich könne noch den Zug auf Gleis 2 erreichen, aber der Weg dorthin
>> über einen benachbarten Straßen-Bahnübergang führt, kann es sein, dass
>> ich diesen Zug doch nicht erreiche.
>>
>> Wenn dieser Bü nämlich durch ein Signal gedeckt ist, welches mehrere km
>> weit entfernt steht, dann beträgt die Schließzeit
>> (Fahrtzeit Bü–Signal) + (Fahrtzeit Signal–Vorsignal) + (Fahrtzeit
>> Einschaltkontakt–Vorsignal). Der Bü sollte nämlich schon geschlossen
>> sein, bevor der Triebfahrzeugführer das Vorsignal passiert. Wenn der Bü
>> dann nämlich noch nicht geschlossen ist, zeigt dieses "Halt erwarten"
>> und der Zug muss abbremsen.
>>
>> Wenn der Bü durch ein Signal gedeckt ist, aber vom Fahrdienstleiter des
>> nächsten Bahnhofs eingeschaltet wird, dann dauert das ggf. noch länger,
>> da der Fdl für ein Fahrt zeigendes Signal auch noch eine Fahrstraße
>> (Freiheit prüfen, alle Weichen richtig stellen und kreuzende Signal
>> müssen Halt zeigen) einstellen muss.
>>
>> Eine Varianz in diesen Werten entsteht durch unterschiedlich schnelle
>> Züge auf der Strecke. Wenn v_max = 160 (mehr ist auf Bahnübergängen
>> nicht erlaubt), dann ist der Bü bei einem Intercity nicht so lange
>> geschlossen wie bei einem Güterzug mit 90 km/h oder einer Regionalbahn,
>> die unterwegs noch einmal hält (Durchschnittsgeschwindigkeit ca. 70 km/h).
>>
>> Der Wert der Standardabweichung kann durch das Beobachten mehrere
>> Schließung des Büs vor Ort ermittelt werden und hängt vom Verkehrsmix
>> auf der Strecke ab. Router können dann entscheiden, ob sie bei einer
>> relativ unwahrscheinlichen, aber möglichen zehnminütigen Schließzeit
>> "Zug wird nicht mehr erreicht! Ein geschlossener Bahnübergang versperrt
>> ihren Weg." oder "Achtung! Zug kann möglicherweise nicht erreicht
>> werden. Ein geschlossener Bahnübergang versperrt ihren Weg." angeben.
>>
>> Diese Argumentation für ein Schließzeiten-Tag steht so auch auf der
>> Wiki-Seite zum Treffen.
>>
>> Viele Grüße
>>
>> Michael
>>
>> --
>> Per E-Mail kommuniziere ich bevorzugt GPG-verschlüsselt.
>>
>>
>
>
--
Per E-Mail kommuniziere ich bevorzugt GPG-verschlüsselt.
** english version below **
Hallo zusammen,
trotz Lokführerstreik habe ich mich gestern auf den Weg nach Karlsruhe
gemacht, um am Hackweekend in der Geofabrik [1] teilzunehmen.
Zusammen mit Michael wurde fleißig an der Erweiterung des Signal- und
Maxspeed-Layers gebastelt. Herausgekommen sind unter anderem viele neue
Signale, die zu einem großen Teil auch schon in den Signal-Layer
eingebaut wurden, sowie eine verbesserte Darstellung im Maxspeed-Layer
Weitere Details finden sich im Blogpost unter
http://www.openrailwaymap.org/blog.php#19.
Gruß
Alex
***
Hi everybody,
yesterday I traveled to Karlsruhe to attend the hackweekend at the
Geofabrik office [1].
Together with Michael we worked on extensions of the signalling and
maxspeed layers. The results are many new german signals, which are
often already added to the signalling layer, and an improved rendering
of the maxspeed layer.
More information can be found in a blogpost at
http://www.openrailwaymap.org/blog.php?lang=de#19. Currently this
blogpost is only available in german, but a translation will follow in
the next few days.
Regards
Alex
[1]
https://wiki.openstreetmap.org/wiki/Karlsruhe_Hack_Weekend_October_2014
Hallo,
über Drehscheibe-Online [1] habe ich erfahren, dass der
Infrastrukturzustands- und -entwicklungsbericht von DB Netz und DB
Station & Service AG online ist. Er ist noch nicht durch das
Eisenbahn-Bundesamt geprüft. [2]
Direkt-Download:
http://www.eba.bund.de/SharedDocs/Publikationen/DE/Finanzierung/IZB/IZB_2...
Im Bericht kann man nützliche Information und Hinweise für OSM/ORM
finden. Man kann die Liste der großen Um-/Ab-/Ausbauprojekte in OSM
abklappern und schauen, wo unsere Daten veraltet sind.
Gelegentlich ist von "Erhöhung der Streckenhöchstgeschwindigkeit" die
Rede. Diese Angaben sollte man auf keine Fall 1:1 in Tags umsetzen, da
sie bestimmt nicht für alle Abschnitte zutreffen. Aber sie eignen sich
zur Kontrolle.
Ebenfalls interessant sind die Zu- und Abgänge an Verkehrsstationen von
DB Station & Service ab Seite 162. Weiter habe ich den Bericht noch
nicht durchgesehen.
Bis Seite 162 habe ich schon durchgeackert und in OSM grob kontrolliert.
Da unsere Manpower aber nicht ausreicht, wird es sinnvoll sein, aus der
Liste der Baumaßnahmen eine ToDo-Liste für die gesamte OSM-Community zu
erstellen und zu bitten, vor Ort per GPS und Fotos Daten zu erfassen [1]
und die Änderungen zu mappen.
Was ich aus der ferne mappen konnte, habe ich bis Seite 161 schon getan.
Die Auflassung von Genshagener Heide als Halt von Reisezügen (Seite 162)
habe ich schon eingepflegt (zum disused:railway=station ein
railway=service_station ergänzt), alle anderen Einträge auf Seite 162
noch nicht.
Ebenfalls an diesem Bericht interessant sind Informationen zu
Streckenlängen, Elektrifizierung, GSM-R-, PZB- und LZB-Ausrüstung. Bei
diesen Längenangaben frage ich aber, ob bei zweigleisigen Strecken nur
ein Gleis gezählt wird oder beide und wie Nebengleise in Bahnhöfen
mitgezählt werden. Wer in OSM jetzt mal railway:radio=*,
railway:pzb=yes, railway:lzb=yes usw. zählen möchte, darf das gerne tun.
OSM wird auf jeden Fall bei railway:pzb/lzb/radio schlecht abschneiden.
Viele Grüße
Michael
[1] http://www.drehscheibe-online.de/foren/read.php?2,7140227
[2]
http://www.eba.bund.de/SharedDocs/Publikationen/DE/Finanzierung/IZB/IZB_2...
[3] Dazu braucht man keine Gleisanlagen betreten. Neue Weichen kann man
z.B. auch von parallel verlaufenden Straßen mappen, indem man auf Höhe
der Weiche einen Wegpunkt mit dem GPS-Gerät setzt.
--
24.–26. Oktober 2014: OpenRailwayMap-Aktiventreffen Bad Nauheim
https://wiki.openstreetmap.org/wiki/DE:OpenRailwayMap/Aktiventreffen_2014_2
Per E-Mail kommuniziere ich bevorzugt GPG-verschlüsselt.
-- Scroll down for English version --
Hallo an alle Eisenbahnmapper,
ich spiele schon länger mit den ÖPNV-Routendaten in OSM und möchte euch
heute meine Zugroutenanalyse <http://osmtrainroutes.bplaced.net> vorstellen.
Das Programm funktioniert so:
Man wählt eine Route durch Eingabe der OSM-ID der dazugehörigen Relation
und wählt einen passenden Zug dazu. Das Programm lädt sich dann die
Relation und alle dazugehörigen Wege und Punkte von der Overpass-API.
Daraus berechnet es unter anderem die Durchschnittsgeschwindigkeit und
erstellt ein Weg-Geschwindigkeitsdiagramm. Außerdem zeigt es Daten zu
Streckenbenutzern, Streckenbetreibern, Elektrifizierung etc.
Es gibt auch eine Übersicht über alle bisher abgefragten Routen um einen
Vergleich zu ermöglichen und zum einfacheren Aufrufen bereits bekannter
Routen.
Die Routen werden für ca. 50 Tage gecached. Am Seitenende findet ihr das
Datum der Routendaten und könnt die Daten dort auch manuell aktualisieren.
Die Auswertung ist natürlich nur so gut, wie es die OSM-Daten sind. Bei
noch nicht eingetragenen Geschwindigkeitswerten greift das Programm auf
Standardwerte (abhängig von rail/tram/subway, usage=*, service=*,
highspeed=* und Zugbeeinflussungssystemen) zurück. Die Auswertung von
Haltestellen klappt bisher nur fehlerfrei, wenn der Punkt auch auf der
Route liegt und ein name=* oder description=* tag hat.
Einige Beispielrouten:
Meine Stammstrecke: RB2 Karlsruhe - Mannheim
<http://osmtrainroutes.bplaced.net/index.php?id=1483681&train=BR425>
Eine der Routen mit der höchsten Durchschnittsgeschwindigkeit: Eurostar
Paris - London
<http://osmtrainroutes.bplaced.net/index.php?id=2905798&train=Class373>
Eine der längsten Routen in Deutschland: ICE11 München-Berlin
<http://osmtrainroutes.bplaced.net/index.php?id=1797144&train=ICE1>
Das ganze ist als eine Demo zu sehen und dazu gedacht Feedback von anderen
Eisenbahnmappern zu erhalten. Bisher ist das Programm noch nicht besonders
fehlertolerant und noch nicht für Tablets, Smartphones und ältere
Webbrowser geeignet. Es können also noch Fehler und Bugs auftreten.
Ich werde wahrscheinlich auch zu einem späteren Zeitpunkt den Code auf
GitHub <https://github.com/sb12/OSMTrainRouteAnalysis> veröffentlichen.
Ich freue mich über Fehlermeldungen, Verbesserungsvorschläge und Feedback
per Mail <osm.mapper999(a)gmail.com>, OSM-Nachricht
<https://www.openstreetmap.org/message/new/mapper999> oder GitHub
<https://github.com/sb12/OSMTrainRouteAnalysis>.
Viele Grüße
Steffen (mapper999)
-----------------------------------------------------------------------------------
Dear railway mappers,
I've been playing around with public transport routes in OSM for a while
now and want to present my Train Route Analysis
<http://osmtrainroutes.bplaced.net> to you.
How does it work:
You can choose a route by entering the OSM id of the relation and choose a
train.
The program then gets the relation and all ways and nodes from the Overpass
API. Based on this data the average speed and a way-speed-diagramm is
calculated. It also shows details about track users, track operators and
electrification of the route.
There's also an overview of all routes, so it is possible to compare routes
and choose already known routes.
The routes are cached for about 50 days, you will see the date of the last
update at the bottom of the page, where you can also manually update them.
Of course the program is only as good as the OSM data. If the maxspeed is
unknown it uses default values (based on railway/tram/subway, usage=*,
service=*, highspeed=*). Please also note that it cannot deal with mph,
yet. The evaluation of stop positions also needs some more work as it only
correctly deals with stop positions that are on a way and have either a
name=* or a description=* tag.
Some examples:
My every day route: RB2 Karlsruhe - Mannheim
<http://osmtrainroutes.bplaced.net/index.php?id=1483681&train=BR425>
One of the fastest routes in Europe: Eurostar Paris - London
<http://osmtrainroutes.bplaced.net/index.php?id=2905798&train=Class373>
One of the longest routes in Germany: ICE11 München-Berlin
<http://osmtrainroutes.bplaced.net/index.php?id=1797144&train=ICE1>
Please see this as a demo to collect feedback from other railway mappers.
The program is not very fault tolerant at the moment and not suitable for
smartphones, tablet computers and older web browsers yet. There are
probably still some bugs and unexpected errors.
I will probably release the source code on GitHub
<https://github.com/sb12/OSMTrainRouteAnalysis> at some point.
I'm happy about any feedback, bug reports or suggestions via Mail
<osm.mapper999(a)gmail.com>, OSM message
<https://www.openstreetmap.org/message/new/mapper999> or GitHub
<https://github.com/sb12/OSMTrainRouteAnalysis>.
Greetings from Germany
Steffen (mapper999)
Hallo,
diese Woche war ich auf der Intergeo in Berlin und da ich aus der Nähe
von Heilbronn komme, heißt das "viel Bahn fahren". Wie es sich gehört,
habe ich dabei auch viel gemappt und möchte euch von meinen Erfahrungen
berichten.
Inhalt:
- Videomapping mit Open Camera
- Hochgeschwindigkeitsmapping
- ICE-Loungemapping
- ICE-Loungemapping im Tunnel
- OSMTracker
- Fahrgastkontakte
- Zusammenfassung gemappter Strecken
*Videomapping*
Videomapping war bisher meine Lieblingsmethode und wird es auch bleiben.
Nur eins hat mich daran gestört. Auf meinem Android-Smartphone
(Cyanogenmod 10.1) war der Fokus der Kamera-App unveränderlich auf
"continous" eingestellt. Dadurch hat die Kamera beim Filmen durch die
Fensterscheibe etwa ein bis zwei Mal pro Minute neu fokussiert. Diese
Sekunden haben meist im Video gefehlt. Auf der freien Strecke kann man
das zur Not noch verkraften, aber nicht in einem unübersichtlichen,
möglicherweise noch von Bauarbeiten gespickten Bahnhofsvorfeld. Die
Lösung heißt "Open Camera". Open Camera ist eine freie [1] Kamera-App
für Android 4.0 und neuer. Sie hat sehr sehr viele
Einstellmöglichkeiten, u.a. für den Fokus. Zum Videomappen stelle ich
diesen (vor dem Start des Videos) auf unendlich, denn die zu filmenden
Objekte sind recht weit von der Kamera entfernt und gleich danach auf
"fixed", damit der Fokus sich nicht mehr ändert.
Allgmeines und Dokumentation: http://opencamera.sourceforge.net/
Google Play:
https://play.google.com/store/apps/details?id=net.sourceforge.opencamera
F-Droid: https://f-droid.org/
Damit habe ich die Fahrt von Heilbronn Gbf [2] bis Würzburg Hbf erfasst
(mit einer Lücke zwischen Möckmühl und Osterburken, weil die
Handyhalterung heruntergefallen ist [3] und ich das versehentliche
Beenden des Filmens erst beim nächsten Halt bemerkt habe).
Zur Kontrolle der Geschwindigkeitsinformationen habe ich gelegentlich
von meinem Garmin mir die GPS-berechnete Ist-Geschwindigkeit (im n-Wagen
hat man guten Empfang) vorgelesen und einen Track aufgezeichnet.
Ich ergänze mein Videomapping noch durch viele viele gesprochene
Kommentare. Wenn ich die Signalnummer erkennen kann, lese ich diese vor.
Ebenso, falls erkennbar, die anzeigbaren Ziffern/Buchstaben an
Zs3(v)-Leuchtanzeigen und Zs2(v). Hin und wieder lese ich auch eine
Hektometertafel vor, beschreibe die Bahnsteigoberfläche oder
Gleisenummern von durchfahrenen Bahnhöfen oder alles andere, was ich für
interessant halte.
Damit ich sehe, was auf mich zukommt, und auch möglichst viele Signale
des Gegengleises in Fahrtrichtung meines Zuges mappen kann, schaue ich
während der Fahrt nach links vorn raus, während die Kamera nach links
hinten filmt.
*Hochgeschwindigkeitsmapping*
Für Geschwindigkeiten über 160 km/h ist Videomapping nur bedingt, über
180 km/h gar nicht geeignet. Für den Streckenabschnitt
Würzburg–Göttingen habe ich daher andere Methoden getestet. Bei 200–230
km/h kann man seitlich zum Fenster raus (in Fahrtrichtung links gesessen
und nach hinten rausgeschaut) nur sehr wenig mappen.
Ich habe eine beschränkte Fahrgast-Streckenkenntnis des Abschnitts
Würzburg–Fulda (ich erkenne die Betriebsbahnhöfe und große Talbrücken
anhand der Landschaft) und damit die Hektometertafeln in kodierter Form
notiert. Im folgenden Auszug vom Notizblock werden folgende Abkürzungen
verwendet:
n. = nach
1., 2., … = 1., 2., … Oberleitungsmast
Tu. = Tunnel (Zählung beginnt nach mir bekannten oder markanten
Kunstbauten oder Betriebsstellen, z.B. die beiden Maintalbrücken, die
Brücke über das Sinntal, Überholbahnhöfe und Tunnel, deren Namen ich im
Vorbeifahren lesen konnte)
Brü. = Brücke (nur Talbrücken werden gezählt)
Auszug aus dem Notizblock:
321,2 1. n Main-Brü
319,0 3. n. Tu. 1
317,0 2. n. Tu. 2
314,6 2. n. Tu. 3
313,2 2. n. Brü 1
311,8 1. n. Brü 2
310,4 BkSig Ri. FFU
308,6 4. n. Hohe-W.-Tu. = Tu. 1
*ICE-Loungemapping*
Mit meiner Leistung war ich nicht zufrieden, aber glücklicherweise wird
der ICE 1082/1132 mit ICE-T gefahren. Daher bin ich in Fulda dann samt
Gepäck in die vorder Lounge gewechselt, deren Scheibe zum Führerstand
glücklicherweise hell war. In der zweiten Reihe sitzt man dort schön
erhöht und hat auf dem Gangplatz einen schönen Blick nach vorn. Dadurch
sah ich, was mich erwartet und konnte neben je einer Hektometertafel vor
und nach jedem Tunnel auch noch viele Blocksignale und deren Vorsignale
zwischen Fulda und Göttingen mappen.
*ICE-Loungemapping im Tunnel*
Ein Teil der Vor- und Hauptsignale steht im Tunnel. Dort muss man beim
Lokalisieren etwas tricksen. Lange Tunnel haben oft Kurven. Also merkt
man sich, wie im Verhältnis zur Kurve das Signal stand (am Kurvenanfang,
am Kurvenende, …). Voraussetzung dafür ist ein einigermaßen gut
gemappter Tunnelverlauf (wo auch immer diese OSM-Daten herstammen ;-)).
Von langen Tunnels habe ich mir auch noch Skizzen angefertigt, um deren
Verlauf in OSM kontrollieren zu können.
Im Tunnel hängen auch Hektometertafeln, die man im Scheinwerferlicht
ablesen kann (sieht man aber nur durch die Führerstandstür vernünftig,
die etwas heller als die Scheiben rechts und links davon ist). Wenn man
ab dem Signalstandort die Hektometertafeln zählt (Ablesen geht in der
Dunkelheit bei dem Tempo nicht so gut), kann man den Signalstandort mit
einer Genauigkeit rekonstruieren, die für OSM ausreichend ist.
Der ICE-T fährt nur 230 km/h. Ob die Methode auch im ICE 3 bei bis zu
300 km/h zwischen Nürnberg und Ingolstadt oder Rhein-Main und Köln auch
klappt, kann ich nicht sagen.
*OSMTracker*
Bei der Heimfahrt gestern Abend habe ich in der Dämmerung den Abschnitt
Würzburg–Lauda befahren. Zum Filmen war es schon zu dunkel (und ab Lauda
war es dann auch Nacht), aber da dort montags bis freitags nur n-Wagen
in den RE eingesetzt werden, ist GPS-Empfang garantiert. Mit der App
"Blue GPS" habe ich mein Smartphone mit meinem neuen GPS-Logger (Holux
M-241) gekoppelt. Mit der Audioaufnahmefunktion von OSMTracker habe ich
dann beim Passieren ausgewählter Hektometertafeln, Lichtsignalen [4] und
Bahnübergänge das Objekt "vorgelesen". Da ich den Verdacht hatte, dass
es zu Verzögerungen beim Auslösen der Audioaufzeichnung kommt, habe ich
Hektometertafeln immer in Relation zu markanten Objekten aufgenommen
(z.B. "zweiter Mast vor Bü").
Ich persönlich finde OSMTracker für diesen Zweck geschickter als OsmAnd.
Man benötigt nur einen Fingerdruck um die Aufnahme zu starten und der
Button dafür ist recht groß. Wer lieber Text aufnimmt … kein Problem,
der Textnotiz-Button ist genauso groß und liegt direkt daneben. Ich
bevorzuge jedoch Audionotizen, da man beim Reden mit den Augen auf der
Strecke bleiben kann und schneller reden als auf einer
Touchscreen-Tastatur tippen kann.
OSMTracker ist aber auch für das Mappen auf dem Bahnhof geeignet. Von
OSMTracker aus kann man die Kamera aufrufen und georeferenzierte Fotos
aufnehmen. Für weit entfernt liegende Objekte kann man in längeren
Audionotizen die nächsten 600 m der Strecke beschreiben. Wundert euch
aber nicht, wenn danach ein Eisenbahnfan euch anspricht. :-) Das ist mir
gestern Morgen in Berlin-Albrechtshof passiert.
Nach dem Beenden des Mappens über das Disketten-Icon muss man den Track
noch "exportieren". Dazu in der Track-Liste den Track lang gedrückt
halten und "Als GPX exportieren" wählen. Nun könnt ihr auf einen Rutsch
den GPX-Track samt Bilder und Audiodateien in JOSM importieren.
Umständliches Synchronisieren und Eintragen von Zeitoffsets bleibt euch
erspart.
Wenn ich Zeit hätte … dann würde ich mir mal OSMTracker genauer
anschauen, ob man den nicht zu einem ORMTracker umfunktionieren könnte,
indem man die Buttons für Straßen, POIs und dergleichen durch Buttons
für Signale, Hektometertafeln, Bahnübergänge usw. ersetzt.
OSMTracker-Website: https://code.google.com/p/osmtracker-android/
F-Droid:
https://f-droid.org/repository/browse/?fdfilter=osmtracker&fdid=me.guilla...
Google Play:
https://play.google.com/store/apps/details?id=me.guillaumin.android.osmtr...
Website BlueGPS: http://sourceforge.net/p/bluegps4droid
F-Droid:
https://f-droid.org/repository/browse/?fdfilter=bluegps&fdid=org.broeusch...
Google Play: – nicht verfügbar –
*Fahrgastkontakte*
Ja, das passiert und ich bin immer noch überrascht, dass so wenige Leute
mich ansprechen. Wie beim normalen Mappen auch, denken die meisten
wahrscheinlich: "Der hat einen an der Waffel." Das stimmt. Aber es gibt
auch Fahrgäste, die nachfragen. Für solche wäre es schön, wenn wir einen
ORM-Flyer hätten.
*Zusammenfassung gemappter Strecken und Stationen*
Falls jemand seine Aufzeichnungen von den folgenden Strecken durch
Videos/Fotos/etc. ergänzen möchte, möge er sich bitte an mich wenden.
Heilbronn Gbf–Heilbronn Hbf–Neckarsulm: per Video + GPS, n-Wagen
Neckarsulm–Bad Friedrichshall-Jagsfeld: dto. (Fahrt im Gegengleis!)
Bad Friedrichshall-Jagstfeld–Möckmühl: dto.
Möckmühl–Osterburken: GPS-Track, n-Wagen
Osterburken–Würzburg Süd: per Video + GPS, n-Wagen
Maintalbrücke Veitshöchheim–Sulzhoftunnel: einzelne Hektometertafeln
Fulda–Göttingen: ICE-Lounge-Mapping
Abzw. Sorsum–Braunschweig Hbf–Wolfsburg: per Video, ICE 1
Berlin Gesundbrunnen–Berlin-Spandau–Seegefeld: per Video, BR 946
Berlin Hbf–Berlin Zoologischer Garten–Wannsee–Potsdam
Hbf–Potsdam-Pirschheide–Beelitz-Heilstätten–Wiesenburg (Mark)–Roßlau
(Elbe): per Video, Talent 2
Abzw. Saaleck–Eisenach–Wommen: IC (Redesign-Bmvsz, Wutha–Eisenach im
Gegengleis)
Reichenbach (Unterfranken)–Lauda: OSMTracker, n-Wagen
Seegefeld: mit Erinnerung und Fotos
Berlin-Albrechtshof: OSMTracker-Fotos und -Audionotizen
Berlin-Spandau: OSMTracker-Audionotizen (Glasdach ist GPS-durchlässig)
Berlin-Messe Süd: OSMTracker-Textnotizen
Dessau Hbf: OSMTracker (nur Ergänzungen zu älteren Aufnahmen)
Leipzig Hbf: Einfahrt/aktueller Bauzustand per Video
Viele Grüße
Michael
[1] frei wie Freiheit, GPLv3+
[2] Den Abschnitt davor kann ich per Rad von daheim erreichen und von
Feldwegen aus mappen.
[3] Mein 2 1/2 Jahre altes Smartphone ist robust und hat keinerlei
Schäden erlitten. :-)
[4] Die Strecke hat im gesamten Verlauf von Stuttgart bis Würzburg
ausschließlich H/V-Lichtsignale.
--
Per E-Mail kommuniziere ich bevorzugt GPG-verschlüsselt.
Hallo,
am 24. bis 26. Oktober 2014 findet in Bad Nauheim nördlich von Frankfurt
(Main) das zweite OpenRailwayMap-Aktiventreffen statt (das erste trug
noch den Namen "Mappingwochenende"). Ziel des Treffens ist, weitere
Fragen zum Tagging zu klären. Die Tagesordnung enthält auch Themen, die
wir aufgrund der übervollen Tagesordnung Mitte Juli in Köln nicht
abgearbeitet haben.
http://wiki.openstreetmap.org/wiki/DE:OpenRailwayMap/Aktiventreffen_2014_2
Derzeit sind nur drei Teilnehmer eingetragen. Es wäre daher schön, wenn
sich weitere Teilnehmer finden würden, damit die dortigen Entscheidungen
keine Einzelmeinungen sind, sondern von einer gewissen Anzahl Mapper
mitgetragen werden. Eine Taggingdiskussion nützt nichts, wenn da nur ein
paar Mapper im stillen Kämmerlein diskutieren, aber die breite
Mapperschaft anders denkt.
Die wichtigsten Themen des Wochenendes werden sein:
- Oberbauformen (wird vertagt werden, wenn keine Straßenbahnmapper
anwesend sein werden) *
- Wann soll highspeed=yes gesetzt werden? *
- Was ist railway=light_rail?
- Museumsstrecken/Erhaltene Strecken **
- Bahnhöfe, die eigentlich mehrere Bahnhöfe sind (z.B. Berlin-
Ostbahnhof)
- Erweiterung des Taggings von Bahnübergängen und ihrer Sicherung
- Tagging diverser nicht-EBO-Signale **
- Signale des Zugleitbetriebs
- ETCS-Features
- Richtungspfeile an Fahrleitungssignalen und Geschwidigkeitssignalen
- Tagging von Kilometersprüngen, Überlängen, Fehllängen
- Entwurf eines Logos und eines Flyers **
*) Wurde in Köln mangels Kenntnissen oder aufgrund der geringen
Teilnehmerzahl vertagt.
**) Wurde in Köln schon diskutiert. Aufgrund der geringen Teilnehmerzahl
wurde keine Entscheidung gefällt.
Wer nicht kommen kann, kann seine Meinung zu den Tagesordnungspunkten
gerne auch schon vorab auf der Wiki-Seite hinterlassen oder mir eine
Mail schreiben, damit wir ihn dann telefonisch in die Diskussion
einbinden können.
Viele Grüße
Michael
--
Per E-Mail kommuniziere ich bevorzugt GPG-verschlüsselt.
