DE:OpenRailwayMap/Mappingwochenende 2014 1

From OpenStreetMap Wiki
Jump to navigation Jump to search
OpenRailwayMap/Mappingwochenende 2014 1 - Other languages

Auf dieser Seite findet sich die Organisation und das Protokoll der ersten Mappingparty im Rahmen der OpenRailwayMap. Die Veranstaltung fand vom 11. bis 13. Juli 2014 im Lokal K in 50825 Köln, Hackländerstraße 2 statt.

Wer kommt?

Protokoll

Das Protokoll wurde in einem Etherpad geführt, dessen Chatverlauf auch im Nachhinein noch interessant sein mag.

Freitag, 11. Juli 2014, Beginn gegen 19:15 Uhr

Vorstellungsrunde

  • ubahnverleih (Consti) aus dem Raum Dresden, noch neu im Bereich des Railwaymappings; zeichnete auch schon Signale für die ORM
  • rurseekatze (Alex): Gründer des Projekts, Hauptentwickler, Hobbyeisenbahner (bei den Eisenbahnfreunden Niederrhein/Grenzland)
  • rotkelch (Emrah): Kommt von Mentz DV, lebt in Berlin, studiert dort Geoinformation und schreibt eine Masterarbeit über das Mapping und die Darstellung komplexer Bahnhöfe.
  • Nakaner (Michael): Mappt seit 2011 und in letzter Zeit überwiegend Eisenbahn. Mappt überwiegend mit Videos und startete die Iconsammlung 'Railway Signals' (https://github.com/Nakaner/railway-signals/tree/master/). Ist dualer Student in einem Vermessungsbüro.
  • bigbug21 (Peter): Studiert(e) im Verkehrsbereich der TU Dresden, mappt viel beim Bahnfahren (mit Osmand), schreibt und dokumentiert am Tutorial (http://wiki.openstreetmap.org/wiki/DE:OpenRailwayMap/Tutorial) und anderen ORM-Wiki-Seiten (http://wiki.openrailwaymap.org).

Öffentlichkeitsarbeit:

  • Große Neuerungen in Foren wie 'Drehscheibe online' oder ICE-Treff ankündigen, dabei auf Einträge im OSM-Blog verweisen. Eventuell auch "fertig" gemappte Strecken zum Anlass nehmen.
  • Man muss bekannt machen, dass man bei der ORM mitmachen kann. Kern: Die Schwelle [nein, keine Bahnschwelle!] senken?
    • Wie wäre es mit einem speziellen OSM-Notes für Eisenbahn-Infrastruktur? ... Ließe sich mit Leaflet wohl recht einfach nachbauen. Auch Bilder sollten eingebunden werden können.
    • Eigentlich haben wir nicht die Zeit, um das ganze (zeitnah) abzuarabeiten.
  • Flyer:
    • Dafür sollten wir erst einmal ein Logo haben. => Consti will mal schauen
  • Vortrag auf der nächsten FOSSGIS?
  • Einen speziellen, einfachen Editor schaffen (ähnlich des jüngst veröffentlichten Hydranten-Tools)? => Dafür ist das Railwaymapping zu komplex (insbesondere Signale, die auch noch auf Ways liegen müssen).
  • Blog:
    • Das Blog soll weiterhin in Deutsch und Englisch laufen, je nach Bedarf und Zielgruppe.

Tagging

  • Wie können wir sicherstellen, dass Änderungen in einer Wiki-Sprachversion Einzug in andere Versionen halten?
    • Vielleicht eine Master-Version definieren (z. B. Englisch)?
    • Es fehlt grundsätzlich an Möglichkeiten, Übersetzungen in einer Version aktiv anzukündigen.

Mapping-Techniken

  • Videomapping (MIchael): Mappt mit Pkw-Smartphone-Halterung und filmt entgegen der Fahrtrichtung.
  • Videomapping (Alex): Filmt mit dem Smartphone entgegen der Fahrtrichtung (ohne Halterung). Eine Möglichkeit ist auch, aus der letzten Türe heraus entgegen der Fahrtrichtung verkehren.
  • Videomapping ist in der Nachbearbeitung sehr zweitaufändig, liefert aber insgesamt ein recht vollständiges Ergebnis. Gerade wenn man nur einmal auf einer Strecke unterwegs ist, kann das von Vorteil sein.
  • Mapping per Papier (Michael): Bei einer bereits gut erfassten Strecke kann man per Papier noch manche Details notieren, beispielsweise die Bezeichnung eines an einer bestimmten Stelle stehenden Signals.
  • Mapping mit nummerierten GPX-Wegpunkten und zusätzlichen Notizen auf Papier (Michael).
  • Sonderfahrten historischer Züge eignen sich aufgrund niedriger Geschwindigkeiten und der Möglichkeit, sich während der Fahrt aus dem Fenster herauszulehnen, besonders für das Mapping; außerdem werden oft Strecken befahren, die von regulären Personenzügen nicht (mehr) befahren werden
  • Fotomapping: In Bahnhöfen von Bahnsteigen aus die Gleisanlagen auf Fotos festhalten

Am Rande

  • Alex wirft einen Blick auf die aktuelle Auswertung der Provider, von denen auf die ORM zugegriffen wird: Der Provider "Deutsche Bahn" steht inzwischen auf Platz 7. Daneben gibt es viele Zugriffe von Behörden und Unternehmen mit Bahnbezug.
  • Eine informative Quelle sind die Fotoserien von Sören Heise, beispielsweise zum Berliner Ostbahnhof (http://www.ice-treff.de/index.php?id=293900). Es gibt auch eine riesige Sammlung von Signalfotos (mit Geotags): http://www.panoramio.com/user/3111163. Solche im Internet stehenden Fotos können wohl als Vorlage für Ergänzungen an OSM verwendet werden.
  • Wagenreihungen deutscher Züge gibt es unter fernbahn.de. Diese Infos sind nützlich, um herauzufinden, bei welchen Zügen man hinten (z. B. durch die "Hintertür") oder vorne (Steuerwagen) hinausschauen kann.
  • Die OpenRailwayMap wurde in einem ungarischen Blog erwähnt: http://vonattal-termeszetesen.blog.hu/2014/06/17/az_openrailwaymap
  • Thema am Ende des Tages: Mapping und Tagging in unseren Träumen
  • Peter wettet, dass Alex in den nächsten zwei Jahren seinen ersten Consulting-Auftrag bekommt.

Samstag, 12. Juli

  • Vormittags wollen wir diskutieren, nachmittag soll auch vor Ort gemappt werden.
  • Ab etwa 9:30 Uhr: Frühstück für alle im Lokal K.
  • Heute neu mit dabei: Margin-auto (Chris) aus Mainz

Am Rande

  • Wir brauchen eine bessere Hintergrundkarte, am besten ist es wohl, gemeinsam mit anderen Projekten eine vielseitig nutzbare Hintergrundkarte in dezenten Karten zu entwerfen
  • Andere Leute sammeln Briefmarke, ich Probleme. (zu einer Anspielung von ubahnverleih)

Mentz DV

  • Nach dem Frühstück stellt Emrah Mentz Dataenverarbeitung vor:
  • Gegründet 1972, mit Sitz in München, Berlin, Stuttgart, Münster
  • Stellen Softwarelösungen her, unter anderem für den Öffentlichen Verkehr
  • Bislang werden meist Navtec-Daten genutzt. Mentz experimentiert mit dem Import von OSM-Daten und die Umwandlung in das eigene Datenformat. Vollstänidgkeit ist dabei ein Thema, aber auch die Pflege der Daten.
  • Es gab in diesem Zusammenhang immer wieder Diskussionen mit der OSM-Community, beispielsweise zur Frage, ob ein Mittelbahnsteig als zwei miteinander verbundene Flächen gemappt werden darf.
  • OSM-Daten sind größtenteils deutlich detaillierter. Viele Details sind interessant, beispielsweise Barrierefreiheit, aber auch Informationen zur Beleuchtung.
  • Aus der Praxisarbeit gingen verschiedene Weiterentwicklungen des verwendeten Taggingschemas hervor. Ein komplexes Beispiel sind beispielsweise Aufzüge: Früher war ein layer-Tag vorgesehen, heute werden diese als Flächen auf den einzelnen Ebenen gemappt, die auf den einzelnen Ebenen angebunden werden.
  • Am Beispiel des Bahnhofs München Ost: Bearbeitung und Detaillierung eines Bahnhofs durch Mentz DV.
  • Es ist kein direktes Ziel von Mentz DV, selbst zu mappen. Für bestimmte Projekte werden dennoch Daten erhoben und aufbereitet. Oft werden Bahnhöfe als Armchair-Mapping
  • DIskussion über geeignetes Tagging von Bahnsteigen.
  • Diskussion über das Tagging von Bahnsteigabschnitten ("A", "B" ...). 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. Fraglich ist indes auch, wie es im Ausland aussieht.
  • Diskussion über die Modellierung des Linienverlaufs bei Halten an planmäßig wechselnden Bahnsteigen.
  • Fußgängerrampen sind ebenfalls sehr interessant fürs Routing. Konkrete Informationen zur Neigung sind seitens der Betreiber nicht verfügbar. Es folgt eine Diskussion über Möglichkeiten zur Messung oder Abschätzung vor Ort.
  • In welchem Abstand sollen Treppen und Rolltreppen getaggt werden?
  • Bei Treppen taggt Mentz an beiden Enden die Ebenen (level), unklar ist, ob die verbindenene Linie (Treppe) eine Ebeneninformation erhalten soll.
  • Interessant sind auch Rolltreppen, Fußweg-Verbindung zu Pkw- und Rad-Parkplätzen, Fahrkartenautomaten, Notrufsäulen
  • Wiki-Seite (http://wiki.openstreetmap.org/wiki/%C3%96PNV_Firma_Mentz_Datenverarbeitung_GmbH/Modellierungsvorschl%C3%A4ge). Dort gibt es unter anderem eine Liste von Stationen und deren Erfassung.
  • Aus der Mentz-Diskussion ergibt sich auch der Vorschlag, am Stationstag die Information zu hinterlegen, dass es keinen Fahrkartenautomaten gibt.
  • Vorstellung des Modellierungsschemas, das aus dem Wiki abgeleitet wurde (https://wiki.openstreetmap.org/wiki/%C3%96V_Firma_Mentz_Datenverarbeitung_GmbH/Modellierungsvorschl%C3%A4ge). Wie wäre es, daraus ein "How to map Railway" für öffentlichen Verkehr zu gestalten.
  • Sollen "Automatenbatterien" (Reihe mehrerer Fahrkartenautomaten) als ein Sammelpunkt oder mehrere einzelne Punkte getagged werden => mehrere einzelne!
  • OSM-Daten sollen zukünftig in 'DIVA' verwendet werden
  • Am Beispiel einer Zugfahrt von Vaterstetten nach München und weiter (Routing in EFA, das in München in westlicher Richtung südlich am Betriebswerk vorbeiführt und nicht über Hauptgleise läuft): Erklärung verschiedener Klassen von Gleisen (z. B. usage=main für Hauptbahnen vs. service=yard für Nebengleise) => Seitens Mentz besteht ein großes Interesse an der Unterscheidung dieser verschiedenen
  • Ein anderes Beispiel für ein fehlgeleitetes Routing betrifft einen aus München Richtung Ulm fahrenden Zug, der nördlich des Hauptbahnhofs über den kürzesten Weg (ab Augsburg-Oberhausen südlich an Neusäß) vorbei. Verschiedene Tipps der Mapper für ein besseres Routing: Geschwindigkeiten und Relationen aus der OSM-Datenbank ebenso berücksichtigen wie Unterscheidung von Haupt- und Nebengleisen u. a.
  • Schließlich noch ein Beispiel eines Knickes im Bahnhof Esslingen, in der ein Gleis um rund 90 Grad abknickt und anschließend zahlreiche weitere Gleise kreuzt.
  • Ausblick: In mehreren Bundesländern (u. a. in Bayern und Baden-Württemberg) soll Kunden bald aktiv OSM angeboten werden). Bei Mentz hat sich der Gedanke durchgesetzt, dass OSM von der Community vorangetrieben werden sollte -- und nicht von Unternehmen.

Mappingpraxis

Nachmittags war Mappen angesagt -> Peter hat sich die Südbrücke angeschaut, der Rest hat die Strecken Köln–Euskirchen und Euskirchen–Bad Münstereifel abgefahren. Gegen halb acht schaute noch jotp rein.

Taggingdiskussionen

  • Wann soll highspeed=yes gesetzt werden?
    • Diskutierte Kriterien: mit wenigstens/mehr als 200 km/h (250 km/h) befahrbar, Feste Fahrbahn, Linienzugbeeinflussung, ausschließlich/überwiegend von Fern-/Hochgeschwindigkeitszügen befahren
    • Was machen wir mir Streckenabschnitten von entsprechend als Schnellfahrstrecken ausgewählten Strecken, die nicht die Krtierien erfüllen, beispielsweise bei der Einbindung von Hochgeschwindigkeitsstrecken in Knoten?
      • Das Tag sollte sich wirklich nur auf die Streckenabschnitte beziehen, nicht auf Strecken, die Teil des Hochgeschwindigkeitsnetzes sind
  • Bahnsteige als Multipolygone
    • dabei die Bahnsteigkanten zum Gleis hin mit ref=Gleisnummer taggen. Vorteil: Man kann dann mehrere Halteplätze (bei Doppelt-/Dreifachbelegung), Nachteil: Multipolygon-Relationen sind komplex
  • Welchen Sinn macht maxspeed=signals bei der Bahn?
    • Konsens: Dieses Artefakt im Taggingschema können wir wohl streichen.
  • Regelfahrrichtung
    • Diese Markierung ist beispielsweise für Routing von Bedeutung
    • Wege auf zweigleisigen Strecken sollten grundsätzlich in Regelfahrtrichtung ausgerichtet werden. Es geht uns um eine spezielle Markierung.
    • JOSM unterstützt das automatische Umdrehen von forward/backward-getaggten Ways, egal mit welchem Schlüssel
    • Anregung an die JOSM-Entwickler: Warnung beim Umkehren der Wegrichtung von Gleisen, auf denen Signale eingetragen sind
    • Tag: railway:preferred_direction=forward/backward/both, both für eingleisige Strecken ("both" klingt positiver als das sachliche "none").
    • Nur für Streckengleise (ohne service=*, also keine Nebengleise und Überleitgleise)
  • tunnel:name, bridge:name, name
    • Laut http://wiki.openstreetmap.org/wiki/Key:tunnel ist die Verwendung von 'tunnel:name in Diskussion, aber umstritten; der Tag wird rund 1.600-mal verwendet. Bei Brücken wird in http://wiki.openstreetmap.org/wiki/Bridge explizit empfohlen, 'name' auf den Namen des überführten Weges zu setzen und das (rund 11.000-mal verwendete) Tag bridge:name zu verwenden.
    • tunnel:name und bridge:name ist zu bevorzugen, u. a. da dadurch Straßenlistenauswertungen vereinfacht werden.
    • Nominatim und gängige Renderer berücksichtigen die tunnel:name und bridge:name offenbar noch nicht. Wir sollten unter anderem Sarah Hoffmann (http://wiki.openstreetmap.org/wiki/User:Lonvia) Bescheid geben, damit sie tunnel:name und bridge:name in Nominatim berücksichtigt.
  • Ticket dazu https://github.com/twain47/Nominatim/issues/157
    • Schlage vor, bei Wikipedia-Links analog zu verfahren. Also wikipedia:de=Streckenartikel und bridge:wikipedia:de=Brückenartikel bzw. Tunnel.
    • Strecken- bzw Brückenrelation
  • Detailverbesserungen Signaltagging
    • Haltvorscheibe heißt seit 2006 Wärtervorscheibe
    • Sh 0 -> Hp 0
    • Beschreibung "Schutzhaltsignal" im allgemeinen Taggingschema für signal:minor ist nicht ganz treffend
  • Unterscheidung von (durchgehenden) Haupt- und Nebengleisen etc.
    • Wohl vor allem ein Thema für die Gestaltung der Vorlagen und Dokumentation
    • Grundsatz: Auf siding wird gehalten, auf yard abgestellt.
    • Wir brauchen einen schematischen Gleisplan zum Erklären. -> Kann man einfach selbst zeichnen
  • Tagging von Schutzweichen:
    • Lassen sich Schutzweichen sicher von Weichen zu Abstellgleisen unterscheiden (beispielsweise an Gleissperren)? micha_k meinte per Telefon: Nein.
    • Lassen sich Schutzgleise von Abstellgleisen durch Gleisperren unterscheiden? => Nicht unbedingt, da über solche Gleise auch rangiert werden könnte.
    • Es ist fraglich, ob es überhaupt eine formale Abgrenzung gibt.
    • Bahnintern werden wohl Nebengleise nach Gleisen mit und ohne Abstellverbot gibt.
    • Besser das Stumpfgleis anders taggen, vielleicht einfach als Nebengleis (yard)? Das wäre wohl auch international gut durchzuhalten.
    • Ein separates Tag für Stumpfgleise wird damit nicht geschaffen.
  • Dunkelschaltung von Signalen
    • Wir wollen dafür ein Tag einführen. Peter schaut in seinem Eisenbahnwörterbuch nach einem passenden englischen Wort für das Tag
    • Wie wäre es mit disablement=dark, disablement=Kennlicht, disablement=yes? Damit wäre man nicht mehr auf eine bestimmte Art des Abschaltens festgelegt.
  • Entgleisweichen (catch points/trap points) => Machen wir erstmal nicht; betrifft eher den englischsprachigen Raum
  • Grundstellung von Weichen:
    • Könnte insbesondere für Rückfallweichen interessant sein. Andererseits ist die Grundstellung bei ferngestellten Weichen nur vermutbar, aber nicht erkennbar.
    • Tag => nochmal in einem Eisenbahn-Wörterbuch nachschlagen und Taggingvorschlag machen
  • Tagging von Weichenheizungen
    • Wäre natürlich cool für eine Winter-Mapping-Aktion. ;) Könnte auch für Datenjournalismus interessant sein. Andererseits sind -- außer bei Eis und Schnee -- die Heizung nicht einfach erkennbar.
  • Tagvorschlag angenommen: railway:switch:heated=yes/no
  • Oberbauformen: Statt Unterscheidung "Feste Fahrbahn ja/nein" differenzierteres Tagging ermöglichen (z. B. Gras oder Asphalt bei Straßenbahnen). => Dies wirft die grundlegende Frage auf, wie wir mit Straßenbahnen umgehen. => Im Moment ist dafür kein rechtes Interesse von aktiven Mappern erkennbar,. Wir würden das aufgreifen. Es bräuchte dann beispielsweise konsequenterweise auch Leute, die sich um Straßenbahnsignale kümmern.
  • Versenkte Mittelstromschienen (wiederum ein Straßenbahnthema)
    • Ja, das machen wir => passenden Wert für "electrified" noch finden, z. B. electrified=ground-level_power_supply, electrifiec=ground_rail oder electrified=middle_rail
  • Tagging von Kilometersprüngen, Überlängen, Fehllängen
    • Vertagt, da international wohl eine Vielzahl von Lösungen existieren.
  • Gleisverschlingungen
    • Als zwei separate Gleise eintragen
    • Zur Kennzeichnung müssen wir ein passendes englisches Tag finden.
  • Tagging von Abscnitten der Notbremsüberbürckung am Way
    • Eher nicht, da damit letztlich nur redundante Information eingetragen wird.
  • Tagging von Schutzstrecken
    • grundsätzlich ja, aber auch dazu mal im Eisenbahn-Wörterbuch nachschlagen.
    • bisherige Vorschläge: railway:lower_pantograph_section=yes/no und/oder railway:main_switch_off=yes/no
  • Working Rules mit Länderkürzel
    • Wir schauen uns das nochmal an, gerade auch im Hinblick auf die bisherige Verwendung.
  • Drehscheiben
    • Erfassung als Fläche
    • Bauformen erstmal nicht interessant
  • Rückfallweichen
    • Tagkonflikt bei Y-Rückfallweichen
    • die Information "Rückfallweiche ja/nein" in ein separates Tag (railway:switch:resetting=yes) ziehen, statt wie momentan als railway:switch=resetting taggen

Sonntag, 13. Juli

Wir treffen uns um 9:30 Uhr im "Lokal K" zum Frühstück und machen dann mit Tagdiskussionen weiter. Die Abreise erfolgt den Tag über.

Taggingdiskussion

  • Mapping von Bahnhöfen als Fläche oder Node
    • Ein Mappen von Bahnhöfen als Fläche aus Fahrgastsicht halten wir für unnötig. Es gibt die stop_area-Relation. Eine konvexe Hülle um die Mitglieder dieser Relation ergibt eine ähnliche Fläche. Deshalb sollten Bahnhöfe weiterhin als Node und stop_area-Relation erfasst werden. Zusätzlich gibt es noch die Betriebsstellen-Relation, die u. a. die landuse=railway-Fläche und den Bahnhofs-Node als Mitglieder hat.
  • Stillgelegte Straßen- und Schmalspurbahnen
    • key=status, status=value ist schlecht, da es Probleme mit Straßenbahnen und Schmalspurbahnen gibt.
    • key=value, status=yes ist auch nicht gut, da inkompatibel.
    • railway=disused wird nicht abgeschafft.
    • Wir definieren disused:railway=rail/tramway/…
    • Comparison_of_life_cycle_concepts#.3Cstatus.3E:.3Ckey.3E_.3D_.3Cvalue.3E
    • Railway#Tag_life-cycle
    • dieses Schema ist kompatibel zum bisherigen Tagging
    • von Seiten der ORM wird dieses Schema in Zukunft ausgewertet werden, dadurch werden die Mapper angeregt, auf das vorgeschlagene Schema umzustellen
  • Museumsbahnen und Bahnen mit Museumsverkehr
    • Wie taggt man Strecken mit Museumspersonenverkehr und regelmäßigem Nahgüterverkehr mit historischen Fahrzeugen?
    • Wie taggt man denkmalgeschützte Strecken?
    • railway=preserved abschaffen; preserved unterscheidet sich eigentlich nicht von regulär betriebenen Strecken
    • zusätzliches Tag (railway:preserved=yes) für Strecken mit historischem Charakter, die mit dem Ziel betrieben werden, den historischen Zustand zu bewahren; meist durch Museumsbahnen betrieben, von historischen Zügen befahren, historischer Streckenzustand
    • vermeidet auch Konflikte etwa zwischen railway=preserved und railway=narrow_gauge
    • Beispiele:
      • Museumseigene Strecke mit Schienenbusverkehr an Wochenenden: railway=rail, usage=tourism, railway:preserved=yes
      • Harzer Schmalspurbahnen (historische Züge, aber regulärer Zugverkehr mit Güterzügen): railway=narrow_gauge, usage=branch, railway:preserved=yes
      • Museums-Kleinbahn in Meterspur: railway=narrow_gauge, usage=tourism, railway:preserved=yes
      • Erhaltene Strecke mit unregelmäßigen Sonderfahrten und gelegentlichem Holzverkehr mit historischen Fahrzeugen: railway=rail, usage=branch, railway:preserved=yes
  • Geschwindigkeitsbegrenzungen für Straßenbahnen, wenn sich Autos und Straßenbahn einen Way teilen
    • Straßenbahngleis und Straße als getrennte Wege erfassen, um Konflikte bei anderen Tags (z. B. ref=*, name=*, operator=*, ...) zu vermeiden
    • saubere Trennung zwischen Auto und Bahn
    • im Normalfall bei zweigleisigen ohnehin notwendig
    • bei eingleisigen Strecken werden zwei Ways übereinander bzw. nebeneinander eingetragen
    • Neben den anderen Punkten: Es ist idR eh gleich (§50 (3) BOStrab), ansonsten gibt es noch maxspeed:tram=*
  • Wie taggen wir zwei Signale unterschiedlicher Richtungen am gleichen Mast (z. B. Geschwindigkeitssignale)?
    • Erfassung mit zwei nah zusammenliegenden Nodes => gerechtfertigt durch Mastbreite
    • wir wollen das Taggingschema der Signale nicht noch komplizierter machen
    • Was tun bei zwei momentan nicht gemeinsam erfassbaren Signalen (z. B. zs3 und lf7 am gleichen Mast in gleicher Richtung)
      • zwei kurz aufeinander folgende (wenige Zentimeter Abstand) Nodes
      • die Erfassung wäre sonst mit dem derzeitigten OSM Datenmodell wohl zu komplex
  • Wie noch nicht bekannte Geschwindigkeits-/Richtungsangaben bei Geschwindigkeits-/Richtungsanzeigern (Zs3/Zs2)?
    • Bei Zs2v, Zs2, Zs3v, Zs3 an Ks-Signalen kann man die einzelnen LEDs im Signal sehen und daraus die möglichen Signalbilder ermitteln. Dazu muss von schräg unten in das Signal schauen (langsame Vorbeifahrt oder Blick als Fußgänger neben der Strecke)
    • Tipp: Foto vielleicht überbelichten
    • nicht immer möglich
    • Wir taggen dann ein Fragezeichen, damit es mit der Overpass-API (oder anderen maschinellen Methoden) abfragbar ist. Fixme-Tags sind nicht maschinenlesbar.
  • LZB-Signale
    • Zitat aus http://fahrweg.dbnetze.com/file/2361510/data/ril_301_B5.pdf: "Im Abschnitt 8 ist der Begriff „LZB-Blockkennzeichen“ durch „Blockkennzeichen“ ersetzt worden. Der zweite Satz des Abschnittes wurde gestrichen. [...] wird der neue Begriff „Blockstelle für anzeigegeführte Züge“ technikneutral eingeführt. Er fasst LZB und ETCS zusammen und ersetzt die bisherigen „Blockstellen für LZB-geführte Züge (LZB-Blockstellen)“. Das bisherige LZB-Blockkennzeichen soll künftig auch auf Strecken mit ETCS angewendet werden. [...] Das Kennzeichen erfüllt sowohl bei LZB als auch bei ETCS den Zweck, dem Triebfahrzeugführer nach einem Halt an einer Blockstelle für anzeigegeführte Züge, die nicht durch ein Hauptsignal oder ein Signal Ne 14 (nur bei ETCS) ..."
    • railway:signal:lzb umbenennen zu railway:signal:cab_signalling
      • Dieses bislang für das LZB-Blockkennzeichen verwendete Tag ist kein Signal am Beginn- und Ende von Abschnitten mit Führerstandssignalisierung, wie der neue Tag andeutet. --Bigbug21 (talk) 17:03, 14 July 2014 (UTC)
        • Wieso deutet das neue Tag dies an? "cab_signalling" ist doch ziemlich neutral und bezieht sich einfach nur auf ein Signal, das irgendwie mit Führerstandssignalisierungen zu tun hat. --rurseekatze (talk) 21:39, 17 July 2014 (UTC)
      • Wir haben noch vergessen zu erwähnen, dass auch railway:signal:lzb_start zu railway:signal:cab_signalling geändert wird. --rurseekatze (talk) 21:39, 17 July 2014 (UTC)
        • Achso, es geht also um eine Reihe von Werten, die allesamt mit railwayːsignalːcab_signalling getagged werden. --Bigbug21 (talk) 10:29, 19 July 2014 (UTC)
    • reicht railway:signal:cab_signalling oder soll noch zwischen railway:signal:cab_signalling_block_marker/railway:signal:cab_signalling_section_marker und railway:signal:cab_signalling_begin/end unterschieden werden? [Nachbemerkung bigbug21: Darüber sollten wir nochmal sprechen. cab_signalling greift zu kurz, da die Trennung zweier Abschnitte damit nicht abgebildet wird.]
  • Sonstige ETCS Features
    • Balisen
    • Signale
    • => später
  • Worin liegt der Unterschied zwischen einem "Sh 1-Licht" und einem Sh-Signale->Schutzhaltsignal?
    • Unterscheidung macht wenig Sinn, daher sollten alle Hauptsignale mit Sh 1 ebenfalls wie ein reines Schutzhaltsignal getaggt werden
      • Änderungen an der JOSM-Vorlage und den Wikiseiten
      • Umtaggen der bislang erfassten Signale
    • Wir werden irgendwann mechanisch alle Sh0 an Lichtsignalen auf Hp0 umtaggen.
  • Schachbretttafeln
    • englischer Begriff: Checkerboard, siehe https://en.wikipedia.org/wiki/German_railway_signalling#Ne4_Schachbretttafel
    • Wir nehmen für den Key eine funktionale Übertragung ins Englische statt einer wortwörtlichen Übersetzung. Vorschläge:
    • railway:signal:different_position
    • railway:signal:altered_position
    • railway:signal:elsewhere
    • railway:signal:expected_position=left/right gibt den erwarteten Standort des Signals (also den Standort der Schachbretttafel) an, der tatsächliche Standort wird am Signal getaggt
  • Trapeztafeln (Ne1) auf dem Gegengleis mit genauer Meterangabe
    • die Vorlage muss um ein Eingabefeld ergänzt werden
  • Besondere Signale besonderer Bahninfrastrukturbetreiber
    • besondere Signale der Albtal-Verkehrsgesellschaft
    • Diskussion, ob man railway:signal:main=DE:EBO:Abkürzung oder DB:Abkürzung oder DE:DB:Abkürzung taggt
    • Diskriminierung von NE-Bahnen?
    • Kann man das Signalsystem vom operator-Tag des Gleises ableiten?
    • ausländische Signale gemischt mit deutschen Signalen: http://www.drehscheibe-online.de/foren/read.php?3,4862854,4863080
    • Wir taggen railway:signal:main=DE-EBO:hp für Hp-Signale bei der Deutschen Bahn, railway:signal:main=DE-AVG:hp für ein Hp-Signal bei der Albtal-Verkehrsgesellschaft, deren Hp2 eine leicht andere Bedeutung hat.
      • Achtung: Gilt nur für FV-NE-Strecken, bei FV-DB-Strecken nicht!
    • Wir sind gegen Länderkürzel, da es in den ehemaligen Ostblock-Staaten einheitliche Hl-Signale gibt, da könnte man dann railway:signal:main=OSSD:hl taggen.
    • Values ohne Präfix ist ein veralteter Eintrag, der noch nicht auf das neue Taggingschema umgestellt ist.
  • Tagging von Straßenbahnsignalen
    • fehlende Experten -> später
  • Richtungspfeile an Fahrleitungssignalen und Geschwidigkeitssignalen
    • -> später
  • Haltetafeln angegebenenen Zuglängen
    • Wir lassen es bei description, da es da alle möglichen Angaben gibt (200 m, Vollzug, VT 642, …).
    • Wenn das 1:1 abgetippt wird, dann kann man es auch parsen (Zahlenwert mit 'm').
  • name-Tag für Streckenname oder -verlauf
    • name nur, wenn die Strecken einen EIGENnamen hat, z. B. "Linke Rheinstrecke" oder "Harzquerbahn".
    • Streckenverläufe "Köln–Aachen" höchstens als description=*
    • Nachtrag: Eine Streckenbezeichnung ist eine zentrale Information und sollte daher IMHO durchaus genannt werden. Das gilt besonders für Bereiche, in denen mehrere Strecken parallel verlaufen. --Bigbug21 (talk) 13:51, 15 July 2014 (UTC)
      • Wenn es Eigennamen sind, dann in name=*, sonst in description=*. Eine Angabe wie "Köln - Aachen" ist kein Name, daher sollte das auch nicht so getaggt werden. Siehe auch DE:Names#name_ist_nur_der_Name. Ob das description-Tag letztlich doch auf der Karte angezeigt oder sonst irgendwie ausgewertet wird, muss die jeweilige Software entscheiden. --rurseekatze (talk) 21:39, 17 July 2014 (UTC)
        • Ok, das ist ein Argument. --Bigbug21 (talk) 10:29, 19 July 2014 (UTC)
  • Bahnhöfe, die eigentlich mehrere Bahnhöfe sind (z. B. Berlin Ostbahnhof)
    • kein Problem, wenn es auch aus Kundensicht mehrere Bahnhöfe sind (z. B. Brig SBB und Brig MGB)
    • ein Problem, wenn es aus Kundensicht ein Bahnhof ist, z. B. Köln Messe/Deutz oder Berlin Ostbahnhof
    • Wir vertagen das Thema und schauen erst nach, wie die Flughafen-Mapper das beim Flughafen Basel/Mulhouse gemacht haben, der einen französischen und einen schweizer Teil hat.
  • Wie weit geht landuse=railway?
    • aus Betrieblersicht bis zur Flurstückgrenze (d. h. meist inkl. Bahndamm)
    • Die Widmung für Eisenbahnzwecke wäre zwar nett zu wissen, ist aber nicht so leicht mappbar.
    • landuse ist Nutzung, der Bahndamm wird nicht genutzt
    • Die landuse-Fläche muss für Laien erkennbar sein -> Oberleitungsmasten als äußere Grenze
    • in Bahnhöfen inkl. Betriebsgebäude
  • Sollen Bahnsteige nicht mehr mit railway=platform getaggt werden?
    • Problem: osmfilter unterstützt keine Tagkombinationen (public_transport=platform + train=yes). Sonst würde die Datenbank der ORM größer werden
    • Wir lassen railway=platform stehen, da es Infrastruktur ist.
  • railway=stop
    • Infrastruktur von öffentlichem Angebot trennen (erleichtert das Filtern)
    • für Güterbahnhöfe
    • nicht jedes Gleis in einem Bahnhof hat eine PT-Relation
    • für das Routing
    • Wir brauchen Streckenrelationen, um railway=station-Nodes railway=junction-Nodes usw. in eine Relation packen zu können, um schematische Wikipedia-ähnliche Streckenrelationen bilden zu können.
  • Bauformen von Bahnsteigen (Seiten-, Mittel-, Inselbahnsteig, …)
    • Wozu braucht man das?
    • für die Zukunft, derzeit besteht kein Bedarf
  • on_demand bei stop_positions, stations und halts entfernen?
    • Bedarfshalt ja/nein ist eine Eigenschaft des Verkehrs statt der Infrastruktur
    • Bedarfshalte als spezielle role in der Route-Relation erfassen z.B: stop_on_demand analog zu stop_entry_only und stop_exit_only
    • Wir stimmen mapper999 zu.
  • Botlauf zur Vereinheitlichung der Dezimaltrenner
    • Wir sind für die Vereinheitlichung und fragen Oli-Wan, ob Wall E das erledigen kann.
    • Kann mal in einen künftiges ORM-QA-Tool eingebaut werden.
  • Für Mirko-Küster-Schema Entsprechungen finden
    • wird via Mailingliste erledigt
  • Umstellung von Mirko-Küster auf ORM-Schema
    • sollte manuell mit Overpass-API geschehen
  • Umtaggen von railway:signal:main:function=between -> intermediate
    • wir ändern die JOSM-Vorlage und machen eine Overpass-API-basierte Umstellung
  • railway:signal:electricity -> railway:signal:catenary
    • electricity bezieht sich auf alle Arten der Stromzuführung, catenary nur auf Oberleitungen -> wir stellen nicht um
  • structure_gauge vs. loading_gauge
  • Stellwerksrelationen/Stellbereichsrelationen eher railway=interlocking statt railway=controlled_area
    • Wir warten wegen sprachlicher Unsicherheiten und vertagen das Thema.
  • Signaltypen (type vs. order)
    • Beispiele:
      • Fahrleitungssignal: railway:signal:electricity=el7, railway:signal:electricity:type=power_off
      • Schneepflugtafel: railway:signal:snowplow=ne7, railway:signal:snowplow:order=up/down
    • Wir stellen auf type um, da es keinen Unterschied gibt.
  • Texte auf Signaltafeln
    • railway:signal:*:description=* wird bei Haltetafeln verwendet und railway:signal:*:caption=* bei Bü-Tafeln
    • Wir stellen auf caption um, da der Text bei Haltetafeln genauso bedeutend ist wie bei Bü-Tafeln

Nächstes Treffen

  • sollte zentraler stattfinden (Hessen) oder im Osten (Eisenach/Erfurt?)
  • sollte in einer großen Ferienwohnung mit Internet stattfinden, um Wege einzusparen ("Wohnen und Arbeiten unter einem Dach")
  • Nähe zu Frankfurt ist wünschenswert, damit man jemanden von DB Netze einladen kann (Unternehmenssitz Frankfurt am Main)

Aufgeschoben auf folgende Treffen

Tagesordnung

Freitag

  • Eintrudeln im Lokal K (früher Abend?)
  • Vorstellungsrunde
  • Grundlegendː Brauchen wir ein Protokoll (falls ja, wer macht es, in welcher Form?)? Inhaltliche und zeitliche Strukturierung des Wochenendes. Was wollen wir hier? Welche Ziele setzen wir uns? Wie strukturieren wir das Wochenende? (Moderationskoffer und -materialien sind vorhanden)
  • Öffentlichkeitsarbeit
    • Wie kommunizieren wir mit Externen (d. h. Nicht-Mappern), gemeint sind die Communities diverser Bahnforen?
      • Werbung für ORM (siehe auch den Leporello weiter unten)
      • Anwerbung von Mappern
      • als Datenquelle (Freigabe von Fotosammlungen)
      • Nachfragen bei Unklarheiten (wo genau ist X)
    • Wie organisieren wir den ORM-Blog?
      • Was für Inhalte sollen dort erscheinen?
      • Jeden Blogpost, der international relevant ist, auf Englisch und (optional) in anderen Sprachen?
      • Wer übersetzt? (Fragen gelten, abgesehen vom Englischen, auch für Twitter-Account)
    • Ein kleines ORM-Leporello gestalten?
    • Hintergrundː 2015 wird ein Fachartikel zur OpenRailwayMap im Eisenbahningenieur erscheinen. Daneben wurden Beiträge zu Fachkonferenzen angefragt, aber nicht weiter verfolgt.
  • Offener Erfahrungsaustausch zu Mappingtechniken, auch zur Ergänzung des Tutorials
  • Wie sollen wir mit den Übersetzungen der Wikiseiten umgehen? Insbesondere bei den Taggingseiten gibt es das Problem, dass man kaum alle Übersetzungen synchron halten kann.

Weiterentwicklung des Taggingschemas und Behebung von Unklarheiten (Freitag + Samstag)

Straßenbahnen und historische Strecken

  • Wie gehen wir mit stillgelegten/abgebauten Strecken um (Konflikt von railway=narrow_gauge mit railway=disused; Auswertungsschiwerigkeiten bei highway=cycleway, railway=disused, ref=Radweg 12 und start_date=1895).
    • Vorschläge, denen ich mich anschließen würde: Railway#Tag_life-cycle, Comparison_of_life_cycle_concepts --rurseekatze (talk) 10:06, 11 July 2014 (UTC)
    • um Probleme zu vermeiden, sollte der zeitliche/zuständliche Aspekt aus dem Value herausgezogen werden und als Präfix in den Key gesetzt werden -> disused/abandoned/razed/construction/proposed:key=value; dies erlaubt sehr genaues Tagging des "Life cycles" --rurseekatze (talk) 10:06, 11 July 2014 (UTC)
  • Diverse Schwierigkeiten bei railway=preserved:
    • Konflikt zwischen railway=preserved und railway=narrow_gauge
    • Wo liegt die Grenze zwischen railway=preserved und railway=rail? Draisinenstrecken, Strecken unter Denkmalschutz aber ohne Verkehr, Touristische Strecken mit Wochenendverkehr und gelegentlichen Güterzügen, museumseigene Strecke, ...
  • Erweiterung des Taggingschemas für Straßenbahnen?
    • z. B. Art des Bahnkörpers (straßenbündig, besonders, unanabhängig / Mitbenutzung durch Busse?)
    • signalisiert: ja / nein
    • Geschwindigkeitsbegrenzungen für Straßenbahnen, wenn sich Autos und Straßenbahn einen Way teilen
      • eigentlich sollten Straßenbahngleis und Straße als getrennte Wege erfasst werden; andernfalls gibt es nämlich auch Konflikte bei anderen Tags (z. B. ref=*, name=*, operator=*, ...) --rurseekatze (talk) 14:24, 9 July 2014 (UTC)

Gleise und Weichen

  • Ausrichtung von Streckengleisen / Tag für Regelfahrtrichtung
  • tunnel:name/bridge:name vs. name
  • Sinnhaftigkeit von maxspeed=signals bei Eisenbahnen. Der Großteil der zulässigen Geschwindigkeiten wird signalisiert. Taggen wir aber nicht die auf einem Gleisabschnitt maximal zulässige Geschwindigkeit?
  • Klare Unterscheidung von durchgehenden Hauptgleisen (Fortsetzung der freien Strecke), Hauptgleisen (das betrifft das alle Bahnsteiggleise, die nicht durchgehendes Hauptgleis sind), Nebengleisen.
    • Macht es Sinn, zwischen Abstellgleisen (service=yard) und sonstigen Nebengleisen (railway=siding) zu unterscheiden?
      • service=siding ist für die nicht-durchgehenden Hauptgleise vorgesehen ("Überholgleise", "Bahnsteiggleise"); eine Unterscheidung macht daher auf jeden Fall Sinn --rurseekatze (talk) 13:18, 9 July 2014 (UTC)
        • Das ORM-Preset für JOSM nennt Gleise mit service=siding "Nebengleis". --rayquaza (talk) 13:36, 9 July 2014 (UTC)
          • Oh, dann ist das falsch. Das muss dann noch angepasst werden (siehe auch ein paar Kommentare weiter unten) --rurseekatze (talk) 21:53, 10 July 2014 (UTC)
    • Welches service=* für Stumpfgleise mit Bahnsteigen, die also nicht zu service=yard und nicht zu service=siding passen?
      • kommt auf die örtlichen Gegebenheiten an; bei Kopfbahnhöfen sind solche Gleise meiner Meinung aber eindeutig mit service=siding zu taggen, da sie ja keine Abstellgleise sind und dazu auch Hauptgleise (service=yard sind eher Nebengleise, aber das ist nochmal eine andere Diskussion) --rurseekatze (talk) 14:40, 8 July 2014 (UTC)
    • Vielleicht sollten wir darüber nachdenken, kleine Beispielgrafiken zu erstellen, um die verschiedenen Gleistypen (vor allem international) besser erklären zu können. --rurseekatze (talk) 21:53, 10 July 2014 (UTC)
    • Bisherige Diskussion
    • Ich denke, dass das Tagging soweit in Ordnung ist, lediglich die Definitionen auf der Wikiseite und der JOSM-Vorlage sind teilweise etwas verwirrend und sollten angepasst werden. --rurseekatze (talk) 21:53, 10 July 2014 (UTC)
      • Evtl besser für beides ein neues, gut definiertes Tag, um erkennen zu können, wo die falsche Verwendung schon ausgetauscht bzw überprüft wurde? --rayquaza (talk) 00:24, 11 July 2014 (UTC)
  • Tagging von Stumpfgleisen
    • Vorschlag: service=trap_road/safety_siding/sand_drag
    • Mögliche Definition: A trap road/safety siding is a short dead-end siding leading to a sand drag or buffer stop to stop a vehicle.
  • Schutzweichen
    • Entgleisweichen (trap points)
      • Taggingvorschlag: railway:switch=trap_point, railway:switch:trap_point=single_rail/double_rail
      • Mögliche Definition: Trap points are found at the exit from a siding or where a secondary track joins a main line. It is used to protect main lines from unautorized movements onto them from sidings ot branch lines by derailing those vehicles.
      • Lassen sich Schutzweichen überhaupt exakt von anderen Weichen in ähnlichen Lagen abgrenzen? Welchen Nutzen hätte ein dezidiertes Tagging von (vermuteten) Schutzweichen?
        • genau deshalb sollen Schutzweichen ja auch nicht besonders getaggt werden (siehe unten) --rurseekatze (talk) 13:15, 9 July 2014 (UTC)
    • Entgleisweichen (catch points)
      • Taggingvorschlag: railway:switch=catch_point, railway:switch:catch_point=single_rail/double_rail/wide_to_gauge
      • (Wide to gauge trap points have switches that work in opposite directions and are therefore either both open or both closed. Any traffic travelling in the correct uphill direction can pass over the turnout savely. Any vehicles travelling downhill will be derailed at these points. Derailed vehicles will tend to continue in a forward direction rather than being thrown to one side. In some cases the catch points can be temporarily overridden to allow safe passage down the gradient in certain controlled circumstances.)
      • Mögliche Definition: Catch points are used to derail vehicles which are out of control on steep slopes. They derail ("catch") any unauthorised vehicles rolling down the gradient.
    • für Schutzweichen mit angeschlossenem Stumpfgleis ist meiner Meinung kein besonderes Tagging notwendig; solche Weichen lassen sich softwareseitig daran erkennen, dass an ihnen ein als Stumpfgleis getaggtes Gleis beginnt
  • Grundstellung von Weichen erfassen?
    • Von Rückfallweichen abgesehen sind sind diese Informationen in Deutschland offenbar praktisch nicht öffentlich verfügbar. Wir könnten in vielen Fällen vielleicht begründete Vermutungen anstellen. Macht es Sinn, trotzdem ein Tag dafür vorzusehen?
    • bei ortsgestellten Weichen ist die Grundstellung am Hebelgewicht erkennbar --rurseekatze (talk) 13:15, 9 July 2014 (UTC)
  • Taggen von Weichenheizungen mit railway:switch:heated=yes/no ?
  • Bei Weichen: Sollen bei ortsgestellten Weichen Informationen aufgenommen werden ob es sich z. B. um eine Weiche mit oder ohne Grundstellung handelt?
  • Oberbauformen differenzierter als "Feste Fahrbahn ja/nein" darstellen? (Schotter, Feste Fahrbahn, bei Straßenbahnen auch Asphalt, Rasen ...)
  • Tagging von Gleisen mit versenkten Mittelstromschienen?
  • Tagging von Kilometersprüngen, Überlängen, Fehllängen
  • Erfassung von Gleisverschlingungen
  • Momentan ist es nicht möglich, eine Y-Rückfallweiche korrekt zu taggen; mein Vorschlag: die Information "Rückfallweiche ja/nein" in ein separates Tag (z. B. railway:switch:resetting=yes/no) zu ziehen, statt wie momentan vorgesehen im Tag railway:switch=* unterzubringen
  • Soll sich das Tag highspeed=* nur auf Hochgeschwindigkeitsstrecken beziehen, oder für alle Strecken verwendet werden, die Teil des Hochgeschwindigkeitsnetzes sind? Hintergrund: Edits eines Users in Köln Hbf, wo manche Gleise mit highspeed=yes getaggt wurden
    • für mich ergibt highspeed=yes in Köln Hbf wenig Sinn, das Tag sollte wirklich nur Hochgeschwindigkeitsstrecken kennzeichnen --rurseekatze (talk) 09:43, 11 July 2014 (UTC)
    • man könnte allerdings auch das Tag abschaffen und alle Strecken mit usage=main und maxspeed>200 als Hochgeschwindigkeitsstrecken betrachten --rurseekatze (talk) 09:43, 11 July 2014 (UTC)
    • Vielleicht irgendwas mit TEN-HGV?
  • Sollte die Notbremsüberbrückung auch als Eigenschaft des Gleises (etwa mit railway:emergency_brake_override=yes/no) getaggt werden?
  • Taggen von Schutzstrecken mit railway:lower_pantograph_section=yes/no und/oder railway:main_switch_off=yes/no ?
  • Genauere Definition der zulässigen Werte von working_rules - ich würde vorschlagen, noch ein Länderkürzel zu ergänzen, also z. B. working_rules=DE:EBO
  • Sonderformen von Drehscheiben: Segmentdrehscheiben, Doppeldrehscheiben
    • allgemein: Drehpunkt mit Radius oder Fläche erfassen?

Signale

  • Was tun bei zwei momentan nicht gemeinsam erfassbaren Signalen bzw. Orientierungszeichen am gleichen Mast/Standort (beispielsweise Hektometertafel mit Blockkennzeichen oder Geschwindigkeitssignal am gleichen Oberleitungsmasten)?
  • Wie taggen wir zwei Signale unterschiedlicher Richtungen am gleichen Mast (z. B. Geschwindigkeitssignale)?
    • mit sehr nahe beieinander liegenden Punkten und einem verbalen Kommentar als noteː...?
    • dieses Thema wurde schon diskutiert --rurseekatze (talk) 23:48, 8 July 2014 (UTC)
  • Wie gehen wir mit unbekannten Werten um, beispielsweise bei Richtungs- und Geschwindigkeitsanzeigern (zs2/zs3)
    • Mit Fragezeichen "60;?;off"? --Bigbug21 (talk) 13:02, 8 July 2014 (UTC)
    • Ich lasse den Wert mit einem Semikolon enden (=ein leerer Eintrag am Ende), wenn vermutlich Werte fehlen. --rayquaza (talk) 08:00, 4 July 2014 (UTC)
  • Signal an LZB- und ETCS-Strecken können komplett dunkelgeschaltet werden. Wie gehen wir damit um? Wie wäre es mit etwas in Richtung: "railwayːsignalːdark=yes"?
  • railway:signal:lzb umbenennen zu railway:signal:cab_signalling_block_marker bzw. railway:signal:cab_signalling_section_marker ? Das dürfte weniger stark auf Deutschland bezogen sein, außerdem wollen wir ja eher allgemeine, englische Begriffe für Tags.
    • (beim Taggingschema wurde das ehemalige "LZB-Blockkennzeichen" schon zum seit 2011 verwendeten, allgemeinen "Blockkennzeichen")
    • Wie gehen wir allgemein mit ETCS-Signalen und -Equipment um?
      • Wie wäre es mit einer Art internationalen Tagging-Modul?
  • Worin liegt der Unterschied zwischen einem "Sh 1-Licht" und einem Sh-Signale->Schutzhaltsignal?
  • Tagging für Schachbretttafeln
  • Trapeztafeln auf dem Gegengleis in Höhe des Esig tragen zusätzlich eine Tafel mit einer km-Angabe, ein Eingabefeld dafür wäre überlegenswert. Könnte dann zu railway:position:exact führen.
  • Tagging von EIU-spezifischen Sondersignalen, die nur bei einer NE-Bahn verwendet werden? Beispiel: Sammlung Betrieblicher Vorschriften der Albtal-Verkehrsgesellschaft für die Albtal-, Hardt-, Kraichtal- und Katzbachtalbahn
    • Wie sollen Haltetafeln mit blauem Zusatzlicht und Indusi-Magnet (Ersatz für Hauptsignale auf Nebenstrecken) getaggt werden?
  • Tagging von Straßenbahnsignalen
  • Sollen Richtungspfeile an Fahrleitungssignalen (betrifft vor allem El 6) erfasst werden, und wenn ja, wie?
    • Betrifft auch Lf1 und Lf6 (nicht Zuordnungstafel! Vgl. 301.0501 8 (6) bzw 301.0002 3)
  • Bisher werden die an Haltetafeln angegebenenen Zuglängen mit railway:signal:stop:description=* getaggt. Sollte für die Längeninformation ein separates Tag verwendet werden?

Bahn- und Reisendenübergänge

  • Sicherung von Bahnübergängen – Taggingschema ergänzen
    • Tags für Tore (England) und aufstellbare Fahrbahnsperren (Russland) ?
    • Kameraüberwachung durch Fahrdienstleiter
    • Gefahrenraum-Freimeldeanlagen (Radarscanner an Bahnübergängen)
    • Andreaskreuz
      • Vorschlag: crossing:saltire?
  • Reisendenübergänge/höhengleiche Bahnsteigzugänge und railway=crossing
  • Schrankenwärterposten und manuell bediente Streckenblöcke (solange es sie noch gibt)
  • Erfassung der Steuerungsart:
    • ortsbedient (z. B. durch Schrankenwärter oder per Schlüsselschalter; Bahnpersonal physisch vor Ort)
    • ferngesteuert (manuelles Schließen durch Fahrdienstleiter)
    • automatisch (durch Gleiskontakte)
  • Unterscheidung zwischen Bahnübergängen, Reisendenüberwegen und Straßenkreuzungen (bei Teilnahme am Straßenverkehr)
  • Was tun mit Bahnübergängen im Bereich einer Einmündung (betrifft hauptsächlich die Strasse)? Beispiel: FSTM, Bahnhofstr

Sonstiges Tagging

  • Vereinheitlichung der Betreiberː
    • Schienenwegeː "DB Netz" oder "DB Netz AG" (allgemeinː mit oder ohne Unternehmensform?)
    • Wen definieren wir als Betreiber für Personenbahnhöfe und -haltepunkteː "DB Netz AG" (Fokus Eisenbahn-Infrastruktur), "DB Station&Service AG" (Fokus Verkehrsstation) oder einfach "Deutsche Bahn"?
  • Müssen Informationen zur Erfassung immer in note=* abgelegt werden oder genügt eine dezentrale Archivierung der Rohdaten beim jeweiligen Mapper? Beispiel Wo Informationen zur Datenquelle (source:*=*) ablegen?
    • Irgendwann bin ich tot oder habe vielleicht keine Lust mehr auf Mapping, dann sind diese paar tausend zusätzlichen Lageinformationen besser in der Datenbank als auf meiner Festplatte. --Bigbug21 (talk) 11:24, 9 July 2014 (UTC)
  • Macht es Sinn, bei Stellwerken Hektometer und Meterwert separat abzufragen? Im Grunde ist die Standortinformation hier in jedem Fall in möglichst genauer Form wünschenswert?
  • Wie sollen Ril 100-Kürzel zu ausländischen Betriebsstellen (X...) erfasst werden? Und umgekehrt ausländische Abkürzungen zu deutschen Betriebsstellen? Gleiche Schwierigkeit bei Betriebsstellen, die von verschiedenen EVUs genutzt werden und bei jedem dieser Unternehmen ein anderes Kürzel tragen
  • Verwandtes Problem: Deutsche Namen von ausländischen Betriebsstellen und umgekehrt
  • Grenzpunkte sollten in Grenzpunkte an Staatsgrenzen und Grenzen von Betreibernetzen aufgeteilt werden; bislang werden beide Arten einheitlich getaggt, was eine unterschiedliche Darstellung auf der Karte nicht möglich macht
  • Firmen mit Gleisanschluss sollten auf einer Eisenbahnkarte besonders angezeigt werden. Ist zur Kennzeichnung ein besonderes Tag nötig oder lassen sich solche Firmen über geographische Abfragen ermitteln?
  • railway=blockpost als Tag für die Betriebsstellentypen Blockstelle (Bk) und Deckungsstelle (Dkst)?
  • Wie können Haltestellen korrekt erfasst werden?
  • railway=spur_junction/refuge_siding für Anst und Awanst?

Tagging das auch für Nicht-Bahninfrastrukturmapper relevant ist

  • Soll das name-Tag von Gleisen nur für den Streckennamen (z. B. "Linke Rheinstrecke"), oder auch für den Streckenverlauf (z. B. "Köln - Aachen") benutzt werden?
  • Tagging von Bahnhöfen und deren Mappen als Fläche
    • Welche Tags für die kundenorientierte Sicht, welche für die betriebliche Sicht?
    • Wie gehen wir mit Bahnhöfen um, die betrieblich getrennte Betriebsstellen sind, beispielsweise
      • Bhf Köln Messe/Deutz vs. Bhft. Köln Messe/Deutz Hp der S-Bahn
      • Berlin Ostbahnhof (BHF) vs. S Berlin Ostbahnhof (BSOB)
      • Berlin Hauptbahnhof (S-Bahn oben, S-Bahn unten, Fernbahn oben, Fernbahn unten)
      • Berlin Westkreuz (BWKRR/BWKR)
      • Dreieich-Buchschlag (FBUS)
  • Wo endet eine Fläche, die mit landuse=railway getaggt ist?
    • Am Rand des Lichtraumprofils + Sicherheitsabstand?
    • Am gleisseitigen Neigungswechsel der Damm-/Einschnittsböschung (also exklusive Gebüsch auf dem Bahndamm)?
    • Alles inkl. Bahndamm/-einschnitt?
  • Brauchen wir noch railway=platform?
    • für Bahnsteige ohne Personenverkehr?
  • Sollen Bahnsteigabschnitte (z. B. "5A") erfasst werden? Wenn ja, wie?
  • Wie sollen Inselbahnsteige erfasst werden? Eine Fläche mit z.B: ref=5;6, zwei separate Flächen oder Bahnsteigkanten, die per Relation zu einem Bahnsteig gruppiert werden?
  • Wozu brauchen wir railway=stop?
    • Eigentlich dazu gedacht, bei Anwendungen wie Routing einfache Streckenverläufe erzeugen zu können
    • Ein railway=stop auf jedem Gleis ist ziemlich redundant; als einzige mögliche Alternative fällt mir nur die Ermittlung über Signale (zumindest in Deutschland) ein --rurseekatze (talk) 21:22, 8 July 2014 (UTC)
    • Falls man an diesem Tag festhält: Wie wird railway=stop bei Abzweigen, Überleitstellen, etc. eingetragen?
    • Ist railway=stop nicht identisch zu public_transport=stop_position und kann einfach ersetzt werden? --Mapper999 (talk) 16:30, 9 July 2014 (UTC)
  • Sollen Bauformen von Bahnsteigen (Seiten-, Mittel-, Inselbahnsteig; bei Straßenbahnen Fahrbahnrand, Fahrbahnmitte, Kap) erfasst werden? Wenn ja, wie?
  • on_demand bei stop_positions, stations und halts entfernen? Bedarfshalt ja/nein dürfte eher eine Eigenschaft des Verkehrs als der Infrastruktur sein
    • Man könnte Bedarfshalte als spezielle role in der Route-Relation erfassen z.B: stop_on_demand analog zu stop_entry_only und stop_exit_only --Mapper999 (talk) 16:30, 9 July 2014 (UTC)

Diskussion Bot-Edits und Umstellung von bestehendem Tagging, das nicht zum ORM-Schema gehört

  • Diskussion über einen Botlauf zur Vereinheitlichung der Dezimaltrenner (alles auf Punkt statt Komma umstellen), bevor man auf talk-de nachfragt
  • ehemaliges Proposal von Mirko Küster durchgehen und schauen, ob es schon für alle Tags Entsprechungen im ORM-Schema gibt
  • Diskussion über einen Botlauf zur Umstellung aller Eisenbahn-Tags von Mirko Küster auf das ORM-Schema, bevor man auf talk-de nachfragt
  • Zwischensignale: railway:signal:main:function=between umtaggen nach railway:signal:main:function=intermediate ?
  • railway:signal:catenary in railway:signal:electricity umbenennen?
  • Ergänzung der deutschen Signale um ein Länderpräfix, analog zum Tagging in anderen Ländern (z. B. railway:signal:main=DE:hp statt railway:signal:main=hp), Diskussion
  • Vereinheitlichung von structure_gauge und loading_gauge
  • Sollten Stellwerksrelationen/Stellbereichsrelationen eher railway=interlocking statt railway=controlled_area getaggt werden?
  • Könnte man railway:signal:*:type=* und railway:signal:*:order=* nicht auch zusammenlegen?
  • Könnte man railway:signal:*:description=* und railway:signal:*:caption=* nicht auch zusammenlegen?

Vorschläge zum Mapping umliegender Bahnstrecken (Samstag nach Tagging, Sonntag)

  • Köln–Düren–Aachen
  • Köln–Rommerskirchen–Grevenbroich
  • Köln–Dieringhausen
  • Köln–Troisdorf–Bonn
  • Köln–Bergisch Gladbach
  • Köln–Leverkusen–Solingen
  • Köln–Leverkusen–Düsseldorf
  • Köln–Euskirchen
  • ...
  • Mapping umliegender Bahnhöfe, beispielsweise Köln Hauptbahnhof und Köln Messe/Deutz
    • ggf. beim Mappen Fotos von den Mappern (müssen ja nicht erkennbar sein/Fotos von hinten) machen?

Hacking (Sonntag parallel zum Mappen, je nach Lust und Laune)

  • Verbesserungen/Erweiterungen Renderingstyle
  • Erweiterungen der API um zusätzliche Abfragen
  • ...

Sonstiges (Sonntag parallel zum Mappen und Hacken, je nach Lust und Laune)

  • GPG-Keysigning (für GPG-Nutzer)

Übernachtung

Ältere Teile dieser Wiki-Seite

Ziele

  • gemeinsames Kennenlernen der Eisenbahnmapper
  • Daten vor Ort erfassen, Daten verbessern
  • neue, interessierte Mapper an das Thema Eisenbahnmapping heranführen
  • Grundlegende Fragen klären, insbesondere zum Tagging-Schema
  • Öffentlichkeit schaffen, Vernetzung versuchen (beispielsweise zur Deutschen Bahn oder zu Mentz Datenverarbeitung)

Interessenten

Bitte tragt euch in die folgende Liste ein, wenn ihr grundsätzlich an einer solchen Veranstaltung interessiert seid.

Ablauf

  • Einführung und Organisation
  • Streckenbefahrungen, Streckenbegehungen, etc. in kleinen Teams
  • Gemeinsames Eintragen der gesammelten Daten
  • Gemütliche Runde zum Kennenlernen und Diskutieren
  • Hacking, falls sich dafür noch etwas Zeit findet

Noch zu klären

  • Ein- oder mehrtägig?
  • Termin
  • Location
  • am Rande der SotM-EU in Karlsruhe (eventuell als separates Get-Together)?

Mögliche Orte

Bitte tragt in die Tabelle ein, welche Orte ihr für eine solche Veranstaltung bevorzugt. Ihr könnt außerdem weitere Orte ergänzen.

Region Kommentar User, die diesen Ort bevorzugen
Rheinland (Köln/Düsseldorf) vielbefahrene Bahnknoten rurseekatze, jotpe (eher Köln)
Ruhrgebiet sehr dichtes Eisenbahnnetz mit unzähligen Strecken rurseekatze
Frankfurt am Main bedeutendster deutscher Bahnknoten, bislang kaum erfasst rurseekatze, Nakaner, bigbug21, Saxonyking, Margin-Auto

Terminvorschläge

Bitte bis zum 1. Juni 2014 hier abstimmen. Abstimmungsergebnis: 11.–13. Juli 2014 im Rheinland

Rückblick

Eine kurze Zusammenfassung des Mappingwochenendes findet sich im OpenRailwayMap-Blog.

Retrieved from "https://wiki.openstreetmap.org/w/index.php?title=DE:OpenRailwayMap/Mappingwochenende_2014_1&oldid=2047859"