DE talk:OpenRailwayMap/Tagging

From OpenStreetMap Wiki
Jump to: navigation, search

Signal-Relation?

Ich finde die aktuelle Vorgehensweise, Signale als Nodes direkt auf dem Gleis zu platzieren, etwas ungenau, weil dadurch der genaue Signalstandort verloren geht. In Proposed features/Railway Signals ist das so gelöst, dass man eine Relation mit type=signal anlegt, wo der Signalstandort als eigener Node mit role=signal erfasst war. Zusätzlich wird der Wirkpunkt als Node auf dem Gleis mit role=track_position in die Relation aufgenommen. Wäre es nicht sinnvoll, das hier auch so zu lösen? Idealerweise kann man auch beide Taggingvarianten zulassen, das Proposal ist ja auch in ein Schema für Laien und eins für Experten aufgeteilt. --Rohieb 21:25, 6 August 2012 (BST)

Zwar ist der genaue Signalstandort nicht mehr erhalten, aber sonst bietet die Erfassung als Punkt auf dem Gleis meiner Meinung nur Vorteile. Ich hatte erst auch die Erfassung per Relation angedacht und das in einem Testgebiet ausprobiert. Dabei habe ich folgendes festgestellt:
* Das Testgebiet umfasste unter anderem die zehngleisige Ausfahrt eines Rangierbahnhofs. Dementsprechend viele Relationen fanden sich auch in JOSM. Das war unübersichtlich und generell war es bei so vielen Signalen eine ziemliche Arbeit, die ganzen Relationen anzulegen und auch die richtigen Gleise aufzunehmen.
* Bei Punkten neben den Gleisen weiß man manchmal gar nicht mehr auf Anhieb, zu welchem Gleis das Signal gehört. Da musste ich erstmal in die Relation schauen oder überlegen was Sinn ergibt. Bei Punkten auf dem Gleis sieht man dagegen sofort, zu welchem Gleis das Signal gehört.
* Anwendungen haben das gleiche Problem: Sie müssen erst in die Relation schauen, damit sie wissen, zu welchem Gleis das Signal gehört. Bei Punkten auf dem Gleis ist das dagegen sehr einfach. Umgekehrt lässt sich genauso einfach ermitteln, welche Signale auf einem Streckenverlauf liegen (Interessant, wenn man Routing-ähnliche Anwendungen hat und praktisch "auf dem Gleis die Strecke abfährt" um Streckenverläufe wie z.B. in Wikipedia zu generieren).
* Der genaue Signalstandort lässt sich trotzdem recht einfach ermitteln: Abhängig von Wegrichtung oder Tag etwa 2-3m neben dem erfassten Gleis sollte eigentlich immer gut dran liegen. Erfasst man das Signal auf dem Gleis, kann man aber auch noch allein an den Tags erkennen, ob ein Signal auf der "richtigen" Seite des Gleises steht oder nicht. --rurseekatze 15:19, 7 August 2012 (BST)
OK, klingt sinnvoll. Mir ist auch grad aufgefallen, dass das Grenzzeichen im Proposal noch nicht spezifiziert ist. Ich habe das jetzt mal nach der gleichen Logik mit zwei Nodes an beiden Weichensträngen und railway=signal, railway:signal=db:ra12 getaggt. Problematisch wird das hier nur, in welche Richtung ich jetzt das direction-Tag setze, ich würde intuitiv sagen, dass es in Richtung von der Weiche weg "zeigt", weil es ja von dort aus berücksichtigt werden muss. --Rohieb 16:12, 9 August 2012 (BST)
Willst du wirklich auch noch Grenzzeichen aufnehmen? Ich will dich natürlich nicht daran hindern. Ich sehe da aber keinen richtigen Anwendungszweck, das kommt dem Gullydeckelmapping schon sehr nahe... Ist die Richtung beim Grenzzeichen nicht egal? Schließlich darf ein abgestellter Zug doch nirgendwo über die Grenzzeichen herausragen. Hätte man bei einem Zug die Koordianten von Lok und letztem Wagen müsste man doch nur prüfen, ob beide zwischen beiden Grenzzeichen auf diesem Gleis liegen. Oder habe ich zu einfach gedacht? --rurseekatze 21:12, 10 August 2012 (BST)
Naja, ist nur ne Kleinigkeit. Hintergrund meiner Frage: die Firma, in der ich arbeite, baut eine Physik-Simulation und ich wollte mal ein paar Strecken aus der echten Welt per Skript aus OSM einfüttern, und dafür braucht man natürlich die Positionen der Weichenenden. Man muss es ja nicht überall so machen.
Andererseits ist es natürlich besser, eine Spezifikation zu haben, die nicht benutzt wird, als keine zu haben, und jeder, der sowas dann eintragen will, denkt sich seine eigenen Tags dafür aus ;-) Ich denke inzwischen auch, die Richtung ist egal.--Rohieb 14:11, 11 August 2012 (BST)
OK, ist hinzugefügt. --rurseekatze 20:59, 6 October 2012 (BST)

Gleiskreuzung

Ich vermisse einen Tag für eine niveaugleiche Gleiskreuzung, also keine Kreuzungsweiche, sondern sowas. Nachtrag: Nach dem englischen WP-Artikel bieten sich zwei values an: railway=level_junction oder =flat_crossing. railway=junction wird hier aber schon für Abzweige verwendet. Und bei flat_crossing zeigt das "crossing" schön an, worum es hier geht. Vorschlag also: railway=flat_crossing. --Geogast (talk) 10:49, 29 May 2013 (UTC)

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.--Geogast (talk) 21:08, 29 May 2013 (UTC)
Hab's hier nochmal gepostet. Am Besten also dort antworten.--Geogast (talk) 21:32, 8 June 2013 (UTC)

railway=preserved für Museumsbetrieb?

Hallo,

die Definition für railway=preserved ist meiner Meinung nach etwas unklar. Sollen so nur Strecken getagged werden, die nur an sich erhalten werden, auf denen aber kein Eisenbahnbetrieb mehr stattfindet und die demzufolge auch nicht mehr gewidmet sind? Oder auch für Strecken, auf denen regulärer Betrieb von Museumsbahnen nach EBO stattfindet? Hintergrund ist das Tagging der Sauschwänzlebahn im Südschwarzwald. Ist preserved wirklich nur für Draisinenstrecken vorgesehen oder auch für solche Strecken, die sich an sich ja technisch und rechtlich nicht von "normalen" Bahnstrecken unterscheiden?

Gruß

--Margin-auto (talk) 12:16, 19 October 2013 (UTC)

Sinnvoll wäre es, auch Strecken, auf denen ausschließlich Museumsbahnen verkehren, mit railway=preserved zu taggen. Allerdings gibt es da einen Konflikt mit railway=narrow_gauge: Mit welchem der beiden Tags würde man eine Schmalspur-Museumsstrecke taggen? Beim derzeitigen etablierten Tagging ist das nicht wirklich definiert und aus Kompatibilitätsgründen wollte ich das Tagging nicht einfach so grundlegend ändern.
Um diese Frage zu lösen gibt es eigentlich nur zwei Möglichkeiten:
* Die einfache Lösung wäre, dass man einem der beiden Tags eine höhere Priorität einräumen, sodass das eine Tag das andere überwiegt. Konkret würde man dann etwa sagen, dass das preserved auf der Karte eine wichtigere Information ist als die Information, dass es sich um eine Schmalspurbahn handelt, denn die Schmalspurigkeit lässt sich ohnehin mit gauge=* ermitteln, während der Erhaltungszustand "preserved" aus keinem anderen Tag ermittelt werden kann.
* Die schwierige, vielleicht aber auch sinnvollere Lösung wäre eine Überarbeitung des gesamten bisherigen Taggings, denn ähnliche Konflikte bestehen ja etwa auch bei den Tags railway=narrow_gauge und railway=disused. Dies würde aber auch viele andere Anwendungen betreffen und ein Proposal mit Diskussion und Abstimmung notwendig machen. --rurseekatze (talk) 20:56, 22 October 2013 (UTC)

Geschwindigkeit für bestimmte Fahrzeugtypen

Wo hier eben die Angabe über eine GNT-Ausrüstung mit einer eigenen Zeile versehen wurde: Wie wollen wir Geschwindigkeiten für bestimmte Fahrzeugtypen erfassen? Mir fallen da GNT, LNT und LZB als Modifikatoren ein. Würde z.B. "maxspeed:LNT"=* mit irgendeinem momentanen Tagging (inkl maxspeed an Strassen) kollidieren? --rayquaza (talk) 17:31, 15 November 2013 (UTC)

Für die Geschwindigkeit von Neigetechnikzügen mit GNT habe ich bereits das Tag maxspeed:tilting=* vorgesehen. Im JOSM Preset habe ich das eben ergänzt, an der Ergänzung im Wiki arbeite ich im Moment.
Wie wirkt sich denn die LZB auf die Geschwindigkeit aus? Dass man ohne LZB nur bis 160 km/h fahren darf, ist mir bewusst. Aber wenn man nun ein Gleis mit railway=rail, maxspeed=200, railway:pzb=yes und railway:lzb=yes taggt, ist doch eindeutig, dass Fahrzeuge mit LZB 200 km/h fahren dürfen und solche ohne LZB eben nur 160 km/h. Wozu dann ein Tag maxspeed:LZB=*?
Und welchen Sinn hat ein maxspeed:LNT=*? Ist das nur zur Unterscheidung zwischen der Höchstgeschwindigkeit von Straßenverkehr und Straßenbahn, falls diese unterschiedlich sind, oder hat das einen anderen Grund? --rurseekatze (talk) 17:49, 15 November 2013 (UTC)
LZB: Es gibt Stellen an denen man ohne LZB nur weniger als 160km/h fahren darf, mit aber mehr (Beispiel habe ich keines, nur mal irgendwo gelesen). --rayquaza (talk) 20:33, 15 November 2013 (UTC)
Kannst du die Seite noch wiederfinden? Ich würde das gerne selbst sehen, weil ich mir nicht erklären kann, warum Züge langsamer fahren müssen als sie könnten. --rurseekatze (talk) 21:22, 16 November 2013 (UTC)
Sorry für die verzögerte Antwort, ich meinte eigentlich dass hier schon geschrieben gehabt zu haben: Wiedergefunden habe ich es leider nicht. Vermutlich war es irgendwas mit nicht ausreichendem Bremsweg, könnte aber sein, dass ich das mit fehlenden BrH bei ICE verwechsle. --rayquaza (talk) 16:42, 5 January 2014 (UTC)
LNT: Nee, hier gibt es Strecken auf denen man mit LNT (leichten Nahverkehrstriebwagen) schneller fahren darf als mit normalen EBO-Fahrzeugen.
"inkl maxspeed an Strassen" meinte ich, damit möglichst keine Überschneidungen mit unterschiedlichen Bedeutungen entstehen (also z.B. wir nicht "maxspeed:hgv"=* erneut definieren). Unterschiede zwischen Vmax des Strassenverkehrs und Vmax des Schienenverkehrs sind ja schon durch die Erfassung als eigener Way gelöst.
Ein international nutzbares Tagging wäre selbstverständlich besser. --rayquaza (talk) 20:33, 15 November 2013 (UTC)
Hast du mal ein Beispiel, eventuell auch Bilder dazu, wie das dann signalisiert wird? Oder ist das nur in den Buchfahrplänen vermerkt, sodass es an der Strecke keine entsprechenden Hinweise gibt? Und um welche Strecke(n) handelt es sich genau? --rurseekatze (talk) 21:22, 16 November 2013 (UTC)
Das sind die Strecken 9412 und 9413. Signalisiert ist per Lf7 die (höhere) LNT-Geschwindigkeit, zusätzlich gibt es Lf4 mit einem "G" oben drüber für Reduktionen der EBO-Geschwindigkeit. Ansonsten steht das z.B. im Buchfahrplan und in der SbV. Momentan kann man das vermutlich bei den Tankfahrten der derzeit auf der S9 verkehrenden RegioShuttle beobachten. --rayquaza (talk) 16:42, 5 January 2014 (UTC)
Im Detail kenne ich es nicht, aber die Schweizer kennen zum Beispiel unterschiedliche Geschwindigkeitsbegrenzungen für Züge der unteren und oberen Zugreihen (und für Neigetechnikzüge je nach Strecke noch eine weitere Beschränkung). In größerem Umfang gibt es solche speziellen Geschwindigkeitsbeschränkungen auf jeden Fall in Großbritannien. Der einfachste Fall sind unterschiedliche Geschwindigkeitsbegrenzungen für (im Prinzip) Passagier- und Güterzüge, daneben gibt es aber noch eine Reihe von weiteren möglichen speziellen Geschwindigkeitsbegrenzungen, beispielsweise für Triebwagen, elektrische Triebwagen, Dieseltriebwagen, HSTs (und als HST eingestufte Triebwagen), Sprinter (und verwandte Baureihen) uns noch ein paar andere örtliche Sonderfälle. Das einfache maxspeed:tilting=* reicht da übrigens auch nicht ganz. In GB gibt es aktuell zwei Baureihen mit Neigetechnik - den elektrischen Pendolino (Class 390) und den dieselbetriebenen Super Voyager (Class 221) - und mancherorts gibt es damit zwei unterschiedliche Neigetechnikgeschwindigkeiten (die Voyager dürfen an manchen Stellen zwar immer noch schneller als normale Züge, aber langsamer als die Pendolini fahren). --JanTH (talk) 11:22, 17 February 2016 (UTC)

Mastschilder

Haben wir schon etwas für Mastschilder? Falls nicht würde ich railway:signal:main:traversable=* mit noch zu findenden Werten vorschlagen. --rayquaza (talk) 16:09, 5 January 2014 (UTC)

Straßenbahnsignale

Wie sollten Straßenbahnsignale eingetragen werden?

Ich habe dafür bisher railway:signal:main=tram für Fahrsignale[1] und railway:signal:switch=tram für Weichensignale[2] benutzt. --Mapper999 (talk) 15:47, 4 February 2014 (UTC)

Wie ich es bisher gemacht habe hast du ja glaube ich schon gesehen. Inzwischen meine ich aber, dass es vielleicht sinnvoller wäre sie als "railway:signal:minor"=* einzutragen. --rayquaza (talk) 23:44, 11 February 2014 (UTC)

Dokumentation: Subkeys zusammen

Momentan steht hier bei jeder Signalbedeutung ein Abschnitt z.B. zu railway:signal:*:form=*. Diese überall anwendbaren Subkeys sollten besser an einer Stelle definiert werden, um später nur Ergänzungen dazu festlegen zu müssen. --rayquaza (talk) 23:44, 11 February 2014 (UTC)

Die Redundanz und Unübersichtlichkeit ist mir ebenfalls aufgefallen, darum habe das Taggingschema in der letzten Zeit etwas umgebaut:
Bisher war es ja so, dass das Taggingschema sehr auf Deutschland bezogen und gerade bei den Signalen ziemlich redundant war.
Nun habe ich dies in meinen Augen besser gelöst: Das Taggingschema ist allgemeiner gehalten, gleichzeitig gibt es für jedes Land eine Seite zum länderspezifischen Tagging, auf denen auf die Besonderheiten der einzelnen Länder eingegangen wird und für jedes Signal das konkrete Tagging aufgeführt ist.
Ich vermute, dass dies in etwa deinem Vorschlag entspricht.
Gleichzeitig würde ich vorschlagen, das vereinfachte Taggingschema zu entfernen. Damit erspart man sich eine Menge an Arbeit, denn bisher musste man immer beide Varianten inhaltlich synchron halten. --rurseekatze (talk) 21:38, 9 April 2014 (UTC)

Railway Status an Eisenbahn- und Planungsrecht orientieren?

Wie sieht es mit stillegungsbedohten, stillgelegten, oder noch gewidmeten Eisenbahnstrecken aus? Ich empfinde hier den Planungs- und Eisenbahnrechtliche Status durchaus relevant und bisher zwischen den Werten preserved, disused, abandoned, razed als zu ungenau beschrieben. Neben der Beschreibung wie eine solche Strecke in der Landschaft eingebettet ist könnte man sich doch auch an den offiziellen "Zuständen" orientieren? Ergänzungsvorschlag für die de:Beschreibung des Tags "railway":

  • preserved - Ein Streckengleis welches Eisenbahnrechtlich stillgelegt ist, jetzt aber als Gleis beispielsweise für Draisinen genutzt wird
  • disused - Eisenbahnrechtlich stillgelegtes, aber noch vorhandenes Streckengleis, welches auch noch als Eisenbahntrasse gewidmet ist (seitens des Eisenbahn Bundes Amtes (EBA))
  • abandoned - gewidmete Eisenbahntrassen deren Gleise aber abgebaut wurden (hierauf werden häufig schon Fahrradwege gebaut)(Planungsrechtlich ist hier relevant, das eine Wiedernutzung der Strecke ohne Planfeststellung möglich ist.)
  • razed - Eisenbahnstrecken die entwidmet wurden, nur noch historisch sind und die überbaut werden (können). (Theoretisch könnten auch hier noch Gleise, Schotter und dergleichen zu finden sein)

Ergänzend zu den Angaben des EBA, die meiner Meinung gemeinfrei sind, da sie Gesetzescharakter haben (?), können hier auch Landes- und Regionale- Entwicklungspläne zu Rate gezogen werden. Für die genauere Beschreibung der Nutzung von Betriebenen oder stillgelegten Gleisen könnte man dann die tags "usage", "service", "railway:traffic_mode" nutzen. Beispielsweise im "railway:traffic_mode" wird für den Fall das kein Personenfernverkehr stattfindet und kein Personennahverkehr mehr bestellt dann der Wert auf "freight" gesetzt) - und klar eigentlich scheitern wir hier immer wieder an der Überladung des Tags "railway" der sich allerdings eingebürgert mit dem Schema Nutzung (rail, lightrail, monorail, narrow_gauge) und Lifecircle (rail, preserved, proposed etc) --Heirei83 (talk) 09:59, 16 April 2014 (UTC)

Ich habe mir schon vorgenommen, in der nächsten Zeit das Tag railway=* mal etwas anzugehen. Um Taggingschwierigkeiten wie stillgelegte Schmalspurbahnen zu beseitigen, möchte ich Gleistyp und Lifecycle voneinander entkoppeln und hin zur bereits auf anderen Wikiseiten vorgeschlagenen Form disused:railway=*, abandoned:railway=*, etc. Damit wäre es dann auch möglich, Stilllegungsdatum, Abbaudatum, etc. gleichzeitig zu erfassen. Bisher gibt es ja lediglich die Tags start_date=* und end_date=*, mit denen sich aber nicht der vollständige Lifecycle einer Strecke sauber abbilden lässt.
Was den Zustand einer Strecke betrifft, möchte ich eigentlich gerne weiterhin an Kriterien festhalten, die international gültig sind und den tatsächlichen Zustand wiederspiegeln. Sprich der Mapper soll das Taggen, was er sieht, nicht was eine Behörde festgelegt hat. Trägt ein Gleis z.B. das Tag railway=razed, dann soll für jeden Ortsfremden erkennbar sein, dass hier keine Gleise mehr liegen und der Streckenverlauf größtenteils nicht mehr nachvollziehbar ist. Wenn der rechtliche Status erfasst werden soll, dann bitte mit einem separaten Tag, damit für jeden Mapper erkennbar ist, ob hier der rechtliche oder tatsächliche Zustand beschrieben wird. --rurseekatze (talk) 15:12, 22 April 2014 (UTC)

service=siding für Hauptgleise?

Die Tabelle ist bezüglich der Verwendung von service=siding nicht konsistent in sich selbst bzw. zum restlichen Wiki. Konkret: Wie sollen "nicht-durchgehende" Hauptgleise (also die Gleise entlang der Bahnsteigkanten eines Bahnhofs) getagt werden? Laut der Spalte "Beschreibung" würden sie ein service=siding bekommen, obwohl sie keine Ausweich- oder Nebengleise (siehe Spalte "Objekt") sind. Diese Interpretation finde ich sonst auf keiner anderen Wiki-Seite, und offensichtlich auch nicht in der OSM-Datenbank außerhalb des Deutschsprachigen Raums (und dort könnte das Tagging möglicherweise auch nur durch diese Wiki-Seite motiviert sein?).

Key Value Objekt Beschreibung Standardwert
service Hinweis: Ein Tag service=* bekommen alle Gleise, die keine durchgehenden Streckengleise sind, also Abstellgleise, Überleitgleise, Firmenanschlüsse und Nebengleise in Bahnhöfen.
yard Abstellgleis Gleise in Rangier-, Güter- oder Betriebsbahnhöfen, die zum Rangieren, Zusammenstellen von Zügen und Abstellen von Wagen dienen. Die Gleise sind oft durchnummeriert, diese Gleisnummer sollte mit railway:track_ref=* erfasst werden. Mindestens ein Gleis sollte als Hauptgleis übrig bleiben und nicht dieses Tag erhalten.
siding Ausweich- oder Nebengleis Parallel zum Hauptgleis verlaufende Gleise, die zum Überholen und Halten von Zügen dienen. Dies sind alle Gleise außer den durchgehenden Hauptgleisen; die durchgehenden Hauptgleise erhalten kein Tag service=*. Weitere Infos...
spur Anschluss- oder Verladegleis Meist kurze Gleise, die Industriebetriebe an eine Bahnstrecke anschließen. Allerdings sollte man dieses Tag nicht automatisch bei größeren Gleisanlagen, etwa innerhalb von Chemiewerken, verwenden. Dort sollte man sich mit diesem Tag auf die Verladegleise beschränken. Die übrigen Gleise werden dann, wenn nötig, mit den anderen möglichen Werten von service=* eingeteilt.
crossover Überleitgleis Kurze Gleise, die das Wechseln zwischen zwei Gleisen bei zweigleisigen Strecken und in Bahnhöfen ermöglichen Meistens an Überleitstellen und in Bahnhöfen zu finden.

Wenn man streng nach dieser Tabelle taggen würde, kann man doch nicht mehr zwischen Haupt- und Nebengleis unterscheiden (und dafür sollte das service-tag doch eigentlich da sein)‽

Beispiel: Bahnhof Rotterdam (nur wirkliche Abstell- und Nebengleise mit service=*) vs. Bahnhof Innsbruck (auch Hauptgleise als service=siding).

--Tyr (talk) 11:32, 31 May 2014 (UTC)

Ich mache es auch so wie du es für sinnvoll befunden hast. Durchgehende Hauptgleise lassen sich dann von anderen Hauptgleisen über die Existenz von ref=*, usage=* oder einer Streckenrelation unterscheiden. service=siding verstehe ich als "sonstige Nebengleise". Imho sollte man darum diese Seite daran anpassen. Btw: Bei service=yard würde ich den letzten Satz entfernen, da nicht immer "mindestens ein Gleis als Hauptgleis übrig" bleibt. --rayquaza (talk) 21:57, 31 May 2014 (UTC)
Mhh... da gibt es wohl auch in der JOSM-Vorlage noch etwas zu tun. Ich melde mich dazu in Kürze. --Bigbug21 (talk) 15:50, 1 June 2014 (UTC)
Ich hatte die Geschichte bisher wie folgt interpretiert (deckt sich m.E. auch mit der JOSM-Vorlage):
  • Durchgehende Hauptgleise -> kein service-Tag, aber usage=main/branch
  • weitere Hauptgleise -> service=siding
  • Nebengleise -> service=yard
  • Gleisverbindungen zweier durchgehender Hauptgleise -> service=crossover
  • Anschlussbahnen/-gleise -> service=spur
So wäre das recht einfach und für das europäische Ausland dürfte das so meist auch funktionieren (Hauptgleis = Ein-/Ausfahrt für Zugfahrten regulär möglich). --Emiriku (talk) 17:22, 1 June 2014 (UTC)
Genau so wie von Emiriku beschrieben sollten die Gleise getaggt werden. Auf dem Mappingwochenende 2014 haben wir das Thema diskutiert und sind zu dem Ergebnis gekommen, dass das Taggingschema für service=* in seiner jetzigen Form ausgereift ist und lediglich die Definitionen von ihren teils widersprüchlichen Formulierungen befreit werden müssen. Die Dokumentation und die Beschriftungen in der JOSM-Vorlage wurden nun entsprechend angepasst, sodass es zu keinen Missverständnissen mehr kommen sollte. --rurseekatze (talk) 18:40, 9 December 2014 (UTC)
Etwas ungünstig finde ich allerdings, dass im englischen Sprachgebrauch - insbesondere bei britisch geprägten Eisenbahnen - mit "siding" sehr wohl nur Neben-/Abstell- oder Anschlussgleise gemeint sind. Dementsprechend sieht beispielsweise in UK auch die Taggingpraxis aus - ab und an findet sich die Version nach dem hier gewünschten Schema, meistens aber Tagging nach dem tatsächlichen Sprachgebrauch, also keine Unterscheidung durchgehende/nichtdurchgehende Hauptgleise (gibt es in UK sowieso gar nicht so formell wie in Deutschland), alles an normalen Abstellgleisen und ähnlichen Nebengleisen ist "siding" und "yard" oftmals nur für tatsächliche Güter-/Rangierbahnhöfe.
Und wir taggen ja nicht für den Renderer, aber ich weiß nicht, inwieweit beispielsweise die Renderingeinstellungen von Mapnik zu dieser Definition von Siding passen - persönlich finde ich es zumindest leicht befremdlich, wenn in größeren Bahnhöfe auf einmal die Hälfte der Bahnsteiggleise in unscheinbarem Hellgrau genau wie echte Nebengleise angezeigt wird.

--JanTH (talk) 17:08, 16 February 2016 (UTC)

Ob die Begriffe ideal gewählt sind, kann ich nicht genau beurteilen, da ich kein englischer Muttersprachler bin. In diesem Taggingschema habe ich die schon existierenden Werte für service=* und deren Definitionen übernommen, da das nachträgliche Ändern solcher Definitionen wenig Sinn macht.
Die Unterscheidung in durchgehende und nichtdurchgehende Gleise macht auch dann Sinn, wenn es diese Unterscheidung rechtlich in UK nicht gibt. Anders ist es zum Beispiel nicht möglich, nur die Streckengleise herauszufiltern, um daraus etwa eine vereinfachte Darstellung des Streckennetzes zu erzeugen.
Auf das Rendering in Mapnik habe ich keinen Einfluss. Wenn es mir nach ginge, würden zumindest in den höheren Zoomstufen die sidings identisch zu den durchgehenden Hauptgleisen gerendert und nur yards, crossovers und spurs in Grau. Aber wir taggen ja nicht für die Renderer... --rurseekatze (talk) 20:07, 16 February 2016 (UTC)

Widersprüchlichkeiten gegenüber anderen Wiki-Seiten

Hallo,

mir ist aufgefallen, dass sich das von OpenRailwayMap empfohlenen Tagging zum Teil mit anderen Wiki-Seiten widerspricht.

Beispiel: Tag:railway=halt und Tag:railway=station

Wiki-Seite DE:Tag:railway=halt/DE:Tag:railway=station: "Ein Node mit railway=halt und name=* wird in einen railway=rail-Weg an der Position an der sich der Halt befindet eingefügt." bzw. "Es sollte ein Node eines Weges mit dem Tag railway=* sein."

Wiki-Seite DE:OpenRailwayMap/Erweitertes_Tagging: "Wird als Punkt in der Mitte des Bahnhofs (nicht auf einem Gleis) erfasst."

Ich denke um ein standardisiertes Tagging zu ermöglichen und Edit-Wars zu vermeiden, sollten die Tags und Konventionen die hier entwickelt werden auch in das "normale" Wiki zurückfließen. Die wenigsten Mapper werden auf der OpenRailwayMap Tagging-Seite nachschauen, wenn sie nur einen Bahnhof eintragen möchten.

Ist es geplant bei einer gewissen Stabilität der hier entwickelten Konventionen und Tags diese auch in das "normale" Wiki zurückfließen zu lassen?

--Mapper999 (talk) 09:21, 20 June 2014 (UTC)

Langfristig ist auf jeden Fall geplant, die Verbesserungen des Bahntaggings, die im Rahmen der OpenRailwayMap entwickelt wurden, auch in die normalen Wikiseiten zu übernehmen. Dabei sollen bestehende Tag-Seiten angepasst und neue Seiten für neu geschaffene Tags angelegt werden.
Allerdings ist dies alles mit einem großen Aufwand verbunden, den die wenigen aktiven ORM-Mitarbeiter in absehbarer Zeit kaum bewältigt bekommen. Alleine die englische Übersetzung des ORM-Taggingschemas kommt kaum voran. Daher sind weitere Mitarbeiter, die uns bei dieser Arbeit unterstützen wollen, gerne gesehen. --rurseekatze (talk) 12:52, 23 June 2014 (UTC)

structure_gauge vs. loading_gauge

Ich habe gerade angefangen, etwas bei der Übersetzung des Tagging-Schemas ins Englische mitzuhelfen. Dabei ist mir folgende Unstimmigkeit aufgefallen:

In unserem Tagging-Schema benutzen wir structure_gauge=* um das Lichtraumprofil zu beschreiben. Wenn ich es richtig verstehe, entsprechen die verwendeten Werte des Lichtraumprofils für Eisenbahnen aber eher dem englischen Loading Gauge (maximale Abmaße der Fahrzeuge) und nicht dem englischen Structure Gauge (minimaler Freiraum um die Gleise).

In der Datenbank gibt es auch schon den key loading_gauge, der ca. 8500 mal hauptsächlich im britischen Raum verwendet wird und auch auf der ITO Loading Gauge Karte angezeigt wird. Meines Wissens wird dieses Tag schon länger benutzt. Daher würde ich vorschlagen den Key in loading_gauge umzubennen und die bisher 13000 Verwendungen von structure_gauge anzupassen. --Mapper999 (talk) 12:20, 24 June 2014 (UTC)

Auf dem Mappingwochenende in Köln haben wir beschlossen, das Tag structure_gauge=* zu loading_gauge=* zu ändern. --rurseekatze (talk) 17:47, 2 November 2014 (UTC)

versenkte Mittelstromschiene

Bei Straßenbahnen gibt es die entwicklung oberleitungsfreier Abschnitte mittels versenkter Mittelstromschienen (APS, Primove, TramWave). Der Fall in Bordeaux ist recht bekannt. Dort wird mit electrified=rail getaggt, was zwar nicht falsch ist - es ist ja eine Stromschiene - aber doch präzisiert werden könnte. Der englisch-sprachichge WP-Artikel zum Thema trägt das Lemma "Ground-level power supply". Irgendwie kompliziert: electrified=ground-level_power_supply, oder? Oder electrified=middle_rail? Was meint ihr?--Geogast (talk) 12:35, 1 July 2014 (UTC)

Abfertigungshilfen

Im Taggingschema fehlen noch Abfertigungshilfen, also z.B. Spiegel oder Kameras und ihre Bildschirme. Hat jemand Ideen zur Erfassung? --rayquaza (talk) 07:34, 17 November 2014 (UTC)

Flachkreuzung

Mir ist eben aufgefallen, dass wir bisher noch kein Tag für eine Flachkreuzung haben. Auf Englisch heisst das wohl "switched diamond". Also railway=railway_crossing "railway:switch:switched_diamond"=yes? --rayquaza (talk) 07:34, 17 November 2014 (UTC)

Pfeifsignal (whistle)

Zusatztafel in Österreich für Eisenbahnkreuzungen

Sollte das Pfeifsignal nicht einem Bahnübergang zugeordnet werden, auf freier Strecke wird kaum ein Lokführer ein Pfeifsignal abgeben. Außerdem ist es nicht generell für die ganze Strecke, sondern nur dort wo es besonders notwendig ist. --K@rl (talk) 08:58, 31 December 2014 (UTC)

Inkompatibilitäten zu Public Transport Version 2

Trotz gegenteiliger Aussage im Wiki ist railway=facility offenbar nicht mit public_transport=stop_area kompatibel. Ersteres erlaubt nur ein Element ohne zugewiesene Rolle (Bahnhof oder Haltepunkt), während letzteres das Hinzufügen von facilities beliebiger Menge ohne Rolle erlaubt.--Trockennasenaffe (talk) 16:35, 19 February 2016 (UTC)