Auf http://wiki.openstreetmap.org/wiki/DE:Tag:public_transport%3Dplatform steht in der Schlüssel-Wert-Tabelle zu operator: “Name der Firma, die die Plattform betreibt. Bitte keine Abkürzungen verwenden.” sowie zu network: “Name des Verkehrsverbunds zu dem der Halt gehört. Bitte keine Abkürzungen verwenden.”
Auf http://wiki.openstreetmap.org/wiki/DE:Key:network steht jedoch im Abschnitt “Öffentlicher Verkehr”: “Der Schlüssel network=* beschreibt hier den Verkehrsverbund. Die Werte sind grundsätzlich Abkürzungen.”
Das widerspricht sich. Welche Aussage stimmt also, und welcher Wiki-Eintrag muss korrigiert werden?
Anmerkung: Auf http://wiki.openstreetmap.org/wiki/DE:Key:operator steht nichts darüber, ob eine Verkehrsgesellschaft mit Abkürzungen einzutragen ist oder nicht - die Information muss dort also noch ergänzt werden.
Überhaupt nicht einheitlich derzeit. Kurzer Check in verschieden Städten ergab, dass man beispielsweise in München und Dresden beides abkürzt, in Berlin den operator abkürzt, aber das network ausschreibt. In Hamburg macht man es mal so mal so, in Köln fehlen beiden Angaben vielfach ganz…
Vielleicht wäre es auch ganz praktisch, wenn man ähnlich wie für Briefkästen eine Liste mit entsprechenden Bezeichnungen für operator und network anlegt.
Edit: Persönlich wäre ich dafür, ausgeschriebene Namen vorzuschreiben (deshalb wäre eine Liste vermutlich noch wichtiger, weil sonst die Einheitlichkeit kaum herzustellen ist). Denn die Abkürzungen haben das Problem, dass sie schon innerhalb der Bundesrepublik nicht kollisionsresistent sind. Eine “MVG” gibt es beispielsweise laut Wikipedia schon sechs Mal in Deutschland. Das würde also Auswertungen sehr kompliziert machen, weil man dann immer noch das Betriebsgebiet der einzelnen Gesellschaften wissen muss, um dort die gleichen Tags aufzulösen.
Diese Auffassung hat jemand auch mal vertreten. Bis er an einen Betreiber gelangt war, der selbt ihm zu lang geschrieben war. Gerade in Dresden mit der DVB gab es diesbezüglich heftige Diskussionen. http://forum.openstreetmap.org/viewtopic.php?id=29920
Nur die berüchtigte Nebenbahn, welche die vehementen Verfechter des Aussschreibens beruhigt hat, habe ich auf die Schnelle nicht gefunden.
Die Frage ist halt, was man damit erreichen will. Das ist momentan ein typischer Fall von Tagging als Selbstzweck, weil überhaupt kein Ziel formuliert ist. Wenn es nur darum geht, Strings nach Zufallsprinzip zu verteilen, läuft alles bestens und eigentlich ist dann auch egal, ob es Widersprüche im Wiki gibt oder nicht. Kann alles so bleiben. Dann sind auch Argumente wie “nicht zu viele Buchstaben tippen müssen” valide, weil tatsächlich dann der Komfort für den Ersteller das einzige relevante Merkmal ist.
Will man damit nun einfach nur einen weiteren String an Haltestellen anzeigen können, falls noch zu viel Platz auf dem jeweiligen Display ist oder will man damit Auswertungen ermöglichen? Darüber muss man sich zunächst einmal klar werden. Denn beide Anwendungsfälle haben unterschiedliche Anforderungen, insbesondere wenn es um die Eindeutigkeit von Bezeichnern geht. Wenn man das weiß, kann man sich ein geeignetes Schema überlegen. Ohne dieses Wissen wird es dagegen tatsächlich nur eine ziemlich sinnfrei Ideologiedebatte.
Edit: Mal noch eine provokante These: Operator und Network wären vermutlich in Relationen besser aufgehoben statt als String an jeder Haltestelle.
Ich denke das Ganze für einen zusätzlichen String an den Haltestellen zu machen wäre übertrieben. Aber Auswertungen sind schon ein Stichwort. Insebesondere was network angeht. Damit lässt sich im regelfall sehr schnell ein gültiger Tarif zuordnen. Also wo bekomme ich Informationen über die benötigte Fahrkarte.
Auch sind Auswertungen nicht allein auf ein Key-Value-Paar zu beschränken. Natürlich ist DVB nicht eindeutig, wenn man die Welt oder Deutschland als Kontext annimmt. Aber im Network VVO ist DVB wieder eindeutig. Und das sind Liniennummern nicht unbedingt. Nichteinmal bei einem Betreiber sind die Liniennummern immer eindeutig. Zum Beispiel RE oder RB Linien. RE7 wird in Mecklenburg wie auch im Brandenburg von DB Regio gefahren. Und trotzdem unterscheiden die Menschen das. Auch durch Aussschreiben des Betreibers wird die Eundeutigkeit nicht hergestellt. Erst ein Network oder regionaler Bezug machen diese Linien eindeutig. Im VBB gibt es auch Liniennummern die nur mit einem Betreiber eindeutig einer Region zuzuordnen sind.
Warum lässt man dann nicht den Mappern die Vorort üblichen Bezeichnungen wie BVG und DVB oder VMS und VVO Der Auswerter kann sich dann weitere Kritieren der Eindeutigkeit überlegen.
“Der Auswerter kann sich überlegen” ist schon einmal gar keine gute Idee. Denn üblicherweise ist der viel weniger in regionale Besonderheiten involviert als diejenigen, die vor Ort die Erfassung machen. Wenn der Auswerter erst großen Aufwand betreiben muss, um Eindeutigkeiten herzustellen, indem er sich geeignete Regionen zur Abgrenzung überlegen und zusätzliche Tags heranziehen muss, wird es schnell sehr fehleranfällig und damit wenig praktikabel. So schützt nicht einmal die Hinzunahme des Network-Keys vor Fallen. Denn beispielsweise gibt es im VRR die Abkürzung SDG theoretisch sowohl als StadtBus Dormagen als auch als Städtische Dienste Geldern. Das wird also schon in Deutschland ein riesiges Chaos an Spezialfällen und Sonderregeln, wenn man es einfach nur irgendwie laufen lässt und der Auswerter sich das dann hinterher zurechtbiegen soll (davon abgesehen, dass vielfach momentan nicht einmal einheitliche Regeln beim Taggen angewendet werden und jede Auswertung schon daran scheitert). Von anderen Ländern haben wir da noch gar nicht gesprochen…
Und je mehr ich darüber nachdenke: Eigentlich schreit dieser Fall nach Relationen. Der Vorteil bei Haltestellen ist, dass dort ohnehin schon Relationen angewendet werden und damit das Standardargument, dass Relationen zu kompliziert sind, nicht zieht. Nebenbei würde das auch solche Sachen vereinfachen, wie dass eine Grenzhaltestelle in zwei Verkehrsverbünden liegt o. ä.
Also ein Auswerter, der keine Ahnung von Regionalen Gegebenheiten hat, muss sich immer fragen lassen, ob seine Ergebnisse valide sind. Auch ist doch gar nicht klar wonach ausgewertet werden soll. Will ich nur alle Linien eines Unternehmens? Oder was soll das Ziel einer Auswertung sein?
Wie sieht das denn bei Adressen aus? Ist da eine PLZ eindeutig? Natürlich nicht! Dort ist es ganz selbstverständlich, dass wir nur über Straße Hausnummer PLZ und ggf. Ort/Ortsteil eine Eindeutigkeit bekommen. Aber beim ÖPNV Soll das Network weltweit eindeutig sein. Und der Operator auch und und und. Dafür habe ich kein Verständniss. Der Informationsgehalt mag zwar steigen, wenn man etwas eindeutiger macht. Aber er verliert signifikant an Wert, wenn er nur von wenigen so umgesetzt und damit cronsich unvollständig/veraltet ist.
“Ich habe kein Verständnis” ist ein sinnfreies Argument. Adressen sind im Gegensatz dazu weltweit eindeutig - zumindest wenn valide getaggt wird. Sie bestehen allerdings nicht nur aus einem einzigen Key, aber das Schema ist zumindest innerhalb Deutschlands identisch und nicht mal so und mal so (die einen kürzen vielleicht Str. ab, die anderen schreiben Straße aus…).
Aber bei öffentlichen Verkehrsmitteln soll halt alles irgendwie gemacht werden und schön nach regionalen Befindlichkeiten getrennt - ist dann halt Sache des Auswerters sich mit all dem Lokalpatriotismus auseinanderzusetzen. So wird es nichts! Und das führt dann eben auch dazu, dass selbst innerhalb eines Verbundes oder eines Betreibers unterschiedlich eingetragen wird, weil es keine allgemein verbindlichen und eindeutig formulierten Regeln gibt, sondern jeder macht, wie er denkt und wenn er mal umzieht oder woanders taggt, er es dann auch so macht, wie er es immer gemacht hat…
Und nochmal, weil dieser Streit in der Form wenig produktiv scheint: Ich bin dafür, operator und network komplett rauszuschmeißen bzw. als syntactic sugar zu hinterlassen und zu überlegen, ob zukünftig Haltestellen (wie auch Linien) nicht Betreiber- und Tarifverbundsrelationen zugeordnet werden sollen. Das erscheint deutlich geeigneter und da gibt es auch keinerlei Namensproblem, sondern die können (ganz nebenbei) sogar den vollständigen Namen und die Abkürzung anbieten.
Wenn man die Anzahl der bisherigen Antworten betrachtet (und dazu die Zeit, innerhalb der diese gepostet wurden), scheine ich da in ein Wespennest gestochen zu haben - allerdings waren es bisher nur 2 Personen, die sich dazu geäußert haben.
Trotzdem wage ich es mal ein Fazit aus den bisherigen Antworten zu ziehen: Die von mir angesprochene Thematik wird regional unterschiedlich gehandhabt, es gibt bisher keinen einheitlichen Standard. So weit, so schlecht. Meine Meinung dazu: Ich weiß natürlich, dass wir nicht für die Renderer taggen - aber wir sollten so taggen, dass die Daten für die Renderer auswertbar sind. Wenn jedoch jeder nach Belieben taggt, ist das für die Renderer nicht auswertbar. Insofern stimme ich besonders der Aussage von Kontinentalverschieber zu, dass es Probleme gibt, wenn ein Mapper umzieht und seine Mapping-Gewohnheiten nicht den regionalen Gegebenheiten anpasst, sondern - verständlicherweise - weiter nach seinem gewohnten Mapping-Schema taggt.
Zu meinem persönlichen Mapping-Verhalten: Ich lebe in Berlin, wo (wie von Kontinetalverschieber korrekt beschrieben) der Wert für network=* üblicherweise ausgeschrieben wird (Verkehrsverbund Berlin-Brandenburg, die entsprechende Abkürzung wäre VBB), der Wert für operator=* jedoch üblicherweise abgekürzt wird (für Busse, Straßenbahnen, U-Bahnen und Fähren ist dieser Wert “BVG”, ausgeschrieben wäre das “Berliner Verkehrsbetriebe”). Anmerkung für alle, die sich mit dem Berliner Nahverkehr nicht auskennen und sich nun wundern, warum die Abkürzung nicht mit der ausgeschriebenen Version kompatibel zu sein scheint: Nach der Wende wurden die Verkehrsbetriebe von West-Berlin (Berliner Verkehrsgesellschaft, kurz BVG) und Ost-Berlin (Berliner Verkehrsbetriebe, kurz BVB) zusammengelegt zu den Berliner Verkehrsbetrieben, kurz BVG - also die ausgeschriebene Version vom Osten übernommen, und die Abkürzung vom Westen.
Mehrfach wurde die Möglichkeit der Problemlösung via Relation ins Spiel gebracht. Jedoch erschließt sich mir nicht so ganz, was für eine Relation gemeint ist. Eine Relation für alle Einrichtungen, die zu einer bestimmten Haltestelle/einem bestimmten Bahnhof gehören (also Halteposition, Wartebereich und - falls separat getaggt - Einrichtungen wie Wartehäuschen, Sitzbank, Mülleimer etc.)? Oder eine Relation für die jeweilige Bus-/Bahnlinie? Oder eine Relation für den jeweiligen operator bzw. network (also auf Berlin bezogen die BVG bzw. den VBB)?
Mein (vorläufiges!) Fazit für mein persönliches Tagging-Verhalten - so lange, bis eine Einigung auf eine mindestens berlinweite, besser bundesweite, am besten weltweite, Verfahrensweise erzielt wird:
Ich werde alle alle Elemente, die zu einer Haltestelle oder einem Bahnhof gehören zu einer Relation zusammenfassen (also z.B. Halteposition, Wartebereich und falls separat getaggt Wartehäuschen, Sitzbank und Mäülleimer). operator=* und network=* werde ich an die jeweilige Relation hängen und dabei die BVG abkürzen und den VBB ausschreiben. Insbesondere das Abkürzen der BVG und Auschreiben des VBB missfällt mir, da es uneinheitlich ist - solange aber die Diskussion darüber im Gange ist und kein einheitlicher Konsens gefunden wurde (wie gesagt mindestens berlinweit, bestenfalls weltweit), werde ich mich eben an bestehende lokale Gegebenheiten halten, auch wenn sie mir unlogisch erscheinen. Wenn dann irgendwann ein Konsens gefunden wurde, sollten bestehende Taggs meiner Meinung nach dementsprechend nach und nach geändert werden.
Letzteres. Grundsätzlich also so, wie bisher auch und so, wie du es machst: Haltestelle mit Zubehör in stop_area-Relation. Allerdings dann in dieser stop_area-Relation keine Werte mehr für operator und network (bzw. diese Werte nur noch redundant), sondern diese stop_area-Relation wiederum als Mitglied in einer neu zu schaffenden operator-Relation und einer neu zu schaffenden network-Relation.
Fiktives, völlig naives und definitiv nicht finales Beispiel für die BVG:
In diese Operator-Relation würden dann sämtliche stop_area-Relation der BVG mit der Rolle stop_area aufgenommen. Sämtliche Linienrelation der BVG könnten dann mit Rolle line aufgenommen werden.
In diese Network-Relation würden dann ebenfalls sämtliche stop_area-Relationen mit entsprechender Rolle und ebenfalls sämtliche Linien mit entsprechender Rolle aufgenommen.
Damit hat man wunderbare Auswertungsmöglichkeiten, jeden Namensstreit ohne viel Tipparbeit entschärft und Einheitlichkeit. Vor allem braucht es da auch keine schlecht auswertbare Semikolon-Lösung, wenn beispielsweise eine Linie durch verschiedene Verkehrsverbünde führt, so wie es momentan der Fall ist. Aber ich will gern dazu Meinungen hören.
schön das du dir in Berlin vorher einiges angeschaut hast.
Also um konkret zu werden. Der Betreiber von Regionalbahnen ist nicht DB Regio. Sondern eine Tochtergesellschaft der DB Regio AG.
Die S-Bahnhöfe werden derzeit noch sowohl von Station und Service als auch von der S-Bahn-Berlin-GmbH betrieben. Die Automaten wiederum verden von DB Vertrieb bereitgestellt.
Mag das wirklich jemand auswerten? Also ein Renderer bestimmt nicht.
Viel wichtiger erscheint mir das jemand der ein Problem mit dem Automaten hat, sich an den Betreiber wenden kann. Und vor allem was verkauft dieser Automat eigentlich (Fahrkarten deutschlandweit oder nur Verbund + ein bisschen). Inzwischen ist es sogar wichtig zu taggen ob das Teil nur Münzen und Geldakarten oder auch Scheine akzeptiert.
Weil es mir sinnvoll erschien, habe ich begonnen Haltestellenmasten der BVG mit ihrer Website aus dem QR Code zu taggen. Außerdem kann es sinnvoll sein, die VBB Nummer allen Masten einer Haltestelle zuzuordnen. Auch damit ließen sich aktuelle Abfragen zu Abfahrzeiten machen.
Relationen wie von Kontinetalverschieber Vorgeschlagen, halte ich angesichts von 1000enden Haltestellen der BVG und über 100 Linien nicht nur für unübersichtlich, sondern für unwartbar. Noch dazu wenn die Haltestellen wie bei Bahnhöfen von mehreren Betreibern stammen.
Schlimmer als das Chaos, was momentan diesbezüglich vielerorts besteht, wird es auch nicht. Es muss in diesen Relationen auch nicht sortiert werden, so dass man da ellenlange Listen durchgehen muss, um die passende Position zu suchen, sondern es geht nur um die binäre Entscheidung: drin oder nicht drin. Wo soll außerdem das Problem mit Haltestellen und Bahnhöfen von mehreren Betreibern liegen? Die kommen dann halt einfach in zwei Betreiber-Relationen. Das ist sogar viel logischer als wenn man mit Semikolon-Listen o. ä. anfängt, so wie das momentan bei verbundraumübergreifenden Linien ist.
Meiner Meinung nach wird es schlimmer! Denn das Monster muss jemand warten, wenn sich etwas ändert. Du musst Haltestelle xyz oder Linie 123 suchen wenn sich der Betreiber nach einer Ausschreibung ändert.
Einen Bahnhof zu mehreren Relationen zuzuordnen wäre falsch.
Schau dir den Hauptbahnhof an. Die Haltestellen werden von der BVG betrieben. Den anderen Teil macht Station und Service Dazu gehört wahrscheinlich sogar der U-Bahnhof. http://brokenlifts.org/station/9003201/213
Einfacher Fall: Bus auf dem Land, Grenzbereich zwischen 2 Landkreisen, 2 Verkehrsgesellschaften
Beteiligte: Regionale Verkehrsgesellschaft Dahme-Spreewald (RVS) für Landkreis Dahme-Spreewald und Verkehrsgesellschaft Oberspreewald-Lausitz (VGOSL) für den Landkreis Oberspreewald-Lausitz , Beteilige Städte: Lübben (LDS), Lübbenau (OSL)
Betreiber der Bus-Haltestelle ist die jeweilige Verkehrsgesellschaft des Landkreises. Da ist es egal, daß die VGOSL die mit der Buslinie 608 (Lübbenau-Lübben) einen anderen Landkreis befährt. Sie unterhält in LDS aber keine eigenen Haltestellen, sondern nutzt die der RVS.
Mit einem sauberen Tagging von operator, network, name und Stations-ID an den Haltestellen funktionieren auch Webdienste.
Also ich weiß nicht, wie es in anderen Editoren ist, aber in JOSM würdest du einfach doppelt auf die jeweilige Haltestellen- oder Linienrelation klicken, deren Betreiber du ja ohnehin ändern müsstest, dann sind dort unter den Schlüssel-Wertpaaren (wie type=public_transport usw.) die Mitgliedschaften in Elternrelationen aufgeführt. Und dann kann man, wie bei Knoten oder Wegen, die Mitgliedschaft entfernen und die Haltestellen- oder Linienrelation einer neuen Operator-Relation hinzufügen. Ich weiß beim besten Willen nicht, was daran nun so viel schwerer ist, als die betroffenen Haltestellen- oder Linienrelation zu suchen und dort jeweils einen anderen Operator-String einzutippen.
Und wenn die Daten in irgendeiner Form zum automatisierten Ändern vorliegen, dann ist man mit Relationen erst recht auf gar keinen Fall schlechter dran als mit vielfach mehrdeutigen Strings.
Was ist nun das genaue Problem gegenüber heute? Außer für den Hauptbahnhof selbst, gibt es für die meisten Haltestellen in der Umgebung weder eine stop_area-Relation noch einen operator-String. Weglassen geht natürlich immer…
Und was ist nun so schwer und unmöglich daran, eine Bushaltestelle vor dem Hauptbahnhof der BVG zuzuordnen und den Hauptbahnhof der DB? Warum geht das nur mit operator-Keys aber nicht mit Relationen?
Und genau das ist der Punkt: Ein solch sauberes Tagging existiert nicht. Das Tagging müsste dort nämlich auf Einheitlichkeit und vor allem auch auf Eindeutigkeit ausgerichtet sein. Genau das ist aber nicht gewünscht, weil das zu viel Tipparbeit machen würden und jeder gern seine lokale Abkürzung verwenden möchte, die schon bundesweit kollidieren, weltweit erst recht. Das ist ein Fall für IDs - in Ermangelung solcher für Relationen.
Die gibt doch… Stichwort UIC, IBNR… auch der VBB listet seine Nummer, verfügbar in den GTFS-Daten: http://daten.berlin.de/kategorie/verkehr es muß nur einer Mappen…
Es ist auch mit Josm unkomfortabel bei 20 Haltestellen den Betreiber zu ändern, wenn diese in einer unsortierten Relation stecken. Ich habe gerade versucht die RB60 Abschnittsweise zu bereinigen und ich denke immer noch nicht alle Objekte zwischen Eberswalde und Lichtzenberg gelöscht zu haben.
Hinzufügen zu einer relation ist einfach, wenn man die Relation kennt. Aber wenn man die erst suchen muss?
Von anderen Editoren möchten wir lieber nicht reden.
Auch muss ich nicht nur die Haltestellen anklicken um zu schauen ob der Operator eingetragen wurde, sondern ich muss schauen ob die Relation mitglied einer Relation ist. Auch das ist wieder eine ganz neue Herangehensweise. Das ist mir bei dem ref:VBB:area schon negativ aufgefallen. Es lässt sich quasie überhautp nicht vernüftig auswerten, wenn man die Ref nur an die Relation schreibt der Relationen schreibt.
Zeige mir einfach die Overpass abfrage, welche mir alle Haltestellenmasten anzeigt, welche in die in der Relation xy nur als Stoprelation aufgenommen wurden.
Und das ist bei Josm das gleiche Problem. Ich sehe vielleicht das der Mast in einer Stoprelation ist, aber ich sehe nicht in welcher Relation diese Relation dann wieder enthalten ist. Ich kann also derzeit auch in Josm nur eine Hirachieebne höher sehen.