Haltestellen in der Stadt Essen

Hallo kann jemand mit einer automatischen Abfrage / Änderung bei den Haltestellen auf dem Essener Stadtgebiet den Betreiber von EVAG oder VIA in Ruhrbahn ändern? Fehlende EInträge vielleicht auch ergänzen?
Vielleicht auch das Netzwerk VRR ergänzen?

Das gleiche dürfte wohl auch das Mülheimer Stadtgebiet betreffen.

Laut Wikipedia:
Die VIA gibt es nicht mehr.
Die EVAG heißt jetzt Ruhrbahn GmbH.
Die MVG heißt jetzt Ruhrbahn Mülheim GmbH
mit veränderten Zuständigkeiten.

Laut Internetseite der Ruhrbahn wird unterschieden zwischen
Ruhrbahn Essen und
Ruhrbahn Mülheim.

Im EVA-System wird aufgeführt:
Ruhrbahn (Essen) und
Ruhrbahn (Mülheim).

Der VRR listet:
Ruhrbahn GmbH mit Logo Ruhrbahn Essen und
Ruhrbahn Mülheim GmbH mit Logo Ruhrbahn Mülheim.

Technisch brauchen wir keine automatisierte Abfrage, das wäre in josm nach overpass-turbo Abfrage sofort möglich.

So ganz eindeutig ist die Sache nicht.
Neben den Haltestellen sind auch die Routen zu berücksichtigen.

Edit: Mülheim

@AxelR: Für jedes Mal Mühlheim gibst du nächstes Mal ein Bierchen aus :smiley:

Hallo Axelr,
wie wäre denn das Vorgehen in JOSM wenn ich das Ergebnis einer overpass-Turbo Abfrage habe und beispielsweise die angesprochene Änderung von “EVAG” auf “Ruhrbahn Essen” für alle nodes in einem Rutsch erledigen möchte?

Nach den fünf Flaschen Bier mache ich dann einen Schreibtest mit dir.
Ich werd es mal editieren.

In josm frische Ebene anlegen und
Filter -operator=EVAG anlegen (alle, die nicht operator=EVAG enthalten) und erstes Häkchen setzen (Ergebis später Deaktiviert: xxx)

In overpass-turbo

/* scan Bus- und Bahnhalte bbox EVAG */
[out:xml][timeout:25];
( node[operator="EVAG"][highway=bus_stop]({{bbox}});
  node[operator="EVAG"][railway=tram_stop]({{bbox}});
  node[operator="EVAG"][railway=halt]({{bbox}});
  node[operator="EVAG"][railway=station]({{bbox}});)->.hnb;
( way[operator="EVAG"][public_transport=platform]({{bbox}});
  way[operator="EVAG"][railway=platform]({{bbox}});)->.hwp;
( node[operator="EVAG"][public_transport=stop_position]({{bbox}});
  node[operator="EVAG"][railway=stop]({{bbox}});)->.hns;
node[operator="EVAG"][public_transport=platform]({{bbox}})->.hnp;
rel[operator="EVAG"][public_transport=platform]({{bbox}})->.hrp;
rel[operator="EVAG"][public_transport=stop_area]({{bbox}})->.hra;
//((((.hwp; node(w.hwp);); .hns;); .hnp;); .hnb;)->.hnd;//scan alle ohne MP
//(.hrp; .hrp>;)->.hnd;//scan nur MP
//(.hns;- node(r.hra);)->.hnd;//scan solo stop_position
//((.hnp;- node(r.hra);); ((.hwp;- way(r.hra);)->.hwd; node(w.hwd););)->.hnd;//scan solo platform ohne MP
//((((.hnb;- node(r.hra););- node(w.hwp););- .hns;);- .hnp;)->.hnd;//scan solo old
//(((((.hwp; node(w.hwp);); .hns;); .hnp;); .hrp;); .hrp>;)->.hnd;//scan PTv2
//(((.hnb;- node(w.hwp););- .hns;);- .hnp;)->.hnd;//scan old
((((((.hwp; node(w.hwp);); .hns;); .hnp;); .hnb;); .hrp;); .hrp>;)->.hnd;//scan alle
//(.hnd;); // Ergebnis nur Elemente
(.hnd; .hra;); // Ergebnis mit stop_areas
//((.hnd; .hra;); .hra;>>;); // Ergebnis mit stop_areas und deren Inhalt
//(.hnd; rel(bn.hnd););//Ergebnis mit Relationen, fuer meta
//out skel qt;//Ausgabe zu klein
//out qt;//Ausgabe normal
out meta qt;//Ausgabe gross und josm

bbox um Essen setzen
Export
Josm

In josm
Filter ist noch gesetzt (der deaktiviert die Endknoten an den ways, die fuer josm mit übertragen werden müssen)
alles durch Aufziehen markieren
jetzt sollten unter operator nur EVAG stehen (ohne Zusatz xx nicht festgelegt)

Bis dahin ist es ja noch Konjunktiv und die Lösung von axelr deswegen auch rein hypothetisch! Wenn dies so umgesetzt wird, handelt es sich definitiv um einen mechanical edit, der unter die Rubrik Automated edits fällt, und was das heisst, brauche ich - denke ich zumindest - nicht näher ausführen.

Wenn ich deinen Link durchklicke finde ich vorwiegend alten Kram.

Könntest du das Vorgehen für diesen relativ eindeutigen Fall (Name hat sich geändert) aufzeigen ?
Fraglich ist hier nur welcher Name richtig ist, wobei Ruhrbahn Essen sicherlich praktikabel ist.

Dann verweise ich explizit noch auf Automated Edits - Code of Conduct - Guidelines.
Im Großen und Ganzen geht’s einfach darum, dass eine solche Änderung diskutieren und dokumentieren soll und auch das Vorgehen, die Hintergründe usw.

Genau, da geht’s ja schon los mit dem ersten Problem bzw. vermutlich längerer Diskussion :wink:

Das Hauptproblem bei solchen “Search&Replace” Edits ist auch die Tatsache, dass die Objekte selbst an sich eventuell gar nicht mehr valide sind, hier z.B. das eine Haltestelle gar nicht mehr existiert oder verschoben wurde, usw. Auch durch so eine Änderung suggeriert man ja durch die letzte aktuelle Version des Objekts, dass es (vollständig) aktuell ist, obwohl man ja auch nur einen Tag geändert hat.

Desweiteren sind natürlich auch noch die genutzen Quellen zu nennen, bin da nicht auf dem aktuellen Stand, aber vielleicht dürfen wir ja aus den genannten Verkehrsbünden deren Daten offiziell nutzen, etc.

@Harald Hartmann
bitte jetzt mal Butter bei die Fische.

Reicht die Diskussion hier ? Wenn ja welche Wartezeit bis zur Umsetzung ?

Muss ich mich erstmals auf einer Mailingliste anmelden ? Wenn ja auf welcher ?

Sollen wir das im wiki VRR diskutieren, wo es wahrscheinlich kaum jemand liest ?

Gruß, Axel

Hallo,

Overpass + JOSM wäre auch meine Vorgehensweise gewesen. So habe ich das beim Übergang der Gleise der S-Bahn Berlin von der S-Bahn Berlin GmbH zur DB Netz AG gemacht. https://wiki.openstreetmap.org/wiki/User:Nakaner/Mechanical_Edit_Berlin_S-Bahn_Infrastructure_Operator_Change

da das betroffene Gebiet recht beschränkt ist (zwei Großstädte), würde ich den Automated Edits Code of Conduct nicht allzu zu streng auslegen. Das Ziel der Regeln ist, dafür zu sorgen, dass die Leute nicht ohne vorher nachzudenken und ohne weitere Prüfung ein Bot-Feuerwerk veranstalten und andere Benutzer verärgern. Die Diskussion soll anderen Mitwirkenden die Gelegenheit geben, auf Fehler hinzuweisen oder im schlimmsten Fall “Stopp!” zu rufen. Die Dokumentation soll die spätere Nachvollziehbarkeit ermöglichen und zwingt im Vorfeld den Autor dazu, sich genau Gedanken zu machen, was er wie machen möchte. Je größer das betroffene Gebiet ist oder je kontroverser die Änderung ist, desto höher sind die Anforderungen an die Diskussion und Dokumentation.

Eine Diskussion ist, wenn du nicht jedes einzelne Objekt beim Ändern im JOSM sichtprüfen [1] möchtest, IMHO schon erforderlich. Diese Diskussion hier im Forum ist auf jeden Fall die Diskussion. Du solltest jedoch unabhängig davon noch eine Mail an die örtlichen Mailingliste schicken, weil wir bei OSM sehr viel Wert auf die Community vor Ort legen.

Die Dokumentation im Wiki kann knapp gehalten sein. Entweder legst du die Seite hxxps://wiki.openstreetmap.org/wiki/Mechanical_Edits/ an, wobei der Benutzername ist, mit dem der mechanische Edit hochgeladen werden wird. Wenn es für den ÖPNV in Essen/Mülheim (Ruhr) eine separate Seite im Wiki oder einen Abschnitt auf der Stadt-Seite im Wiki gibt, kannst du den mechanischen Edit auch dort dokumentieren (anstelle von hxxps://wiki.openstreetmap.org/wiki/Mechanical_Edits/)

Die Dokumentation sollte folgende Fragen beantworten:

  • Warum ist der mechanische Edit erforderlich? Was ist das Ziel? – Antwort: Betreiber hat Struktur geändert und heißt anders
  • Wie werden die bearbeiteten Objekte ausgewählt? – Antwort: Overpass-Abfrage angeben (kein Link, sondern Quellcode)
  • Womit werden die Änderunge hochgeladen? – JOSM
  • Wer macht den Edit? – dein Benutzername
  • Wo wurde der Edit diskutiert? – Link hierher und ins Archiv der örtliche(n) Mailinglisten

Eine einwöchige Wartezeit zwischen dem ersten Posting und dem Edit halte ich angemessen, solange keine berechtigte Kritik an der Vorgehensweise geäußert wurde.

Viele Grüße

Michael

[1] Eine Besichtigung vor Ort ist nicht erforderlich, aber eine Bushaltestelle in einem See sollte dir dabei schon auffallen.

@Nakaner: Danke für die Unterstützung :slight_smile: So detailliert hätte ich es definitiv nicht hinbekommen. Aber vielleicht dann beim nächsten Mal

Mal eine Frage: sind die Mentz (oder wie die jetzt heißen) Bearbeiter aus der Sache inzwischen raus? Vielleicht können die Prüfung und Änderung schneller übernehmen? Nicht, dass ich jetzt jemanden den Spaß wegnehmen will.

Vorschlag A zur Neubenennung der Operatoren:
Wir nehmen operator=“Ruhrbahn” für vormals EVAG und MVG

Vorschlag B zur Neubenennung der Operatoren:
Wir nehmen operator=“Ruhrbahn Essen” für die ehemalige EVAG
Wir nehmen operator=“Ruhrbahn Mülheim” für die ehemalige MVG

**Hintergrund: **
Die EVAG ist umbenannt in Ruhrbahn GmbH, die MVG ist an der Ruhrbahn GmbH beteiligt und firmiert als Konzessionsgeber der Linien in Mülheim als Ruhrbahn Mülheim GmbH
Es scheint nach der Firmenaufteilung, dass die Ruhrbahn GmbH Betreiber aller Linien im Bereich ist.
Die Zuständigkeit für die Haltestellen müsste erfragt werden.

Jedoch gibt es unterschiedliche Fahrscheine mit Übergangsvereinbarungen in die jeweils andere Stadt.
In der Eigendarstellung der Ruhrbahn wird zwischen Ruhrbahn Essen und Ruhrbahn Mülheim unterschieden.

Die Namen EVAG und MVG und Via sind in jedem Falle Geschichte.

Massenedit:
Ich schlage nach Diskussion hier einen Massenedit vor.

Für Haltestellen durchzuführen in josm durch Änderung des Operators von altem Namen auf neuen Namen.
Die Suche der Haltestelle erfolgt nach diesem Forumsbeitrag #6.
Die räumliche Begrenzung auf Essen und Mülheim und Umgebung ist notwendig, da EVAG und MVG mehrfach vorkommen.

Für Routen durchzuführen in josm durch Änderung des Operators von altem Namen auf neuen Namen.
Die Suche der Routen erfolgt durch overpass api Abfrage ohne räumliche Begrenzung ähnlich zu
http://www.roeltgen.com/gpx/ibro_ol5relf.html#type=route&network=VRR&operator=EVAG bzw
http://www.roeltgen.com/gpx/ibro_ol5relf.html#type=route&network=VRR&operator=MVG

Die Umsetzung sollte zeitnah erfolgen. Angestrebt ist der 22.07.2018

Verfahrensbeschreibung: https://wiki.openstreetmap.org/wiki/VRR/Mechanical_Edits#Umbennnung_EVAG_und_MVG_in_Ruhrbahn

Anmerkungen:
Ich bevorzuge den Vorschlag B (“Ruhrbahn Essen” und “Ruhrbahn Mülheim”).

Proposal gefällt mir und da dieser Eingriff weder eine essentielle Veränderung des Datenbestandes mit sich zieht, sondern eine Überführung von historischen zu aktuellen Fakten ist, gebe ich ein +1

Ich würde allerdings noch eine Ergänzung anfügen: Statt der BBOX mit Begrenzung EVAG würde ich zusätzlich z.B. in der Relation der Stadt Essen prüfen, welche Haltestellen noch keinen Operator führen. Das ist allerdings optional und hat mit dem Namenswechsel nichts zu tun.

Nach heutigem Telefonat mit einer Ansprechpartnerin der Ruhrbahn GmbH:
Die Ruhrbahn GmbH betreibt das ganze operative Geschäft (Busse, Fahrer und Haltestellen).
Die Ruhrbahn Mülheim GmbH ist nur Konzessionsgeber für die Linien in Mülheim.

Demnach kommt nur Vorschlag A in Frage

@TobWen: Das Ziel ist die Beseitigug der veralteten Namen, nicht das Zupflastern mit teils überflüssigen Tags.

Danke für Eure Mithilfe. Der Betreiber kommt doch in mehr Felder vor, wie ich gedacht hatte.

Hoffe das es demnächst erfolgreich umgesetzt wird.

was genau meinst du mit “Felder”?

Gemeint waren die Einträge in der Overpass Abfrage von Axelr

Hallo zusammen,

ich hätte da einen Gegenvorschlag. Grund dafür ist, dass man mit https://overpass-turbo.eu/s/Aqq noch mehr einschlägige Werte für “operator” findet:


0	0	4		BOGESTRA;EVAG	
247	590	125		EVAG	
0	0	2		EVAG, MVG	
0	0	1		EVAG; Bogestra	
8	3	5		Essener Verkehrs-AG	
63	13	82		MVG	
4	0	1		Mülheimer VerkehrsGesellschaft mbH	
0	1	0		Mülheimer Verkehrsgesellschaft	
0	3	0		Mülheimer Verkehrsgesellschaft mbH	
44	91	2		Ruhrbahn	

Ich persönlich würde jetzt erst einmal abklären, welche Arten von Elementen nach dem Edit einen Tag “operator” tragen sollen und bitte um Votum:

  • Bei Gleisen würde ich das befürworten
  • Busspuren, auch in Busbahnhöfen: nicht (gehört MH Hbf der Ruhrbahn oder der Stadt?)
  • Bahnsteige: ja
  • Aufzüge, Rolltreppen: unbedingt ja
  • weitere Wegeelemente im Bahnhof: ja. Für Fragen der Art, wer die Beleuchtung repariert und den Weg putzt.
  • Zuwegungen zum Bahnhof: nein
  • Linienrelationen: ja
    Es gibt dann noch einige Elemente, die ich nicht verwende, und zu denen ich keine Meinung habe: Station-Nodes, Stop-Area-Relation, Masterrelationen.

Ich rege an, dann

  • alle Elemente, die einen der obigen operator-Tags tragen, nach JOSM zu laden:

area[name="Ruhrgebiet"]->.a;
( nwr(area.a)[operator~"EVAG|Essener Verkehrs-AG|MVG|Mülheimer Verkehrs"]; >; );
out meta;

  • unabhängig davon die Klassen von Objekten, für die sich die Tendenz bestätigt, neu mit “Ruhrbahn” taggen
    Die Elemente mit “MVG”, die erkennbar zur Märkischen MVG gehören, werden dabei nicht geändert.

Zum Thema Mentz: Funktionierende Daten, d.h. Straßen- und Gleisgeometrien mit auswertbaren Tags möchte der VRR natürlich nach wie vor. Als Firma Mentz würden wir aber Mechanical Edits nur dann anstoßen, wenn das unbedingt notwendig ist (z.B. nur von uns Gemapptes anpassen). Daher ist der Beitrag jetzt hier aus rein persönlichem Interesse. Ich selbst bin auch kein Befürworter von Mechanical Edits. Ich versuche gerade nur, das Wie zu verbessern, nachdem das Ob nicht mehr zur Debatte steht.

Viele Grüße,
Roland