DE:OpenRailwayMap/Aktiventreffen 2014 2

From OpenStreetMap Wiki
Jump to navigation Jump to search
OpenRailwayMap/Aktiventreffen 2014 2 - Other languages

Auf dieser Seite findet sich die Organisation und das Protokoll des zweiten Aktiventreffens (vormals bekannt als "Mappingwochende") im Rahmen der OpenRailwayMap. Das Treffen fand vom 24. bis 26. Oktober 2014 bei User spth in Bad Nauheim (Nähe Bahnhof) statt.


Ablauf und Ziele

  • Fragen zum Tagging klären, die seit Mitte Juli 2014 aufgetaucht sind oder auf dem letzten Mappingwochende in Köln vertagt wurden.
  • zwischendurch zur Abwechslung: ein klein wenig Bahnanlagen-Mapping draußen
  • bei ausreichend Zeit: Hacking
  • Öffentlichkeit schaffen, Vernetzung versuchen (beispielsweise zur Deutschen Bahn)

Teilnehmer

Tagesordnung

Taggingfragen

Gleise

  • Oberbauformen: Statt Unterscheidung "Feste Fahrbahn ja/nein" differenzierteres Tagging ermöglichen (z. B. Gras oder Asphalt bei Straßenbahnen)
  • Wann soll highspeed=yes gesetzt werden?
    • 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?
    • Taggt man vollständige Strecken oder Streckenabschnitte?
    • Welche Kriterien? Diskutierte Kriterien: mit wenigstens/mehr als 200 km/h (250 km/h) befahrbar, Feste Fahrbahn, Linienzugbeeinflussung, ausschließlich/überwiegend von Fern-/Hochgeschwindigkeitszügen befahren
  • Wo endet ein Abschnitt mit highspeed=yes?
  • Enthält highspeed=yes denn überhaupt sinnvolle zusätzliche Informationen, die der interessierte Benutzer/Renderer sich nicht auch schon aus den anderen (genannten) Kriterien (maxspeed>200, lzb=yes) ableiten kann?
  • Einröhrige vs. zweiröhrige Tunnel
  • Wir sollten uns eine kurze, knackige, für Laien verständliche Definition überlegen, was railway=tram, was light_rail und was rail in Deutschland (ggf. inkl. Österreich und Schweiz) ist. Die Definition sollte so sein, dass keine größeren Umtaggarbeiten nötig werden. Diese Definition könnte man dann unter anderem auf De:Tag:railway=light_rail unterbringen. --Nakaner (talk) 09:57, 2 October 2014 (UTC)
  • Museumsstrecken/Erhaltene Strecken
    • railway=preserved streichen, da Kollision mit anderen Tags wie railway=narrow_gauge und fehlender Unterschied zu regulär betriebenen Strecken (schon auf dem letzten Treffen beschlossen)
    • stattdessen railway=* und ein zusätzliches Tag
    • Mögliche Definition: "Strecken unter Denkmalschutz oder mit historischem Charakter, die mit dem Ziel betrieben werden, den historischen Zustand (Signaltechnik, Oberbau, Bauwerke, eingesetzte Fahrzeuge) zu bewahren. In der Regel (aber nicht zwingend) werden solche Strecken von Museumseisenbahnen für touristische Zwecke betrieben, allerdings gibt es auch Strecken mit regulärem Personen- oder Güterverkehr (z.B. Harzer Schmalspurbahnen). Ebenfalls dazu zählen Bahnstrecken, die regulär nicht mehr von Personen- oder Güterzügen genutzt werden, zu besonderen Anlässen (z.B. Großveranstaltung, Spezialtransport) aber kurzzeitig wieder reaktiviert werden." --rurseekatze (talk) 16:03, 6 October 2014 (UTC)
    • Die Kollision mit railway=narrow_gauge halte ich für nicht relevant, da die Information, ob es sich um Normal-/Schmalspur handelt, eh im gauge-Tag vorhanden ist, nur sehr viel genauer. Sollte man zusätzlich also auch das railway=narrow_gauge lieber streichen? --User:bjoern_m 14 October 2014 (UTC)
  • Gleisverschlingungen
    • wollen wir als zwei separate Gleise eintragen (siehe letztes Treffen)
    • wir brauchen noch ein passendes englisches Tag, um solche Gleise zu kennzeichnen --rurseekatze (talk) 08:33, 18 October 2014 (UTC)
    • reicht eine Kennzeichnung mit einem Tag überhaupt für eine Auswertung per Software aus? Beispiel: Ein Routingprogramm benötigt die Information, dass gleichzeitig immer nur ein Gleis einer Gleisverschlingung befahren werden kann. --rurseekatze (talk) 08:33, 18 October 2014 (UTC)
      • Ein Schema dafür könnte optimalerweise auch gleich Begegnungsverbote abdecken. --rayquaza (talk) 15:18, 19 October 2014 (UTC)
  • Tagging von Industriebahnen
    • Eigentlich ist definiert, dass usage=* nur für Streckengleise verwendet werden soll; bei der Erfassung von Industriebahnen stößt man dabei aber auf Konflikte: Ein Abstellgleis einer Hafenbahn, das korrekt mit railway=rail, service=yard getaggt ist, erscheint dadurch auf der Karte schwarz die Hauptgleise dagegen braun, was ein uneinheitliches Kartenbild ergibt. --rurseekatze (talk) 08:40, 18 October 2014 (UTC)
      • Das Problem gibt es auch für Nebengleise von militärisch genutzten Strecken und militärisch genutzte Anschlussgleise. Sollten wir ausnahmsweise entgegen der Grundregel, dass usage=* und service=* nicht an das selbe Gleis getaggt sein dürfen, folgende Tagkombinationen erlauben: service=spur + usage=military für Anschlussgleise zu Materiallagern usw., service=siding/yard + usage=military für Nebengleise in Bahnhöfen eigenständiger, rein militärisch genutzter Strecken, service=yard/siding + usage=industrial für Nebengleise von Hafenbahnen (Teile HGK-Streckennetz?)? Ich persönlich bin gegen die Einführung von railway:traffic_mode=military/industrial für die genannten Fälle, da ich dieses Tag für die Unterscheidung Güter-/Personenverkehr vorbehalten möchte. Andererseits werden wir sonst über kurz oder lang Fälle haben, wo die Leute usage=main + service=siding taggen, was falsch ist. Ich freue mich auf eure Kommentare --Nakaner (talk) 09:15, 21 October 2014 (UTC)
  • Wir einmal über die zulässigen Werte und die Dokumenation des Tags working_rules=* sprechen
  • Da railway:track_class=* (Streckenklasse) meines Wissens nur eine europäische Norm ist, wäre vielleicht zu überlegen, die Daten in Meterlast mit railway:meterload=<Tonnen/Meter> und Achslast mit railway:axleweight=<Tonnen> anzugeben.
  • Unterschiedliche Maxspeeds bei verschiedenen Fahrzeugtypen
  • Entgleisweichen (catch points/trap points)

Stromversorgung

  • Tag für Oberleitungsmast
    • Vorschlag 1: railway=catenary_mast
    • Vorschlag 2: man_mad=catenary_mast
    • Hinweis: Oberleitungen gibt es auch bei Bussystemen! Das ist ein Argument gegen railway=*
      --Nakaner (talk) 17:10, 27 September 2014 (UTC)
    • Das Erfassen von Oberleitungsmasten sehe ich als ziemlichen Overkill an. Wozu soll das gut sein? --rurseekatze (talk) 16:07, 6 October 2014 (UTC)
      • Wenn Speiseleitungen auf Oberleitungsmasten mitgeführt werden, möchte man die Masten nicht als Strommasten taggen. Würde man kein Tag an die Nodes setzen, würden diverse QA-Tools meckern. Ich weiß, wir mappen nicht für QA-Tools. :-) --Nakaner (talk) 08:40, 13 October 2014 (UTC)
      • OL-Masten haben auch Nummern, die teilweise bereits erfasst sind, aber noch ohne echtes Tag (z.B. Strassenbahn Bielefeld). --rayquaza (talk) 13:07, 17 October 2014 (UTC)
  • Einspeisungen aus Speiseleitung
    • Tag erfinden
    • Wie mappt man das, wenn
      • Speiseleitung als Linien parallel vorhanden ist
      • Speiseleitung nicht gemappt ist
        --Nakaner (talk) 17:10, 27 September 2014 (UTC)
  • Aufhängungsarten der Speiseleitung
    • auf Oberleitungsmasten
    • auf den Auslegern von Oberleitungsmasten
    • auf einfachen Oberleitungsmasten, aber nicht ganz mittig. Wohin der Node? Auf den Masten oder die 20 cm daneben?
      --Nakaner (talk) 17:10, 27 September 2014 (UTC)
  • Tag für Überbrückbarkeit von Trennstellen und die Standardstellung (ein/aus) dieser Schalter (gibt es an den Systemwechsel-Schutzstrecken der AVG in Karlsruhe-Durlach und Karlsruhe-Albtalbahnhof) --Nakaner (talk) 17:10, 27 September 2014 (UTC)
  • Tagging von Schutzstrecken
    • => ja (beschlossen auf dem letzten Treffen), aber wir brauchen noch ein sinnvolles Tag
    • bisherige Vorschläge: railway:lower_pantograph_section=yes/no und/oder railway:main_switch_off=yes/no
    • Übersetzt wäre es: phase break und section break --Jimmy K (talk) 17:42, 23 October 2014 (UTC)
  • Versenkte Mittelstromschienen
    • Ja, das machen wir (beschlossen auf dem letzten Treffen) => passenden Wert für "electrified" noch finden, z. B. electrified=ground-level_power_supply, electrified=ground_rail oder electrified=middle_rail

Betriebsstellen

  • Schrankenwärterposten und manuell bediente Streckenblöcke (solange es sie noch gibt)
  • railway=blockpost als Tag für die Betriebsstellentypen Blockstelle (Bk) und Deckungsstelle (Dkst)?
  • railway=spur_junction/refuge_siding für Anst und Awanst? Eine Differenzierung zwischen Abzweigen und Anschlussstellen wäre jedenfalls wünschenswert
  • Besetzungszeiten von Betriebsstellen und Stellwerken: manned=yes/no/<times>?
  • 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?
  • Unterschiedliches Tagging von Vollbahn-, Stadtbahn-, S-Bahn- und U-Bahnhöfen für bessere Differenzierbarkeit
  • Sollen Straßen-/Stadtbahnhaltestellen nur als railway=tram_stop getaggt werden, oder soll auch hier zwischen Bahnhöfen und Haltepunkten unterschieden werden?
    • In Deutschland gibt es diese Unterscheidung rechtlich nicht, aber was ist mit anderen Ländern? Außerdem erfassen wir ja nicht Vorschriften, sondern Dinge der Realität --rurseekatze (talk) 12:54, 9 September 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, diverse Berliner Bahnhöfe, wo S- und Eisenbahn halten, Leipzig Messe
    • wir schauen nach, wie die Flughafen-Mapper das beim Flughafen Basel/Mulhouse gemacht haben, der einen französischen und einen schweizer Teil hat
    • durch strikte Trennung von Bahnhöfen aus Kundensicht und aus betrieblicher Sicht ließe sich das Problem lösen; die Frage ist
      • ob railway=station und railway=halt nur noch für die betriebliche Sicht stehen und public_transport=station die Kundensicht abbilden soll, oder
      • ob wir ein neues Tag entwickeln wollen, um nicht bestehende Taggingdefinitionen zu ändern
    • 2 Hinweise, die bei der Festlegung des Betriebsstellentaggings beachtet werden sollten:
      • es gibt auch ziemlich verworrene Betriebsstellen, z.B. Königs Wusterhausen, da ist die S-Bahn (BKWS) mitten im Regionalbahnhof (BKW) --Streckensucher (talk) 19:43, 24 October 2014 (UTC)
      • wie verfahren, wenn die Betriebsstelle mehrere Betreiber hat? Soweit ich weiß, ist z.B. Berlin-Wuhletal eine BVG-, also U-Bahn-Station, an der aber auch die S-Bahn (also Eisenbahn) hält. --Streckensucher (talk) 19:43, 24 October 2014 (UTC)
  • railway=stop
    • Notwendig für das Routing, um Streckenverläufe ähnlich wie in Wikipedia oder in Buchfahrplänen zu generieren
    • Infrastruktur von öffentlichem Angebot trennen: bei Güter- oder Betriebsbahnhöfen würde ein public_transport=stop_position keinen Sinn ergeben
    • Welche Gleise einer Betriebsstelle (zusätzlich zu den Bahnsteiggleisen) sollen einen Node mit railway=stop erhalten?
    • 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.
      • Hilft für das Routing leider nicht weiter, da eine berechnete Wegstrecke über viele verschiedenen Teilstrecken führen kann; eine direkte Beziehung zum befahrenen Gleis ist nötig --rurseekatze (talk) 22:52, 14 September 2014 (UTC)
    • Wie sieht die Erfassung bei Abzweigen aus? Sinnvoll wäre eigentlich das Taggen der abzweigenden Weiche mit railway=stop, doch dann kommt es zu Tagkonflikten mit der Weiche selbst
  • Bahnsteige mit verschiedenen Oberflächen
  • 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; bisherige Diskussion
    • das Problem gibt es auch bei Betriebsstellennamen --rurseekatze (talk) 15:46, 23 October 2014 (UTC)
    • evtl bei allen das Unternehmen angeben (z.B. "railway:ref:DBAG"=FF)
      • Zumindest das Kürzel des Betreibers sollte als railway:ref erfasst werden (so, wie wir auch bei Städten den Namen in der Landessprache mit name=* erfassen), sonst ist das Auswerten kaum möglich. --rurseekatze (talk) 15:46, 23 October 2014 (UTC)
  • Tag für "Betriebshof" (Tram und Bw-Gelände)
    • gibt es schon: railway=service_station für die Betriebsstelle und Tags wie railway=workshop für die Werkstatt oder railway=fuel für die Tankstelle --rurseekatze (talk) 15:46, 23 October 2014 (UTC)
  • Verfeinerung der Definition, welche Ausdehnung die Fläche einer Betriebsstelle (landuse=railway, Mitglied in Betriebsstellenrelation) haben sollte?
    • sollten Einfahrsignale Teil der Fläche sein, oder innerhalb der Fläche liegen? --rurseekatze (talk) 20:41, 23 October 2014 (UTC)
  • Grenzpunkte sollten in Staatsgrenzen und Infrastrukturwechsel aufgeteilt werden; bislang werden beide Arten einheitlich getaggt, was eine unterschiedliche Darstellung auf der Karte unmöglich macht --rurseekatze (talk) 20:42, 23 October 2014 (UTC)
  • Für das Tagging der Bahnsteigabschnitte wurde auf dem letzten Treffen noch kein Tag festgelegt. Und wir müssen nochmal festlegen, ob die Erfassung nun über Nodes oder Wege geschehen soll. --rurseekatze (talk) 21:43, 23 October 2014 (UTC)

Bahnübergänge

  • Unterscheidung zwischen Bahnübergängen, Reisendenüberwegen und Straßenkreuzungen (bei Teilnahme am Straßenverkehr)
  • Reisendenübergänge/höhengleiche Bahnsteigzugänge
  • Definition: Was soll mit railway=level_crossing, was mit railway=crossing getaggt werden?
    • derzeit meist railway=level_crossing und nur Reisendenüberwege sowie ausschließlich mit Z-Gitter gesicherte Fußgänger-Bü als railway=crossing --Nakaner (talk) 20:09, 24 September 2014 (UTC)
  • Was tun mit Bahnübergängen im Bereich einer Einmündung (betrifft hauptsächlich die Straße)? Beispiel: FSTM, Bahnhofstraße
  • Sicherung von Bahnübergängen - Taggingschema ergänzen
    • Tags für Tore (England) und aufstellbare Fahrbahnsperren (Russland)
    • Andreaskreuz, Vorschlag: crossing:saltire?
      • crossing:saltire=yes oder gleich crossing:saltire=DE:201 :-) Gibt es überhaupt fremdländische Andreaskreuze an Bahnübergängen in der Bundesrepublik? --Nakaner (talk) 20:09, 24 September 2014 (UTC)
  • Tag für Art der Überwachung
    • Gefahrenraum-Freimeldeanlagen (Radarscanner)
    • Kameraüberwachung durch Fahrdienstleiter
    • Sprechanlage (Anrufschranken)
    • Person vor Ort (Schrankenwärter oder Bahnpersonal beim Absichern per Fahne oder manuellem Einschalten der technischen Sicherung, Lokführer)
  • Tag für Art der Einschaltung
    • ortsbedient (z.B. Schrankenwärter, per Schlüsselschalter oder per Sender aus dem Führerstand; Bahnpersonal physisch vor Ort)
    • ferngesteuert (aus einem Stellwerk, z.B. durch Fahrdienstleiter)
    • automatisch (durch Gleiskontakte)
  • Tag für Art der Sicherung
    • durch Signal Bü0/Bü1
    • durch Fahrdienstleiter (bei Fü-Anlagen)
    • Deckung durch Hauptsignal
    • Sollte man das mit einer Relation abbilden, die Signal und Bü enthält
      --Nakaner (talk) 09:00, 28 September 2014 (UTC)
  • Relation, die alles, was zu einem Bü gehört zusammenfasst
    • vor allem für Bahnübergänge an mehrgleisigen Strecken oder Bahnübergänge mit als separate Ways gemappte Bürgersteige/Radwege
    • kann Bü0/Bü1-Signale bzw. Hauptsignale aufnehmen, die diesen Bü decken
    • kann Einschaltstrecken, Achszähler, Steuerungshäusen mit aufnehmen
      --Nakaner (talk) 09:00, 28 September 2014 (UTC)
  • Automatik HET, etc. (sowohl die Tafeln als auch die Art der Einschaltung)
  • Tag für Schließzeiten (durchschnittliche Schließzeit und Standardabweichung)
    • wichtig für's Routing (normal und mit dem Ziel einen Zug noch zu erreichen), insbesondere, wenn Bahnsteige nur über Büs erreichbar sind, die durch entfernt liegende Signale gesichert sind und fünf Minuten Schließzeit haben
    • Vorschlag: railway:level_crossing:closure:average=Zeit in Minuten, railway:level_crossing:closure:rms=Standardabweichung S in Minuten mit
      S-square.pngRoot mean square.png --Nakaner (talk) 10:14, 21 October 2014 (UTC)
    • Wir brauchen dieses Tag. 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 km/h (mehr ist auf Bahnübergängen in Deutschland 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). --Nakaner (talk) 10:26, 21 October 2014 (UTC)
    • 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.

Signale

  • railway:signal:direction=* als Winkel statt forward/backward/both? Falls ja: Die Richtung in die das Fahrzeug fährt oder in die das Signal "schaut"? (aus dem JOSM-Ticket)
    • Erfassung als Winkel ist meiner Meinung (zumindest für Bahnsignale) sinnlos: Der Winkel ergibt sich ja aus dem Way, auf dem das Signal gemappt ist, und der Wegrichtung. Würde man den Winkel erfassen, wäre es außerdem umständlich, die Anzeigerichtung eines Signals zu ermitteln, etwa bei Routinganwendungen oder für Validatoren --rurseekatze (talk) 13:16, 9 September 2014 (UTC)
  • Tagging diverser nicht-EBO-Signale
    • Hp 3 bei der KVB
    • Straßenbahn-/Stadtbahn-/U-Bahn-Signale
    • Wie wären Taggings wie railway:signal:<Funktion>:<Land>:<Betrieb>:<Signalkürzel>, also bspw. für ein "Hauptsignal" der HHA (Hochbahn Hamburg): railway:signal:main:DE:HHA ? Das wäre recht ähnlich zu dem bisherigen. --User:bjoern_m 14 October 2014.
      • Auf dem letzten Treffen haben wir uns schon für railway:signal:<Funktion>=<LAND>-<Regelwerk oder Gesellschaft>:<Signalkürzel> entschieden. Siehe auch das Protokoll. Bei diesem TOP geht es nur um das Festlegen von Values für die zusätzlichen Signale bei der KVB, für BOStrab-Strecken bundesweit usw. --Nakaner (talk) 12:44, 14 October 2014 (UTC)
  • Signale des Zugleitbetriebs
    • Signalhaltmelder (Drehscheibe-Diskussion, Ril (Seite 32))
    • Überwachungsmelder für technisch unterstützten Zugleitbetrieb (TUZ) nach KoRil 436 (Haltetafeln mit blauem Zusatzlicht und Indusi-Magnet)
  • ETCS Features
    • Balisen
    • Signale
  • Richtungspfeile an Fahrleitungssignalen und Geschwidigkeitssignalen
    • Vorschlag: railway:signal:turn_direction=left/right/<winkel in grad> --Nakaner (talk) 16:11, 21 September 2014 (UTC)
  • Dunkelschaltung von Signalen
    • Wir wollen dafür ein Tag einführen (beschlossen auf dem letzten Treffen), suchen aber noch nach einem passenden Begriff
    • Vorschläge: railway:signal:*:disablement=dark, railway:signal:*:disablement=Kennlicht, railway:signal:*:disablement=yes
    • Damit wäre man nicht mehr auf eine bestimmte Art des Abschaltens festgelegt
  • Zugdeckungssignale (z.B. in Köln Hbf) Bild
  • Das Signal Gsp 2 (Gleissperrsignal aufgehoben) heißt seit 14.12.2008 Wn7. Bestehende Sh1 an Gleissperren sind bis 10.12.2028 durch Wn7 zu ersetzen. (Quelle: Bekanntgabe 1 zur Ril 301 vom 17.12.2007, gültig ab 14.12.2008) Wir sollten Wn7 ins Taggingschema und die JOSM-Vorlagen aufnehmen und ein Umtaggen bestehender Gsp 2 erwägen. --Nakaner (talk) 14:47, 19 October 2014 (UTC)

Sonstiges

  • 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"?
  • Tagging von Kilometersprüngen, Überlängen, Fehllängen
  • Firmen mit Gleisanschluss
    • sollten auf einer Eisenbahnkarte besonders hervorgehoben werden
    • Varianten:
      • name-Tag am Anschlussgleis: railway=rail, service=spur, name=Sägewerk Musterstadt; keine Möglichkeit, den Firmennamen in der Mitte des Werksgeländes zu positionieren
      • zusätzliches Tag am Firmenobjekt, z.B. railway=factory oder railway_link=yes; einfaches Rendering
      • Ermittlung über geographische Abfragen (Gleise innerhalb einer Fläche mit landuse=industrial, man_made=works, etc.; aufwendiger zu berechnen, schwierige Vollständigkeitskontrolle, liefert nicht immer die richtigen Ergebnisse
  • 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)
    • Ich gebe die Quelle der Daten meist im Changeset an, z.B. source=survey;Bing, meiner Meinung ist das ausreichend. Eher uninteressant finde ich die Art der Erhebung (Befahrung, Ortsbegehung, ...). Generell erwarte ich, dass Informationen mit der höchst möglichen Genauigkeit eingetragen werden (GPS-Genauigkeit, Luftbildversatz, etc.), dann sind zusätzliche Lageinformationen meiner Meinung nicht nötig. Nur wenn grob geschätzt wurde und eine genaue Einteilung nicht möglich ist, sollte ein Hinweis mit note=* oder fixme=* gesetzt werden. --rurseekatze (talk) 22:14, 14 September 2014 (UTC)
  • Stellwerksrelationen/Stellbereichsrelationen: lieber railway=interlocking statt railway=controlled_area?
  • Diverse Einrichtungen in Betriebswerken/Abstellgruppen: WC-Entsorgungsanlage, Wasserfüllanlage, Druckluftständer, Elektrant, Innenreinigungsanlage, Zugvorheizung, Besandungsanlage, etc.
  • Heißläuferortungsanlagen
  • Tagging umgenutzter Bahnhofsgebäude mit historic=railway_station (in Anlehnung an das Schema der Historische-Objekte-Karte)?
  • Stationen mit Infrastruktur für Bedarfshalte, d.h. der potentielle Fahrgast muss irgendwo einen Knopf drücken, damit ein Signal für den Lokführer aufleuchtet. --Streckensucher (talk) 19:50, 24 October 2014 (UTC)

Mechanical Edits

  • Mechanical Edit zur Umstellung des Mirko-Küster-Schemas auf das ORM-Schema
    • Tag-Entsprechungsliste zusammenstellen
  • Mechanical Edit zur Umstellung des ORM-Signaltaggings ins internationale System mit Präfixen (DE-ESO:hp statt hp)

Öffentlichkeitsarbeit

  • Entwurf eines Logos
    • Logowettbewerb wie JOSM ausloben? --Nakaner (talk) 17:21, 14 October 2014 (UTC)
    • Was für ein Logo wollen wir? Soll es Ähnlichkeiten/Andeutungen zum OSM-Logo haben (z.B. eine Lupe mit gleicher Richtung wie OSM oder eine gefaltete Karte)? --Nakaner (talk) 17:21, 14 October 2014 (UTC)
      • Meiner Meinung sollte sich das Logo am OSM-Logo orientieren, allerdings durch einen "Eisenbahn-Aspekt" (Schienenprofil, Gleisstück, Signal, Rad, Lok, etc.) ergänzt werden, ähnlich wie auch das Logo der OpenSeaMap. --rurseekatze (talk) 16:00, 16 October 2014 (UTC)
      • Vorschlag fürs Logo: OSM-Logo, aber statt der roten Grenze eine schwarz-weiß schraffierte Eisenbahnlinie (ist diese Signatur international üblich?), natürlich nicht so zackig, sondern abgerundete Kurven. Und durch die Lupe blickt man auf ein Schienenprofil. --Streckensucher (talk) 19:35, 24 October 2014 (UTC)
  • Entwurf eines Flyers
    • Geht erst wenn wir ein Logo haben --Nakaner (talk) 17:21, 14 October 2014 (UTC)
  • Vortrag auf der FOSSGIS
    • Wer?
    • Worüber? Mehr Technik oder mehr das Mappen oder ein Vortrag der Kategorie "Neues von <Projekt>"? --Nakaner (talk) 17:22, 14 October 2014 (UTC)
  • Ergebnisse auf Diskussionsseiten im Wiki dokumentieren - einige Fragen wurden dort schon vor längerer Zeit aufgeworfen, wir sollten unsere Ergebnisse dort erwähnen
  • Die Änderungen in [1] durchgehen und schauen, was wir reverten sollten und was brauchbar ist. --rurseekatze (talk) 21:27, 23 October 2014 (UTC)

Hacking

  • Signal- und Sicherungslayer verbessern
    • Wären generell Veränderungen hin zu "typischen" Symbolen aus Signallageplänen besser geeignet? Insbesondere für die Richtung/Position von Hauptsignalen und Entsprechungen sind die sicherlich übersichtlicher, auch Zusatzsignale könnten platzsparend integriert werden. --User:bjoern_m 14 October 2014.
      • Bitte via Github melden. --Nakaner (talk) 12:47, 14 October 2014 (UTC)
      • Auf jeden Fall sollten die Icons nicht zu kompliziert sein, denn dann werden sie schlecht erkennbar und die Karte unübersichtlich. Die Signalsymbole der Gleispläne könnte man in dieser Hinsicht durchaus als Anregung nehmen. Allerdings sind die am Vorbild orientierten, bildlichen Symbole auch sofort für Leute lesbar, die mit den intern verwendeten Symbolen nicht so vertraut sind. --rurseekatze (talk) 15:55, 16 October 2014 (UTC)
        • Eventuell umschaltbar? Mit den Gleisplansymbolen lässt sich mEn mehr erkennbar machen als mit Zeichnungen im momentanen Stil. Ein Nachteil wäre, dass sie vermutlich landesspezifisch sind? --rayquaza (talk) 13:07, 17 October 2014 (UTC)
        • Ein umschaltbarer Style wäre nur beim Einsatz von clientseitigem Rendering sinnvoll. --rurseekatze (talk) 21:39, 17 October 2014 (UTC)
    • Suchmöglichkeiten nach den Ril 100-Bezeichnungen wären für "Insider" schneller. --User:bjoern_m 14 October 2014.
      • gibt's schon --Nakaner (talk) 12:47, 14 October 2014 (UTC)
    • Stellwerke scheinen noch recht schwierig in der Anzeige zu sein; ggf. in geringerer Zoom-Stufe nur die Abkürzung? --User:bjoern_m 14 October 2014.
      • Ja, das Rendering der Stellwerke muss noch überarbeitet werden. Da müsste man etwas mit der optimalen Darstellung experimentieren. --rurseekatze (talk) 15:50, 16 October 2014 (UTC)
  • Dokumentation und Übersetzung
  • JOSM Validator um weitere Regeln ergänzen

Protokoll

Das Protokoll zum OpenRailwayMap-Treffen wird in einem Etherpad geführt. Im Folgenden eine hierher übertragene und besser lesbare Variante des Protokolls.

Freitag, der 24. Oktober 2014

Gleise

  • Feste Fahrbahn, Tagging des Oberbaus
    • Wir sehen derzeit noch keinen Bedarf. Wer Bedarf sieht oder hat, soll ein Tag erfinden und das auf der Mailingliste zur Diskussion stellen.
    • Es fehlen noch genug maxspeed-Tags in der Datenbank.
  • Tunnelrelationen/zweiröhrige Tunnel
    • Tunnel sollten wie auch bei Straßen erfasst werden, also mit Tunnelrelationen
    • Tunnelrelationen sind bereits im Taggingschema erwähnt
  • light rail
    • ist das, was weder Eisenbahn noch Straßenbahn ist
    • nur Personenverkehr
    • Verknüpfung innerstädtischer Bereiche mit dem Umland
    • einfachere Bauweise als Eisenbahnen, aber höuboherer Standard gegenüber Straßenbahnen
    • fährt weitgehend getrennt vom Straßenverkehr, daher gesicherte Bahnübergänge
    • Hochflurigkeit sollte kein Kriterium sein, sonst ist die RNV im Rhein-Neckar-Raum keine light_rail
    • light rail fährt Überland in umliegende Orte, subway/tram innerstädtisch
    • etwas Unschärfe werden wir immer haben
    • tram hat Bushaltestellen-ähnliche Haltstellen, light rail hat ausgebaute Stationen
    • zusammenhängende Netze sollten einheitlich getaggt sein (z.B. Freiburg sollte tram bleiben, auch wenn die Strecke nach Güntersthal eher light rail ist)
    • Kriterienliste:
      • eigener Gleiskörper für light rail und gegen tram
      • Hochflurigkeit für light rail und gegen tram
      • unterirdische Strecken eher für light rail und gegen tram
      • Hochbahnen für light rail und gegen tram
      • Betrieb nach Eisenbahnrecht für light rail und gegen tram
      • Ausbau der Haltestellen eher die Trennung von Gleis und Fahrgast fördernd: für light rail und gegen tram
      • Stromschienen neben dem Gleis sind ein Argument für light rail
      • Das Bestehen von Verbindungen zur Vollbahn sind kein Kriterium.
      • light rails haben geringere/schwächere Zugsicherungsysteme als Vollbahnen
      • Straßenbahnen fahren auf Sicht, light_rail nach Signalen -> daher kommt Fahrerloser Betrieb nahezu auschließlich bei light_rail und nicht bei tram und rail vor
      • light_rails fahren mit höheren Geschwindigkeiten als Straßenbahnen (da getrennt vom Individualverkehr, aufwändigere Sicherungstechnik und Fahren nach Signalen)
      • Subway verkehrt überwiegend unterirdisch und in den oberirdischen Teilen vom übrigen Verkehr getrennt und (nahezu) frei von Bahnübergängen.
  • Museumsbahnen
    • Wir nehmen den Vorschlag von Alex aus der Tagesordnung an.
  • railway=narrow_gauge
    • Das Tag ist sehr verbreitet. Für eine grobe, einfache Unterscheidung zwischen der Normalspurweite eines Landes und der aus dortiger Sicht schmäleren Spur ist es nützlich.
    • Wir meinen nach einer Diskussion, dass "narrow_gauge" ein veraltetes Synonym für rail ist. Umtaggen nützt nämlich nichts. Anwendungen könnten railway=narrow_gauge einfach genau wie railway=rail behandeln und gauge=* als Entscheidungshilfe verwenden
  • Gleisverschlingung
    • Wir verzichten auf Relationen für dieses Mapping und empfehlen das Tagrailway:interlaced=yes an alle betroffenen Gleise zu hängen und diese einzeln zu mappen.
    • Erst wenn es erste Routinganwendungen gibt, wird man die Auswertbarkeit dieser Informationen besser beurteilen können
  • Begegnungsverbote wegen mangelndem Gleisabstand
  • Entgleisweichen als Bauform von Gleissperren. Also railway=derail.
    • zusätzlich sollten wir ein Tag (railway:derail=Bauform?) einführen, was die Bauform der Gleissperre beschreibt, z.B. die typische deutsche Bauform mit einem Klotz auf dem Gleis (wedge), eine weichenähnliche Bauform wie vor allem in UK anzutreffen (???) oder ein Schutz gegen Befahren in falscher Richtung (???)
    • das Tag ist flexibel um weitere Values erweiterbar, sodass wir uns jetzt noch nicht Gedanken zu allen möglichen Bauformen machen müssen

Samstag, der 25. Oktober 2014

Gleise

  • Industriegleise
    • Zur Unterscheidung von Nebengleisen von Industriebahnen gegenüber normalen Nebengleisen erlauben wir service=* + usage=industrial.
  • working_rules
  • Zur Streckenklasse: Einerseits ist es möglicherweise doch International, andererseits kann man zusätzlich auch angeben:
    • Meterlast: meter_load=<zulässige Meterlast in Tonnen/Meter>
      • weight_per_metre könnte auch das Gewicht der Schiene bezeichnen, daher besser meter_load
    • Achslast: axle_load=<zulässige Achslast in Tonnen>
    • wir behalten das Tag railway:track_class=* bei, Meter- und Achslast können zusätzlich getaggt werden
  • Geschwindigkeit für verschiedene Fahrzeugtypen
    • Ansatz 1: Wir taggen die höchste Höchstgeschwindigkeit als maxspeed=* und alle anderen als maxspeed:<Variante>=*
    • Ansatz 2: Wir taggen die Höchstgeschwindigkeit für "normale Eisenbahnfahrzeuge" als maxspeed=* und Abweichungen als maxspeed:<Sonderform>=*
      • wenn eine Strecke als Vollbahn eingetragen ist, dann erwarte ich, dass maxspeed=* die Geschwindigkeit für die Vollbahnfahrzeuge angibt; andere Fahrzeugtypen sind dann Ausnahmen und sollten mit maxspeed:<Sonderform>=* erfasst werden
      • Problem: Was ist "normal"? LZB? Neigtechnik? Wirbelstrombremse? Wankkompensation?

Stromversorgung

  • Oberleitungsmasten
    • Mappt man, wenn man eine Speiseleitung mappt, die auf Oberleitungsmasten mitgeführt wird. power=pole und power=tower wäre für Oberleitungsmasten unangebracht. Ohne Tag würden diese Nodes bald von KeepRight-Nutzern falsch getaggt werden.
    • Nicht railway, da es Oberleitungsmasten auch bei Schiffen und Bussen gibt.
    • Wir verwenden stattdessen power=catenary_mast.
  • Einspeisung aus der Speiseleitung
  • Aufhängearten der Speiseleitung: vertagt
  • Überbrückbarkeit von Trennstellen per Schalter
  • Tagging von Schutzstrecken
  • versenkte Mittelstromschiene

Betriebsstellen

  • manuell bediente Streckenblöcke und Schrankenwärterposten
    • Manuell bediente Streckenblöcke tragen wir als Stellwerke ein. Anhand der Bezeichnung kann man sie unterscheiden.
    • Schrankenwärterposten als railway=crossing_box
  • Blockstellen
    • Deckungsstellen erfassen wir nicht getrennt, da das etwas typisch Deutsches zu sein scheint
    • wir führen das Tag railway=blockpost ein
  • Anschlussstellen und Ausweichanschlussstellen
    • Wir bezweifeln, dass es im Ausland auch diesen Unterschied gibt.
    • Wir taggen alle Anschlussstellen mit railway=spur_junction. Ein weiteres Tag soll dann zwischen Anst und Awanst unterscheiden.
  • Besetzungszeiten von Betriebsstellen
  • Macht es Sinn, bei Stellwerken Hektometer und Meterwert separat abzufragen?
    • Wir wissen nicht, was die Motivation hinter diesem Antrag ist. Man kann durch einen einfachen regulären Ausdruck, Kilometer und Meterwert trennen. Reiche doch einfach ein Pull-Request für die JOSM-Objektvorlage ein, damit das geschieht.
  • Unterscheidung von U-Bahnhöfen, light_rail-Bahnhöfen und richtigen Bahnhöfen
    • Das über Relation abzubilden ist umständlich.
    • Betreibsstellen-Nodes müssen nicht im Gleis-Way enthalten sein. Daher ist eine Unterscheidung anhand des Gleises, auf dem der Node liegt, nicht möglich.
    • Wir werden in einem größeren Kreis (Forum, große Mailinglisten) die Einführung des Tags railway=subway_station analog zu railway=tram_stop anregen. Man muss dann halt Mapnik auch zeitnah patchen, bevor dumme Für-den-Renderer-Mapper einen Editwar anfangen wollen.
    • ein unterschiedliches Tagging ist notwendig, um eine unterschiedliche Darstellung auf Karte zu ermöglichen
    • Vollbahnhöfe sollten von U- und Stadtbahnhöfen unterscheidbar sein
  • Bahnhöfe, die eigentlich mehrere Bahnhöfe sind
    • In Berlin scheint es zu funktionieren, dass Bahnhöfe, die aus mehrere Betriebsstellen bestehen, als mehrere Nodes eingetragen sind. stop_area-Relationen verbinden dann die beteiligten Betriebsstellen, um die Umsteigemöglichkeit zu verdeutlichen
    • Bahnhofsteile werden als eigenständige Bahnhöfe eingetragen und durch Betriebsstellen-Relationen an ihren Mutterbahnhof "gekuppelt". Somit ist Köln Betriebsbahnhof railway=service_station und Köln Messe/Deutz (S-Bahn) ein railway=halt.
    • Zu Berlin Wuhletal:
      • Hier sollte man zwei Nodes machen. Einen "S Wuhletal" einen "U Wuhletal". Bei Bahnhöfe, wo in einer anderen Ebene die U-Bahn fährt, würde man das auch so machen.
    • Zu Königs Wusterhausen
      • S-Bahn kreuzt dort die Vollbahn. Sind das zur Zeit überhaupt getrennte Betriebsstellen oder macht das ein Fahrdienstleiter?
  • railway=stop und wie man Betriebsstellen, für Routenberechnungen zugänglich macht
    • Dieses Tag sorgt auf Nodes dafür, dass Router, die eine Route von A nach D berechnen, auch die durchfahrenen Betriebsstellen B und C kennen lernen.
    • wird getaggt auf:
      • bei Bahnhöfen und Haltepunkten (egal ob mit Personenverkehr oder ohne) je einen Node je durchgehendes Hauptgleis und zusätzlich je einen Node für jedes Gleis mit Bahnsteig
      • je ein Node je Gleis kurz vor (bei Fahrt zur Abzweigung hin) der verzweigenden Weiche auf Abzweigungen
      • ebenso bei Anst und Awanst
      • je ein Node je Gleis kurz vor der Überleitstelle bei Überleitstellen
      • bei Blockstellen und Deckungsstellen auf das Gleis
    • Auch wenn der Node mit public_transport=stop_position getaggt ist, wird um ein Taggen mit railway=stop gebeten. Dann müssen Güterzugrouter nicht noch public_transport=* filtern.
  • Bahnsteige mit verschiedenen Oberflächen
    • Beispiel Trier Quint OSM-Karte
    • Wenn es als Fläche erfasst wird, macht man einfach zwei aneinander angrenzende Flächen
  • Ausländische Betriebsstellenkürzel
    • Wie bei name=* machen. railway:ref=<Kürzel> für das Kürzel, das der Betreiber der Betriebsstelle vergibt. [[Key:|]]=[[Tag:=railway:ref:<Unternehmenskürzel|railway:ref:<Unternehmenskürzel]].
    • Für Grenzbahnhöfe, bei denen beide Betreiber gleichwertig sind (z.B. Bahnhof Brenner), muss man auf die südtiroler Lösung railway:ref=<Kürzel1>/<Kürzel2> zurückgreifen.
  • Tag für "Betriebshof" (Tram und Bw-Gelände)
    • Wurde durch Kommentaren in der Tagesordnng schon gelöst
  • Verfeinerung der Definition, welche Ausdehnung die Fläche einer Betriebsstelle (landuse=railway, Mitglied in Betriebsstellenrelation) haben sollte
    • alles, was zur Betriebsstelle gehört, sollte innerhalb der Fläche liegen
  • Grenzpunkte (railway=owner_change)
  • Tagging der Bahnsteigabschnitte
    • Wenn man nur den Standort des Schilds kennt und nicht, wie weit es gilt, dann sollte man das Schild als Node mappen, ansonsten die Bahnsteigkante aufsplitten und an den Way taggen.
    • railway:platform:section=A/B/C oder Nord/Süd

Bahnübergänge

Signale

  • railway:signal:direction=* als Winkel statt forward/backward/both
    • Zu diesem Thema gibt es nichts zu sagen. Es gibt keinen Diskussionsbedarf.

Sonntag, der 26. Oktober 2014

Signale

Sonstiges

  • Vereinheitlichung der Betreiber:
    • Geschäftsform weglassen. Die ändert sich nämlich schnell mal.
    • Ob wir den Konzern (Deutsche Bahn) oder die Töchter (DB Netz, DB Station & Service) in operator=* eintragen, sollten wir in einer größeren Diskussion entscheiden.
  • Tagging von Kilometersprüngen, Überlängen, Fehllängen
    • als Node auf die Hauptgleise mit missing_length=<Wert in Metern>
    • Fehllängen kann es auch bei Flüssen und Straßen geben. Man könnte mal schauen, ob es dort solche Tags gibt.
  • Gleisanschlüsse
    • landuse ist oft nicht gut genug gemappt und eignet sich daher nicht für is_in-Abfragen
    • Die Gleisanschlüsse (die Gleise selbst) mit name=Gleisanschluss Raiffeisen zu taggen, halten wir für falsch, da das kein Eigenname ist.
    • Wir empfehlen, die Eigenschaft, das ein Unternehmen einen Gleisanschluss hat mit railway_link=yes an das Objekt zu taggen, das die Firma repräsentiert.
  • Müssen Informationen zur Erfassung immer in note=* abgelegt werden
    • Bleibt dem Mapper überlassen: Hierzu gibt es nichts zu sagen. Bei OSM müssen die Quellenangaben nicht so super detailliert und perfektionistisch sein wie bei Wikipedia.
  • Stellwerksrelationen/Stellbereichsrelationen
    • Wir stimmen der Änderung zu.

Rückblick

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

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