Womit sich der Kreis zu meiner eigentlichen Aussage “uic_ref sollte für Bushaltestellen nicht gemappt werden” schließen würde
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.
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.
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.)
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:
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.
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.
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
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
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.
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
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 )
Dresden ist ja nicht im VRR.
Für die Ummodellierungen der Umsteigepunkte sind meines Wissen zumindest teilweise OSM-Mapper durch Mentz angeworben worden, wenn auch nur für einen kurzen Zeitraum. Nichtsdestotrotz sollte man diese auf Ungereimtheiten und Fehler aufmerksam machen, damit sie die Möglichkeit haben, auch andere von ihnen bearbeitete Umsteigepunkte zu berichtigen.
Für den VRR trägt aber im Normalfall keines der Unternehmen Daten in OSM ein, sondern nutzt diese. Was nicht heißt, dass Haltestellenverlegungen etc. von Mitarbeitern der Unternehmen nicht eingetragen werden dürfen (Anm.: ohje, doppelte Verneinung, hoffentlich geht das gut :-)) ).
Ich würde davon ausgehen, dass der operator-Wert eh v.a. für Programme nutzbar ist und weniger für die direkte Anzeige beim Endnutzer. Gerade dafür könnte aber operator:abbr sinnvoll sein. Nominatim-Abfragen zeigen oft analog short_name statt name an. Nebenbei: Du hast entgegen den VRR-Taggingvorschlägen die Routen immer länger (ausführlicher) benannt als notwendig. Ich habe z.B. die Routen der 310 auf z.B. “Tram: 310: Bochum→Witten” gekürzt wie im Wiki vorgesehen.
Die Namen sollen nicht direkt von der Software verarbeitet werden können. Es geht mir nur um Eindeutigkeit. BOGESTRA ist da auch weniger das Problem, eher TLAs wie VER und VRR.
Sie sind durch relativ breite Benutzung etabliert. Siehe: Taginfo: wikidata
Holzkamp-Gesamtschule: 373 fährt scheinbar bis/ab Steig direkt an der Schule.
Witten-Annen: 373 an falschem Steig
Dortmunder Straße: 4 Steige mit 2 Bereichen physikalisch vorhanden statt 2 Steige mit 2 Bereichen
Himmelohstraße: 371 halten angeblich alle an Steig 1
Diese Fehlerbeschreibungen stehen auch, wahrscheinlich übersichtlicher in den OSM-Daten.
Es wäre sehr nett, wenn du diese Fehler an die zuständige Person bei der BOGESTRA weitergeben könntest. Ich wäre auch an Rückmeldungen interessiert.
Nebenbei: Soweit sollte der ÖPNV-Bereich in Witten vollständig sein. Jedenfalls sind alle “normalen” Linien (Busse, Bahnen und Fähren; nach PTv2; ASTs haben in Witten keine Routen) und Haltestellen eingetragen und die Plattformen nach Möglichkeit mit allen Attributen und Fotos (aus Commons, Mapillary…) versehen. Die IFOPTs sind nach Möglichkeit in der langen Form angegeben und die IBNRs korrigiert. Haltestellenhäuschen, Bänke und Mülleimer sind nach Möglichkeit auch separat eingetragen. Es fehlen allerdings die E-Linien.
Bei den Routen habe ich bei den BOGESTRA-Linien auch fee=yes, dog=yes, smoking=no und bicycle=yes eingetragen.
Falls ich zu aggressiv gewesen sein sollte tut mir das Leid! Ich hoffe in Zukunft auf gute, produktive Zusammenarbeit!
Trotz des ironischen Smileys: Es würde mich tatsächlich interessieren inwieweit diese Fußwege Sinn machen. In der Realität sind sie ja nicht vorhanden.
Bei neu eingetragenen Haltestellen habe ich diese Wege weggelassen und bei einer “normalen” Bushaltestelle mit Haltestellenschild auf einem Bürgersteig die Plattform als Knoten eingetragen. Es gibt ja Fälle, in denen es tatsächlich separate Plattformen in der Realität gibt. Die habe ich als Weg eingetragen und zusätzlich highway=footway gesetzt.
Es gibt ja den Trend, dass Bürgersteige statt nur als sideway=*-Attribut als separate Wege highway=footway eingetragen werden. Da scheinen mir Plattformen als Knoten (in dem Fall als Knoten im Weg des Bürgersteigs) besser zu passen. Trägt man die Plattformen als Wege ein ist es ja völlig willkürlich wo sie anfangen und enden.
Zu Wikidata: Es gibt einen aktuellen Vortrag von der FOSSGIS 2016 dazu: Michael Maier: OpenStreetMap und Wikidata, leider mit Tonausfall gegen Ende, trotzdem sehenswert
