Umtaggingaktion light_rail=yes des Münchner Verkehrsverbundes

Hallo,

aus aktuellem Anlass [1] habe ich gerade ein besonders scharfes Auge auf das Mapping der ÖPNV-Infrastruktur. Frage ich etwa einmal täglich von der Overpass-API die in den letzten 24 Stunden geänderten Objekte bestimmter Themenbereiche ab. Als Beifang ging mir gerade eben eine koordinierte Taggingaktion des Münchner Verkehrsverbunds ins Netz.

Als erstes fiel mir dieser Änderungssatz von Floppy919 auf: https://www.openstreetmap.org/changeset/37868660
Kommentar: “S8 Ost: S-Bahn-Gleise mit “light_rail=yes” versehen und Streckenverlauf überarbeitet”
Der Kommentar beschreibt zutreffend, was getan wurde. Es wurde den Gleisen, die von S-Bahnen befahren wurde, ein light_rail=yes hinzugefügt.

Auf der Wiki-Seite des MVV findet sich eine Liste an Accounts (wie aktuell die ist, weiß ich nicht). Ich habe mir die Accounts dieser Liste angesehen und festgestellt, dass auch noch folgende weitere Accounts an dieser Aktion beteiligt waren:
https://www.openstreetmap.org/user/vstrasser
https://www.openstreetmap.org/user/valle129

Die Edits dieser beiden Benutzer habe ich auch kommentiert. Ich habe alle drei Benutzer gebeten, ihre Taggingaktion nicht fortzuführen. mvv.osm@gmail.com bekommt gleich noch eine Mail.

Eine Diskussion zu diesem Edit ist mir nicht bekannt. https://wiki.openstreetmap.org/wiki/Automated_Edits_code_of_conduct

light_rail=yes wird bislang nur an Routenrelationen, Bahnsteigen, Stop-Area-Relationen und Haltepositionen verwendet. Für die Münchner S-Bahn ist es falsch, denn die Münchner S-Bahn wird mit Vollbahn-Fahrzeugen auf normaler Vollbahn-Infrastruktur gefahren. Laut PTv2 ist das Tag sogar veraltet.

Die Züge der Baureihen 420 und 423 (die beiden werden in München eingesetzt) sind AFAIK normale Vollbahnfahrzeuge. Von Nutzungeinschränkungen ist mir nichts bekannt. [2] Wenn man für das Routing ein S-Bahn-Vorzugsnetz braucht, also eine Unterscheidung, ob ein Gleis von S-Bahnen regulär befahren wird oder nicht, braucht ihr nicht light_rail=yes an die Gleise taggen. Da genügt es, die Routenrelationen der S-Bahnen auszuwerten und dann im Routinggraphen bzw. der Datenbank des Renderers den entsprechenden Kanten/Linienzügen ein entsprechendes Attribut zuweist o.ä.

Viele Grüße

Michael

[1] Ich suche eigentlich nach Leuten, die gesperrt sind und sich Sockenpuppen anlegen.
[2] Manche Fahrzeuge haben nur eine eingeschränkte Zulassung, d.h. dürfen nur einen Teil des deutschen Eisenbahnnetzes befahren. Im Stammtstreckentunnel liegt die Linienzugebeeinflussung, die Züge der BR 420 haben sie (noch) nicht. Die Linienzugbeeinflussung wird mit railway:lzb=yes getaggt.

EDIT: Dativ → Genitiv
EDIT2: Titel verbessert

Nur eine kleine Ergänzug zu [2]:
Den 420 ist der Stammstreckentunnel nicht verwehrt, sie können mit den ortsfesten Signalen schon fahren, allerdings reduziert das die Kapazität, weshalb es kaum gemacht wird. Im Fahrplanjahr 2015 gab es gerade eine planmäßige S4 nach 23 Uhr, im derzeitigen Plan gar keine planmäßige Fahrt durch den Tunnel.

Grüße,
Rainer

Und noch eine kleine Anmerkung von mir:
Gerade die BR 420 hatte sehr viel LZB vom Start 1972 bis zur Einstellung gegen 1981 … alles schon mal dagewesen :wink:
Die aktuellen “Notbehelfs-Krücken” aus Stuttgart haben sie nicht, waren meiner Kenntniss nach auch “nur”
für die (LZB-Freie) Strecke nach Altomünster vorgesehen. Das nur nebenbei.

Zu Mentz (die das für den MVV machen) und deren Einträge:
Ich verfolge deren (manchmal wechselndes) Tagging mit leichtem Schmunzeln
und buche das unter “Die werden das für ihre MVV-App wohl brauchen”
Da sind viele unterwegs und “light” geht nicht nur für railway,
dass gibt es auch bei den Zugängen (entrance:light=yes) zB.

http://www.openstreetmap.org/node/186969912
und damit es auch “ganz sicher ist” gleich danach noch
http://www.openstreetmap.org/node/368112268
Klingt komisch, ist aber so …

Letztlich stört es aus meiner Sicht nicht wirklich schließlich taggen sie nicht railway=light rail
sondern machen sich mit ihrem light_rail=yes einen “EigeneWurstTag”.

Ob es missverstänlich ist dafür light_rail=* zu nutzen … mhhh.
Sicher kommt demnächst einer um die Ecke und möchte wissen:
Was nu, ist die Strecke railway=rail oder light_rail=yes, oder beides …

(Ich will jetzt nicht auf die Karlsruher Zweisystem-Stadtbahnbetrieb eingehen,
in dem letztlich genau das Tagging passen würde: Trambahn auf Bahngleisen …)

Servus
derBeKri

Hallo,

ich habe mittlerweile eine Antwort auf meinen Änderungssatz-Kommentar erhalten:

Danke, dass du mich darauf hinweist. So genau habe ich deren Edits noch nicht geprüft. Da München nicht zu meinem Interessensgebiet gehört(e), habe ich mir das dortige Tagging bislang nicht genauer angeschaut.

Ich denke, dass sich hier die Anwendung von Mentz an OSM anzupassen haben und nicht umgekehrt. Sonst kommt bald jeder und ergänzt seine privaten, selbst erfundenen Tags.

Das Problem ist, dass dieses Tag erstens anders definiert ist (ein 423er/420er ist keine Stadtbahn) und es eben schon in Verwendung ist, aber für andere Zwecke. Hier versucht jemand OSM an seine Applikation anzupassen, verzichtet auf eine ausreichende Anhörung der Community und das geht mir gegen den Strich.

Das hätte man sich auch früher überlegen können. Hier besteht wohl noch etwas Nachholbedarf im Umgang mit der Community.

Ehrlich gesagt finde ich es angemessen, schon kommendes Wochenede aufzuräumen (d.h. light_rail=yes löschen). Hier hat man ohne ausreichende Konsultation losgelegt und für mich ist das mit einem undiskutierten Import/mechanischen Edit vergleichbar. [1] Was meint ihr dazu?

Viele Grüße

Michael

[1] Der ursprüngliche Titel dieses Threads enthielt die Worte “mechanischer Edit”, ich habe sie entfernt, weil es eben keiner ist, sondern bloß eine Umtaggingaktion.

Dazu genügt folgende Overpass-Abfrage auf Basis der Routenrelationen:


[out:json][timeout:25];
(
relation[route=train][ref~"^S[ 0-9]"][operator~"^DB"]({{bbox}});
relation[route=train][ref~"^S[ 0-9]"][operator~"^Deutsche Bahn"]({{bbox}});
);
out body;
>;
out skel qt;

Wenn es bis dahin noch einmal eine Rückmeldung von den “Verursachern” gibt, und man sich auf eine andere Methode zur Markierung der Strecken geeinigt hat (z.B. eben die besagte Overpass-Abfrage, wenn sich diese für den gedachten Einsatzzweck eignet), kann man das ja durchaus so schnell schon machen. Aus der Antwort geht ja hervor, dass die neuen Tags problemlos wieder gelöscht werden sollten, wenn man denn durch Diskussion einen geeigneten Ersatz gefunden hat. So einen Ersatz zu finden ist ja sicher kein Problem und sollte auch nicht lange dauern, es braucht nur eben noch eine Bestätigung, ob dieser denn geeignet ist.

Wenn es natürlich eine Kollision zwischen diesem Tagging und dem etablierten Tagging gibt, also die Tags nicht nur überflüssig, sondern tatsächlich falsch sind, und das potentiell zu Problemen führt (so wie der Fall “Waldbesetzung als Campingplatz” neulich), sollte man das natürlich so schnell wie möglich beheben, meinetwegen auch mit einer temporären Zwischenlösung, bis die Sache geklärt ist - ohne die Daten an sich kaputt zu machen, in denen ja ein gewisser Arbeitsaufwand steckt.

Hallo zusammen,

ich hätte das schon noch gern selbst ausführlicher beantwortet aber es wurde ja bereits meine PM an Nakaner hier rein kopiert…

Zu dem Vorschlag mit den Routenrelationen:
Auch wenn das jetzt recht einfach klingt, kann ich das nicht selbst beurteilen. Ich bin nicht von der Firma Mentz sondern vom MVV, und Firma Mentz hat für uns einen automatisierten Import gebaut, der eben anhand dieses Tags erkennt ob es ein normales Bahngleis oder ein S-Bahn-Gleis importiert. Ich bin kein Programmierer und kann nicht beurteilen wie aufwändig der Umbau ist, dazu brauche ich erst mal eine Rückmeldung von Fa. Mentz.

Nakaner, du sprichst von UMtagging: Ich möchte darauf hinweisen, dass wir nichts UMgetaggt haben sondern eine neue Information hinzugefügt haben, es wurde inhaltlich nichts entfernt.

Abgesehen davon möchte ich hier mal die Grundsatzfrage stellen, wo denn bitte das Problem liegt wenn einem Gleis das permanente Merkmal “zugehörig zum lokalen S-Bahn-System” hinzugefügt werden soll. Klar, die Schiene mag sich optisch/technisch nicht von einer anderen unterscheiden, aber dann müsste man genauso gut das Operator-Tag hinterfragen, das sieht man der Schiene ja auch nicht an.

Für uns wäre das schon eine Vereinfachung da man die vorgeschlagene Relation-Abfrage bei jeder Linienänderung anpassen müsste, während sich an der von der S-Bahn befahrenen Infrastruktur viel seltener etwas ändert. Wenn das der Fall wäre übernehmen wir da natürlich auch die Anpassungen.

Unter http://wiki.openstreetmap.org/wiki/DE:Key:railway wird das light_rail-Tag beschrieben als “Stadtbahn und straßenbahnähnliche Untergrund oder Überlandbahnen. Verfügt oft über einen eigenen vom Straßenverkehr unabhängigen Gleiskörper.”
Auch in der Detailbeschreibung des Tags finde ich nichts was der Nutzung für S-Bahn grob widerspricht.

Wir wollen allerdings niemandem auf die Füße treten und sind natürlich gern offen für geeignetere Vorschläge um eine Schiene mit dem Merkmal “gehört zum lokalen S-Bahn-Netz” zu taggen.

viele Grüße

Dazu möchte ich nochmal folgenden Satz wiederholen:
" ich bitte dich aber die Änderungen bis auf Weiteres drin zu lassen da wir schon fast das gesamte Netz so getaggt haben"

Danke für dein rücksichtsvolles Verhalten!

Ich wiederhole gern auch nochmal, dass wir natürlich das Tag wieder flächendeckend ändern bzw. entfernen werden wenn das hier ausdiskutiert ist.
Davon nimmt doch jetzt wirklich niemand Schaden wenn das Tag jetzt erstmal dort stehen bleibt - und uns würde es eine Menge Arbeit ersparen.

Hallo,

ich denke, dass Mentz es sich hier mit der Aussage “Taggt doch einfach light_rail=yes dran.” einfach gemacht hat. Das spart Programmierarbeit und wahrscheinlich war dem Mitarbeiter nicht bewusst, wie das Tag definiert ist.

Diese Information ist schon mit den Routenrelationen erfasst. light_rail=yes für Gleise zu verwenden ist AFAIK eine Eigenkreation aus dem Hause Mentz/MVV. Für mich ist das Tagging für den Renderer/Router.

Es gehört sich bei OSM, dass man großen (koordinaten) Tagging-Aktionen, vorher diskutiert und nicht einfach loslegt. Das reduziert die Wahrscheinlichkeit, dass es nachher knallt (d.h. dass Leute wie ich sich beschweren oder die Edits revertiert werden). Die bisher bei OSM existierenden Richtlinien sind geschrieben worden, als kommerzielles Mapping noch Zukunftsmusik war. Wer jedoch mit mehreren Leuten gleichzeitig, in großem Stil Tags ändert, löscht oder ergänzt, ist von der Wirkung mit einem mechanischen Edit vergleichbar.

Du musst die Overpass-Abfrage nicht anpassen, wenn Linienäste getauscht werden. Dafür enthält die von mir als Beispiel genannte Abfrage extra reguläre Ausdrücke auf das ref=- und das operator=-Tag.

Wir erfassen die Linien, die eine Schienen-/Straßeninfrastruktur nutzen, in OSM nicht mit Tags an den Ways, sondern mit Routenrelationen. Aus demselben Grund taggen wir nicht psv=yes an alle Ways, die von Buslinien befahren werden.

Die Münchner S-Bahn ist keine Stadtbahn. Die einzige S-Bahn (das heißt als S-Bahn vermarktetes und das S-Bahn-Logo verwendende Bahnsystem), die eine Stadtbahn ist, ist die Karlsruher Stadtbahn. Es hat sich in den letzten ein bis zwei Jahren als Konsens herausgebildet, dass wir für die S-Bahn-Systeme Stuttgart, München, Rhein-Neckar, Rhein-Main, Rhein-Ruhr und Hannover nicht light_rail=yes verwenden.

Kennt ihr übrigens https://wiki.openstreetmap.org/wiki/DE:Tag:railway%3Dlight_rail

Viele Grüße

Michael

Guten Tag zusammen!

Ich muss Michael hier zustimmen, wenn jeder einfach eigene Tags erfindet und diese ohne Absprache großräumig Verteilt, kann das nur zu Chaos führen, zumal solche Tags die Eigenschaft besitzen, vergessen zu werden und Jahre später immer noch fragmentartig durch die Gegend zu geistern.

Allerdings freut es mich sehr, dass inzwischen auch größere Unternehmen die Vorzüge von OSM entdecken und diese auch nutzen wollen. Ich denke dem sollten wir auch nicht im Weg stehen, sondern versuchen konstruktiv zusammen zu arbeiten. Dies hat für alle Vorteile, so haben diese Unternehmen ein natürliches Interesse an aktuellen und genauen Daten, was für OSM nur positiv sein kann und die Unternehmen haben hier die Chance, diese Daten selber zu Pflegen und nicht darauf angewiesen zu sein, dass Unternehmen wie Google das rechtzeitig hinbekommen. Außerdem tut das unserer Publicity sehr gut.

Mein (vorläufiger) Lösungsvorschlag wäre eine Relation, die sämtliche Infrastrucktur im S-Bahn Bereich zusammenfasst und so für Mentz auswertbar wird. Diese könnte nicht nur die Streckengleise, sondern auch Weichenverbindungen, Abstellanlagen, Bahnsteige, Zugänge usw. beinhalten, jeweils durch die Rolle definiert. Das ermöglicht es diese Daten zielgenau auszuwerten und zu verarbeiten.

In Zukunft sollten wir uns überlegen, ob wir nocht ein Instrument schaffen sollten, mit dem sich Unternehmen Informationen, die sie brauchen und die es in der Form noch nicht im Datenbestand von OSM gibt, zurechtlegen können, ohne großartig am Bestand herum zu Basteln. Ich denke hier sind Relationen das Mittel der Wahl.

Viele Grüße,
hsimpson

Wenn jemand die Daten über OSM nutzen möchte, dann müssen sie auch mit OSM verträglich sein. Ansonsten sollte es kein Problem sein, mit einer internen Datenbank zu arbeiten. Relationen bzw. ganz allgemein Daten, welche nur für einen bestimmten Betrieb von Interesse ist, gehören nicht nach OSM.

Die Frage “Wo fährt die S-Bahn” ist selbstverständlich etwas, was auch die Allgemeinheit interessiert. Diese Information ist zudem schon vorhanden (siehe Overpass Query von oben). Wenn diese Informationen nicht reichen, sollte besser geklärt werden, was daran noch geändert werden muss.

OSM beinhaltet alle möglichen Daten. Über (zum Teil sehr komplizierte) Anfragen lassen sich dann genau die Daten filtern, die man benötigt. Ist das nicht möglich, sollte man auf neue Kriterien für die Anfrage prüfen und diese ggf. ergänzen. Aber bitte nicht die gewünschten Daten mit einem Tag markieren.

Hallo,

Nein, bitte keine Sammelrelation!

Ich habe gerade mal geschaut, welche Gleise mit light_rail=yes getaggt sind, die Abstellgleise sind (also in Betriebswerken und Abstellanlagen).


way[railway=rail]["light_rail"=yes][service=yard]({{bbox}});
out body;
>;
out skel qt;

Ergebnis: 0

Folglicherweise ist der MVV nur an den befahrenen Gleisen, auf denen die Linien verkehren, interessiert, also das, was in den Routenrelationen enthalten ist.

Wenn man “[service=yard]” durch [service] ersetzt, erhält man diverse Ausweichgleise in Kreuzungsbahnhöfen auf eingleisigen Strecken, diverse Überholgleise (service=siding) und ein paar Überleitgleise (service=crossover).

Unternehmen haben sich an uns anzupassen und sich ggf. innovative Konzepte zur Verknüpfung von OSM und eigenen Daten ausdenken.

Du sprichst mir aus der Seele.

Viele Grüße

Michael

PS Ein MVVler hat kürzlich usage=main an allen Gleise in München Hbf ergänzt. Das kritisiere ich nicht, weil da ursprünglich mal service=siding an vielen Gleisen korrekterweise getaggt war, aber von einem Nicht-MVVler entfernt wurde. (Der Änderungssatz wurde kommentiert)

EDIT: Link https://www.openstreetmap.org/changeset/34178754 ergänzt.

Genau so macht es die http://openptmap.org ! Und zwar schon seit vielen Jahren. OK, eher sinngemäß, weil die Karte Overpass nicht verwendet, sondern alles mit osmfilter erledigt. Läuft aber letztlich aufs Gleiche raus.

Beispiel München: http://openptmap.org/?zoom=15&lat=48.13641&lon=11.56833&layers=0B000TFFT

Mentz könnte sich mit diesem Trick die ganze Arbeit mit dem zusätzlichen Tagging sparen…

taoxue (eine Mentz-Mitarbeiterin) hat light_rail=yes gestern entfernt. Danke. https://www.openstreetmap.org/changeset/37923726

Jetzt bleibt nur noch das Problem mit entrance:light=yes und entrance=yes, welches auch an irgendwelchen Punkten in Stationsnähe verwendet wird, wo keine Tür o.ä. ist, sondern einfach nur als Routingziel dienen sollen.

Schädlich? Ich glaube nicht, deswegen sehe ich es auch nicht als Problem. Klar könnte man argumentieren, dass Metz hier Daten für sich selbst einträgt, aber damit sind es automatisch freie Daten, und irgendeine andere Firma könnte sie genauso nutzen, um ein eigenes Routingsystem oder eine eigene Übersichtskarte darauf zu stützen. Deswegen sehe ich in solchen Beiträgen eher einen Mehrwert für OSM und keine störende Datenergänzung. Zumal Metz ja dokumentiert, was sie tun und wozu es da ist:

https://wiki.openstreetmap.org/wiki/MENTZ_GmbH/Modellierungsvorschl%C3%A4ge_Indoor#Zug.C3.A4nge

Einzig den Namen des Schlüssels “entrance:light” finde ich etwas unglücklich gewählt, weil missverständlich. “entrance:light_rail” wäre vielleicht geschickter gewesen. Aber das lässt sich generell ändern – wenn es denn überhaupt wichtig ist.

Jo, und da steht ja dann auch … “Um einen Eingang in ein Bahnhofsgebäude kennzuzeichnen …”

Wenn es für Dich in Ordnung ist, das mitten in der freien Pampa ein “virtuell” Türe steht
http://www.openstreetmap.org/node/247450969
“ok” für Dich, ich finde es unpassend !
Ein entrance sollte ein (baulicher) Eingang bleiben und nicht ein beliebiger Zugangspunkt.

Ich werde in Zukunft an jeden “Eingang” in eine Grünanlage einen entrance setzen … ist ja nicht schädlich … und wichtig auch nicht.

Du hast Recht, die Beschreibung auf der Wiki-Seite von Mentz ist hier nicht korrekt. Ich hab sie korrigiert. Dazu ist es ja ein Wiki. :slight_smile:

Ja, das wär für mich ok. Ein Eingang ist ja nicht zwangsläufig ein Eingang in ein Gebäude. Es kann ja auch der Eingang in einen – irgendwie – zusammengehörigen Bereich sein. Aber das kann man ja noch diskutieren.

Kann man sicher machen, wenn die “Grünanlage” eine gewisse Bedeutung hat… zum Beispiel bei einem kleinen Park…

Ich weiß ja nicht wer Du bist, dass Du die Wiki-Seite von Mentz änderst (das wäre ja wohl deren Entscheidung)
und ich halte Deine Änderung von
Eingang in ein Bahnhofsgebäude → Eingang in ein Bahnhofsgebäude oder zu einem offenen Stationsbereich
schlicht für unpassend

WAS bitte ist unter einem “offener Stationsbereich” zu verstehen ?
WO setzt ich den Eingang zu einem “offener Stationsbereich”, an jede Ecke ?

Was wäre jetzt ok für Dich ? Mein letzter Satz ?
Du kennst das Wiki ? http://wiki.openstreetmap.org/wiki/DE:Key:entrance
Was heißt “beschreibt den Eingang zu einem Gebäude oder einer umschlossenen Fläche” ?
Ist ein “offener Stationsbereich” eine umschlossene Fläche ? Ich denke nein.

Das Mentz für’s Routing einen Zugangpunkt definieren muss mag sein, dafür entrence zu nutzen halte ich für sehr mißbräuchlich.
Was kommt als nächstes ? Ist eine Bus-platform dann auch ein “zusammengehöriger Bereich”
und bekommt vorne und hinten und überall einen entrance ? (und beim Bus natürlich noch einen entrance:bus=yes)

Aber das können wir ja noch diskutieren :wink:

Das war eigentlich als Ironie gemeint, aber dass muss ich in Zukunft wohl besser kennzeichnen.
Nein, kann man eigentlich nicht, macht (außer vielleicht Mentz) bisher auch keiner, hat wohl seinen Grund