DE talk:OpenRailwayMap

Einige Anmerkungen

Hallo, ich erlaube mir mal ein paar Anmerkungen:

• Was ist der Hintergedanke hinter usage=highspeed? Der Tag taucht bisher überhaupt nicht in der Datenbank auf. Auch finde ich den angegeben Schwellenwert zu niedrig. In NRW fahren ja schon die meisten RE und einige RB schneller als 150 km/h. International ist Hochgeschwindigkeitsverkehr als Bahnverkehr mit >= 200 km/h definiert.
• Da es in der Datenbank einige tausen Einträge mit maxspeed-Werten von 140 km/h und höher gibt, ist maxspeed wohl auch an Eisenbahnstrecken verbreitet. Das wäre doch was zum Auswerten.
• Neben etcs=* könnte man auch noch lzb=* auswerten: taginfo

Ansonsten wäre ich gern bereit zu helfen, aber ich habe keine Ahnung von Mapnik (nur etwas von Maperitive). --ABRob 05:15, 7 October 2011 (BST)

Die übliche, aber glaube ich nicht offizielle, Definition war wenn die üblichen Sicherungsanlagen nicht mehr reichen (PZB, etc.) und somit war es "über 160 km/h". Aufgrund der wachsenden Geschwindigkeit ist jetzt wie du bereits geschrieben hast >=200km/h üblich.

Die meisten Karten haben dann noch eine Unterteilung ob >=200 oder >=250 (teilweise schon eine eigene Farbe für >300).

Auch stoße ich mich an der Definition, dass sie zweigleisig und elektifiziert sein müssen.--Jimmy K 08:51, 10 October 2011 (BST)

Hallo,

• usage=highspeed habe ich selbst erfunden, generell ist die gesamte Seite ein von mir entwickeltes Taggingschema für eine Bahnkarte und bei weitem noch nicht ausgereift; Geschwindigkeit und Ausbauzustand hängen natürlich stark vom jeweiligen Land ab: was hier eine Nebenstrecke ist, ist in Afrika vielleicht schon eine Hauptverbindung; daher habe ich willkürlich die genannten Merkmale gewählt; wichtig war mir auch, dass Mapper, die keine Kenntnisse in Richtung Eisenbahn haben, eine Strecke damit in eine Kategorie einordnen können; die Beschreibung könnte man also noch etwas verfeinern oder auf bestimmte Länder beziehen
• lzb=* habe ich noch hinzugefügt

• meine Planungen habe ich etwas geändert: statt mit Mapnik will ich die Karte nun dynamisch mit OpenLayers bauen. Das hat mehrere Vorteile: zum einen braucht man weniger Speicherplatz als bei den vielen Tiles, außerdem braucht man keinen aufwendigen Renderprozess und es lassen sich z.B. mit Popups zusätzliche Informationen einblenden; vielleicht kannst du da helfen, wenn du Lust hast?

• ich habe das Projekt auch noch umbenannt, damit der Name international verständlich ist...

--Rurseekatze 22:18, 5 December 2011 (BST)

Hallo, eventuell wärs besser, für die Namen der Tags Eisenbahnbezug herzustellen, also z.B. railway:ects=yes. Ich kenn das von der Arbeit an der DE:OpenFireMap sowie aus anderen Bereichen und halte es für sinnvoll. --Marqqs 17:23, 6 December 2011 (UTC)

Ich habe die Tags ein wenig angepasst - passt es jetzt? --Rurseekatze 19:05, 6 December 2011 (BST)

Hey, das war nur ein Vorschlag, ich kann und will das nicht alleine entscheiden. :-) Ich halte es halt für besser, wenn Tags, die in anderen Bereichen praktisch nicht verwendet werden können, ein entsprechendes Präfix erhalten. --Marqqs 18:14, 6 December 2011 (UTC)

Ich wollte ja nur wissen, ob du noch weitere Verbesserungsmöglichkeiten siehst ;) Der Vorschlag hatte auch seine Berechtigung, denn "etcs" oder "signal" kann auch außerhalb von Eisenbahnen verwendet werden, ist also tatsächlich nicht ganz eindeutig. (bei "name" macht es natürlich keinen Sinn mehr) Ich denke, dass es jetzt keine Überschneidungen mit anderen Bereichen mehr geben sollte. --Rurseekatze 20:23, 6 December 2011 (UTC)

Ich bin da einfach nicht so sicher und gespannt auf eine dritte Meinung. :-) Was mir grad noch aufgefallen ist: "railway:signal:main:form=semaphore" ist schon eine arg umständliche Konstruktion. Wahrscheinlich verwendest du sie, um EINEM Knoten mehrere Signaltypen zuordnen zu können. Bin mir nicht sicher, ob das der richtige Weg ist. Alternative wären zwei Knoten, ggf. an der gleichen Position (im Fall von kombinierten Signalen). Per "type=main" kann man dann den Typ entsprechend eintragen. Aber auch hier: nur ein Gedanke, ich weiß nicht, was letztlich besser ist. :-) --Marqqs 20:12, 6 December 2011 (UTC)

Ja, das Tag ist dann schon sehr lang, aber ich hatte wegen des komplizierten Taggings sowieso schon vor, ein JOSM-Preset zu erstellen. Damit wäre das Problem zu einem Teil beseitigt. Mehrere Punkte an einer Stelle ist kompliziert handzuhaben und dazu im Grunde falsch. Wenn mehrere Signale an einem Mast sind, dann sollte dieser Mast auch durch einen Punkt repräsentiert werden. --Rurseekatze 22:18, 6 December 2011 (UTC)

Der aus meiner Sicht korrekte Weg, ein kombiniertes Signal zu taggen, wäre dieser: einen Punkt eintragen und für diesen dann zwei Relationen definieren, z.B. eine Relation für das Hauptsignal, eine zweite für das Vorsignal. --Marqqs 21:23, 6 December 2011 (UTC)

Relationen bei einem einzigen Punkt? Das macht es doch nur unnötig kompliziert. Die Auswertung ist mit Relationen ebenfalls schwieriger. Dann lieber komplexe Tags. --Rurseekatze 23:18, 6 December 2011 (UTC)

Fahrplankarte

Hallo, aus den so gesammelten Daten müsste sich doch eine Fahrplankarte automatisch erstellen lassen. Ich finde die Fahrplankarte des VCD genial. Sie entstand zum Großteil in Handarbeit und wurde zum letzten Mal 2004 aufgelegt. Wegen des großen Aufwands gab es seither keine Aktualisierung. Vielleicht können wir hier einspringen? rurseekatze, kennst du diese Karte? Wenn nicht, mail mich einfach mal an. --Marqqs 14:29, 7 December 2011 (UTC)

Nein, die Karte kannte ich noch nicht. Du musst mir mal genauer erklären, was die Karte darstellt. --Rurseekatze 14:29, 7 December 2011 (UTC)

Hab dir grad eine Mail geschickt. Mit der Kommentar-Signatur ist grad was durcheinandergelaufen. Erstellst du die von Hand? Ich nehm dafür immer --~~~~ (siehe WP:SIG). --Marqqs 21:19, 7 December 2011 (UTC)

Danke, die Funktion kannte ich noch nicht... ;) --rurseekatze 21:43, 7 December 2011 (UTC)

service=*

Ein Tag vermisse ich: mit service=yard/siding/spur kann die Verwendung einer Strecke beschrieben werden. Dieses Tag wird auch schon fleissig verwendet (75829 x spur, 56107 x yard, 32795 x siding). --Mdk 11:24, 11 December 2011 (UTC)

Die Tags sind mir bekannt, aber ich bin noch nicht dazu gekommen, sie in das Taggingschema einzufügen. ;) --rurseekatze 11:45, 11 December 2011 (UTC)

rack (Zahnradbahn)

Es gibt schon den etablierten Tag rack=yes/no. Warum jetzt den neuen Tag railway:rack_rail=* erfinden? --Geogast 13:18, 12 December 2011 (UTC)

Mir war nicht bekannt, dass das Tag schon existiert. Danke für den Hinweis. Ich tendiere zwar eher zu railway:rack_rail=*, da man dort besser sieht, dass es sich um ein eisenbahnspezifizisches Tag handelt, aber da es schon relativ häufig verwendet wird, ändere ich es. --rurseekatze 19:46, 12 December 2011 (UTC)

Ich seh grade: Dasselbe betrifft im Prinzip auch railway:structure_gauge=*. Das gibt es schon als structure_gauge=* bzw. loading_gauge=* (Ich versteh da den Unterschied nicht.) --Geogast 12:00, 15 December 2011 (UTC)

structure_gauge = Lichtraum (in dem keine Bauten hineinragen dürfen); loading_gauge= Fahrzeugbegrenzungslinie. Die W kommen aus Großbritanien, Groß- und Kleinprofil aus dem U-Bahnbereich; GA,GB,GC von der UIC; G1 und G2 urspürnglich aus Deuschtland. Das UIC Profil ist irgendwie beides, müsste man somit gleich auswerten. Ein bildlicher Link dazu (Clearence ist structure_gauge): http://www.gritton.org/greg/rail/docs/clearance/AAR_plates_with_UIC.gif --Jimmy K 18:59, 29 December 2011 (UTC)

Und ebenso gibt es bereits traction=rack/cable beim Oxomoa-Schema. --EvanE 16:29, 15 December 2011 (UTC)

Da rack=* etwas sehr Eisenbahn-spezifisches ist, sollte eher railway:rack=* verwendet werden. Damit ist auch für den nicht Eingeweihten klar, dass es sich um einen Tagg für die Eisenbahn handelt, um den er/sie sich nicht kümmern muss. Zahnstangen kommen schließlich auch bei anderen rtechnischen Systemen vor.
Bei den verschiedenen Zahnstangensystemen sollte man einen kurzen Hinweis auf die Unterschiede geben.
Bei rack=no steht noch ein falscher Text. Das sollte man zun Standardwert erklären, wenn keine Angabe zu (railway:)rack gemacht wird.
--EvanE 00:56, 17 December 2011 (UTC)

Ich habe es nach railway:rack=* geändert. traction=rack/cable ist mir zu wenig eindeutig, sowohl im Bezug auf das verwendete System als auch im Bezug auf das Thema Eisenbahn. Den Text zu railway:rack=no habe ich geändert. --rurseekatze 15:46, 30 December 2011 (UTC)

Weichen: Radien und zulässige Geschwindigkeiten

Bei Weichen sollten noch Tags für Radien und zulässige Geschwindigkeiten eingebaut werden. --Bigbug21 16:02, 12 December 2011 (UTC)

Radius könnte ich einbauen, aber wird die zulässige Geschwindigkeit nicht schon durch die maxspeed-Tags der Gleis vor und hinter der Weiche begrenzt? --rurseekatze 19:46, 12 December 2011 (UTC)

Nein, leider nicht. In Bahnhöfen wird die zulässige Geschwindigkeit vielfach durch abzweigend stehende Weichen bestimmt. --Bigbug21 12:10, 14 December 2011 (UTC)

Welches Tag schlägst du vor? maxspeed:straight=* und maxspeed:left/right=*? --rurseekatze 16:49, 14 December 2011 (UTC)

Aus dem technischen Englisch wäre es eher: "maxspeed:straight=*" und "maxspeed:diverging=*" --Jimmy K 15:51, 16 December 2011 (UTC)

OK, habe es geändert. --rurseekatze 21:45, 16 December 2011 (UTC)

Der Radius ist eine Eigenschaft des Gleises nicht einer Weiche. Damit gehört railway:radius an das Gleis und nicht an den Punkt der mit railway=switch gekennzeichnet ist. Es gibt auch keinen Grund Radius auf Weichen zu begrenzen. Es gibt schließlich auch Kurven.
Man könnte sich auch überlegen direkt radius=* zu verwenden, was mit width=*, length=* und height=* gut zusammenpassen würde. Radius ist eine an vielen Stellen nützliche Eigenschaft, die auch keine Missverständnisse auslöst, wenn sie in einem anderen Zusammenhang verwendet wird.

Ähnlich verhält es sich mit railway:maxspeed:*. Auch das ist eine Eigenschaft des Gleises nicht eines Punktes. Darüber hinaus ist bei den OSM-Wegen der Begriff straight nicht eindeutig. Insbesondere wenn am Weichenpunkt drei OSM-Wege beginnen/enden. Bei einer Y-Weiche gibt es nicht einmal in der Realität ein Geradeaus. --EvanE 00:04, 17 December 2011 (UTC)

"straight" und "geradeaus" sind keine geometrischen Vorgaben sondern von der Infrastruktur definiert. Bei Bogenweichen ist es üblicherweise das Gleis mit dem gerineren Bogenradius, in manchen Fällen ist es auch das stärker befahrene Gleis. Vielleicht etwas verwirrend, nur hat es sich so durchgesetzt. --Jimmy K 19:09, 29 December 2011 (UTC)

Weichen Bezeichnung

Im Abschnitt Weichen wird eine Doppelte Kreuzungsweiche wie folgt definiert.

Key	Value	Element	Objekt	Beschreibung	Standardwert
railway:switch	double_crossover		Doppelkreuzungsweiche	Doppelkreuzungsweiche: Eine Weiche, die eine Kombination aus Kreuzung und Weiche ist

Das ist allerdings die Übernahme eines Fehlers aus Proposed_features/detailed_Railway_Network.
Ein double_crossover ist ein doppelter Gleiswechsel bei parallen Gleisen, ein einfacher Gleiswechsel heißt schlicht crossover.
Eine Doppelte Kreuzungsweiche wird mit double_slip bezeichnet (eine einfache Kreuzungsweiche entsprechend mit single_slip).
--EvanE 10:04, 15 December 2011 (UTC)

"Kombination aus Kreuzung und Weiche ist" könnte man noch um ", genauer eine Kreuzung und vier paarweise gekoppelten Weichen, ist" ergänzen. Ich kann nicht einschätzen, ob das für Nicht-Bahnfreaks wichtig oder hilfreich ist. --EvanE 10:11, 15 December 2011 (UTC)

Ja, das hatte ich tatsächlich aus dem Proposal übernommen. Habe es nun korrigiert und Links zu Wikipedia-Artikeln als Erklärung eingefügt. --rurseekatze 19:43, 15 December 2011 (UTC)

Dreiwegweiche ist nicht wirklich eindeutig. Im Bahn-Deutsch heißt das übrigens Doppelweiche, kennt aber niemand außer den Bahnspezialisten. Von daher ist die Namenswahl trotzdem passend.
Es gibt sehr unterschiedliche Formen von Dreiwegweichen:

• Symmetrisch (wie bei der Modellbahn): Das gibt es bei der 'normalen' Eisenbahn praktisch nicht, eigentlich nur bei Feldbahnen.
• Versetzt: Der rechte und der linke Abzweig beginnen an unterschiedlichen Punkten, praktisch zwei ineinander geschobene Weichen. Wenn es ein gemeinsames, drittes Herzstück gibt, ist es eine Doppelweiche, sonst zwei einfache Weichen. Im ersten Fall passt three_way, im zweiten sollte man das auch in OSM als zwei unabhängige Weichen eintragen.
• Einseitig: Also zwei Abzeige nach links oder zwei Abzweige nach rechts. Die Aussage zum gemeinsamen Herzstück gilt auch für diese Form.

Y-Weichen heißen im Bahn-Deutsch Außenbogenweichen. Da das aber wieder nur die Spezialisten wissen, ist die Namenswahl leichter verständlich und sollte nicht geändert werden. Innenbogenweichen brauchen nicht extra bezeichnet zu werden, da sie im Prinzip 'gebogene' Standardweichen sind.

Übrigens versucht die DB Doppelkreuzungsweichen zu vermeiden oder durch zwei einfache Weichen (die erste einmündend, die zweite abzweigend) zu ersetzen. Die Schweizer SBB hingegen benutzt sie gern und reichlich.
--EvanE 00:40, 17 December 2011 (UTC)

uic_ref versus IBNR

Im Abschnitt Bahnhof wird uic_ref wie folgt beschrieben:

Key	Value	Element	Objekt	Beschreibung	Standardwert
uic_ref	<Bahnhofsnummer>		UIC-Bahnhofsnummer	Internationale Bahnhofsnummer (IBNR)

Dadurch wird die von der UIC vergebene Bahnhofsnummer mit der IBNR, wie sie in der Fahrplanauskunft von DB/HAFAS verwendet wird gleichgesetzt. Das ist aber nicht der Fall.
Für Haltestellen (in DE im Wesentlichen nur Bahnen), für die es eine UIC-Nummer gibt verwenden HAFAS/DB natürlich die UIC-Nummer. Für andere Haltestellen (z.B. Bushalte) werden eigene Nummern verwendet, die auch nicht dem UIC-Format entsprechen. Die Gesamtheit ihrer Haltestellen-Nummern werden dann als IBNR bezeichnet.
Also am Besten die Beschreibung durch "Die von der UIC vergebene, weltweit eindeutige Bahnhofsnummer" ersetzen.
--EvanE 10:28, 15 December 2011 (UTC)

OK, ist korrigiert. Mir war der Unterschied nicht ganz genau klar. --rurseekatze 18:23, 15 December 2011 (UTC)

Grundlegende Daten

Hallo,

ich habe mich in den letzten Wochen ebenfalls mit dem Erstellen einer bahnbezogenen Karte aus OSM-Daten beschäftigt (per Osmarender, für den Druck) und bin dabei auf eine Unklarheiten im Tagging gestoßen, die ich hier zur Diskussion stellen möchte:

• Es ist offenbar immer noch unklar, ob Gleise oder Strecken gemappt werden sollen. Es gibt zahlreiche zweigleisige Strecken, die nur als einzelne Linie gemappt sind. Vorteil beim Mappen einzelner Gleise ist natürlich, dass bei großmaßstäblichen Karten auch alle Gleise einzeln dargestellt werden könnte. Bei kleineren Maßstäben bräuchte man jedoch einen Mechanismus, der erkennt, dass beide Gleise zu ein und der selben Strecke gehören und diese mit einem einzelnen Strich entsprechend anders darstellen als eingleisige Strecken. Das sollte dringend geklärt werden, bevor zuviel gemappt wird, was dann wieder korrigiert werden muss.

• Ich hatte versucht, den Namen von Tunnels und Brücken auszuwerden, bin aber wieder davon abgekommen, da der name-Tag oftmals nur sowas wie "Strecke Adorf-Bhausen" enthält, und die Namen der Tunnels und Brücken nicht einzeln hinterlegt sind. Andererseits hat halt auch nicht jedes Brückerl über jedes Bacherl einen Namen...

• Es fehlt ein sinnvolles Tagging für Betriebsbahnhöfe. Das anzutreffende railway=station in Verbindung mit station:mode=service wird von Osmarender genauso gerendert wie ein normaler Bahnhof mit Personenverkehr und ist somit in der Karte nicht zu unterscheiden. Vorschlag: railway=service_station

Wenn mir noch was einfällt, trage ich es nach

Gruß

--Margin-auto 08:06, 28 January 2012 (UTC)

• Ich bin eindeutig für das Mappen einzelner Gleise und habe das auch so im Tagging beschrieben. Die Auswertung ein- oder mehrgleisig ist dann tatsächlich schwieriger, aber es lässt sich lösen. In einer Datenbank wie einer PostgreSQL mit PostGIS könnte man abfragen, ob in einem Abstand von einigen Metern ein weiteres Gleis mit der gleichen Streckennummer liegt. Wenn das erfüllt ist, kann man die Strecke anders zeichnen. Wie man das in den Renderern einbauen kann, weiß ich nicht, aber vielleicht könnte man dieses Problem den Entwicklern melden und die haben eine Idee, wie man zwei parallele Linien anders rendern kann.

• Dieses Problem besteht auch schon bei Straßen und auch dort hat man noch keine Lösung gefunden. bridge_name=* ist schon häufiger eingesetzt, vielleicht übernimmt man das einfach.

• Habe da etwas im Tagging ergänzt, kannst ja schauen, ob es dir gefällt.

--rurseekatze 13:47, 29 January 2012 (UTC)

Danke für die Ergänzung. Brauchen wir einen separaten Tag für Überleitstellen, oder kann man das mit in die Betreibsbahnhöfe packen? Ich fände ein railway=crossover schon sinnvoll.

Bei Bahnhöfen/Haltepunkten sollte man noch abandoned=yes als "offiziell" möglichen Zusatz ergänzen, da Osmarender das derzeit nicht versteht. (Osmarender ist für mich sowas wie vor 10 Jahren der Internet Explorer: Wenns dort sch***e aussieht, kann mans nicht verwenden, egal was der Standard sagt ;- ) )

Mit position=xy bekommt man Probleme bei Bahnhöfen/Abzweigen, die an mehreren Strecken liegen und daher mehrere Kilometrierungsangaben erhalten müssen.

--Margin-auto 17:23, 30 January 2012 (UTC)

• Ich schlage railway=crossover an den Weichen und ein service=crossover für die Überleitgleise vor. (siehe Ergänzung Tagging)
• Ich habe da mal was ergänzt... ;)
• Bei Bahnhöfen werde ich wahrscheinlich dazu übergehen, einen Punkt auf jedes Gleis zu setzen, somit hat sich das Problem gelöst. Bei Abzweigen hat man das Problem, dass es zum einen die Kilometerangabe der durchgehenden und die der endenden Strecke gibt.

--rurseekatze 18:48, 2 February 2012 (UTC)

Ich habe inzwischen entdeckt, dass Osmarender mit railway=station und disused=yes umgehen kann und das Ergebnis grau und mit grauer Beschriftung darstellt. Der Abschnitt mit disused_station etc. kann also meiner Meinung nach weg und man sollte auf dieses Tagging verweisen.

Ich habe mich mal die Schwarzwaldbahn entlanggearbeitet und Positionen und DS100-Kürzel verteilt. Die vorhandenen Daten i.S. Bahnhöfe sind ein ziemliches Durcheinander. Teilweise liegt ein Punkt auf der Schiene (wie beabschtigt), teilweise hat jedes Gleis einen Punkt, teilweise liegt der Punkt separat neben den Gleisen... Ich habe mich nicht überall getraut, aufzuräumen, da ich Angst habe, Relationen etc. kaputt zu machen (mit denen ich mich (noch) nicht so auskenne). Gruß --Margin-auto 14:01, 5 February 2012 (UTC)

• Das Tagging würde ich aber beibehalten, sonst stellt zum Beispiel Mapnik diese Bahnhöfe als normale Bahnhöfe dar. Am Tag sollte direkt erkennbar sein, dass es sich nicht um einen normalen Bahnhof handelt.

• Was ich schonmal sagen kann ist, dass die Bahnhöfe auf dem Gleis erfasst werden sollten. Ob es nun sinnvoll ist, das bei jedem Gleis zu machen, ist eine andere Frage. Darauf habe ich noch keine richtige Antwort gefunden. --rurseekatze 19:04, 14 February 2012 (UTC)

Lange Wartezeit

Hier gibt es einen Bahnübergang, bei dem man mitunter sehr lange warten muss. (Von 2 Besuchen stand ich einmal gut 15 min bis wieder geöffnet wurde.) Auf dem Hinweisschild steht frei übersetzt: "Wegen vieler Rangier- und Zugfahrten bleibt der Bahnübergang oft längere Zeit geschlossen." Fürs Routing ist es sicherlich sinnvoll, den Übergang in irgendeinerweise zu behandeln/taggen. Gibt es dafür schon taggs, oder ist das ein (nichtbeachtenswerter) Einzelfall? -- MasiMaster 13:20, 10 May 2012 (BST)

Da hat man natürlich das Problem, dass die Definition "lange Wartezeit" etwas schwammig ist. Je nachdem, wie man es sieht, hat man an jedem Bahnübergang eine mehr oder weniger lange Wartezeit. Bei dem von dir gezeigten Bahnübergang ist auffallend, dass er sehr viele kreuzende Gleise hat. Ich denke, dass der Router anhand der Gleisanzahl eine möglicherweise lange Wartezeit ermitteln sollte. Also dass bei einer eingleisigen Strecke die Wahrscheinlichkeit einer langen Wartezeit kleiner ist als bei einer viergleisigen und solch ein Bahnübergang daher zu bevorzugen bzw. zu vermeiden ist. Auch noch könnte man das Gleis selbst berücksichtigen, dass z.B. bei einer elektrifizierten Hauptstrecke die Wahrscheinlichkeit, warten zu müssen, höher ist als bei einem nicht elektrifizierten Gleis einer Hafenbahn. Bisher kenne ich zwar keinen Router, der solch eine Funktion hat, aber vielleicht werden zukünftige Router diese Funktion unterstützen. Diese Lösung halte ich für langfristig besser als ein Tagging. --rurseekatze 19:04, 21 May 2012 (BST)

Richtig, das ist sehr schwammig. Bei normalen Ampeln muss man etwa 0...2 min Warten, dort wird vermutlich eine mittlere Wartezeit fürs Routing angenommen. Jedoch geht dort die Tendenz in Richtung EINER Ampel(-Relation) für eine Kreuzung (weil man nicht warten muss, wenn man "von hinten" eine Ampel anfährt). Bedarfsampeln könnten beim Routing eine kürzere mittlere Rot-Zeit fürs Routing erzeugen. Vielleicht kann man so einen Wert (für Ampeln und auch) für Bahnübergänge einführen?! (Anzahl der Gleise finde ich keinen guten Indikator für die mögliche Wartezeit.) -- MasiMaster 19:54, 22 May 2012 (BST)

Ich würde vorschlagen, dieses Problem im Forum oder auf der Mailingliste weiter zu diskutieren. Dort gibt es mehr Experten und wie du schon sagtest betrifft das Problem eigentlich nicht nur Bahnübergänge, sondern auch Ampeln. --rurseekatze 20:20, 30 May 2012 (BST)

zugehörige Verwaltung zu railway:ref=*

Zu railway:ref=* sollte noch die zugehörige Verwaltung dazu (z.B. railway:ref:DB=*). Zum Beispiel der französische Bahnhof "Paris Ostbahnhof" lässt sich mit den deutschen (=DBAG) Abkürzungen mit "XFPO" abkürzen, hat aber warscheinlich auch eine französische Abkürzung. --rayquaza 10:42, 27 June 2012 (BST)

Danke für diese Ergänzung! Ich würde vorschlagen, das Tag ähnlich wie name=* zu verwenden. Man verwendet immer railway:ref=* für die landeseigene Abkürzung und dann jeweils railway:ref:*=* für ausländische Bezeichnungen. Dies ist einfacher auszuwerten, als in jedem Land ein anderes Tag für diese Information zu haben. --rurseekatze 12:40, 28 June 2012 (BST)

Das ist das, was ich meinte. --rayquaza 05:23, 28 June 2012 (BST)

Alles klar... ;) --rurseekatze 12:40, 28 June 2012 (BST)

Sollte railway:ref=* besser das Kürzel des jeweiligen Betreibers oder das Landesübliche erhalten? Hintergrund: z.B. Mannheim-Wallstadt (Schmalspurbahn, nach ESBO) ist nach DS100 RMWT, das Kürzel der OEG ist natürlich ein anderes. --rayquaza (talk) 15:16, 21 July 2013 (UTC)

Infrastrukturregister der DB Netz AG als Datenquelle

Ich habe gesehen, dass die DB Netz AG gemäß der Verordnung über die Interoperabilität des transeuropäischen Eisenbahnsystems (TEIV in der Fassung vom 23. Juni 2008, BGBl. I S. 1092) ein Infrastrukturregister anbietet, das unter anderem auch die Gleispläne aller Betriebsstellen in Deutschland enthält. Das finde ich insbesondere interessant, da dort auch die Bezeichnungen der Weichen und Signale enthalten sind. Meine Frage wäre jetzt, ob man diese Informationen (Bezeichnungen und topologischer Standort, Geodaten sind da ja nicht vorhanden) als Referenz zum Mappen benutzen darf. Weiß da jemand näheres? Ich bin leider in dieser Hinsicht aus den Contributor Terms nicht besonders schlau geworden. Und wenn nicht, ist es erlaubt, Signal-/Weichenbezeichnunge aufgrund von GPS-Survey zu mappen? Und falls man das macht, darf man solche Informationen als "Unterstützung" (Erinnerungshilfe, Bestätigung der GPS-Daten) nutzen? Grüße, Rohieb 14:01, 3 August 2012 (BST)

Ah. Ich sehe grade Beginners Guide 1.1#Don't use copyrighted data:

As a rule of thumb, use no external resources except those available in the editors.

Dann hat sich meine Frage wohl von selbst erledigt :-) --Rohieb 14:19, 3 August 2012 (BST)

Naja, so ganz korrekt ist das Zitat nicht. Man darf durchaus auch Quellen verwenden, die nicht in einem Editor verfügbar sind, z.B. Datensätze, für die man sich eine Erlaubnis eingeholt hat, eigene Luftbilder, Public-Domain Daten, etc.

Im vorliegenden Fall würde ich aber die Finger von den Quellen der Bahn lassen. Man könnte natürlich dort nachfragen und um Erlaubnis bitten, aber ich mache mir da keine großen Hoffnungen. Ich würde auch keine Streitigkeiten wegen Copyrightverletzungen mit dem Konzern riskieren wollen.

Nutze lieber die legalen Mittel, also selbst von öffentlichem Grund erfassen, oder mit Luftbildern, um Signale und Weichen zu mappen. Damit bist du rechtlich auf der sicheren Seite.

Ob man die Pläne als Erinnerungshilfe nutzen darf, weiß ich nicht, das ist wahrscheinlich grenzwertig. Wenn du eigene "Beweise" in Form von Aufzeichnungen wie Fotos oder GPS Tracks hast, dass du vor Ort warst, dann könnte man dir nur schwer ein Abzeichnen von Karten nachweisen, außer, du kopierst Fehler aus deren Karte nach OSM. Rechtlich dürftest du eigentlich auf keinen Fall deren Karte als "Inspiration" nehmen.

Ich bin aber auch nicht wirklich ein Experte in solchen Fragen, da wendest du dich besser z.B. in Forum oder Mailingliste an Leute mit mehr Hintergrundwissen. Wenn du es komplett selbst erfasst, solltest du keine Probleme bekommen, wie das in den anderen Fällen ist, fragst du besser die Experten. --rurseekatze 11:47, 4 August 2012 (BST)

Ja, ich dachte mir schon, dass man da besser die Finger von lässt, oder offiziell anfragt (wobei ich mir da auch keine großen Hoffnungen mache, aber fragen kostet ja nichts ;-)) Auf kleineren Bahnstrecken mit nur 1-2 Züge pro Stunde geht das Mappen per GPS ja auch ganz gut, und die Infos, die man dadurch kriegt, sind ja nicht wirklich anders als die, die in den Plänen stehen – teilweise sogar noch mehr, ich habe heute ziemlich viele P-Tafeln und Zs 3(v) gefunden, die nicht im Plan stehen. Nur bei den Signalstellungen bin ich mir nicht sicher, wie man zB Hauptsignale mit Hp0/Hp2 von solchen mit Hp0/Hp1/Hp2 unterscheiden kann, das ist für mich nur aus den Plänen ersichtlich. --Rohieb 18:47, 4 August 2012 (BST)

Da man Hauptsignale mit Hp0/Hp2 von welchen mit Hp0/Hp1/Hp2 nicht wirklich unterscheiden kann (außer man weiß das durch lange Beobachtung oder weil sich das durch die örtlichen Gegebenheiten ergibt), würde ich im Zweifel immer als Hp0/Hp1/Hp2 taggen, da das Signal aufgrund seiner Lampen theoretisch in der Lage wäre, alle drei Zustände anzuzeigen. Bei Form-Vorsignalen kann man aufgrund fehlender Lampenkästen sehen, dass die nur Vr0/Vr2 anzeigen können, womit das zugehörige Hauptsignal auch nur Hp0/Hp2 anzeigen kann. --rurseekatze 20:35, 4 August 2012 (BST)

Railway:short

Hallo,

ich habe bislang railway:short für Abkürzungen von Betriebsstellen nach DS 100 ([1]) verwendet. Jetzt aber festgestellt, dass der Tag auch für Abkürzungen von Stellwerken (Dingenskirchen Fahrdienstleitung = Df) verwendet wird. Das sollte man IMO im Wiki nochmal klarstellen.

Danke

--Margin-auto 11:14, 10 November 2012 (UTC)

railway:short ist mittlerweile veraltet, railway:ref ist das neue Tag.

Was genau soll ich deiner Meinung klarstellen? Dass man das Stellwerkskürzel mit railway:ref angeben kann, ist auf der Taggingseite bereits vermerkt. --rurseekatze 10:28, 17 November 2012 (UTC)

*seufz* Dann muss ich meine railway:shorts wohl mal gesammelt umbauen

Nein, ich wollte im Gegenteil darauf hinaus, dass man *nicht* den selben Key für Stellwerkskürzel und DS100 verwenden sollte! Diese beiden Abkürzungsschemen haben nichts miteinander zu tun. DS100 identifiziert bundesweit eindeutig eine Betriebsstelle. Ein Stellwerkskürzel ist nur innerhalb eines Bahnhofs eindeutig. Das sollte man in den Keys unbedingt trennen. --Margin-auto 10:17, 24 November 2012 (UTC)

Ich sehe kein Problem darin, dass man auch Stellwerkskürzel mit diesem Tag einträgt. Ob das Kürzel nun als DS100-Kürzel eine Betriebsstelle bezeichnet oder ein Kürzel eines Stellwerks ist, ergibt sich eindeutig aus den übrigen Tags.

ref=* ist ebenfalls so ein allgemeines Tag, dessen Bedeutung auch vom jeweiligen Objekt abhängt. Ob die mit ref=* getaggte Bezeichnung nun die Nummer einer Autobahnabfahrt oder einer Kreisstraße ist, lässt sich ja auch an den anderen Tags erkennen. Als so ein allgemeines Tag ohne Festlegung auf ein bestimmtes Abkürzungssystem sehe ich auch railway:ref. --rurseekatze 22:03, 30 November 2012 (UTC)

S-Bahn als light_rail?

Hallo,

gemäß der Definition hier im Wiki, sind S-Bahnen als light_rail zu taggen:

Stadtbahn und straßenbahnähnliche Untergrund oder Überlandbahnen. Sie entsprechen zu einem Teil Vollbahnen, unterscheiden sich aber z.B. durch ein anderes Stromsystem, eigene Signaltechnik und einen speziellen Fuhrpark (z.B. S-Bahnen Hamburg und Berlin, Hamburger Hochbahn)

In Berlin ist das auch in weiten Bereichen umgesetzt, anderswo ist es mir noch nicht aufgefallen.

Nach meinem Verständis ist allerdings die deutsche Entsprechung für den englischen Begriff "Light Rail" alles, was hierzulande rechtlich als Straßenbahn behandelt wird, und somit nach BOStrab fährt. Also alles, was gemeinhin als Straßenbahn, Stadtbahn oder U-Bahn bezeichnet wird. Die erwähnten S-Bahnen in Hamburg und Berlin verkehren allerdings nach Eisenbahnbetriebsordnung (EBO) und sind somit vollwertige Eisenbahnen.

Ich würde vorschlagen, die Unterscheidung zwischen light_rail und rail entlang der bestehenden rechtlichen Abgrenzung zwischen BOStrab und EBO vorzunehmen. Das ist eindeutig und vermeidet Grauzonen.

Wo es direkte Übergänge zwischen EBO- und BOStrab-Strecken gibt (bspw. in Karlsruhe) ist das bereits sauber unterschieden und separat getagged.

Gruß

--Margin-auto (talk) 18:22, 2 May 2013 (UTC)

Servus

Durch die Unabhängigkeit (Stromsystem, Sicherungssystem, Fahrwege) von der Berliner S-Bahn vom restlichen System, finde ich light_rail als durchaus passend. Eine wirkliche Grenze zu ziehen ist schwierig. Ich finde leider keine Unterlagen die Fahrzeug der S-Bahn betreffend, aber man könnte als Kriterium z.B. auch die zul. Längsdruckkraft nehmen (Vollbahn je nach Fahrzeug >1500 kN). --Jimmy K (talk) 15:12, 3 May 2013 (UTC)

Ich stimme soweit der Meinung von Jimmy K zu. Wir sollten uns mit dem Tagging nicht zu sehr an deutschen Rechtsvorschriften orientieren, sondern objektive Kriterien als Tagginggrundlage verwenden, um das Taggingschema international anwendbar zu machen. Was light_rail betrifft, ist die "Abtrennung" vom üblichen Vollbahnnetz solch ein Kriterium, also ein eigenes Signalsystem, Stromschienen im Gegensatz zu den üblichen Oberleitungen und die Tatsache, dass die dortigen Fahrzeuge nie auf anderen Strecken fahren und umgekehrt keine "normalen" Züge auf diesen Gleisen.

Natürlich ist die Abgrenzung zwischen tram, light_rail, subway und rail teilweise etwas schwierig, aber da muss der jeweilige Mapper selbst abwägen und kann sich im Zweifelsfall auch an rechtlichen Regelungen orientieren.

Reine Straßenbahnen sind auf keinen Fall als light_rail zu taggen, denn für sie ist bereits das Tag railway=tram vorgesehen.

Es gibt lediglich ein paar Sonderfälle, bei denen man sich darüber streiten kann: Etwa einige Stadtbahnstrecken der Rheinbahn in Düsseldorf. In der Stadt verkehren die Züge auf den üblichen Straßenbahngleisen und sind eindeutig als tram einzuordnen, es gibt aber auch Überlandstrecken, die sogar mit LZB ausgerüstet sind

--rurseekatze (talk) 17:58, 7 May 2013 (UTC)

Hallo,

so ganz kann ich die Argumente nicht nachvollziehen. Was gibt es denn Objektiveres als die geltenden Rechtsvorschriften? Auf deren Grundlage wäre stets eine eindeutige Klassifizierung möglich. Ich kann aber damit leben, dass S-Bahnen wie in Berlin und Hamburg als light_rail getagged werden. In diesem Fall sollte aber stets über workrules=EBO deutlich gemacht werden, dass es hier um Eisen- und nicht um Straßenbahnen geht.

--Margin-auto (talk) 11:26, 26 May 2013 (UTC)

Beim Tag railway=* geht es um eine generelle Einordnung eines Gleises, vergleichbar mit dem highway=* Tag bei Straßen. Und bei diesen wird ja ebenfalls gesagt, dass sich die Einordnung zwar an den jeweiligen Vorschriften des Landes orientieren kann, aber nicht muss, weil sie eben nicht zum Tagging von Vorschriften dient, sondern weltweit anwendbar sein soll.

Würde nun in jedem Land streng nach Rechtsvorschriften getaggt, dann ergibt das zwar für ein Land objektive Kriterien, aber nicht weltweit. Beispiel: Jemand aus einem fernen Land ist zu Besuch in Deutschland und schaut sich auf der OpenRailwayMap die Strecken in Berlin an. Wären die S-Bahn-Gleise streng nach deutscher Rechtsauffassung als railway=rail getaggt, könnte das beim besagten Nutzer eine völlig falsche Vorstellung von der Art dieser Strecke hervorrufen. Sind die Gleise dagegen nach den im Taggingschema definierten Merkmalen als railway=light_rail getaggt (anderes Stromsystem, eigene Signaltechnik, speziellen Fuhrpark, vom Straßenverkehr getrennt), hat der Benutzer eine viel bessere Vorstellung davon, wie die Strecke in etwa ausschaut, da ähnlich beschaffene Strecken in seiner Heimat auf der Karte gleich gerendert werden.

Wie bereits gesagt geht es mir beim Projekt OpenRailwayMap vor allem darum, eine weltweite Streckennetzkarte zu erstellen, die meines Wissens in dieser Form bislang noch nicht existiert. Daher ist auch das Tagging der Signale so kompliziert, denn ich will vor allem die Bedeutung und Art der Signale erfassen, nicht Begriffe wie "Hp 2".

Beim Tagging steht also die internationale Einheitlichkeit im Vordergrund, was aber nicht ausschließt, dass man zusätzlich noch landesabhängige Informationen in separaten Tags erfasst. Daher wäre ich mit einem zusätzlichen Tag, wie von dir vorgeschlagen, einverstanden, um eine Unterscheidung zwischen Eisenbahn und Straßenbahn im deutschen Rechtssinn zu taggen. --rurseekatze (talk) 17:59, 5 June 2013 (UTC)

Gleiskreuzung

Bei der Diskussionsseite des Erweiterten Taggings kam keine Antwort. Also hier dieselbe Sache: Ich vermisse einen Tag für eine niveaugleiche Gleiskreuzung, also keine Kreuzungsweiche, sondern sowas. Nach dem englischen WP-Artikel bieten sich drei values an: railway=level_junction oder =flat_crossing oder =diamond. railway=junction wird hier aber schon für Abzweige verwendet. 36 Mal wird railway=diamond verwendet. Damit scheint das Gleiche gemeint zu sein (Quelle). Aber diamond passt doch bei Kreuzungen im rechten Winkel gar nicht Bei flat_crossing zeigt das "crossing" schön an, worum es hier geht. Vorschlag also: railway=flat_crossing.--Geogast (talk) 21:31, 8 June 2013 (UTC)

Hmm, kann mir gar nicht erklären, warum mir dein erster Beitrag entgangen ist. Normalerweise bekomme ich immer eine Benachrichtigungsmail, da die Seite auf meiner Beobachtungsliste steht. Diesmal hab ich aber keine Mail bekommen... Wenn ich auch nach längerer Zeit nicht antworte, liegt es dann wahrscheinlich daran, dass ich davon einfach nichts mitbekommen habe. Im Zweifel dann nochmal eine Private Nachricht als Erinnerung.

Zu deinem Vorschlag: Bin auch der Meinung, dass railway=flat_crossing am ehesten passt. railway=level_junction könnte man meiner Meinung auch leicht mit railway=junction oder railway=level_crossing verwechseln. --rurseekatze (talk) 16:00, 12 June 2013 (UTC)

Ich sehe gerade, dass railway=railway_crossing schon sehr häufig verwendet wird, ~1500 Mal. Der Tag ist undokumentiert, aber damit ist das gemeint, wovon hier die Rede ist. Einfach übergehen kann man das ja nicht. Also railway=railway_crossing statt r=flat_crossing?--Geogast (talk) 21:30, 2 July 2013 (UTC)

Es wäre sinnvoll, das vorhandene Tag zu verwenden, auch wenn die Bezeichnung "railway_crossing" für mich ein wenig merkwürdig klingt. Die Wikiseiten und das JOSM Preset werde ich dann morgen entsprechend anpassen. --rurseekatze (talk) 21:38, 14 July 2013 (UTC)

Wiki und JOSM Preset sind nun entsprechend geändert. --rurseekatze (talk) 19:25, 15 July 2013 (UTC)

Gleissperren

Unser erweiterte Schema nennt sowas railway=derailer (das wird auch 17-mal benutzt), aber von offizieller Seite gibt es auch railway=derail, was 69-mal benutzt wird. In meinen Augen ist es sinnvoll, aus Kompatibilitätsgründen hier die offizielle Version zu übernehmen und keine Tag-Doppelung einzuführen.

Ich würde auch noch die Definition um railway:turnout_side=* und railway:local_operated=* ergänzen, um die Auswurfrichtung zu kennzeichnen. --Rohieb (talk) 22:38, 19 June 2013 (UTC)

Habe das Tag auf railway=derail geändert. Die 17 mit railway=derailer getaggten Gleissperren muss man dann eben irgendwann noch manuell umtaggen.

railway:local_operated=* klingt sinnvoll und ist nun ergänzt.

Wofür die Auswurfrichtung interessant sein soll, hat sich mir aber noch nicht so recht erschlossen... --rurseekatze (talk) 16:46, 22 June 2013 (UTC)

Überholbahnhöfe

Hallo,

was mir noch nicht klar ist, ist das Tagging von Überhol- oder anderen Betriebsbahnhöfen. Damit meine ich Bahnhöfe an Strecken, die nicht für den Personenverkehr genutzt werden. Ich meine damit keine Werkstätten und keine Güterbahnhöfe. Ich meine damit sowas wie bspw. Werlau an der linken Rheinstrecke oder Kraichtal an der SFS Mannheim-Stuttgart.

Bei "Betriebsbahnhof" heisst es ja:

Ausdrücklich nicht zu dieser Kategorie gehören z.B. Bahnhöfe ohne Personenverkehr, die nur dem Überholen von Zügen dienen.

ACK, aber wie tagge ich diese dann? railway=crossover ist zwar nicht falsch aber auch nicht ausreichend. Ein Überholbahnhof ist mehr als eine Überleitstelle.

Gruß

--Margin-auto (talk) 09:26, 23 June 2013 (UTC)

Eigentlich hatte ich für Bahnhöfe aller Art (egal ob mit oder ohne Personenverkehr) railway=station vorgesehen. Ich musste aber gerade feststellen, dass sich dabei wohl ein paar Probleme ergeben. Taggt man nämlich einen reinen Überholungsbahnhof als railway=station, dann würde er z.B. auch in ÖPNV-Anwendungen als Bahnhof auftauchen, da man ihn nicht von einem Personenbahnhof unterscheiden kann.

Das heißt also, das wir uns eine andere Lösung einfallen lassen müssen:

Ein zusätzliches Tag wie railway:dedication=passenger/freight ist wohl wenig sinnvoll, denn existierende Anwendungen müssten erst geändert werden, damit sie dieses Tag auswerten.

Sinnvoller wäre also ein anderes Tag. Entweder nimmt man hier doch railway=service_station, obwohl ich das eigentlich für richtige Betriebsbahnhöfe, Abstellbahnhöfe, etc. vorgesehen hatte, oder man erfindet noch ein neues, zusätzliches Tag.

Was meinst du dazu? Neues Tag oder railway=service_station nehmen? Das ist natürlich davon abhängig, ob man unbedingt Abstellbahnhöfe von Überholbahnhöfen unterscheiden will oder nicht. Zumindest in Deutschland gelten ja beide betrieblich als Bahnhof.

--rurseekatze (talk) 18:16, 29 June 2013 (UTC)

Ich würde vorschlagen, railway=service_station für die von mir im Ausgangsposting genannten Überhol- und Kreuzungsbahnhöfe ohne Verkehrshalt zu verwenden. Das was du mit "richtigen" Betriebsbahnhöfen bezeichnest, ist mit railway=workshop IMHO bereits ausreichend abgedeckt. Für Abstellanlagen müsste man sich noch was einfallen lassen (railway=parking? ;-) )

--Margin-auto (talk) 06:58, 14 July 2013 (UTC)

Vielleicht sollten wir alle Bahnhöfe ohne Verkehrshalt in zwei Gruppen aufteilen: Zum einen railway=service_station für Betriebsbahnhöfe, Abstellbahnhöfe (also mehrheitlich stehende Züge) und zum anderen ein neues Tag für Überhol- und Kreuzungsbahnhöfe, also Bahnhöfe mit überwiegend durchfahrenden Zügen. Bei letzterem fiel mir jedoch bisher noch keine geeignete Übersetzung ein... Vielleicht hat da jemand etwas passendes?

Warum diese Lösung? Nun, ich denke, dass etwa die Grenze zwischen einem Betriebsbahnhof und einem Abstellbahnhof ziemlich fließend und eine weitere Unterscheidung daher nicht sinnvoll ist. Die verschiedenen Betriebseinrichtungen (railway=fuel, railway=workshop, etc.) können dann noch einzeln eingetragen werden.

Allerdings ergibt sich dabei auch wieder ein neues Problem: Es gibt nämlich durchaus Betriebsbahnhöfe mit gleichnamigem Personenbahnhof. Betrieblich ist das natürlich alles eine einzige Betriebsstelle, aber nach dem derzeitigen Stand müsste man sich entweder für railway=station oder railway=service_station entscheiden oder aber zwei Objekte eintragen, was aber wiederum nicht so recht der Realität entspricht.

Bezüglich railway=workshop: Das Tag ist nicht für Betriebsstellen, sondern für die Werkstätten selbst vorgesehen, denn die können auch unabhängig von Betriebsstellen vorkommen. Wie bereits beschrieben kann man mit diesem Tag einzelne Betriebseinrichtungen auf dem Gelände eines Betriebsbahnhofes erfassen.

Was die Abstellanlagen betrifft, bin ich noch etwas unentschlossen: Einerseits sind Abstellgruppen insbesondere für Privatbahnen interessant, die irgendwo ihre Lok "parken" müssen, andererseits sind Lokabstellplätze insbesondere auf größeren Güterbahnhöfen nur schwer erkennbar, weil die Loks auf normalen Rangiergleisen geparkt werden. Und streng genommen kann fast jedes Bahnhofsgleis als Abstellgleis genutzt werden.

--rurseekatze (talk) 20:30, 14 July 2013 (UTC)

Ich frage mich, warum es da überhaupt eine Unterscheidung braucht: Zugangsstellen für den Personenverkehr werden doch bereits per public_transport=* (z.B. public_transport=station) von anderem unterschieden? Und wer soll entscheiden, ob etwas eine Awanst, ein Überholbahnhof oder ein Abstell-/Betriebs-/whatever-Bahnhof ist? Und wenn es jemand entscheidet: Wo wäre der Nutzen dieser Unterscheidung? --rayquaza (talk) 07:52, 15 July 2013 (UTC)

Viele Anwendungen werten railway=station bisher als einen Bahnhof mit ÖPNV-Halt aus und beachten das public_transport Tag nicht. Und auch im Wiki ist im entsprechenden Artikel das Tag railway=station bisher als Personenbahnhof definiert. Daher brauchen wir Tags, die die ÖPNV-Bahnhöfe von den sonstigen Bahnhöfen (Überholbahnhof, Abstellbahnhof, Betriebsbahnhof, Güterbahnhof, etc.) trennen.

Ob und wie stark man diese nicht-ÖPNV Bahnhöfe nochmal unterteilt, muss man noch diskutieren.

Wenn man etwa bei den Betriebsbahnhöfen die Werkstatthallen, die Tankstelle oder Lokschuppen ohnehin noch separat taggt, könnte man sich es natürlich sparen, noch irgendeine Kategorisierung des Bahnhofs vorzunehmen.

Andererseits könnte man aber auch begründen, dass ein Betriebsbahnhof eine andere Bedeutung hat als ein Überholbahnhof und deshalb irgendwie besonders kenntlich gemacht werden müsste.

--rurseekatze (talk) 19:08, 17 July 2013 (UTC)

Die Definition von railway=station als Personenbahnhof kommt vermutlich einfach daher, dass andere Bahnhöfe früher nicht erfasst wurden. Alle Bahnhöfe, denen ich bisher in OSM begegnet bin, waren als railway=station erfasst – Egal ob Personenbahnhof oder nicht (selbst die meisten ehemaligen Bahnhöfe an stillgelegten Strecken!). --rayquaza (talk) 11:44, 18 July 2013 (UTC)

Dass railway=station nur als Personenbahnhof gesehen wird, hängt, wie von dir bereits gesagt, mit der Geschichte des Tags zusammen. Und genau hier liegt ja auch das Problem: Man sollte nicht nachträglich die Bedeutung des Tags verändern und plötzlich alle sonstigen Bahnhöfe auch als railway=station taggen - ich sehe schon die bösen Mails auf mich zukommen, wo sich Leute beschweren, weil plötzlich alles so komische Bahnhöfe auf der Mapnikkarte erscheinen oder irgendeine App plötzlich den örtlichen Betriebsbahnhof als nächstgelegenen Nahverkehrshalt anzeigt... ;)

Daher ist es meiner Meinung absolut notwendig, ein separates Tag zu finden, denn sonst werden wir einige Konflikte bekommen - sowohl technischer als auch organisatorischer Art. --rurseekatze (talk) 19:20, 18 July 2013 (UTC)

Aber warum sollten wir die anderen Bahnhöfe für die es scheinbar problemlos genutzt wird umtaggen? Es funktioniert ja offensichtlich. Ich sehe es darum gar andersrum: Man sollte nicht nachträglich die Definition davon ändern und diese anderen Bahnhöfe als Personenbahnhöfe interpretieren. --rayquaza (talk) 23:29, 18 July 2013 (UTC)

Naja, was heißt "es funktioniert" - Bei der Anzeige auf der Karte ist eine Unterscheidung vielleicht noch nicht ganz so wichtig. Aber für manche Anwendung braucht man eben zumindest eine Unterscheidung zwischen Personenbahnhöfen und sonstigen ohne Personenverkehr. Könntest du deinen letzten Satz noch etwas genauer ausführen? Ich verstehe nicht ganz, was du genau sagen willst. --rurseekatze (talk) 21:22, 21 July 2013 (UTC)

Damit meinte ich, dass ich seit ich railway=halt bemerkt hatte (schon etwas her ;-) ) railway=station als Bf i.S.d. EBO ansehe, weil ich schon vorher Bahnhöfe ohne Personenverkehr bemerkt hatte, die damit erfasst waren, und auch keine eindeutig andere Definition finden konnte und kann. Gibt es zu railway=station ein Proposal, in dem man nachlesen könnte, wie es ursprünglich mal gedacht war?

Als Anwendung, die eine solche Unterscheidung braucht, würde ich nach Relationen in denen der railway=stop drin ist sehen. Wenn eine Rolle in einer passenden Relation "stop" enthält oder das Tag public_transport=stop_area hat gibt es Personenverkehr. Ich habe aber inzwischen bemerkt, dass diese Unterscheidung in unvollständiger erfassten Bereichen nicht zielführend wäre (ausser man möchte Nutzer dazu bringen es zu ergänzen). Und "es funktioniert": Ich habe selbst schon Bahnhöfe so erfasst (einige auch noch als Fläche, also nichtmal so einfach zu ändern) und (noch?) keine entsprechenden Nachrichten erhalten. --rayquaza (talk) 12:47, 23 July 2013 (UTC)

Eine Auswertung über Relationen macht wenig Sinn, da dies z.B. das Rendern erschweren würde und auch keine Unterscheidung zwischen Güter- oder Überholbahnhof erlauben würde.

Dass einige nicht-Personenbahnhöfe bisher auch als railway=station erfasst wurden, liegt wohl eher daran, dass bisher kein Taggingschema für Bahnhofstypen existierte.

-rurseekatze (talk) 21:46, 23 July 2013 (UTC)

Du hast mich überzeugt, finden wir Tags ;-) --rayquaza (talk) 22:05, 23 July 2013 (UTC)

Ich gehe das Thema jetzt noch einmal systematisch ganz von vorne an. Hier nochmal eine Zusammenstellung der verschiedenen Bahnhofstypen und der bisher vorgesehenen Tags:

* Personenbahnhof - railway=station

* Betriebsbahnhof/Überholbahnhof - ???

* Güterbahnhof, Umschlagbahnhof, Rangierbahnhof, Übergabebahnhof, Hafen-, Werks-, Industriebahnhof - railway=yard

* Abstellbahnhof/Betriebsbahnhof Bbf - railway=service_station

Ich denke, dass diese Einordnung sinnvoll ist, um zwischen Personen- und Güterverkehr sowie Bahnhöfen mit Zugangsfunktion und solchen für den internen Betriebsablauf zu unterscheiden.

Nun stellt sich aber noch folgende Frage: Sollen wir für die Betriebs-/Überholbahnhöfe noch ein neues Tag finden, oder legen wir diese Bahnhöfe mit der Kategorie der Abstell-/Betriebsbahnhöfe zusammen?

Für die letzte Möglichkeit spricht meiner Meinung, dass beide Arten nur bahnintern interessant sind (wobei das die Rangierbahnhöfe zum Teil auch sind) und die einzelnen Einrichtungen auf dem Betriebsbahnhof (Werkstätten, etc.) sowieso separat erfasst werden.

Dagegen spricht jedoch, dass ein Betriebsbahnhof bahnintern doch eine gewisse regionale Bedeutung und eine Art "Anlaufpunkt" ist, während ein Überholbahnhof nicht wirklich ein Anfahrtsziel von Zügen ist.

Also:

• Bahnhof als Zugangsstelle für den Personenverkehr: railway=station
• Bahnhof als Zugangsstelle für den Güterverkehr: railway=yard

Soweit in Ordnung. Die Unterteilung Übf/Bbf wäre dann doch im Prinzip NV-Bahnhof/FV-Bahnhof, was wir ja auch nicht unterscheiden. Also für alle Bf, die nicht =station oder =yard sind, railway=service_station. Oder übersehe ich mal wieder etwas? --rayquaza (talk) 22:05, 23 July 2013 (UTC)

Ja genau, soweit korrekt. Alle Bf, die nicht =station oder =yard sind, als railway=service_station zu taggen, wäre die erste Möglichkeit. Dann könnte man diese Kategorie als Bahnhöfe definieren, die weder für Personen- noch für Güterkunden eine Zugangsstelle sind. Ausnahme sind natürlich Rangierbahnhöfe, denn an denen findet oft keine Güterverladung statt, aber andererseits sind diese das Ziel von Zügen des Einzelwagenverkehres, die dann vor Ort aufgeteilt und an die einzelnen Kunden verteilt werden.

Die andere Möglichkeit wäre, zwischen Bbf und Übf noch eine Unterscheidung vorzunehmen. Bahnintern sind nämlich die Betriebs- und Abstellbahnhöfe eine Art Regionalniederlassung für den Personennahverkehr und auch Ziel von Zügen (Stichwort PbZ). Die Überholbahnhöfe dagegen dienen nur kurzzeitig zum Ausweichen von Zügen und sind für den Zugverkehr relativ uninteressant.

Ich selbst bin ziemlich unentschlossen, welche Variante nun besser ist. Würde man eine Unterteilung in Bbf und Übf vornehmen, kann man die Bahnhöfe in der Software immer noch als gleichen Bahnhofstyp behandeln, während es beim umgekehrten Fall nicht möglich ist, aus einem einzigen Tag irgendeine Unterscheidung vorzunehmen. --rurseekatze (talk) 21:20, 24 July 2013 (UTC)

Ich denke, dass wir beide Arten, also Bbf und Übf bzw. Bahnhof ohne Personenverkehr als railway=service_station taggen. Solange niemand Argumente dagegen hat, würde ich also diese Lösung so als beschlossen ansehen. --rurseekatze (talk) 18:29, 25 August 2013 (UTC)

Richtung bei einfachen Kreuzungsweichen und Bauform

Kann man irgendwie (am besten ohne Relation oder gar Auftrennen) die "Richtung" (also welche Hälfte die Weichenfunktion hat) bei einfachen Kreuzungsweichen angeben? Ausserdem fehlt noch eine Unterscheidung innen-/aussenliegende Zungen. --rayquaza (talk) 23:58, 7 July 2013 (UTC)

Am einfachsten wäre es wohl, die Abbiegerelationen vom Straßenverkehr auf die Eisenbahn zu übertragen, aber genau wie du möchte ich Relationen auch möglichst vermeiden.

Spontan fällt mir übrigens ein, dass man das vielleicht mit oneway=yes (oder einem vergleichbaren Tag) an den Gleisen angeben könnte. Dazu müsste man sich aber mal alle vorkommenden Weichentypen anschauen und untersuchen, ob sich die Fahrbeziehungen allein mit oneway=yes modellieren lassen. --rurseekatze (talk) 21:12, 14 July 2013 (UTC)

Bei Rückfallweichen wird es schon mit oneway=* etwas kritisch: Zumindest bei der AVG weiss ich von Rückfallweichen, die sich aufschliessen lassen, wodurch oneway=* imo nicht mehr passend wäre. Bei Kreuzungsweichen lässt sich eh jede Relation in beide Richtungen nutzen. Die Abbiegebeschränkungen könnte man imo dafür missbrauchen, würde aber auch nicht so ganz passen – besonders, da man pro Kreuzungsweiche zwei Relationen bräuchte. Ausserdem fehlt dann trotzdem noch die Bauform ;-) --rayquaza (talk) 07:41, 15 July 2013 (UTC)

Also mit oneway=* wäre zwar das Eintragen relativ leicht, aber so richtig geeignet ist das Tag wohl nicht, um damit Abbiegemöglichkeiten zu modellieren. Aber dennoch lehne ich auch Relationen ab, zumindest solange es keine Editoren gibt, die einem das Eintragen erleichtern können. Bei großen Bahnhöfen können schnell etliche solcher Relationen zusammenkommen und diese Daten kann und will auch niemand pflegen.

Bezüglich der Bauform: Ist die Bauform denn überhaupt für irgendetwas interessant? Ich will jetzt hier keine Relevanzkriterien a la Wikipedia einführen, aber man sollte die Daten, die man erfasst, auch irgendwie nutzen und vor allem auch pflegen können. Aber wenn die Daten für dich irgendwie wichtig sind, kannst du sie natürlich erfassen und ein geeignetes Tag dafür vorschlagen.

--rurseekatze (talk) 18:31, 18 July 2013 (UTC)

Die Richtung der Rückfallweichen liesse sich vermutlich ähnlich der turnout_side (bei der mir noch nicht ganz klar ist, wozu sie notwendig ist: Lässt sich das nicht über die Geometrie ermitteln?) erfassen. Bei EKW werden wohl Relationen unvermeidbar. Wenn man das Schema passend gestaltet könnte man jedoch DKW und einfache Kreuzungen ohne Relationen lassen und müsste trotzdem nicht umtaggen.

Zur Bauform: Für eine Simulation wäre es imo schon schön, wenn da die richtige Bauform erscheinen würde und wenn man mit OSM Gleispläne "nachbauen" will braucht man das auch, da die Darstellung etwas unterschiedlich ist. Meine Englischkünste sind allerdings nicht gut genug um dafür Tags zu erfinden. --rayquaza (talk) 23:04, 18 July 2013 (UTC)

Ob man die Abzweigrichtung auch über die Geometrie ermitteln kann, weiß ich nicht. Ich habe mich allerdings bisher auch noch nicht mit diesem Problem beschäftigt. Wenn ich irgendwann vielleicht doch eine Lösung dafür finde, dann könnte man das Tag dann automatisch aus der Datenbank entfernen. Im Moment ist aber erstmal wichtiger, dass die Karte selbst richtig funktioniert. --rurseekatze (talk) 21:59, 20 July 2013 (UTC)

Ich zersetze mal deinen Beitrag zum absatzweisen Antworten. Die Abzweigrichtung ist doch immer das, was den kleineren Radius an den nächsten paar Nodes (der sich ermitteln lässt) hat, oder? --rayquaza (talk) 00:00, 21 July 2013 (UTC)

Was die Fahrbeziehungen angeht: Derzeit finde ich keine Lösung wirklich befriedigend. Daher ist es wohl sinnvoll, dieses Thema erstmal zurückzustellen, bis sich eine bessere Lösung findet. Da derzeit noch kein Routing möglich ist und es auch noch nicht geplant ist, die Fahrbeziehungen von Kreuzungsweichen auf der Karte darzustellen, ist diese Thema ohnehin noch nicht --rurseekatze (talk) 21:59, 20 July 2013 (UTC)

Zum Thema Routing: Doch das gibt es, wenn man Routen-Relationen bastelt ;-) Da kann dann so eine "Abbiegebeschränkung" schon mal "störend" (weil man eben nicht da lang kann wo man vermutete) werden. Aber dafür reicht es auch erstmal, wenn es als note=* dran steht (Vorschlag: Der Text sollte zum Wiederfinden "EKW" enthalten). --rayquaza (talk) 00:00, 21 July 2013 (UTC)

Zur Bauform: Als Key würde ich spontan railway:switch_rail=* vorschlagen. Ich habe versucht, einen passenden Begriff für die Bauformen zu finden, aber scheinbar gibt es im Englischen keinen entsprechenden Ausdruck für "Engländer" und "Bäseler". Entweder übersetzt man die Werte einfach frei ins Englische, also "british" und "baeseler", oder man verwendet "inside" und "outside" als Angabe für die Lage der Zungen. Letztere Variante wäre wohl auch für Außenstehende verständlich, während die erste Variante wohl eher an die Eisenbahn-Fachsprache angepasst ist. Welche Variante der Values (inside/outside oder british/baeseler) bevorzugst du?

--rurseekatze (talk) 21:59, 20 July 2013 (UTC)

Wenn ich das hier richtig interpretiere ist "double outside slip switch" eine DKW mit aussen liegenden Zungen und "double inside slip switch" eine DKW mit innen liegenden Zungen. "switch_rail" klingt für mich noch etwas seltsam, wie kamst du darauf? Ich wäre eher für "railway:switch:configuration"=* (laut leo.org: "Bauform"=="configuration") oder "railway:switch:type"=*. --rayquaza (talk) 00:00, 21 July 2013 (UTC)

Laut Wikipedia heißt eine Weichenzunge "switch rail" oder auch "point blades". Das mit "double inside/outside slip switch" hatte ich wohl überlesen, damit gibt es ja scheinbar doch einen passenden englischen Begriff.

Bislang sieht das Taggingschema railway:switch=double_slip für DKWs vor. Ich würde vorschlagen, dass wir dieses Tag auch für das Tagging der Bauform verwenden. Heißt also: railway:switch=double_slip kennzeichnet eine DKW ohne Angabe der Bauform, gibt man dagegen railway:switch=double_inside_slip oder railway:switch=double_outside_slip an, ist gleich auch noch die Bauform spezifiziert. Wie findest du die Idee? --rurseekatze (talk) 13:05, 21 July 2013 (UTC)

Ich fände das nicht so gut, da man damit nicht mehr einfach so nach "DKW" suchen könnte sondern nach {"DKW" oder "DKW (innen)" oder "DKW (aussen)"} suchen müsste. Es sollte also imo schon in einem eigenen Tag sein, das eine genauere Spezifikation von "railway:switch"=double_slip darstellt. Am besten sollte dieses einigermassen allgemein gehalten sein, um den Key weiternutzen zu können, falls es bei einer anderen Weichenart hinreichend deutliche Unterschiede zwischen Bauformen geben sollte, die wir bisher noch nicht bedacht haben. --rayquaza (talk) 15:04, 21 July 2013 (UTC)

OK, das stimmt natürlich. Dann würde ich railway:switch:configuration=inside/outside vorschlagen. Wenn du keine weiteren Schwierigkeiten siehst, würde ich das so auf der Taggingseite und im JOSM Preset ergänzen. --rurseekatze (talk) 20:22, 4 August 2013 (UTC)

Mir fällt jetzt gerade nichts dagegen sprechendes ein ;-) --rayquaza (talk) 06:28, 5 August 2013 (UTC)

Habe die Taggingseite und das JOSM Preset entsprechend angepasst. --rurseekatze (talk) 17:22, 7 August 2013 (UTC)

weitere "Bauform": Bewegliches Herzstück

Mir ist noch etwas für "railway:switch:configuration"=* eingefallen: Bewegliche Herstücke. Mein Vorschlag für den Value wäre "moveable_point_frog" (britisch, evtl kurz als "movable_frog") oder "swingnose_crossing" (amerikansch, evtl kurz als "swingnose"?) (Quellen: wikipedia:en:Swingnose crossing und sh1.org). --rayquaza (talk) 01:11, 16 August 2013 (UTC)

Gibt es eventuell Konflikte mit den Werten inside/outside beim Tag railway:switch:configuration=*, oder kommen bewegliche Herzstücke bei DKWs nicht vor? --rurseekatze (talk) 17:39, 25 August 2013 (UTC)

Ich kenne keine, aber bekanntlich gibt es bei der Bahn ja nichts, was es nicht gibt ;-) Es dürfte mEn zumindest selten genug sein, dass man sich dafür einen Sonderfall-Workaround einfallen lassen kann (und sei es (imo unschöne) Semikolon-Trennung). --rayquaza (talk) 18:39, 25 August 2013 (UTC)

Ich würde aber doch ein separates Tag bevorzugen. Vielleicht railway:switch:movable_frog=yes/no? --rurseekatze (talk) 19:58, 24 September 2013 (UTC)

Wäre für mich in Ordnung. Die paar die ich kenne habe ich bisher nur mit note=* getaggt und Taginfo zeigt auch keine Verwendungen, also auch kein Umtaggen nötig. Ein weiteres Argument für einen eigenen Key wäre, dass es dabei vermutlich auch verschiedene Bauformen gibt, die man dort anstelle des yes/no angeben könnte. --rayquaza (talk) 03:33, 25 September 2013 (UTC)

Ich habe das Tag zum Taggingschema und zur JOSM Vorlage hinzugefügt. --rurseekatze (talk) 13:44, 25 September 2013 (UTC)

Teilnummern Kreuzungsweichen

Ich greife das Thema nochmal auf, weil ich gesehen habe im Lübecker Raum das eine Kreuzweiche im Prinzip aus zwei hintereinander liegenden Weichen besteht (aber bautechnisch das wohl doch nicht der Fall ist) und die Nummern 23a bzw. 23b sind. Sollte das jetzt jeweils als eine Weiche mit Typ Kreuzweiche und den a,b-Nummern erfaßt werden ?--Lübeck (talk) 08:48, 14 March 2014 (UTC)

Die a- und b-Nummern beschreiben in der Regel die Weichenantriebe, von denen bei einer Kreuzungsweiche mehrere vorhanden sind. Im momentanen Taggingschema sind Weichenantriebe aber nicht vorgesehen. Die Kreuzungsweiche trägt also nur die Nummer und sollte daher auch lediglich die Nummer als Wert im ref-Tag erhalten. --rurseekatze (talk) 21:24, 23 October 2014 (UTC)

Beispielsweise bei der Stadtbahn Heilbronn gibt es eine EKW (n897994154), die statt a/b wirklich zwei Nummern hat. --rayquaza (talk) 14:41, 24 October 2014 (UTC)

Abtsche Weiche

Standseilbahnen haben ja spezielle Weichen für die Ausweichstellen, die sog. Abtsche Weichen. Könnte man die in das Tagging-Schema für Weichen einarbeiten? railway:switch=abt? (nicht verwechseln mit rack=abt!...)--Geogast (talk) 13:48, 29 July 2013 (UTC)

Klingt gut, können wir so übernehmen. Werde ich gleich im JOSM Preset und auf der Taggingseite ergänzen. --rurseekatze (talk) 17:52, 4 August 2013 (UTC)

OK, ist nun ergänzt --rurseekatze (talk) 19:14, 5 August 2013 (UTC)

mehrere Objekte an selber Stelle

Ich hatte jetzt schon ein paar mal das Problem, das teilweise real mehrere Objekte an einer Stelle sind: z.B. ein Signal, das den Betreiberwechsel definiert, am selben Mast Tafeln in unterschiedlicher Richtung. Wie sollte sowas erfasst werden? --rayquaza (talk) 09:00, 30 July 2013 (UTC)

Bislang habe ich für solche Fälle noch keine Lösung gefunden. Zwar könnte man das Tagging auch so ändern, dass man nicht für den Node, sondern für jedes Einzelsignal die Richtung angibt, aber das verkompliziert meiner Meinung nur das Tagging. In mehr als 90% der Fälle sind Signale ja auch nicht an einem Mast befestigt, und bei den paar Sonderfällen, muss man dann eben zwei Nodes nebeneinander setzen.

Von was für einem Signal für den Betreiberwechsel sprichst du? --rurseekatze (talk) 20:19, 4 August 2013 (UTC)

Irgendwo hatte ich glaube ich sogar schonmal sowas gemacht (also z.B. "railway:signal:speed_limit:position"=*). Könnte man das (und auch für "railway:signal:*:direction"=*) als Variante zulassen? Also so, dass (ähnlich wie beim Access-Schema) spezifischeres allgemeineres überschreibt.

Zwei Nodes dafür fände ich etwas blöd, da man das schon z.B. bei dem ganz einfachen Fall "Hinrichtung: Lf7 Kz3; Rückrichtung: Lf7 Kz8" oder bei einer Lf2/Lf3-Wendetafel bräuchte. --rayquaza (talk) 07:33, 5 August 2013 (UTC)

Das klingt gut und sinnvoll. Ich denke, dass wir das so übernehmen können.

Da stellt sich nur die Frage, wie man das JOSM-Preset dementsprechend anpassen kann, sodass man Richtung und Standort auch für einzelne Signale festlegen kann, trotzdem aber bei den Standardfällen nur für den Mast Richtung und Standort angeben muss. --rurseekatze (talk) 08:57, 14 August 2013 (UTC)

Evtl. mit einer Checkbox "Richtung nur für diesen Signalteil"? Ob man mit einer Checkbox etwas in einen Key einsetzen kann weiss ich jedoch nicht. Ansonsten würde ich es (erstmal) aus der Vorlage rauslassen und nur in der Spezifikation ergänzen – Wer es sucht wird es schon finden ;-) --rayquaza (talk) 14:42, 14 August 2013 (UTC)

Das Problem bei den JOSM-Presets ist, dass sie (derzeit) nicht verküpft werden können. Eine Checkbox etwa ist fest einem Tag zugewiesen und kann nur den Wert true oder false setzen. Was aber nicht geht sind Verknüpfungen wie "wenn bei einem Feld Eintrag x ausgewählt wurde, dann soll Auswahlfeld y nicht erscheinen/nur bestimmte Auswahlmöglichkeiten anbieten".

Vielleicht verbessern die Entwickler von JOSM dies in der Zukunft, denn dann könnte man einige Taggingdialoge einfacher gestalten.

Aber so, wie man auch nicht für die Renderer taggt, sollte man sich beim Taggingschema wohl auch nicht nach den begrenzten Möglichkeiten von Editoren orientieren. Daher denke ich, dass man das vorgeschlagene Tagging so in die Spezifikationen übernehmen kann, und bis eine entsprechende Unterstützung durch JOSM gegeben ist, vorerst die bisherigen Vorlagen beibehält. --rurseekatze (talk) 09:34, 16 August 2013 (UTC)

Ich habe gerade festgestellt, dass dein Taggingvorschlag ja nur für unterschiedliche Signale an einem Mast funktioniert, aber nicht, wenn etwa zwei Geschwindigkeitstafeln mit unterschiedlichen Werten für jede Richtung an einem Mast hängen. Denn beide Signale sind ja ein railway:signal:speed_limit und können daher nicht mit dem Anhängen von *:position oder *:direction unterschieden werden. --rurseekatze (talk) 09:45, 21 August 2013 (UTC)

Ja, das ist mir heute auch aufgefallen. Ich habe mich an einer kreativen Lösung versucht ;-) --rayquaza (talk) 12:14, 21 August 2013 (UTC)

Das klingt nicht schlecht. Allerdings sehe ich auch hier wieder Probleme:

In Österreich etwa habe ich an eingleisigen Strecken schon Geschwindigkeitswechsel gesehen, bei denen für jede Richtung jeweils rechts des Gleises eine Geschwindigkeitstafel stand (Beispiel: http://youtu123.be/HMHslpGMNYE?t=10m16s - musste '123' wegen Spamschutzfilter einfügen, bitte entfernen). Auch mit deinem letzten Vorschlag lässt sich dies nicht taggen.

Man könnte natürlich sagen, dass die beiden Geschwindigkeitstafeln nicht am gleichen Mast, sondern an zwei unterschiedlichen Masten hängen und jedes railway=signal genau einen Mast abbilden soll. Allerdings finde ich das etwas unschön, weil dann etwa in meinem Beispiel immer nur eine Tafel auf den Verbindungsnode der am Geschwindigkeitswechsel gesplitteten Ways gesetzt werden und der andere dann ein Stück davor oder dahinter gesetzt werden muss. --rurseekatze (talk) 18:01, 25 August 2013 (UTC)

Das mit den mehreren Knoten an (fast) selber wollen wir hier doch gerade loswerden ;-) Sowas würde ich mit "railway:signal:position:forward"=right lösen. Man müsste allerdings festlegen, wie man das "backward" dabei wertet: Ändert sich dabei auch die Betrachtungsrichtung des Ways? Da es das afaik bei anderen Tags tut würde ich die Situation im Video mit "railway:signal:position:forward"=right "railway:signal:position:backward"=right (also bei beiden *=right!) taggen. --rayquaza (talk) 07:42, 26 August 2013 (UTC)

Ich würde das Links/Rechts immer streng nach Wegrichtung sehen, ansonsten muss man drei Mal um die Ecke denken. Ansonsten finde ich das Tagging ansprechend. PS: In Österreich sind die Tafeln bei zweigleisigen Strecken außen, ansonsten (fast) immer rechts (oder oben). --Jimmy K (talk) 17:16, 1 September 2013 (UTC)

Mit "Signal für den Betreiberwechsel" meinte ich ein (ganz normales) Hauptsignal, an dem der Übergang zwischen Ril408 und FV-NE ist (nicht direkt Betreiberwechsel, aber das gibt es bestimmt auch).

Btw: Hast du eine Idee, wie man zwischen Ril408 und FV-NE unterscheiden könnte? Eine Spezifizierung von working_rules=* vielleicht? --rayquaza (talk) 07:33, 5 August 2013 (UTC)

Spontan weiß ich nicht, wie man das erfassen soll, ein Betreiberwechsel ist es jedenfalls nicht. Ich bin aber auch mit Ril408 und FV-NE nicht vertraut und weiß daher nicht so genau, was beide Vorschriften besagen wie dieser Übergang zwischen beiden aussieht. --rurseekatze (talk) 08:57, 14 August 2013 (UTC)

Ich meinte mit der letzten Frage nur die Unterscheidung, welches Regelwerk auf einer Strecke gilt (wie bei working_rules=*), nicht den Übergang. Damit liesse sich vermutlich auch der Übergang ausreichend gut abbilden. --rayquaza (talk) 14:42, 14 August 2013 (UTC)

Angabe Signaltyp im Ausland

In Deutschland erfasst man nach dem derzeitigen Taggingschema etwa eine Trapeztafel als railway:signal:main=ne1 taggt. Nun gibt es aber im Ausland oft keine einheitlichen Kürzel für die unterschiedlichen Signale. Für diese Fälle hatte ich bisher vorgesehen, einfach nur yes anzugeben. In manchen Ländern lässt sich damit aber der exakte Signaltyp nicht genau genug taggen.

Ein Beispiel ist Österreich: Im Signalbuch der ÖBB haben die Signale keine einheitlichen Abkürzungen wie in Deutschland (Ne 1, etc.), sondern nur einheitliche Namen. Würde man aber etwa eine Trapeztafel nur mit railway:signal:main=yes taggen, könnte man sie nicht von "normalen" Hauptsignalen" unterscheiden. Daher würde ich vorschlagen, in Ländern, in denen es keine einheitlichen Bezeichnungen für Signalbegriffe gibt, den vollständigen Namen mit vorangestelltem Länderkürzel anzugeben, etwa railway:signal:main=AT:Trapeztafel bei einer Trapeztafel in Österreich oder auch railway:signal:whistle=AT:Gruppenpfeifpflock bei einem Gruppenpfeifpflock.

Sieht jemand irgendwelche möglichen Probleme? Sonst würde ich das so in das Taggingschema übernehmen. --rurseekatze (talk) 13:21, 26 August 2013 (UTC)

Finde ich sehr passen und lässt sich dann auch bei Bedarf recht leicht (länderabhängig) in ein neues Schema umwandeln. Habe es jetzt auch bei meinem Taggingvorschlag für AT bei den states eingeführt. Somit wäre es dann AT:frei;AT:halt;AT:40;AT:60?

Ja genau. Wobei ich vorschlagen würde, hier im Wiki eine Liste von Signalbegriffen und dem zu verwendenden Tag anzulegen, denn dass Frei mit 60 km/h zu AT:60 wird, dürfte Außenstehenden nicht klar sein.

Dann werde ich mal das Taggingschema um diesen Hinweis ergänzen sowie an geeigneter Stelle eine besagte Liste anlegen. --rurseekatze (talk) 16:51, 2 September 2013 (UTC)

Gibt es ein Schema für die Geschwindigkeits(vor)anzeiger? Konnte leider nichts finden --Jimmy K (talk) 17:44, 1 September 2013 (UTC)

Ja, siehe Geschwindigkeisbegrenzung. --rurseekatze (talk) 16:51, 2 September 2013 (UTC)

Überarbeitung Tagging Weichen

Das derzeitige Taggingschema für Weichen [2] weist eine Schwachstelle auf: Es ist zum Beispiel nicht möglich, eine Y-Rückfallweiche korrekt zu taggen. Deswegen würde ich vorschlagen, die Information "Rückfallweiche ja/nein" in ein separates Tag zu ziehen, statt wie momentan vorgesehen im Tag railway:switch=* unterzubringen. Ich würde dazu das Tag railway:switch:resetting=yes/no vorschlagen.

Gibt es noch Verbesserungsmöglichkeiten zu diesem Vorschlag? --rurseekatze (talk) 20:02, 26 September 2013 (UTC)

Außerdem fehlt beim bisherigen Tagging ein Tag für Bogenweichen. Diese Information sollte man mit dem Tag railway:switch=* erfassen. Gibt es Ideen für den zu verwendenden Wert? --rurseekatze (talk) 17:01, 23 September 2013 (UTC)

Könnte man Bogenweichen (egal ob Aussenbogenweiche oder Innenbogenweiche) nicht einfach aus der Geometrie erkennen? Das erscheint mir etwas zuverlässiger. Ich habe hier mal etwas zur Erkennung von Kurven geschrieben, was man dazu weiternutzen könnte. --rayquaza (talk) 23:11, 23 September 2013 (UTC)

Lässt sich denn mit diesem Code ausreichend sicher zwischen einfachen Weichen und Bogenweichen unterscheiden?

Grundsätzlich sieht dein Ansatz schonmal interessant aus. Ob er wirklich sicher funktioniert, müsste man mit Testdaten ausprobieren.

Falls du Zeit und Lust hast, dich damit zu beschäftigen: Wäre es möglich, basierend auf diesem Code eine SQL-Funktion zu schreiben, mit der die Information Einfache Weiche/Bogenweiche/Y-Weiche genauso zurückgegeben werden kann, als wäre sie mit einem Tag erfasst, also etwa so: SELECT typeofswitch(geom) AS type from points where tags->'railway'='switch'; ? Das wäre echt genial... ;) --rurseekatze (talk) 11:48, 24 September 2013 (UTC)

Weichen habe ich noch nicht getestet. Wie genau ist denn "Nicht-Bogenweiche" definiert? Also bis wann gilt es als "gerade"? Herauszufinden in welche Richtung davon es abweicht wäre auf jeden Fall möglich. Man bräuchte vermutlich nur einen passenden Grenzwert und müsste den Bogen noch ein Wenig verallgemeinern (ich hatte bei Tests teilweise z.B. bei Rechtskurven auch kurze Stücke nach links drin, sowas müsste man ausgleichen – sonst ergeben gröber gezeichnete Kurven schönere Ergebnisse…). Wenn du ein paar Beispiele jeweils mit OSM-ID des Knotens und Angabe der Art hättest könnte ich da mal etwas rumprobieren.

SQL kann ich nur so ganz grob (für sowas reicht es geradenoch, bei deinem Beispiel muss ich schon raten). Ob es in SQL möglich wäre kann ich also nicht beurteilen. --rayquaza (talk) 13:40, 24 September 2013 (UTC)

Hier sind mal einige Testdaten: http://overpass-turbo.eu/s/17b.

Zur Feststellung, ob eine Weiche einfach oder eine Bogenweiche ist: Da Weichen im Werk fertig zusammmengebaut werden und erst dann komplett eingebaut werden, bezieht sich die Bezeichnung ([3]) und die darin enthaltene Information EW/IBW/ABW wohl nur auf die Länge der Weiche. Nun kann die natürlich stark variieren, von wenigen Metern bei Schmalspurbahnen bis zu mehreren 100m bei Hochgeschwindigkeitsstrecken, doch mit einem Mittelwert von vielleicht 50m sollte man gute Ergebnisse erzielen können.

Heißt also: Man müsste nur die Gleise 25m vor und hinter dem Kreuzungspunkt in die Betrachtung einbeziehen. Vielleicht vereinfacht dies die Erkennung und hilft dir...

Aber generell dürfte die Erkennung per Software nur bei eindeutigen Fällen funktionieren. Bei Grenzfällen dürfte es öfter zu Problemen kommen. Am sichersten dürfte daher das Tagging sein, denn da kann sich der Mapper an der Weichenlaterne oder seiner persönlichen Einschätzung orientieren. --rurseekatze (talk) 20:05, 25 September 2013 (UTC)

Wenn ich die Unterscheidung EW/BW richtig verstanden habe (EW==gerader Zweig mit 0° ±Tolleranz) müsste man nur prüfen, ob beide Ways im Bereich bis zum Herzstück eine Abweichung von z.B. >3° (Zeichentolleranz) vom ursprünglichen Winkel oder z.B. einen Radius kleiner 28 km haben (dann wäre es eine BW). Zur Länge der Weiche hatte ich ja neban was geschrieben und ob ein Bogen innerhalb einer Weiche ist ist zur Ermittlung von Radius, Winkel und Länge nicht relevant.

Genau so meinte ich das. Man müsste nur prüfen, ob eines der beiden abgehenden Gleise auf einer Länge von etwa 25m hinter dem Herstück zusammen mit dem Gleis 25m vor dem Herzstück annähernd eine Gerade bildet. Wie man das genau umsetzt, überlasse ich dir.

Wenn du einen Code in einer Programmiersprache deiner Wahl hast, von dem du glaubst, dass er zuverlässig funktioniert, dann würde ich damit ein Tool bauen, das überprüft, ob erkannter und getaggter Weichentyp übereinstimmen. Weichen, bei denen beide Informationen unterschiedlich sind, könnte man auf einem "Validatorlayer" hervorheben. --rurseekatze (talk) 20:02, 26 September 2013 (UTC)

Die Bogenweichen die ich kenne sind jedenfalls alle recht deutlich gebogen und die EW alle recht deutlich gerade. Wenn dann sollten wir imo die komplette Typbezeichnung (z.B. EW 60-760-1:14 R Fz B, evtl besser die Bestandteile als einzelne Tags) taggen. --rayquaza (talk) 06:26, 26 September 2013 (UTC)

Ich halte es für praktisch nicht umsetzbar, die vollständigen Weichentypbezeichnungen zu taggen. Ohne Daten seitens DB Netz kann man diese Infos wohl kaum in größerem Maßstab erfassen. --rurseekatze (talk) 20:02, 26 September 2013 (UTC)

Zurück zur eigentlichen Frage: Wie wäre es mit dem Tag railway:switch=curved für Bogenweichen? --rurseekatze (talk) 18:24, 1 October 2013 (UTC)

Länderpräfix auch bei deutschen Signalen?

Nach meinem Vorschlag zum Tagging von ausländischen Signalen ohne bestimmte Bezeichnung fiel mir auf, dass es beim Tagging der deutschen Signale zu Problemen kommen könnte:

Möglicherweise gibt es Fälle, in denen etwa das Kürzel hp nicht nur in Deutschland verwendet wird, sondern auch im Ausland. In solchen Fällen wäre eine eindeutige Identifizierung des Signals nicht mehr möglich.

Daher die Frage: Sollte man auch hier ein Länderpräfix vorstellen, sodass etwa aus railway:signal:main=hp railway:signal:main=DE:hp wird, oder wäre es sinnvoller, anhand der Koordinaten des Signals das dazugehörige Land zu ermitteln (womit ein Umtaggen der bereits vorhandenen Signale nicht notwendig ist)? --rurseekatze (talk) 20:24, 25 September 2013 (UTC)

Man braucht nichtmal bis ins Ausland schauen um solche Probleme zu entdecken: Das SOStrab-Singal Sh1 bedeutet "Zwangshalt", das ESO-Signal Sh1 "Fahrverbot aufgehoben". Da bräuchten wir auch schon eine Unterscheidung. Einfach über das working_rules=* des Gleises geht es nicht, da hier teilweise auch BO-Strab-Signale im ESBO-Bereich stehen. Ausserdem kann ein EIU auch weitere Signale festlegen (siehe z.B. in der SbV der AVG), was dann auch wieder nicht zwingend landesweit eindeutig wäre. --rayquaza (talk) 03:40, 26 September 2013 (UTC)

Bei den von dir genannten Signalen der AVG sehe ich keine Probleme, da deren Kürzel nicht in Konflikt zu den herkömmlichen Signalbezeichnungen stehen.

Die Probleme mit BOStrab-Signalen im EBO-Bereich und umgekehrt sind wieder ein anderes Problem. Das könnte man wahrscheinlich noch recht einfach lösen, indem man Signalen, wenn nötig und nicht bereits am zugehörigen Gleis getaggt, das Tag working_rules=* anhängt. Ist das in deinen Augen eine sinnvolle Lösung?

Zum eigentlichen Problem: Ich würde es ja bevorzugen, einfach überall ein Präfix vor dem Signaltypkürzel zu verwenden. Momentan sind aber schon so viele Signale erfasst, dass es mit einem nachträglichen Umtaggen schwierig wird. --rurseekatze (talk) 20:14, 20 October 2013 (UTC)

Dass die Bezeichnungen der "neuen" Signale nicht mit den "normalen" Signalen in Konflikt stehen sollte überall so sein. Allerdings könnte es bei einer anderen Privatbahn gleichnamige Signale geben. Mit working_rules=* am Signal kann man das wohl noch ein Weilchen aufschieben; Eine andere, allgemeinere Lösung (z.B. mit Prefix) wäre vermutlich dennoch sinnvoll. Die meisten derartigen Probleme dürften sich jedoch durch working_rules=* oder operator=* am Signal (bzw. Vererbung vom Gleis) lösen lassen. --rayquaza (talk) 11:42, 21 October 2013 (UTC)

Genau so hatte ich das auch gemeint: Wenn die Werte von working_rules=* und/oder operator=*am Gleis identisch mit denen des Signals sind, dann sind die Tags nur am Gleis notwendig, weil sie sich dann auf das Signal vererben. Wenn es Abweichungen gibt (z.B. BOStrab-Signal im EBO-Bereich), dann muss man die Tags zusätzlich am Signal setzen. Ich werde dieses Vorgehen bei den Sonderfällen dann im allgemeinen Taggingschema oder auf der Seite des länderspezifischen Tagging ergänzen.

Ich denke, dass dies in Verbindung mit einem Länderpräfix vor dem Signaltyp eindeutig genug sein sollte. Jetzt bleibt aber noch offen, wie man die bisher ohne Länderpräfix erfassten Signale sinnvoll umtaggen kann... --rurseekatze (talk) 13:36, 21 October 2013 (UTC)

Mir ist eine Idee gekommen, wie sich das Problem auch ohne Umtaggen der bisher erfassten Signale lösen lässt:

Statt für jeden Signaltyp einen Länderpräfix anzugeben (was bei mehreren Signalen an einem Mast auch etwas redundant wäre), taggt man jedes Signal mit dem Tag working_rules=*, um die Signalvorschrift und ein Länderpräfix, also praktisch den "namespace" für dieses Signals anzugeben.

Das würde dann für ein "normales" Hp-Signal etwas so aussehen: working_rules=DE:EBO. Damit lässt sich auch das Problem der BOStrab-Signale im EBO-Bereich sehr einfach lösen.

Gibt es in einem Land nur eine einzige Signalvorschrift, gibt man nur das Länderpräfix an, also etwa working_rules=RU. --rurseekatze (talk) 21:47, 27 October 2013 (UTC)

Hinweis: ladegleis.de

Im Forum läuft eine Diskussion über eine mögliche Datenübernahme von ladegleis.de, wozu ein paar Tagging-Fragen zu klären wären. --rayquaza (talk) 18:44, 16 December 2013 (UTC)

Richtung der Trasse als Tag ?

Durch die Erfassung der Hektometertafeln ergibt sich eine primäre Richtung für die Fahrtrichtung. Bei den Signalen und anderen Dingen soll auch angegeben werden in/entgegen Fahrtrichtung und die Lage (links/rechts) in Fahrtrichtung. Wäre es nicht gut darüber nachzudenken die Fahrtrichtung wie eine Art Oneway zu definieren (direction_of_travel) um das dann auch in den Editoren als Pfeil anzeigen zu lassen. Das würde die Definition der Wegerichtung sicherlich vereinfachen. Einziges Problem ist, wenn auf einem Gleisstrang eine Stationierung in zwei Richtungen vorliegt (wenn da theoretisch machbar ist). --Lübeck (talk) 08:59, 14 March 2014 (UTC)

Bei Straßenbahnen gib es meist eine vorgeschriebene Richtung, aber selbst bei U- und Stadtbahnen ist dies nicht mehr so fix (Störungen, Bauarbeiten, etc.), aber spätestens im Vollbahnsystem gibt es dank moderner Sicherungstechnik kaum mehr ein vorgeschriebenes Gleis. Es gibt ein Regelgleis (links / rechts) und für bestimmte Zugkategorien noch vorprogrammierte (vorgeschlagene) Routen, ansonsten kann man frei nach Verfügbarkeit wählen. Somit wäre ich zwar für so einen Tag, aber nur dort wo die Richtung tatsächlich nicht änderbar ist. --Jimmy K (talk) 15:21, 28 April 2014 (UTC)

Langfristig ist es auf jeden Fall notwendig, ein Tag für die übliche Verkehrsrichtung auf einem Gleis anzugeben, was vor allem für das Routing wichtig ist.

Allerdings habe ich noch nicht so richtig verstanden, wie sich dadurch das Mappen vereinfachen soll. --rurseekatze (talk) 22:22, 11 April 2014 (UTC)

das ist doch ganz einfach. Wie soll ein "Laie", was die meisten von uns sind erkennen was die Fahrtrichtung ist und wenn dann an anderen Objekte wieder rechts/links der Fahrtrichtung definiert wird. Das kann schnell zu Fehlinterpretationen und damit Informationsverlust führen. --Lübeck (talk) 06:45, 23 April 2014 (UTC)

Ich habe den Eindruck, dass viele Streckengleise ohnehin in Regelfahrtrichtung ausgerichtet sind und dies entsprechend in JOSM dargestellt wird. Darauf aufbauend kann ja schon jetzt angegeben werden, ob und ggf. inwieweit ein Gleis auch in Gegenrichtung befahrbar ist (Gleiswechselbetrieb etc.). Bei eingleisigen Strecken habe ich die Wege indes in Kilometrierungsrichtung aufsteigend ausgerichtet. --Bigbug21 (talk) 06:53, 27 April 2014 (UTC)

Ein sehr exotischer Fall, aber es gibt auch Strecken, wo historisch bedingt die Kilometrierung entgegen der "Streckenausrichtung" läuft. Somit würde ich vorschlagen, dass man die Strecke km-aufsteigend ausrichtet und zusätzlich tags anführt in welche Richtung das Gleis befahrbar ist (z.B.:1/-1/both) und welches die Regelrichtung ist. (und noch ein exotisches Tag für den Fall der entgegenlaufenden Kilometrierung) --Jimmy K (talk) 15:21, 28 April 2014 (UTC)

Für mich stellt sich weiterhin die Frage, wozu die Streckenausrichtung interessant ist. Da sie scheinbar nicht unbedingt identisch mit der Kilometrierung sein muss, ist sie ja für den außenstehenden Mapper nicht erkennbar.

Für die Kennzeichnung der Regelfahrtrichtung würde ich das Tag railway:traffic_direction=* oder traffic_direction=* vorschlagen. Als Werte können forward, backward und both (nur bei eingleisigen Strecken) verwendet werden. In Kombination mit railway:bidirectional=* könnte so detailliert die Regelfahrtrichtung und eine eventuelle Befahrbarkeit des Gegengleises erfasst werden. --rurseekatze (talk) 15:38, 4 May 2014 (UTC)

Es ist sicher nicht verkehrt, bei zweigleisigen Strecken (mit je einem Gleis je Regelfahrtrichtung) die Gleise in Regelfahrtrichtung auszurichten. Bei eingleisigen Strecken könnten wir uns dagegen an dem Standard der Eisenbahnplanung orientieren, alles immer nur in Kilometrierungsrichtung aufsteigend zu sehen (und auszurichten). ;) --Bigbug21 (talk) 16:08, 5 May 2014 (UTC)

Arbeitsblatt für die Signale

Es gibt ja auch bei anderen Techniken immer so Blätter mit Kurzreferenzen zu Programmiersprachen zum Beispiel. Im ORM-Tutorial werden auch einige Links genannt - ich würde es klasse finden, wenn einer der Signal-Spezis mal etwas zusammenstellen könnte um das dann mit in den "Außendienst" zu nehmen. Wenn man dann noch eine Kurznummer darunterschreibt, dann wäre das "Feldbuch"-Führen noch einfacher. In der letzten Variante könnte vor den Bezeichnungen im JOSM-Present diese wieder auftauchen was die Identifizierung vereinfachen würde. ... ? --Lübeck (talk) 08:59, 14 March 2014 (UTC)

Kannst du vielleicht ein kurzes Beispiel geben, wie du dir so eine Übersicht vorstellst? --rurseekatze (talk) 22:29, 11 April 2014 (UTC)

Lübeck, kauf dir doch einfach Signale der deutsche Eisenbahn. Da stehen die ganzen Abkürzungen (z.B. Hp0, Sh1, Lf7) mit Bildern drin. Du kannst dir dann in deinem Feldbuch die Abkürzung notieren. Im Laufe der Zeit lernt man die Abkürzungen. Eine ältere Ausgabe (ca. sieben Jahre alt) des Buchs habe ich selber im Einsatz. --Nakaner (talk) 19:54, 3 May 2014 (UTC)

Gleisverschlingung

Gleisverschlingungen sind Streckenabschnitte, in denen sich 2 Gleise überlappen. Prominente Beispiele sind Dreischienengleise mit unterschiedlichen Spurweiten. Es gibt aber auch andere Beispiele mit 4 Schienen, die 2 Gleise mit identischen Spurweiten ergeben, zum Beispiel in Bremen; siehe dazu hier und hier; dieser Fall wurde mit 2 ganz dicht liegenden ways gemappt. Das finde ich nicht optimal, denn die Gleise liegen ja nicht neben-, sondern ineinander; Dreischienengleise werden ja auch mit einem way gemappt und einem Semikolon im gauge-Tag. Sollten es besser 2 ways sein, die sich die nodes teilen? Würde man nämlich einen way für beide Gleise nehmen, könnte man im Bremer Beispiel kaum eintragen, dass es einmal railway=rail und einmal railway=tram ist. Zugegeben: Überlappende Gleise (2 ways mit denselben nodes) sind immer unschön, gerade im Handling. Ein Tag wie "gauntlet_track=yes" wäre gut, um anderen Mappern (und einer geneigten Karte...) zu zeigen, was hier los ist.--Geogast (talk) 21:07, 20 March 2014 (UTC)

Per Tags würde sich das Problem wohl nicht lösen lassen. Haben die beiden Gleise nämlich auch noch unterschiedliche Gleisnummern, dann ist das Chaos perfekt. Getrennte Gleise sind also unvermeidbar.

Ich würde jedoch zwei parallele Gleise bevorzugen: Zum einen ist die Bearbeitung einfacher und es ist sofort erkennbar, dass mehrere Gleise eingetragen sind. Zum anderen gestaltet sich das Rendering auf einer Karte einfacher - zumindest wüsste ich nicht, wie man zwei übereinanderliegende Wege gleichzeitig rendern könnte. Auf jeden Fall ist aber ein Tag zur Kennzeichnung der Gleisverschlingung notwendig. --rurseekatze (talk) 22:48, 11 April 2014 (UTC)

Da muss ich zustimmen. Ich sehe große Unterschiede zwischen einem Dreischienengleis und zwei Gleisen, welche sich Lichtraum und Schwellen teilen. Zusätzlich wäre es vermutlich unmöglich abzubilden, dass zwischen den Gleisen nicht gewechselt werden kann. --Jimmy K (talk) 15:05, 28 April 2014 (UTC)

Das letzte ist tatsächlich ein wichtiger Punkt: Bei gemeinsamen nodes scheint es so, als wäre da eine Weiche.--Geogast (talk) 12:37, 1 July 2014 (UTC)

Bahnhöfe als Flächen

In Baden-Württemberg und Hessen wurden einige Bahnhöfe als Fläche von Einfahrsignal bis Einfahrsignal eingetragen. Das führt leider zu Problemen in den meisten gängigen Renderer (vgl. z. B. http://www.openstreetmap.org/note/91467 ), da der Bahnhofspunkt in der Mitte der Fläche und nicht da, wo die eigentlichen Bahnsteige sind, angezeigt wird. Auch Routing-Programme dürften damit ihre Probleme haben.

Gibt es hier vielleicht eine Möglichkeit die "bahntechnische" Fläche eines Bahnhofes oder auch einer anderen Betriebsstelle mit einem anderen Tag zu beschreiben? Spontan würde mir z.B. railway:area=station etc. einfallen. --Mapper999 (talk) 10:07, 5 April 2014 (UTC)

Um dieses Problem zu vermeiden, ist im Taggingschema schon seit längerem die Erfassung mit einer Betriebsstellenrelation vorgesehen. Dabei wird die Betriebsstelle selbst mit einem Node erfasst, der beliebig positioniert werden kann. Zusätzlich wird eine Fläche mit landuse=railway eingezeichnet, die die Ausdehnung der Betriebsstelle abbildet. Die Beziehung zwischen beiden Objekten wird dann über die Betriebsstellenrelation umgesetzt. Beispiel: [4] --rurseekatze (talk) 10:19, 10 April 2014 (UTC)

Eine Bitte an diejenigen, die das jetzt umtaggen: Macht es gefälligst richtig! Sowohl in Heidelberg wie auch in Mühlacker ist es nun fehlerhaft und eine Zuordnung der Fläche dadurch nicht möglich… --rayquaza (talk) 19:10, 27 April 2014 (UTC)

Danke für den höflichen und zielführenden Kommentar. --Jimmy K (talk) 15:22, 28 April 2014 (UTC)

http://forum.openstreetmap.org/viewtopic.php?id=26086 --Geogast (talk) 12:38, 1 July 2014 (UTC)

Basis-Tags?

Welche Tags müssen zwingend vorhanden sein, dass eine Linie bei openrailwaymaps.org angezeigt wird? Ich habe angezeigte und nicht angezeigte Bahnlinien verglichen und bin nicht drauf gekommen. Kann mir jemand auf die Sprünge helfen? z.B. in Afrika ist auf openrailwaymaps.org noch sehr viel weiss, obwohl auf openstreetmaps.org deutlich mehr Eisenbahnen vorhanden sind. --Männedorf (talk) 13:41, 16 March 2017 (UTC)

openrailwaymaps.org ist bei mir grau und oben rechts steht in weiß auf orangem Grund "Diese Domain kaufen". Die Website, die du meinst, heißt vermutlich openrailwaymap.org. Dieses Projekt hat eine Mailingliste, die aktiver ist und von mehr Leuten gelesen wird. Du musst die Mailingliste abonnieren, bevor du Mails an sie senden kannst. --Nakaner (talk) 13:45, 16 March 2017 (UTC)

Grundsätzlich werden Gleise mit folgenden Tags gerendert: railway=rail/light_rail/subway/tram/narrow_gauge/preserved/disused/abandoned/razed. Beim Rendering wird aber unter anderem auch das Tag usage=* ausgewertet. Es entscheidet mit darüber, ab welcher Zoomstufe ein Gleis angezeigt wird. Gleise ohne usage-Tag werden erst in höheren Zoomstufen gerendert und auch nur als schwarze Linien. Vermutlich ist das der Grund dafür, dass in Afrika viele Bahnstrecken nicht bzw. erst in hohen Zoomstufen erscheinen. --rurseekatze (talk) 14:05, 2 April 2017 (UTC)

La-Streckennummern

Bisher sind KBS- und VzG-Nummern im Taggingschema verankert. Das ginge doch prinzipiell auch für die La-Streckennummern [5], die ja nochmals einer komplett eigenen Systematik folgen, oder? Als Tag vielleicht ref:la=* (bei mehreren La-Nummern auf einem Gleis werden die einzelnen durch Semikolon voneinander getrennt), Relation route=la oder ähnlich, in Bahnhöfen zu erfassen nur für durchgehende Hauptgleise. Oder gibt es schon vergleichbares, was ich bisher nicht entdeckt habe?

Rechtlich ist es u.U. schwierig, aus den Streckenbückern abzuschreiben, aber wenn ich als Tf auf ner bestimmten Strecke unterwegs bin und damit arbeite, müsste doch eigentlich alles in Butter sein... --Tocosibirsk (talk) 12:26, 9 December 2017 (UTC)

Eisenbahndraisinen

Wie werden Draisinen beschrieben?

Geht das mit railway=disused + draisine=yes? --geozeisig (talk) 12:30, 22 June 2018 (UTC)

Anmerkungen zu Österreich

Einige Anmerkungen von mir zu den großartigen Taggingschemen:

1.) Bremsprobesignale und Abdrücksignale gibt es schon lange nicht mehr, habe die entsprechenden Passagen aus dem Taggingschema schon gelöscht. Es wurden nie welche getaggt, die Presets können gelöscht werden.

Auch Verschub-Grenzmarke und Grenzmarke für Rollwagenbetrieb gibt es nicht mehr.

2.) Bei Hauptsignalen gibt es als fünfte Funktion Deckungssignale, welche Überleitstellen und Abzweigstellen decken. Bisher waren diese als railway:signal:main:function=block getaggt, ich habe dies für die betreffenden Signale auf function=protection ausgebessert. Bin gerne für bessere Vorschläge bereit, wenn der Tag so passt bitte in die Presets einarbeiten. Im Wiki hab ichs schon angepasst.

3.) Ebenso gibt es Signale, die je nach befahrenen Fahrstraßen verschiedene Funktionen haben, also beispielsweise Ausfahr- und Zwischensignale sind. Habe einige davon mit Schrägstrich getaggt, mit der Reihenfolge hab ich mich an logische Gesichtspunkte gehalten.

4.) Es gibt keine einheitliche Vorgangsweise für Verschubsignale, welche sich auf Hauptsignalen befinden. Ich bin bisher so vorgegangen, ein eigenes Verschubsignal in Mastbauform gemäß Preset auf den Hauptsignalnode zu taggen, und dann den state AT-V2:verschubverbot zu löschen, da Verschubsignale auf Hauptsignalen grundsätzlich natürlich kein Verschubverbot zeigen.

Am sinnvollsten fände ich es, im Preset der Hauptsignale eine Checkbox "Shunting signal" einzufügen, welche bei Aktivierung die Tags railway:signal:shunting=AT-V2:verschubsignal railway:signal:shunting:form=light railway:signal:shunting:states=AT-V2:verschubverbot_aufgehoben einfügt.

Möglich wäre es auch, mittles des keys height=normal bzw. height=integrated zwischen eigenen unter den Hauptsignalen angebrachten sowie im Hauptsignalschirm integrierten Verschubsignalen zu unterscheiden, da es beide Varianten gibt.

5.) Eine ähnliche Problematik gibt es bei den Schutzsignalen. Es gibt alte Schutzsignale ("Schutzsignal alter Bauart") und neue Schutzsignale ("Schutzsignal neuer Bauart"), welche sich dadurch unterscheiden, dass die neuen zusätzlich zu Fahrverbot und Fahrverbot aufgehoben auch Verschubverbot aufgehoben zeigen können und durch einen senkrechten weißen Strich in der Mitte des Schirms gekennzeichnet sind. (Siehe hier)

Hier habe ich es bisher ähnlich wie bei den Hauptsignalen handgehabt, auch hier wäre eine Checkbox in den Presets wünschenswert.

6.) Eine eher philosophische Frage: Ist es wirklich notwendig, Schneeräumsignale zu taggen? Von einer auch nur entfernt vollständigen Aufnahme mal abgesehen, inwiefern sind solche Signale relevant? Sehe da wirklich keinen Bedarf daran.

Ähnliches denke ich über Grenzmarken. Jede Weiche hat eine bzw. zwei Grenzmarken, sehe kaum Mehrwert, diese zu taggen.

Und last but not least: Langsamfahrsignale sind meist nur von kurzer Dauer aufgestellt, wurden bisher noch nicht getaggt, auch hier würde ich eine Streichung aus Wiki und Presets erwägen.

Mfg Negjana

--Negjana (talk) 14:01, 19 September 2018 (UTC)

Wird OpenRailwayMap noch aktiv unterstützt?

Hallo,

da es momentan ein Problem mit dem Rendering in verschiedenen Ebenen gibt, habe ich versucht, hier einen Kontakt herzustellen. Leider habe ich nach mehreren Tagen keine Antwort bekommen. Wird das Projekt momentan noch unterstützt? Die Blogeinträge sind ja teilweise schon über ein Jahr alt. Wen jemand was weiß, mich bitte wissen lassen ;-)

Viele Grüße

Patrick--Patrick1977 (talk) 15:59, 12 April 2019 (UTC)

Hallo zusammen, ich frag mich auch, was hier los ist. Meine Änderungen wurden nur teilweise abgebildet. Wie kann ich helfen? —EM311 (talk) 14:43, 17 August 2019 (UTC)

@Patrick1977:@EM311: Ich habe ein Ticket bei GitHub dazu gefunden: OpenRailwayMap/server-admin/issues/15. Sieht mir nicht so aus als würde sich jemand aktiv um etwas kümmern. Auf der Seite OpenRailwayMap/openrailwaymap-blog/blob/master/AUTHORS stehen E-Mail-Adressen, vielleicht ist das eine Hilfe? --Tigerfell  (Let's talk) 20:23, 18 August 2019 (UTC)

Alex hab ich schon per Mail angeschrieben, bisher ohne Antwort :-( Ich nehme hier mal @Rurseekatze: und @Nakaner: dazu. --EM311 (talk) 09:00, 19 August 2019 (UTC)

Achterbahnen

Hallo, beim Durchsehen der OSM-Karte ist mir aufgefallen, dass Achterbahnen dort erscheinen (da sie als Schmalspurbahnen getaggt sind), Miniatur-/Aufsitzgartenbahnen aber nicht (wenn sie korrekt als Miniaturbahn getaggt sind). Ist das "im Sinne des Erfinders"? Grüße --Chriz1978 (talk) 14:27, 22 July 2020 (UTC)

Aus meiner Sicht ist das falsch, für Achterbahnen gibt es das Tag roller_coaster=track. Ich habe auch schon Kranbahnen gesehen, die als railway getaggt waren. --EM311 (talk) 14:58, 22 July 2020 (UTC)

Ja, das hört sich besser an. Ich habe dann mal den ersten von "Miniatureisenbahn" auf "attraction=roller_coaster" umgestellt. --Chriz1978 (talk) 10:51, 23 July 2020 (UTC)

Miniatureisenbahnen

Wieso werden eigentlich Miniaturbahnen (=Gartenbahnen mit Aufsitz) nicht in der Karte dargestellt, obwohl es vorne im Artikel ja beschrieben wird? --Chriz1978 (talk) 10:51, 23 July 2020 (UTC)

Electrification Legende (Farben)

Hallo,

Welche Bedeutung haben die Farben der Bahnlinien im Kartenthema Electrification? [6]

Die Karte ist sehr langsam. Kann man dem mit einem schnelleren Server Abhilfe schaffen?

--Alex-esko (talk) 18:37, 17 February 2021 (UTC)

@Alex-esko: Eine Legende findet sich hier: https://www.openrailwaymap.org/legend-generator.php?zoom=7&style=electrified und wird zumindest auf Desktoprechnern auch in der Seitenleiste angezeigt. --Nw520 (talk) 15:40, 3 June 2022 (UTC)

Schild an Oberleitungsanlagen

hier: grüne 13 an Oberleitungen in Neunkirchen (Saar)

An einigen Tragseilen einiger Oberleitungen habe ich kleine rechteckige einfarbige Plastikschilder mit ausgestanzer Zahl bemerkt. Was sagen die aus und wie kann man sie in OSM erfassen? --Nw520 (talk) 11:42, 26 September 2021 (UTC)

Heimatgeschichte

Hallo, in der letzten Bearbeitung dieser Seite wurde folgender Absatz hinzugefügt:

* Heimatgeschichte: Dargestellt werden neben in Betrieb befindlichen Strecken auch stillgelegte und abgebaute, deren genauer Verlauf in natura durch städtebauliche oder landschaftliche Veränderungen gegebenenfalls nicht mehr nachvollziehbar wäre.

Das widerspricht doch allerdings der "On-The-Ground"-Regel der OSM und wird so immer wieder dort zum Streitpunkt.

Ich weiss daher nicht, ob es so sinnvoll ist, das als "Pluspunkt" zu listen. --Chriz1978 (talk) 17:50, 20 March 2023 (UTC)

Gut, ich nehme es wieder raus. Im Grunde aber sehr schade, es gibt keine andere interaktive Plattform für so etwas. Und im Grunde braucht es ja auch keinen zu stören, da es eh nur in ORM angezeigt wird. Das einzige sind eben die zusätzlichen Linien im Editor, durch die er vielleicht nicht übersichtlicher wird, aber am Ende befinden sie sich ja meist auf (ehemaligem) Bahngelände, das überwiegend ja nur von dieser Art von Interessierten bearbeitet wird, sodass der Zweck dieser Linien bekannt sein sollte. -- Chemnitzer Eisenbahner (talk) 06:06, 21 March 2023 (UTC)

Vielleicht gibt es ja auch andere Meinungen. Deshalb hier auf der Diskussionsseite.

Aber eine entsprechende Diskussion im Forum war da letztens Recht eindeutig, leider. Zumindest ein Streckenband würde ich auch sehen, aber bitte nicht jedes Gleis. Das kann durchaus störend sein, auch in der ORM. Chriz1978 (talk) 07:42, 21 March 2023 (UTC)

Gibt aber auch einige in OSM, die gezielt danach suchen, um es zu entfernen. Am Ende aber nur doppelter Aufwand, den man lieber in die Erfassung neuer Daten hätte investieren sollen. -- Chemnitzer Eisenbahner (talk) 08:41, 21 March 2023 (UTC)