Es gibt Tags für ungenutzte und auch abgerissene Schienen. Ungenutzte Schienen werden mittlerweile von Mapnik sogar speziell gerendert. Es spricht also nichts dagegen die auch zu Mappen. Abgerissene Schienen sollte man dann allerdings wirklich nur mappen, wenn die Trasse noch erkennbar ist, und nichts anderes darauf errichtet wurde.
Genau so finde ichs Sinnvoll…
Die besagten Namen werden im allgemeinen Sprachgebrauch häufig zur Orientierung genutzt. Daher ist es schon ganz gut, wenn die im Name-Tag angegeben werden. Kursbuchstrecken scheinen mir eher ein Fall für Route-Relationen zu sein, oder?
Richtig! Ich bin z. B. kein Eisenbahn-“Freak”, auch wenn ich andauernd Bahn fahre. Aber unter anderem die “abandoned”-Streckeneinträge finde ich wegen der noch vorhandenen Dämme etc. manchmal interessant.
Ansonsten sollte man ein “Proposal” wohl auf jeden Fall klar gliedern, von allgemeineren hin zu spezielleren Punkten. Das grundlegende Einzeichnen einzelner Gleise z. B. sollte ja wohl unstrittig sein. Wenn ein Porsche-Fahrer darüber meckert, mich als Mountainbiker interessieren die für ihn wichtigen getrennten Autobahnfahrtrichtungen ja auch nicht, dennoch bekommt er sie. Und warum soll der Eisenbahner nicht irgendwann, wie ich als MTBler und Skifahrer, seine eigene gerenderte Karte bekommen, solange die Datenquellen zulässig sind.
Ich denke, dass 90% der Strecken längst entwidmet und vielerorts überbaut wurden. Das war hier aber nur ein Beispiel (sicher ein extremes), anderen Ortes liegen wenigstens noch die Gleise oder die Trasse gilt zumindest noch als Bahnstrecke.
Sorry für meine Nachfrage, aber ich habe ja ca. 1 Jahr pausiert: Gibt es denn jetzt offizielle Tag’s für Signale und sonstige Einrichtungen der Bahn, die über das reine Gleis hinweg gehen?
Und wie sieht es mit dem sächsischen Kernland zwischen Leipzig, Dresden und Chemnitz aus? Das ist die Gegend, für die ich mich interessiere und wo ich auch gerne was machen würde.
Woher “holt” man das rein?
Da stimme ich Dir zu! Ich erinnere mich an eine unsägliche Diskussion über die Erfassungsform von Bahnsteigen. Da wurde heftig debattiert, ob das nun ein Polygon sein darf oder eine Linie sein muß. Aus Frust habe ich das dann alles nicht weiter verfolgt.
Da bin ich halt etwas anderer Meinung. Kaum ein Mensch (und ich stehe der “Bahnszene” sehr Nahe) benutzt heute z.B. noch Bezeichnungen wie “Leipzig-Dresdener-Eisenbahn” oder “Borsdorf-Coswig-Linie”. Bei den Vermarktungsnamen bin ich mir nicht sicher, es gibt aber ja auch nur einen Bruchteil dieser “offiziellen” Namen. Die “Müglitztalbahn” von Heidenau nach Altenberg heist wohl auch nur im Volksmund so, ebenso die “Muldentalbahn” Großbothen-Rochlitz-Glauchau. Es gibt somit viele verschiedene Bezeichnungen: offizielle Nummern, Kursbuchstrecken neu (und alt), Marketingnamen und Umgangssprachliches.
Wofür man dann ja super eine Relation erzeugen kann, oder sehe ich das flasch?
Selbst wenn eine Strecke überbaut ist, wäre eine Punktelinie für den früheren Verlauf eine super Sache. Über den “abandoned”-Tag sollte eine Render-Software das ganze ja unterscheiden können und entweder gar nicht anzeigen oder eben als gestrichelte Linie, sofern ein weiterer Eintrag das Gleis überschneidet. Am Ende muß man sich al historisch interessierter Bahnfan wohl davon lösen, Karten auf www.openstreetmap.de aufzurufen. Hier bedarf es sicher einer exakt auf diese Bedürfnisse zugeschnittene “Renderei”, die eine Spezialkarte erzeugt.
Hallo Mirko,
in Ergänzung zu Deinem weiter oben geschriebenen Entwurf eines Proposals wärme ich mal folgende Idee von mir neu auf:
den Strecken (bzw. Gleisen) könnten 3 Datumsfelder beigefügt werden: Verkehr eröffnet, Verkehr eingestellt, Strecke abgerissen
Über diese Informationen (sofern vorhanden) könnte man noch viel mehr selektieren und sich Karten erzeugen lassen:
Alle Bahnlinien, auf denen aktuell noch Verkehr ist
Alle Bahnlinien, die nach 1990 abgerissen wurden
Alle Bahnlinien, die zwischen 1890 und 1910 eröffnet wurden
Ich habe mal irgendwo eine OSM-Anmimation aus den USA gesehen, wo die geografische Entwicklung einer Stadt über die letzten 100 Jahre in einer Art Film ablief.
In dem Fall muss man den neuen Daten natürlich platz machen, die Daten extern nutzen. Aber bei weißen Flächen tut die Kennzeichnung einer alten Trasse keinem weh.
Nö. Das sollte uns aber wie gesagt nicht abhalten. Schlüssel sind austauschbar und nicht für die Ewigkeit. Selbst entwickelte Schlüssel kann man später noch immer in einem Artbeitsgang mit offiziellen ersetzen. Wichtig ist nur, dass man seine Kreation dokumentiert. Ich habe das ganze erstmal auf meiner Wiki Userseite dokumentiert, ergänze und streiche fortlaufend. Das entwickelt sich in der Praxis weiter. Wenn es passt, wir ein Propo draus.
Das Problem ist momentan folgendes. Die welche sich offiziell damit beschäftigen, sind schon wieder 2 Schritte vor dem ersten. Man kümmert sich nicht um die Erfassung ansich, sondern oritiert sich schon an irgendwelchen Systemen wie NaPTAN. Das führt teilweise zu Einschränkungen, die eine weitergehende Auswertung behindern.
Da habe ich auch noch einiges da. Auch nicht alles und sowieso nicht tagesaktuell.
Ich komme aus der MSTS Szene, wollte 2001 Mitteldeutschland in der Sim umsetzen. Apropo, du bist doch nicht etwa “DerSachse” der da an der Schmalspurgeschichte mitgebastelt hat? Wenn ja dann dürftest du mich ja unter Eastrail kennen. Wenn nicht, dann die weitere Erklärung. Damals war es schwierig an Daten zu kommen. Luftbilder usw. waren noch ein Traum, Datenspenden fast unmöglich. Also fing ich an zu sammeln. In all den vergangenen Jahren kam so einiges zusammen. Das wird nun auf OSM getrimmt und entsprechend eingepflegt. Manches ist natürlich teilweise überholt, aber besser als nix oder krumme Linien.
Mitlerweile wird gar über die Behandlung als Fußweg nachgedacht. Lass sie machen. In der Zeit in der die sich totreden, hat man längst vernünftige Fakten geschaffen.
Der Name ist die derzeit einzig gerenderte Ausdrucksform. Alles andere ist für die Spezialkarte. Und da kannst du ja dann selbst entscheiden was dargestellt wird. Mit den Vermaktungsnamen wird auch offiziell geworben.
Kann man auch machen. Ich hänge die entsprechenden Nummern gleich mit an die Streckenabschnitte. Das lässt sich für mich bei Änderungen schneller per Search & Replace ändern, als wenn man eine Relation neu zusammenklicken muss. Wenn man es schon jetzt in der ÖPVN Karte visualisiert haben möchte, kann man natürlich auch eine Relation anlegen.
Die Renderer sind in dem Punkt noch zu “blöd”. Ohne Hilfsmittel geht da kaum etwas automatisch. Und es besteht immer die Gefahr, dass Unwissende das ganze als störend sehen, und die komischen Striche einfach löschen.
So eine Spezialkarte ist ja in planung. Dort kann man dann auch Daten einfließen lassen, die man so nicht in die Hauptkarte eintragen kann. Das wäre dann hier Fall.
Leider musste ich eben lesen das man irgendwo wieder irgendwas heimlich ausgekaspert hat und man sich sofort auf die Umsetzung stürzt.
Damit hat sich das ganze dann wohl erledigt. Ich werde meine bereits eingefügten Daten wieder schrittweise rausnehmen und den vorherigen Zustand wieder herstellen. Wird etwas dauern, waren inszwischen ja doch einige tausend Kilometer an Gleisen und zugehöriger Infrastruktur.
Was meinst Du damit?
Zufällig den Karlsruher ÖV-Workshop?
So auf flüchtigem Blick erkenne ich da keine wirklich schlimmen Überschneidungen, da das dortige nicht im Geringsten Signale etc. behandelt, wovon deine Beiträge hier hauptsächlich handeln, sondern tendentiell eher die saubere Erfassung von Linien, Verbünden und Zugangsstellenzusammenhängen mit Relationen.
Oder gibt’s noch was anderes, abgesehen von Stuttgart, auf das ich schon vor Monaten hinwies?
Signale usw. sind Detailerfassungen um die es garnicht primär geht. Mir ging es um eine Datenbasis für eine Railmap. Dafür braucht es aber eine offene Datenbasis die man breit auswerten kann. Ihr wandert da aber eher in die Richtung ÖPNV Auswertung. Und da fängt der Hamster das Bohnern an.
Mit euren teils magerem Schema aber dafür auch überflüssigen Tags wird das nichts. Da kann ich mir die Arbeit Mitteldeutschland zu importieren sparen. Das wird sich langfristig beißen. Ich lasse mir mit der Ausarbeitung nicht umsonst Zeit. Sowas muss sich entwickeln. Sowas kann man nicht mal eben in einer netten Schwatzrunde übers WE auskaspern. Aber anscheinend ist man nicht würdig mal seine Gedanken einbringen zu dürfen.
verstehe dich nicht so ganz kannst du mir das bitte näher erläutern ?
Im Grunde ist es doch erstmal Hardware die erfasst und Gettagt wird (Schienen / Gebäude / Bahnsteige). Wo ist nun das Problem wenn man das via Relationen in Logische Konstrukte ( Bahnlinien) einteilt?
Heimlich? Der Workshop war länger angekündigt, jeder der was einzubringen hatte oder Ideen einbringen wollte konnte teilnehmen. Auch ist das Wiki für jeden editierbar, talk-transit exisitert, du kannst deine Bedenken oder eigenen Ideen jederzeit einfließen lassen. Vielleicht gehts nur mir so, aber außer das du irgendwas irgendwie taggst oder importierst und lamentierst, das alle miteinander ein Schema aufbauen, sieht man eigentlich garnichts von dir - dein Forumbeitrag mit der Tagging-Liste? … geschenkt.
Warum? Das Schema vom Workshop steht offen zur Diskussion!
Und was hat das ÖPNV-Schema mit den Gleisen und der Infrastruktur zu tun?
Das scheint der Schwerpunkt zu sein, daher sehe ich da auch keine unlösbaren Konflikte.
Was die reine Schieneninfrastruktur angeht, ist es auch in meinen Augen etwas mager strukturiert, ja, das hatte ich vorm ÖV-Workshop auch schon auf der Wikiseite so hinterlasen. Ich hatte zwischenzeitig mal Europa flüchtig gesichtet bzgl. der Verwendung der Haupttags, um zu shcauen, wie man da weiter kommen kann. Die Tage muss ich das mal noch besser dokumentieren und Konsequenzen (d.h. neues Schema ) überlegen …
Soweit ich weiß, wurden viele angesprochen, von denen man wusste, dass sie sich im Bereich Bahn und OSM engagierten.
Jedenfalls waren bundesweit Leute versammelt.
Vielleicht hat man von Dir einfach nix gewusst, was mich aber auch nicht erstaunt, denn ich habe zwar Deine Wikiseite letzte Nacht gefunden, aber nur weil ich nach Deinem Namen suchte, denn wie das Wiki verrät:
Die Seite ist auf keine bahnrelevanten Seite verlinkt, sie ist auch hier nicht genannt und auf talk-de ist sie mir glaub auch nie begegnet. Und der Beitrag hier mit den tags ist eine eher unleserliche Textwüste…
Klappern gehört zum Handwerk, das vermisse ich bei Deinem Vorschlag etwas
Ich hatte diesen alten Forumsthread auch schon längst vergessen, als ich vor dem Workshop recherchierte.
Aber nun habe ich ihn ja wieder gefunden und kann die Tage schauen, ob man neben dem alten tagging-Schema, den Vorschlägen von Sebastian und den Stuttgarter Vorschlägen und was sonst noch so kursiert auch Deine Vorschläge unter einen Hut kriegt.
Aber ich sehe da im Moment noch keine großen unlösbaren Konflikte. Dein Netz ist bei weitem nicht das einzige Netz, wo schon versucht wurde, gleistreu zu mappen (daher wird man um diesen Bedarf nicht ignorieren können), wenn auch noch nirgends so detailtreu wie bei Dir, wenn ich das bei der Inventur richtig sah. Von daher setzt Dein Netz vermutlich Maßstäbe, um die man nicht drumrum kommt, die vorrangig zu berücksichtigen. Bei der Signalerfassung auf jeden Fall. Beim Rest schaun mer mal, dafür muss ich mir dessen praktische Umsetzung einfach erstmal genauer anschauen…
Ich habe aus obigen Grund noch nicht “geklappert”. Ich habe hier eine riesen menge an genauen und detailreichen Daten, die sich obendrein nicht so leicht in ein mal eben ausgedachtes Schema pressen lassen. Mit einem Schnellschuss ist da keinem geholfen. Also kam erst die Übernahme der Daten um dann sehen zu können wie man das denn nun in OSM halbwegs einheitlich unter einen Hut bekommt und auswerten kann. Erst dann ist es überhaupt sinnvoll, mit etwas brauchbaren klappern zu gehen.
Vieles fällt einem erst in der Praxis ein. So fiel mir z.B. erst beim Import in Leipzig ein, das da ja noch Angaben zum Verkehrsverbund und der jeweiligen Tarifzone fehlen, was ich dann an allen Referenztationen ergänzt habe.
Die Richtung ÖPNV beißt sich beispielsweise an den Stationen. Eine “stop_area” im Gleis kann man dort nicht gebrauchen. Die Schnittstelle ist die von der Linie bediente Bahnsteigfläche, die ich so auch schon in dutzenden Referenzstationen erfasst hatte. Das ist die für den Fahrgast einzig relevante “stop_area”. Der Bahnverkehr hat seine eigenen teils abweichenden “stop_areas” im Gleis. Und dort kam das nächste Problem. Irgendwer wollte alle Bahnsteige mit highway=platform zu einer Soße vermanschen. Schön einfach für Router, schlecht wenn man für einen spezielle Bahnanwendung auf eine eindeutige Identifizierung angewiesen ist.
Da bin ich bisher auch noch nicht auf eine zufriedenstellende Lösung gekommen. Aber irgendwelche willkürlich im Gleis gesetzten Punkte sind bei weitem kein Optimum. Zumal man dort auch weiterhin ein weiteres Problem hat. Ich erfasse Linienrelationen Fahrweggenau. Für jede Richtung eine, die dann auch an den jeweilig angefahrenen Bahnsteig führt. In großen Bahnhöfen gibt es aber keinen Stammbahnsteig bzw. Gleis. Die Spurpläne richtigen sich nach dem Betrieb. Wenn zu einem bestimmten Zeitpunkt eine bestimmte Fahrstraße benötigt wird, hält eine Linie auch mal an einem anderem Bahnsteig. Schnödes A nach C über B reicht bei gleisgenauer Erfassung nicht.
Und da sind noch einige andere Probleme, die man vor einer verbindlichen Lösung knacken muss.
Wo war denn etwas angekündigt? Ich habe nichts gesehen. Ich verfolge bei etwas Zeit die talk de Liste übers Archiv. Das muss eine kleine Ankündigung gewesen sein, die nach einem Tag nach hinten durchgerutscht sein muss. Ansonsten hätte ich das mitbekommen. Die Transit Liste nützt mir bei magerem Englisch nichts.
Ansonsten siehe oben. Ich versuche an einer Lösung zu basteln, der eine Menge Praxis voraus geht. Ich liefere nicht nur irgendwelche theoritischen Wortfetzen sondern gleich die umfangreichen Geodaten dazu. Vom “sich sehen lassen” alleine wird es nichts. Ich lasse mich erst mit Ergebnissen sehen.
Mag sein, aber wenn man nicht an relevanten Stellen wenigstens eine “Duftmarke” hinterlässt, dass man an etwas arbeitet, sollte man sich nicht beschweren, wenn am selben Problem anderswo parallel gearbeitet wird…
Sobald man mit Rollstuhl unterwegs ist, kann auch die stop_area im Gleis schnell relevant werden, weil die Einstiegshilfe nur an der 1. Tür des 1. Wagens vorhanden ist oder so…
Soweit meiner Erinnerung nach kompatibel zu Karlsruhe.
So eine ähnliche Frage hatten wir bei den Bussen, wo es Linien gibt, bei denen 30 Kurse einer Linie ca. 20 verschiedene Wege fahren.
Habe aber gerade nicht im Gedächtnis präsent, wie da nun die angestrebte Lösung ist, weil ich mit dem Thema. noch wenig Kontakt hatte.
Schau einfach mal auf der Workshopseite selbst nach, ob das auch für Dich passen könnte bzw. bringe Deine Zweifel ggfs. dort ein.
Und in dem Stadium ist der Karlsruher Workshop nun auch: in der Praxis schauen, wie die Theorie umsetzbar ist.
Jeder trägt das dazu bei, was er jeweils gut kann. Also keine prinzipielle Inkompatibilität bisher, weil noch nix umnumstößlich festgezurrt ist.
Genau da ist ja das Problem mit einem Punkt irgendwo im Gleis. Da muss ich einiges mehr beachten.
Wir haben einen Bahnsteig als ganzes. Der Unterteilt sich wiederum in Zonen. Die dienen der Orientiereung mit dem Wagenstandsanzeiger, der sich an der Zugzusammenstellung orientiert. Die Züge ansich haben keine einheitliche Stopstelle. Es gibt unterschiedliche Haltetafeln an denen der Triebfahrzeugführer mit der Zuspitze hält. Mancherorts ist man ja dabei die einzelnen Verkehrsarten zu trennen. Es gibt aber noch genügend Stationen wo sich S-Bahn, Nah- und Fernverkehr einen Bahnsteig teilen. Während da der Fernverkehr die gesamte Bahnsteiglänge nutzt, steht der S-Bahn Halbzug weiter mittig. Denn seine Haltetafel steht meintwegen 200m weiter vorn, während der Langzug wiederum ganz woanders hält. Wenn ich den Rollstuhlfahrer also möglichst genau platzieren möchte, muss da mehr kommen.
Das brauchbar umzusetzen ist nicht ganz easy. Speziell die Behindertenkiste ist hier schwierig. Da herscht im Vorbild Chaos.
Von der Infrastruktur her ist es ja schon gelöst und entsprechend getaggt. In jedem Bahnhof ist das über Spurpläne geregelt. Jede Strecke hat im Gleisfeld zugeteilte Fahrstraßen die der jeweilige Strecke zugeteilt sind. Ab Weiche 0815 teilt sich die Strecke 1234 auf und führt beispielsweise an die Bahnsteige 17 bis 20. Was nebenbei ein weiteres Problem mit sich bringt. Streckennummer vs. Gleisnummer in der Betriebstelle, also zwei ref Werte. Diese Fahrstraße werden dann Betriebsabhängig genutzt. Manchmal wird aber auch ein fremder Abschnitt genutzt, wenn es durch Kapazitätsengpässe erforderlich wird. Dann steht der Zug meinetwegen auch mal auf der 7.
Das muss man nun über Rlationen lösen, was aber verständlich, sinnvoll und vor allem auswertbar sein muss.
Mal was anderes. Hat man im Vorfeld überhaupt mal mit den wichtigsten Leuten zwecks Auswertung gesprochen?
Es ist ja schön wenn die Leute immer wieder irgendwelche Relationsfrickeleien erfinden. Nur nützt das am Ende überhaupt keinem, wenn allein die ÖPVN Karte das ganze irgendwann mal umsetzen will, irgendein kleiner Verkehrsverbund das genau wie eine Geofabrik über den hauseigenen Programmierer lösen kann, der Rest das ganze aber links liegen lässt.
Von den teilweise noch immer ignorierten Problemen mal abgesehen, sehe ich da wieder Probleme kommen. Bei dem jetzigen Modell hat man z.B. mal wieder den Unterschied zwischen Haltepunkt und Bahnhof komplett vergessen. Da kriegt der Aachener Busschubser Verbund von mir ein sh2=yes. Denn ohne irgendeine Angabe kann man das nunmal nicht unterscheiden, geschweige denn das es ein renderer vernbüfntig darstellen wird, wenn denn die Relation überhaupt verarbeitet wird.
Bevor solche Punkte nicht geklärt sind, braucht man mit dem umtaggen erst garnicht anfangen. Ansonsten löschen wir optisch nur dutzende Haltepunkte aus der Karte, der Grund warum ich erstmal auf den bereits unterstützten Tags aufgebaut habe. Super PR wenn die Leute die Karte als Anfahrtshilfe auf ihrer Seite einsetzen, auf der dann mangels Unterstützung keinerlei ÖVPN Halte zu finden sind.
BTW Meine Importe erstrecken sich wie so oft geschrieben auf Mitteldeutschland. Das schließt bekanntlich Thüringen, Sachsen-Anhalt und Sachsen ein. Für komplette Geobanausen alles zwischen Hessen /Niedersachsen und Polen. Nur als Tipp für denjnigen, der da Sachsen hingeschrieben hat. Ich bin selber ein in Sachsen-Anhalt geborener Thüriunger, kein Sachse. Das ist ja glatt so, als würde man einen Kölner mit einem Düsseldorfer verwechseln.
Könntest Du mir das bitte mal auf dieser Karte zeigen, die völlig ausreichend für mein Weltbild ist?
Irgendwie wurden hier glaub nur URLs auf Beispiele in Sachsen reingestellt, danke, dass Du die Region nun näher spezifiziert hast
Sobald ich mit den Basteleien an den Osmarender-Styles fertig bin, muss ich mich wohl mal intensiver um die diversen Tagging-Schemen kümmern…
Zwecks Tagging Schemen. Nimm dir schonmal viel Zeit. Ich bin da nun schon ein halbes Jahr dran. Das man nun noch den Schnellschuss eures “Workshops” zwischen hat, macht das ganze nicht unbedingt einfacher. Wichtig ist eben das die Grundelemente die für alle von Interesse sind dann auch anständig von den Anwendungen ausgewertet und von den Renderern dargestellt werden. Wie wir wissen schleift es da. Selbst die einfachen Road Relationen werden bis heute nicht genutzt, liegen tot in der DB.
Deswegen wollte ich die halt und station so belassen und habe das ganze nur um Informationen ergänzt. Das garantiert schonmal vollkommene Kompatibilität und ist simpel auszuwerten, da diese Elemete bereits von allen Anwendungen erkannt werden und sich keiner mit komplexen Relationen rumschlagen muss. Der Rest sollte wie auch hier im Thread geschrieben und leider durch das Forenupdate total vermanscht in eine Gesamtrelation kommen, in meinem Fall nur Umfangreicher. Stop Punkte usw. kann man ja extra definieren. Die brauchen die Renderer ja nicht. Da sind dann Dinge für Spezialanwendungen und die müssen die Standardrenderer nicht berücksichtigen.
Und in diesem von der Mainstreamkarte abgekoppelten Tagginbereich, kann man sich dann auch mal mehr gedanken machen. Individuelle Stop Punkte für unterschiedliche Verkehrsarten, Bahnsteigzonen ect. Der Missbrauch des Halt Tags ist da eher suboptimal.
Da sind noch einige mehr Schnitzer drinnen. Service und Usage überschneiden sich z.B. da hätte die Erweiterung von service ausgereicht. Da fehlt dann aber wiederum eine ausführliche Definition. Zum Beispiuel was eine Haupt- und eine Nebenbahn ist. Es gibt die konzipierten und die gefühlten. Der Laie neigt dazu eine Hauptbahn als Nebebenbahn zu taggen, wenn dort heute nur noch ein Triebwagen fährt. Genauso wie manche Verbidungskurve durch ICE Betrieb schnell zur Hauptbahn wird.
Beim Lichtraumprofil gibts UIC konforme Normen. In Deutschland gilt fast durchgängig EBO G2, Ausland meist G1, ansonsten gibts Einschränkungen. So verwende ich das bereits. International gibts UIC GA, GB und GC. In mm gibt das keiner mehr an. Das soll und kann auch sowieso keiner genau nachmessen, da reicht die UIC Norm.
Voltage muss auch nicht überall dran. In Deutschland impliziert rail mit contact_line automatisch 15 kV. Voltage kann man daher auf die ganz wenigen Ausnahmen anwenden. 25 kV dürfte so gut wie ausgestorben sein. Da gab es hier nur die Teststrecke vom LEW und die Rübelandbahn. Daneben gab es beispielsweise die Kohlen- bzw. Werkbahnenbahnen mit 1200 bis 1400 Volt, von denen es auch nur noch ganz wenige gibt. Daneben noch Stadtbahnen auf eigener Infrastruktur. Aber ansonsten sind 99% mit Strippe immer 15 kV.
BTW taucht auf der Mailingliste das nächste Problem auf. Irgendwer verswechselt da die Fahrgastinformation Gleis X mit dem Gleis ansich und rät nun tatsächlich dazu bei Bahnsteigen mit zwei Nummern die “Gleis” Nummer direkt an das Gleis zu hängen. In der Praxis hätten wir damit dann gleich bis zu 3 mal ref, was nicht geht. Bei Streckengleisen und deren laut Spurplan zugehörigen Brüdern die Streckennummer, die Gleisnummer der Betriebsstelle die nicht immer Deckungsgleich mit der “Gleis” Nummer am Bahnsteig ist und nun auch noch die “Gleis” als reine Fahrgastinformation am Bahnsteig.
