Busrouten mit network=network:short + network:long - undiskutiertes Massen-Tag?

In der Gewissheit, dass Ihr mich schelten werdet, weil ich den “Veranlasser” dieses Threads @bernward1 nicht zuerst anschreibe, möchte ich heute etwas zur Diskussion stellen.

Durch Warnungen im iD

bin ich heute in Wetzlar auf veränderte Busrouten gestoßen

die gleich 3 namenbezogene network-tags enthalten

Dabei entspricht network dann network:short. Der ursprüngliche lange Name wanderte durch die vorhergehende Bearbeitung in network:long. Akzeptiere ich die vorgeschlagene Aktualisierung, wird network wieder geändert in die Langversion; n:short und n:lang bleiben erhalten.

Das habe ich erstmal anders geändert, indem ich network gelöscht habe und anschließend den Teil :long, damit war die vorherige Version wiederhergestellt.

Vorher hatte ich extra geschaut, ob es dazu eine Info gibt

Screenshot 2026-05-27 at 19-09-37 iD – Bus 13 Wetzlar Krankenhaus Asslar Freizeitbad OpenStreetMap

Da habe ich mich dann auch nicht weiter bemüht, sondern angenommen, es sei ein Any tags you like-Eintrag.

Erst, als ich dann die eigentliche Relation mal genauer angeschaut habe, fand ich einen blauen Tag,

der mich zu network:long dirigiert hat.

In der Versionsgeschichte dazu fand ich dann bernward1 als Autor für diesen “Artikel”.

Trotz längerer Suche finde ich keine Diskussion zu diesem tag - aber bei taginfo unzählige Einträge, die erst ab ca. 2025 massiv eingesetzt wurden. Um die zu untersuchen habe ich dann overpass bemüht. (Achtung: Das Laden erfordert einen 2. Klick und etwas Geduld!).

Ergebnis: Der user ist zwar nicht der Erfinder des tags, aber derjenige, der es extrem verbreitet.

Ich möchte das nicht nur mit ihm diskutieren, sondern Euch alle um Eure Stellungnahme bitten. Ich bin überzeugt, dass es dazu dementsprechend viele Warnungen in seinem Wirkungsbereich gibt. Zudem empfinde ich die Auslegung im Wiki “if the short name is common” als sehr subjektiv: Jeder weiß bei uns, was mit RMV gemeint ist, aber alle kennen auch und vor allem den Rhein-Main-Verkehrsverbund. Den tag network:long=* halte ich insgesamt für überflüssig, da eine Kurzversion des Namens mMn ausreicht.

(Meine o.g. Änderungen habe ich bereits revertiert, weil ich doch erst Gewissheit haben will, dass meine Ansicht nicht falsch ist.)

Sollte das Tagging doch allgemein akzeptabel sein, werde ich wohl bei iD anklopfen und um Änderung bitten…

Grüße aus Herborn

Andreas

1 Like

Der Id-Editor ist der falsche Ansprechpartner. Die Einstellungen im NSI (Name Suggestion Index) sind die Ursache für Meldungen im Id-Editor. Ich habe dort schon vor einem Jahr gemeldet, dass die Einträge nicht korrekt vorgenommen wurden (zumindesten für den VRS und VRM). In diesen Verkahrsverbünden verwendet man nur die Abkürzung wenn man vom Verkehrsverbund spricht. Im NSI wurde wohl fast überall der Langname hinterlegt was falsch ist (weil ungebräuchlich).

Das es anders im NSI hinterlegt werden kann zeigt er VRR. Denn für den VRR wird Kürzel als korrekt akzeptiert und auch im Id-Editor wird keine Problemmeldung ausgegeben.

Bis Anfang 2025 habe ich nur das Kürzel in den hier benachbarten Verkehrsverbünden gesehen. Wenn ich richtig recherchiert habe wurde zu Beginn des network Schlüssels nur das Kürzel verwendet. Nur der Aachener Verkehrsverbund und der Augsburger Verkehrsverbund hatte dasselbe Kürzel. Da wollte man dann die Langnamen verwenden um Verwechselungen zu vermeiden. Für diesen Fall finde ich das vernünftig. Aber für alle anderen Verkehrsverbünde finde ich das nicht vernünftig, weil alle bestehenden Abfragen und Verarbeitungen durch die Änderung angepasst werden müssen, damit sie weiter funktionieren.

Wenn bei Euch der Langname gebräuchlich ist bitte ich das zu entschuldigen. Ich bin davon ausgegangen dass es auch um die fehlerhafte Warnung des id-Editors geht.

Betroffen ist davon nur die Linie RMV13. Die hatte noch einen veralteten Fahrweg, den ich korrigiert habe. Dabei stieß ich dann in der PTV1 Version auf mehrere Widersprüche bezüglich forward und backward und Wegstückchen die im Nichts endeten. Da erschien es mir einfacher alles auf PTV2 Level zu ändern.

Nach meinem Verständnis muss in network=… das stehen, wie man gewöhnlich den Verkehrsverbund nennt (Kürzel oder voller Namen). Denn network ist der entscheidende Schlüssel, der in den Proposals genannt wird. network:short und network:long sind nur ergänzende Schlüssel. Meiner Ansicht nach sind sie überflüsssig.

Wenn man unbedingt network ergänzen will um die fehlende Variante sehe ich
network:short wenn in network die Langform steht und
network:long wenn in network die Kurzform steht.

(das passt doch und ist verständlich. network:long wurde vor vielen, vielen Jahren im Raum Hannover erstmalig verwendet.)

Ich schreibe die Ergänzung network:long dazu, damit man sieht wie man den Langnamen unterbringen kann ohne die Jahrzehnte alte Tradition zu zerstören.

Hallo, bernward1,

ich danke für Deine umgehende Reaktion, habe aber Zeit gebraucht, um die Angelegenheit nochmal in Ruhe zu überdenken und ein bisschen zu recherchieren.

Es ändert sich aber nichts: Dein eingeschlagener Weg ist offensichtlich nicht abgestimmt und daher nicht die angemessene Vorgehensweise. Trotzdem will ich Dir mit meinem Einwand nicht ins Handwerk pfuschen! Mir geht es einzig um klare Anwendung der allgemein gültigen Vorgaben. Ein neues Tag (wenn im Ursprung auch schon älter) sollte vor einer so weitgehenden Anwendung nicht nur mit einem(!) Satz im Wiki begründet sein, sondern auch ausgiebig in der Community besprochen werden.

Besonders dann, wenn ausgelöste Fehlermeldungen, die im iD (oder wo auch immer sonst) aufscheinen, zu Änderungen wie meiner führen, die im ersten Impuls dann alles rückgängig machen. Ich habe mich ja doch noch gebremst; andere machen das einfach nebenbei (Beispiele 1 und 2). Ich werde das nicht wieder ändern oder die Mapper darauf aufmerksam machen, dass Du das anders wünschst!

Das ist sicher nicht zielführend für Dich.

Wenn sich Dein Beharren auf Deine Absichten an “fehlerhafte(n) Warnungen des iD-Editors” orientiert, die man, so lese ich Deine Angaben, bestenfalls ignorieren soll, so ist vor einem weiteren Verwenden von network:long das mMn erst zu klären (wenn das auch länger dauert und Nachdruck erfordert) - besonders, wenn die Meldungen so zahlreich auftauchen. Da stimmt jedoch Deine Reihenfolge nicht! Erst in der Community etablieren, dann kann man sich mit Vehemenz für die Verwendung einsetzen. So verstehe ich das richtige Handeln. Zudem: Nicht ich will das durchsetzen und muss mich folgerichtig auch nicht drum kümmern, das network:long auch als gültiger Tag im NSI eingepflegt ist…

Mir fehlt hier ein von Dir gewollter Konsens mit den Mitmappern, der Dein (durchaus redliches!) Bemühen rechtfertigt!

Bisher ist network:long=Rhein-Main-Verkehrsverbund von Dir ja nur an der Linie 13 verwandt worden - was ist mit den vielen anderen im “RMV-Gebiet”?

Laut Taginfo gibt es 19.336 x network=Rhein-Main-Verkehrsverbund, 19.283 x network:short=RMV und 14.027 x network=RMV. Insgesamt gibt’s 10.499 x network:long=*, von denen fast 90% auf gerade mal 2 Verkehrsverbünde entfallen, alle zusammen betreffen gerade mal 9 deutsche Verkehrsverbünde und einen französischen. Das sind nicht wirklich viele!

Deine jetzt 6 x network:long=Rhein-Main-Verkehrsverbund zeigen mir derzeit nur eins: Du hast Dir ganz schön was vorgenommen, oder soll der “Rest” hier im Rhein-Main-Verkehrsverbund bleiben, wie er ist?

Ich kann es nicht verhehlen, das mir das nicht gefällt, bin aber der Letzte, der sich gegen gute Absichten sperrt.

Wie gedenkst Du damit weiter umzugehen?

Grüße aus Herborn

Andreas


edit:

Was ich vergessen habe: Da ich mich mit Verkehrstagging (besonders PTV2) überhaupt nicht beschäftige, fehlt mir die Expertise, diese Meldungen in OSMOSE zu bearbeiten. Die sind alle im Zusammenhang mit Deiner Bearbeitung aufgetaucht. Würdest Du bitte danach schauen? Außerdem möchte ich Dich auf Deine hdyc-Seite aufmerksam machen,

da kannst Du viel verbessern, auch, wenn nicht alles von Dir “verursacht” wurde.

Danke vorab!

1 Like

Nur so zu Info: Laut Abkürzungen und short_name im Wiki sollen Namen vollständig ausgeschrieben werden, falls diese immer noch in Verwendung sind, gerade wenn die Etymologie dazu allgemein bekannt ist. Bei den ganzen Verkehrsverbünden ist das nicht anders, die nennen sich ja selber mit dem vollständigen Namen.

2 Likes

Ich kenne das Problem auch. Im VRM (Verkehrsverbund Rhein-Mosel) ist fast überall “network=VRM” getaggt. Allerdings ist oft zusätzlich noch “network:short=VRM” zu finden (vermutlich aus Zeiten, als mal der Langname im Tag verwendet wurde). Das stört mich auch schon seit längerem. Zu Beginn hab ich auch den langen Namen in das network-Tag geschrieben, was aber teilweise dann von anderen geändert wurde, woraufhin ich mich der Konvention gebeugt habe. Eigentlich finde ich es aber falsch, die Abkürzung ins network-Tag zu schreiben. Das sollte man allenfalls tun, wenn der (richtige) Name des Verbunds so sperrig bzw. unbekannt ist, dass die Abkürzung praktisch die einzige geläufige Form des Namens ist. das ist aber in den meisten Fällen nicht so.
Dieses Thema wurde auch bereits hier diskutiert - jedenfalls kann ich mich erinnern hierzu eine Diskussion gelesen zu haben.

2 Likes

Ich weiß auch nicht, woher iD diese Daten bezieht.
Hier im Bereich des ZVON wird auch nur ZVON für Network angeboten, obwohl das eigentlich der Kurzname ist.
Ich habe mich inzwischen damit abgefunden. Dauert ja hier mit ner Änderung auch nicht mehr lange, da es hier ja zwischen dem VVO und dem ZVON einen Zusammenschluß gibt.
Ich kann nur hoffen, daß dann die Lang- und Kurznamen passen…

1 Like

Ich trage generell nur das network und den Shortnamen ein.
Wenn es für den ZVON im iD stimmen würde, dann wären das network=Zweckverband Oberlausitz Niederschlesien und network:short=ZVON.
Irgendwas mit network:long=* spare ich mir.
Das dürfte mit den anderen Tags abgedeckt sein.

1 Like

Änderungswünsche können unter Issues · osmlab/name-suggestion-index · GitHub gemeldet werden.

1 Like