"VRR Tagging": Abkürzungen, tram_stop, subway, Diskussions-Transparenz

Für die Stationen der DB sowie für die Eisenbahnstationen nicht-bundeseigener Eisenbahnen und diverser Straßen-/Stadt-/U-Bahn-Haltestellen kann man die “EVA-Nummer” (OSM: uic_ref=*) dem Datensatz “Haltestellen” des Open-Data-Portals der DB entnehmen. http://data.deutschebahn.com/datasets/haltestellen/

Ich schrieb “VRR”, weil in der Frage von Reclus eplizit nach dem Taggen von uic_ref im VRR-Bereich gefragt war …und nein, deswegen arbeite ich nicht automatisch bei oder für Mentz :slight_smile:

Sehe das Thema aber völlig unkritisch… meinetwegen kann uic_ref auch gern weiter gemappt werden. Würde meinen Rat dann auch zu einem versöhnlichen “wenn Du nicht weißt, woher Du die uic_ref einer Bushaltestelle bekommen kannst, ist es nicht schlimm, wenn Du sie ignorierst oder nicht pflegst” ändern. Gleiches gilt übrigens auch für die IFOPT-Nummer.

Um an die uic_ref einer Bushaltestelle zu kommen, kenne ich aktuell nur den Weg, auf http://reiseauskunft.bahn.de die gesuchte Hst im Abfahrt-Feld einzutippern und mit einem Network-Sniffer (z.B. Fiddler für Windows-Systeme) die JSON-Response der erfolgten AJAX-Anfrage “/bin/ajax-getstop.exe/…” mitzulesen. Dort ist dann im Objekt “suggestions” der Wert des Attributs “extId” zu verwenden, davon die letzten 7 Stellen zu nehmen und eine 8 davor zu setzen. Gibts ne “offiziellere” Quelle?

An die IFOPT-Nr einer NRW-Haltestelle kommt man übrigens via http://vrrefaosmprojekt.abd.systems/#stop-lists
Sorry, dass da schon wieder “EFA” und “VRR” auftauchen. Ich arbeite aber weiterhin nicht für/bei Mentz oder den/dem VRR :wink:

Gruß
Achim

http://wiki.openstreetmap.org/wiki/DE:MENTZ_GmbH#User.2C_die_in_unserem_Auftrag_Mappen

Hallo Achim,

Ich habe zwar das Verfahren nicht ganz verstanden, aber die 8-stellige uic_ref ist total falsch.
Eine uic_ref ist immer 7-stellig und wird nur für Bahnhalte vergeben.
Die Hafas-Nummer für Bushalte ist 6-stellig und gehört unter ref:ibnr=123456.
Der bessere Bezug, eine Haltesttelle mit Allerweltsnamen zu identifizieren, ist unter ref_name den Namen einzugeben unter dem man die Haltestelle im Bahnverzeichnes findet.

Sämtliche 8-stelligen uic, die mit deinem Verfahren mit 80 beginnen, sollten ohne die 80 unter ref:ibnr eingetragen werden.

Eine Erfolgskontrolle ist letzendlich mit der openptmap.de (eine Woche nach Änderung) möglich. Haltestellen anklicken und wenn die Bahnauskunft eine Auswahl verlangt, sollte ref_name oder ref:ibnr gesetzt werden.

Gruß Axel

Womit sich der Kreis zu meiner eigentlichen Aussage “uic_ref sollte für Bushaltestellen nicht gemappt werden” schließen würde :wink:

Aber Spaß beiseite. Tatsache ist, dass in der von Reclus zitierten Haltestelle https://www.openstreetmap.org/relation/1633847 genau so eine uic_ref drin ist (80664068). Und die kann man sich über den von mir genannten Weg “konstruieren”. Ob das nun was taugt, kann ich nicht beurteilen.
In der openptmap erscheint beim Klicken auf ebendiese Haltestelle jedenfalls die korrekte Abfahrtstafel. Kann aber auch an dem Attribut uic_name liegen, dass dort ebenfalls mit “Husemann-Sporthalle, Witten” erfasst ist.
Aber zumindest ist das doch schonmal ein sinnvoller Nutzen dieser beiden Attribute. Wäre nur noch zu klären, welches der beiden Attribute von openptmap.de mit welcher Prio verwendet wird.

Die sinnvolle Nutzung liegt darin, 8-stellige Nummern zu überlesen. Der name=Husemann-Sporthalle ist hinreichen eindeutig.

Die openptmap liest in der Reihenfolge uic_ref , ref:ibnr , ref_name , name und nimmt den ersten vorhandenen Tag.

Gruß Axel

Danke!

Hallo,
nach langer krankheitsbedingter Abwesenheit melde ich mich mal wieder. Aber nur kurz.
Die uic-Nummern für Bushaltestellen sind mittlerweile aus meiner Sicht obsolet. Mit dem VRR hatten wir uns auf die Nutzung der IFOPT-Nummer geeinigt. Aus meiner Erinnerung waren die uic-Nummern tatsächlich von Dittrich, es wurde aber damals der Fehler gemacht, die Länderkennzeichnung vor alle Bushaltenummern zu setzen. Das das ein Fehler war, wurde damals nicht erkannt. Das openptmap zuerst die uic_ref liest, war mir bisher auch nicht bekannt.
Bei Bushaltestellen, die ich nach Eintragung der IFOPT-Nummer angefasst habe, habe ich die uic_ref wieder eintfernt gehabt. Ich bin auch nicht 24 Stunden mit OSM beschäftigt, deshalb möge man nachsehen, wenn es nicht vollständig passiert ist.

Welcome back und gute Genesung!

In meiner Stadt (Witten) habe ich mich jetzt ein wenig mit ÖPNV beschäftigt. Dazu ein paar Fragen:

  1. Mir sind ein paar eindeutige Fehler in den VRR-Daten aufgefallen. Habt ihr schon wegen Fehlern Kontakt zur BOGESTRA aufgenommen?

  2. Könnt ihr mir den Ansprechpartner bei der BOGESTRA mitteilen?

  3. Den Ennepe-Ruhr-Kreis hat zur Nahverkehrsplanfortschreibung 2015 ein Haltestellenkataster angelegt. Habt ihr schon bei Büro Stadtverkehr nach den Daten angefragt?

  4. Wie haltet ihr es mit share_taxi=yes und share_taxi:= für Anruf-Sammel-Taxis? Ich habe das vorerst an stop_position getaggt. (Es gibt auch route=share_taxi.)

  5. Habt ihr die neuen elektronischen Anzeigetafeln der BOGESTRA wahrgenommen?

  6. Spricht etwas dagegen, in den Routen Unicode-Pfeile → statt ASCII-Pfeilen => zu nehmen?

Die Abkürzungen in operator=* halte ich übrigens auch für sehr problematisch. So etwas sollte schon auf absehbare Zeit international eindeutig sein. Ein Hinweis auf eine Tabelle in einem nur auf Deutsch (!) verfügbaren Wiki-Artikel ist da wenig hilfreich. Ich würde eine Langform ohne Rechtsform wie oft als Wikipedia-Lemma verwendet für operator=* nehmen, zusätzlich operator:abbr=* und operator:wikidata=* für die Zukunft und Maschinenlesbarkeit. Beispiel für BOGESTRA, VER und BVR:


operator=Bochum-Gelsenkirchener Straßenbahnen
operator:abbr=BOGESTRA
operator:wikidata=Q889060


operator=Verkehrsgesellschaft Ennepe-Ruhr
operator:abbr=VER
operator:wikidata=Q2516281


operator=Busverkehr Rheinland
operator:abbr=BVR
operator:wikidata=Q151378

(Alles nicht meine Idee.)

Ich würde in meiner Gegend gerne alles so umtaggen. Würde dadurch etwas kaputtgehen?

Genauso problematisch sehe ich network=VRR. Da könnte man analog taggen:


network=Verkehrsverbund Rhein-Ruhr
network:abbr=VRR
network:wikidata=Q448199

Die ganze Geschichte mit den Abkürzungen haben wir jetzt gefühlt schon 100mal durchgekaut und sind bei dieser Lösung angekommen. Jetzt wieder alles für den ganzen VRR umtaggen halte ich erstmal für keine gute Idee. Das ist Unsinn. In Verbindung mit VRR und mit dem Gebiet sind die Bezeichnungen wie z.B. VER, BOGESTRA etc. eindeutig und bedürfen keiner ausführlichen Ausschreibungsform. Zudem sucht der Nutzer nicht nach “Bochum-Gelsenkirchener Straßenbahn” sondern nach BOGESTRA. BOGESTRA findet man auch überall an Schilder, Bussen, Bahnen etc. und nicht bzw. an nicht auffälliger Stelle die Langform.

Wir haben mit dem VRR und einzelnen Verkehrsgesellschaften durchaus Kontakt. Mitarbeiter z.B. der BOGESTRA sind bei Änderungen in ihrem System angehalten auch OSM zu ändern. Das ist so verabredet. Warst Du damals bei den beiden Treffen dabei?

Natürlich macht es Sinn, wenn operator=, network= etc. international eindeutig sind. Es vereinfacht die Datenbankabfragen und verhindert Fehler. Wenn die Bezeichnungen nur in bestimmten Gebieten eindeutig sind verkompliziert das die Datenbankabfragen oder führt zu Fehlern. Und die Abkürzungen können ja gerne in operator:abbr=* gemappt werden.

Ist es tatsächlich so, dass ihr bei dieser Lösung angelangt seid? Das Thema war für das nächste Treffen mit dem VRR vorgesehen, das nicht stattgefunden hat. Es könnte ja auch sein, dass ein bestimmter Mapper, der eine Zeit lang viel bzgl. VRR gemacht hat, die Abkürzungen gemappt hat und Leute, die sich im Forum mit anderer Meinung melden, aggressiv angeht.

Ich war nicht bei den Treffen dabei. Nochmal: Ich habe Fehler in den Daten gefunden. Ich würde diese Fehler gerne an die BOGESTRA weitergeben, damit sie korrigiert werden können. Daher meine Frage, ob ihr schon Kontakt wegen Fehlern mit der BOGESTRA aufgenommen habt und ob ihr mir den Ansprechpartner bei der BOGESTRA mitteilen könnt.

Es hat zwar nichts mit meinen Fragen zu tun, aber: Es ist in den letzten Jahren einiges an Bushaltestellen hier in Witten gearbeitet worden (erhöht, Blindenstreifen…). Die BOGESTRA hat aber nichts umgemappt. Ich hatte an vielen Haltestellen FIXMEs eingetragen (nicht wegen dieser Arbeiten, sondern wegen Mappingfehlern). Da sich aber niemand um die Korrektur gekümmert hat, habe ich mich vor kurzem der Sache selbst angenommen.

Lieber Reclus,

so…habe mal wieder kurz Zeit,

Wir haben uns auf dem Treffen in Dortmund am 29.03.2016 für den VRR auf das folgende Tagging-Schema geeinigt: https://wiki.openstreetmap.org/wiki/VRR_Tagging. Darin haben wir uns auch auf die Kurzbezeichnung (Abkürzung) der Verkehrsunternehmen geeinigt. Da ist keinerlei Agressivität dran zu erkennen.
Ich verstehe nicht den Sinn, ständig alles hin und her zu ändern. Wir haben uns damit viel Arbeit gemacht. Der Einwand “mir gefällt es anders besser” ist nicht gerade zielführend. Die Diskussion und die Einigung dahingehend war nunmal ein Kompromis. Meine Bitte ist, nicht beleidigend zu werden und einzelne User/Mapper hier anzugreifen, sondern sich auch mal auf einen Kompromiss einzustellen. Nachvollziehbare Gründe für Langnamen gibt es nicht, Eindeutigkeit ist schon durch das Zusammenspiel VRR/Verkehrsunternehmen gegeben. Und es nur in einzelnen Gebieten so zu machen, an anderer Stelle wieder anders, bringt das Chaos zurück, was wir auf den gemeinsamen Treffen versucht haben zu beseitigen.

Eine Haltestellenübersicht des ganzen VRR haben wir bekommen, ein dezidiertes Haltestellenkataster bisher nicht. Ob dies bereits jemand angefragt hat, entzieht sich meiner Kenntnis.

Was für Fehler in welchen Daten sind es denn? An die BOGESTRA kann ich gerne Fehlermeldungen weitergeben. Bezieht es sich auf Linienführungen in OSM, so ist die Bogestra für nicht zuständig. Alle Fehler bei Daten in OSM sollten mit dem User besprochen werden, der die Änderung vorgenommen hat.

Thoschi

Die Verkehrsunternehmen mappen die Haltestellen meines Wissens bisher noch nicht. Die Lage von Haltestellen wird bzw. soll aber geprüft werden. Haltestellen und Busbahnhöfe werden meist von MentzDV für ein Routing umgetaggt. Fehler passieren dabei uns sind mir auch schon an einigen Haltestellen aufgefallen. Inwieweit MentzDV aber jede Haltestelle mappt, ist mir unbekannt.

Auf einen sachlichen Vorschlag einfach mit “Das ist Unsinn.” zu reagieren, ist aggressiv.

Das ist völlige Ignoranz gegenüber meiner auch schon wiederholten Begründung und das Ziel scheint es zu sein, eine sachliche Diskussion zu verhindern. Ich habe niemals “mir gefällt es anders besser” geschrieben.

Für mich ergibt sich ein ganz anderes Bild, das sich eben auch in diesem Thread zeigt. Eine kleine Gruppe (oder nur eine Person) “sitzt” auf ihren Festlegungen und blockt Verbesserungsvorschläge hartnäckig ab. Das wäre mir auch fast egal, wenn ihr in den letzten Jahren wenigstens eure Aufgabe erledigt hättet. Aber das ist eben nicht passiert. Ich habe praktisch alle Haltestellen in meiner Stadt nachbearbeitet. An praktisch allen waren Fehler. Und zwei Linien (371/373) waren unvollständig. Teilweise fehlten auch die Haltestellen. FIXMEs wurden nicht bearbeitet.

Du schreibst es praktisch selbst: Um die Daten sinnvoll auswerten zu können bedarf es externen Informationen, die nicht in der OSM-Datenbank liegen. Man muss wissen, dass es einen VRR gibt, was er ist und dass er in einem bestimmten Gebiet ansässig ist und in einem anderen nicht. Gleiches zu den einzelnen Unternehmen. Steht ja auch alles im Wiki. Das ist leider eine ignorante Sicht aus Mapper-Perspektive.

Du musst aber davon ausgehen, dass die OSM-Daten von einer dir unbekannten Software irgendwie verarbeitet werden und möglichst etwas sinnvolles dabei rauskommen soll. Deshalb ist Eindeutigkeit wichtig. Und deshalb ist es auch gut, dass es in OSM den Grundsatz gibt, möglichst nichts abzukürzen sondern auszuschreiben. Uneindeutige Abkürzungen sind wie auf einem Fußweg ausgelegte Bananenschalen.

Eindeutigkeit wird einerseits durch das vorgeschlagene operator:wikidata gegeben. Ich habe in den letzten Tagen über 1000 operator:wikidata-Tags mit Zusammenhang zum VRR gesetzt, da dies ja ein etablierter Tag ist, der auch nichts kaputt macht. Zusätzlich ist aber auch die Langform sinnvoll um auch Programmen, die nicht operator:wikidata lesen, Eindeutigkeit zu geben. Ich hätte bei dieses Edits auch problemlos schon operator-Tags ändern und die operator:abbr-Tags eintragen können. Soll sagen: Man kann diese Änderung schnell durchziehen wenn man will.

Fehler in den VRR-Daten wie geschrieben. Einmal z.B. hält ein Bus in der Realität an einem anderen Steig als laut VRR.

Das wäre ja noch schöner. Fehler in OSM korrigiere ich natürlich statt sie länger zu diskutieren. Wie geschrieben waren in meiner Stadt praktisch an allen Haltestellen Fehler und ich habe sie korrigiert. Vorher standen lange FIXMEs dran, wurden aber ignoriert. Ich habe weiter oben sechs Fragen gestellt und ihr seid nicht darauf eingegangen. Wäre das Ergebnis besser gewesen wenn ich mehrere hundert Fragen gestellt hätte? Wohl kaum. Ich habe den Post dann auch an die NRW-Mailingliste geschickt (laut Wiki euer offizielles Diskussionsforum) und dort ist jemand darauf eingegangen und hat die Vorschläge begrüßt.

Wenn das für Dich aggressiv ist, dann bist Du sehr zart besaitet.
Wie bewertest Du dann, einen Vorschlag zu bringen, der schon zigmal diskutiert wurde?

Wir haben uns über das Thema ob wir z.B. Bochum-Gelsenkirchener Straßenbahn (ggf. mit AG) oder BOGESTRA schreiben, zuletzt im März letzten Jahres ausführlich unterhalten. Mehrheitlich haben wir uns dazu entschieden, im VRR die Abkürzungen zu verwenden, da diese am gebräuchlichsten sind. Und wir haben festgestellt, dass diese sehr wohl eindeutig sind. Zeige mir jemanden, der in seiner Software “Bochum-Gelsenkirchener Straßenbahn” auswertet.
Zudem haben wir dies aus Praktikabilitätsgründen gemacht. Die Fehleranfälligkeit beim Schreiben des Langnamens ist deutlich höher. Es wird Chaos geben (wie es früher war), weil es zig unterschiedliche Schreibweisen gibt (bei der BOGESTRA alleine schon ob mit oder ohne Bindestrich). Somit ist eine einheitliche Auswertung auch nicht mehr möglich. Mit der gebräuchlichen Abkürzung aber schon.

Und auf den Ergebnissen der Auswertungen hast Du einen ellenlangen Namen stehen, der ggf. andere wichtige Informationen überdeckt oder aufgrund der langen Angabe nutzerunfreundlich vielleicht sogar unbrauchbar macht. Ich (ja, hier werde ich mal persönlich) möchte z.B. nicht auf dem Smartphone ständig nach links oder rechts scrollen müssen, nur weil der Langname mit Informationen dahinter nicht ins sichtbare Feld passt. Diese Problematik ist mit der Abkürzung ebenfalls größtenteils behoben.

Und dann die regelmäßigen Vorschläge, insbesondere dann, wenn jene, die bei der Entscheidung nicht dabei waren um zu erklären, dass man sich sehr wohl darüber Gedanken gemacht hat, und Änderungen mit einer “Mehrheit” von nur einem Abstimmenden durchsetzt. In diesem Zusammenhang bitte ich Dich wahrzunehmen, dass nicht ich etwas alleine durchgesetzt habe, sondern dass wir beim Mappertreffen ausführlich und kontrovers darüber diskutiert haben und eine Entscheidung gemeinsam getroffen haben.

Nun, wir alle haben Jobs, sind mal krank oder im Urlaub und nicht hauptberuflich mit OSM beschäftigt. Man hat auch mal ein paar Wochen einfach keinen Bock sich damit zu beschäftigen. Dafür dass zur Zeit ich derjenige bin, der Deine Prügel abbekommt, ist Zufall. Im Übrigen werden Verbesserungsvorschläge nicht hartnäckig abgeblockt. Zum einen ist es eine Frage, ob es überhaupt ein Verbesserungsvorschlag ist. Zum zweiten kann man nicht davon ausgehen, dass wenn ich heute etwas schreibe, morgen schon die 30 Leute geantwortet haben, die sich ausführlich damit beschäftigt haben. Manchmal sind die Erwartungen an Antworten so hoch wie an professionelle Auskünfte, so what.
Ich habe mal kurz die Haltestelle Saalbau angesehen. Dort ist z.B. gar kein FIXME gewesen. Zudem bitte ich Dich folgendes zu bedenken. Wenn Du z.B. vor einem Monat ein FIXME eingesetzt hast, dann kann man nicht davon ausgehen, dass dies schon einen Monat später behoben ist. Schau Dir manche an, die sind Jahre alt.
Und dann stelle Dir die Frage, ob Du diese FIXME nicht selbst kurz hättest beheben können, wenn es eindeutige Fehler waren. Du bist selbst lang genug dabei. Ja, im Endeffekt hast Du es jetzt gemacht.

Haltestellen und Linien fehlen an allen Ecken und Enden im VRR, da macht(e) Witten keine Ausnahme. Ich für meinen Teil kann nicht hexen und bin keine 24 Stunden in OSM, im Gegenteil, ich lag über 6 Monate im Krankenhaus und hatte keine Möglichkeit dazu.

Wieso kann ich denn davon ausgehen, dass die mir unbekannte Software einen Namen wie “Bochum-Gelsenkirchener Straßenbahn AG” verarbeiten kann? Und wenn ich nach Verkehrsunternehmen suche und im Bereich des Ruhrgebietes BOGESTRA oder VER finde, dann sollte auch dem unbekannten Softwareentlickler klar sein, worum es geht. Wenn er für seinen Bereich Kohleminen haben will und nur Namen sucht und dabei auf z.B. BOGESTRA stößt, dann hat er eine fehlerhafte Abfrage gemacht und unsere Daten sind deswegen nicht falsch.

Schön dass Du operator:wikidata-Tags nutzt, meines Wissen gibt es da aber bisher keine Abstimmung drüber, sondern es dümpelt seit 2013 als Proposal vor sich hin.

Nun, die da steht VRR und nicht BOGESTRA…warum schickst Du die Fehlerliste dann nicht an den VRR?

Eine Schwalbe macht noch keinen Sommer…Scherz beiseite…ich habe keine Ahnung welche Zeitvorstellungen Du bei Antworten hast. Du scheinst aber nicht daran zu denken, dass wir alle nur Freizeitler sind und keine bezahlten Kräfte bei OSM. Wir haben alle ein Leben neben OSM und das hat in den meisten Fällen Priorität. Somit muss man sich einfach auch mal gedulden können.

Gruß
Thoschi (in der Hoffnung, Deinen Anspruch auf Sachlichkeit erfüllt zu haben)

Zu 1:
Wenn Du Fehler in den VRR-Daten findest (die zwar im Datenbestand des VRR enthalten sind, faktisch aber in der Verantwortung der BOGESTRA Haltestellen-Infrastruktur-Sachbearbeiter liegen), kannst Du diese momentan z.B. über Thoschi an die BOGESTRA melden. Es ist bekannt, dass speziell das Thema Steignummern und welche Linien nun an welchem Steig abfahren bei der BOGESTRA hier und da schief ist. Habe da selbst Erfahrungen in GE-Horst/Buer gemacht. Aktuell plant der VRR, für solche Fälle ggf. sogar E-Mail-Adressen der Verantwortlichen bei den Verkehrsunternehmen zu publizieren, damit dort korrigiert werden kann.

Zu 2:
Siehe zu 1.

Zu 3:
Nein. Für HST-Infrastruktur-Basidaten nutzen wir http://vrrefaosmprojekt.abd.systems und vor Ort-Besuche. Wenn Du Möglichkeiten siehst, die Haltestellenqualität in OSM durch diese Anfrage zu verbessern - z.B. den barrierefreien Ausbau ohne prmanente vor Ort Besuche mitzubekommen - tu das gern. Speziell im Raum EN kenne ich aktuell nur einen ÖPNV-affinen Mapper (Thoschi), der sich über konstruktive Unterstützung sicher freuen würde - vor allem bei Tätigkeiten, die am Ende jemandem etwas nützen.

Zu 4:
Grundsätzlich halten wir uns an die ÖPNV-Mapping-Empfehlungen für das VRR-Gebiet im Wiki:
http://wiki.openstreetmap.org/wiki/VRR_Tagging
Dort ist allerdings keine Aussage zu den AST vorhanden. Meiner Meinung nach wäre das verwenden von share_taxi=yes eine Option, sollte aber nicht den Key bus=yes pauschal ersetzen sondern zusätzlich auftauchen. Allein schom um HST mit ausschließlich AST-Bedienung von denen mit auch AST-Bedienung unterscheiden kann. Gemäß Definition und Erhaltung der Kontinuität gehört die Angabe eines Verkehrsmittels aber dann sowohl in die platform wie auch in die virtuelle stop_position. Dies jetzt aber einfach so nur für Witten zu ändern, halte ich für wenig zielführend. Habe allerding in meinem Schwerpunktbereich Kreis RE/Bottrop ein ähnliches Tag schon vermisst.

Zu 5:
Jepp. Coole Dinger, vor allem wenn das mit dem Batteriebetrieb durchgängig haltbar ist. Das Display und die Funkübertragung der Daten brauchen ja auch ihren Strom… Kannst Du übrigens gern mit passenger_information_display=yes taggen :wink:

Zu 6:
Unicode Pfeile:
Technisch wahrscheinlich nicht. Nur dass es im Wiki anders vorgegeben ist und die Unicode-Pfeile nicht auf Tastaturen zu finden sind. Und evtl. nicht jeder Mapper immer eine CharMap bei der Hand hat, um sich die Zeichen dort rauszukopieren. Es wäre eine rein kosmetische Änderung, sicher machbar, aber meiner Meinung nach nicht dringend notwendig, es flächendeckend zu ändern.

Abkürzungen:
Hier kann ich mich nur komplett den Aussagen von Thoschi anschließen. Gemäß Lehrbuch, in einer idealisierten, theoretischen Welt wäre sicherlich Dein Vorschlag der einzig vertretbare. Das ist OSM aber nunmal nicht. Die Frage ist halt, wem eine plötzliche Änderung von jahrelang etablierten Schreibweisen, die zudem sogar eindeutig sind, etwas bringt - außer jeder Menge Konfusion, weil jeder den Langnamen künftig anders schreibt (gutes Fehlerpotezial bieten da erfahrungsgemäß die Bindestriche (oder eben keine) sowie ß oder ss.
wikidata:
Die Idee mit operator:abbr oder operator:wikidata zu arbeiten, ist nicht schlecht - die Frage ist, wie schlau es ist, solche massiven Redundanzen zu generieren und in z.B. in mehr als 50.000 VRR-platform/stop_position-Objekten neben dem neuen Langnamen noch festzuhalten, was die Abkürzung und die Wikipedia-ID des Betreibers ist… das würde mir an einer Stelle reichen. Eine lokale Lösung für Witten bringt am Ende wahrscheinlich auch eher wenig.

Noch ein kleiner persönlicher Appell:
Meiner Meinung nach gibt es so viel im ÖPNV-Bereich des VRR (mit immerhin 38 Verkehrsunternehmen) in OSM zu tun, dass die wenigen Leute, die sich dafür aktuell schwerpunktmäßig interessieren, sich nicht an Grundsatzdiskussionen mit minimalstem Nutzwert aufreiben sollten, nur um einen Idealzustand zu erreichen, sondern eher an den Dingen werkeln, die OSM-Nutzern oder gar den VRR-Fahrplanauskunftsnutzern was bringen, dies sind meiner Meinung nach:

  • Korrektes platzieren von Bussteigen, versehen mit korrektem Namen und Steignummer - auch wie von Dir erwähnt mit Fehlerreport an das Verkehrsunternehmen (Habe ich für die Vestische beim Erfassen der 3.500 Steige auch ausgiebig getan)

  • Pflegen von Straßen und Fußwegdaten im Haltestellenumfeld (direkte Einflussnahme aufs Fußgängerrouting in der VRR EFA)

  • Pflege von Haltestellenausstattung im platform-Objekt (shelter, wheelchair, bench, bin, lit, tactile_paving)

  • Entfernen von Fußwegen zwischen platform und stop_position sofern noch vorhanden :wink:

  • Pflegen von relevanten POI aus der Liste http://wiki.openstreetmap.org/wiki/VRR/Zusammenarbeit#Jahreswechsel_2015.2F16 (direkte Einflussnahme auf angebotene POI in der VRR EFA)

Achja, und ganz wichtig, für die meisten ist OSM ein Hobby und soll Spaß machen. Individuelle Holzhammer-Herangehensweisen oder das Gefühl, dass von einem permanente Präsenz auf der Plattform “gefordert” wird, sind eher kontraproduktiv.

Es ist per Deifinition nicht die Aufgabe der Verkehrsunternehmen, Haltestellen/Steige in OSM zu mappen. Schön ist/wäre es natürlich, wenn sie es trotzdem tun. Manche tun es, manche nicht. Aber auch dort spielt der Faktor Zeit und KnowHow eine Rolle. Nicht jeder Verkehrsplaner ist Hobby-Kartograph oder hat noch ein paar Tage übrig, sich ausgiebig in OSM und JOSM einzuarbeiten.
Aktuelle Aufgabe der VU ist es eher, die Steigpositionen der eigenen Haltestellen für die VRR Fahrplanauskunft nachzubearbeiten. Diese konnten früher aufgrund des verwendeten Kartenmaterials (Pkw-Karten von NAVTEQ ohne jegliche brauchbare Bezugspunkte) nur geschätzt werden und sind deshalb heute noch oft deutlich von ihrer tatsächlichen Position entfernt, mit manchmal negativen Auswirkungen auf das Fußgänger-Routing.
Bei der Repositionierung der Steige würde den VU-Kollegen eher ein bereits in OSM sauber positionierter Steig helfen, um die Korrektur im GIS des EFA-Backends dann nachzuziehen. :wink:
MENTZ hat nur die Haltestellenumgebungen angefasst, für die es beim VRR bereits Umgebungspläne gab, also grundsätzlich für die “größeren Umsteigepunkte”

Strenge Worte für ein (s.o.) vermeintliches Sensibelchen :wink:
Wer ist denn die Person (wir haben hier doch keine Geheimnisse) und wer sind denn “ihr” und was genau ist denn in OSM wessen definierte Aufgabe!? Und welche Verbesserungen (ja, Verbesserungen, nicht Veränderungen) wurden denn hier im Forum schon vorgeschlagen und abgelehnt?
Das Problem ist (für Dich) in diesem Fall, dass leider niemand die Pflicht hat, permanent nach Möglichkeiten zu schauen, ÖPNV-Daten in OSM zu verbessern. Wer Fehler findet, darf sie korrigieren oder gern diskutieren, aber - mal überzeichnet gesagt - irgendwo hinschreiben, dass alles falsch ist und sich dann beschweren, dass niemand es sofort oder überhaupt korrigiert, ist eventuell eine ungünstige Herangehensweise an das Thema…

Und ein klares Statement zum erneuten Aufbringen zigfach diskutierter Themen mit geringem bis keinem realen Nutzwert (“Abkürzungen”) musst Du dann schon vertragen können (gerade als bisher Unbeteiligter), und zu allen anderen Punkten hast Du aus meiner Sicht vernünftige Antworten erhalten.

Meine Meinung: ganz klar gesagt: wenn ein Unternehmen (z.B MENTZ) Daten in OSM einträgt und dafür User benennt, sollten diese auch Fehler oder Änderungen überprüfen. Eine einmalige Aktion hat noch nie etwas gebracht. Schließlich möchten diese Unternehmen bestimmt weiterhin aktuelle Daten habe.
Und OSMI, keep_right und OSMOSE sollte eventuell einmal um diese “größeren Umsteigepunkte” verwendet werden; und beim eintragen auf den JOSM-Validator achten.
( http://keepright.ipax.at/report_map.php?schema=101&error=78117968 )