Oh ... da musste ich jetzt aber wirklich überlegen und es mir nochmal genau anschauen. Weiß nicht, ob da noch alles zusammen bekomme bzgl. wieso und weshalb.

Mit der Kernfrage zu B51 bin ich jetzt wirklich überfragt. Ich weiß nicht genau, wie da der offizielle Verlauf ist und habe das vor Ort auch noch nicht versucht nachzuprüfen. Das hatte ich, soweit ich mich erinnere, nur übernommen von Straßenabschnitten, wo es schon dran war und nicht neu hinzugefügt (und mir auch nicht viele Gedanken dazu gemacht). Kann durch Aufsplittung auf Segmente geraten sein, wo ich jetzt als (Erst-)Ersteller angegeben bin.

Zu dem w125381578:
Das access=no habe ich entfernt (soweit ich mich erinnere …), weil man als Radfahrer, wenn man aus Richtung Ludwigskreisel kommt, ab dem Überweg (n8579690324) dort auf die Trierer Straße fahren kann. Und außerdem Fußgänger hier auch erlaubt sind (sidewalk ist ab dort ja auch angegeben!), die wären ja durch access=no auch ausgeschlossen. Wichtig wohl für Radfahrer- und Fußgänger-Routing. Ich glaube, darüber hatte ich mir an der Stelle Gedanken gemacht beim Ändern + das war vielleicht sogar das Wichtigste dort. Klar, man hätte auch foot=yes + bicycle=yes hinzufügen können ... Aber hier gibt es ja kein ausdrückliches Verbotszeichen wie z.B. DE:250 oder ein Bus-/Taxi-Schild, das nur psv erlaubt (soweit ich mich erinnere …). Vielleicht sind auch Pferde erlaubt hier, wer weiß ... access=no kommt mir da etwas hart vor. Und es unterscheidet sich ja auch in keinster Weise von dem Teilstück (w1038118827), wo dann die Anwohner, die dort wenden, wieder drauf fahren dürfen (ich fand ein einheitliches Tagging da besser als noch mit foot=yes und bicycle=yes Verwirrung zu stiften).

Und primary_link, weil es ab der Stelle ein Teil der Trierer Straße ist, die ja als primary angegeben ist und nix mehr von einem service-Weg hat. "service" sind ja eigentlich "Zufahrtswege" zu Gebäuden, Gewerbegebieten, Parkplätzen usw. – das finde ich bei so einem Teilstück der Trierer Straße und bei einer Straße "mitten in der Stadt" grundsätzlich etwas merkwürdig. Eigentlich auch bei dem Teil davor im Bereich "Westspange" (w103080498 usw.) Aber das ist vielleicht ein Tagging-Graubereich oder eine wirklich passende Tag-Definition fehlt ... Es ist meiner Meinung nach eher ein Verbindungsstück zu einer Primary-Straße, also ich fand da primary_link einfach besser/passender. Meiner Meinung nach kann man "xyz_link" für Straßen-Verbindungsstücke verwenden, die anders schwer zu definieren sind, was in der Stadt und bei aufgesplittet gezeichneten Straßen häufig mal vorkommen kann. Und ich würde primary_link nicht mit Verkehrsaufkommen in Verbindung bringen, es ist eine Art „Zufahrt“/Verbindung ZU einer Straße mit Primary-Verkehrsaufkommen usw. Genau wie es wohl bestimmt Autobahnzufahrten gibt, die nur minimales Verkehrsaufkommen haben usw. Wenn du denkst, dass eine andere Art des Tagging zutreffender wäre, dann ändere es doch einfach. Manche Dinge sind vielleicht nicht so 100% eindeutig und mehrere Arten es zu taggen sind denkbar. Und der ganze Bereich Trierer Straße/St. Johanner Straße/Westspange/Ludwigskreisel ist ja nicht gerade unkomplex ... Bestimmt gut, wenn da immer wieder mal mehrere Leute drauf schauen ... Beschilderung ändert sich auch mal usw.

Viele Grüße + happy mapping!!!

Hallo! Ich glaube, bei der Korrektur von dir hat der Versatz des Satellitenbildes (Maxar) nicht gestimmt ... da hat viel nicht mehr zusammengepasst mit Position von angrenzenden Straßen und Gebäuden (z.B. Haldystraße, die hatte ich auch schon mal recht genau ausgerichtet, jetzt nochmal korrigiert). Siehe z.B. per OSM History Viewer: https://osmhv.openstreetmap.de/changeset.jsp?id=121292717.

Wollte es nur anmerken, weil ich heute auch einiges auf dem Rotenbühl korrigiert habe (und auch vor Ort war vorher – siehe Changesets 125835172 + 125834253). Ich benutze dafür seit längerem v.a. Bing + Esri (Clarity Beta) und hab den Eindruck, dass die Bilder von Bing sich seit einiger Zeit stark verbessert haben ... Aber Rotenbühl ist auch nicht ganz einfach ... viele starke Verzerrungen wohl wegen der Hügellage ... Viele Grüße!

Hello Casper,

my opinion is that your understanding of the "Name_is_the_name_only" principle is wrong.

I also cannot find any example on the wiki page and the section you have linked (like the "Spielplatz" example).

I would agree completely to EinKonstanzer – why should a pitch NOT get the name "Bolzplatz" if there is a sign with exactly this naming? The same with playgrounds which are named "Spielplatz" on a sign.

I never understood why this should be avoided and – as you wrote "tagging it with name=* is incorrect". Why should it be a bad thing?

I think this interpretation of the naming principles is too harsh and not necessary. Even if some other users seem to like such a harsh interpretation, too.

My opinion is that names don't need to be unique. Many people are also named Peter or Peter Miller and it's not forbidden or wrong. And if there is a sign with a name, even if it's not a unique one, this should be enough to use this for the name tag (my opinion).

Therefore, I changed back one "Bolzplatz" today where I know it has a sign with this name – osm.org/way/117192566.

And I would appreciate it if this changeset would be reversed.

Zur Information: Dieser Tag basiert auf einem Vorschlag von mir und (in leicht anderer Notation) von User Biff aus einem Talk auf der engl. Wiki-Seite von barrier=guard rail (nicht durch mich angestoßen), wo andere User wohl auch mit Unklarheiten und Verwirrungen zu kämpfen hatten, was die „richtige“ Seite einer Leitplanke sein soll (bzw. was mit „außen“/„innen“ gemeint ist) und wie Leitplanken mit ZWEI glatten Seiten getaggt werden sollten, die es auch gibt – das deckt das bisherige Schema z.B. nicht ab (bzw. man müsste 2 Linien dafür zeichnen). Und das ist auch ein fundamentaler Unterschied etwa zu barrier=retaining_wall o.Ä., wo es 2 ganz klar definierte Seiten gibt (oben/unten) und NIEMALS z.B. oben+oben oder unten+unten ...

Siehe: osm.wiki/Talk:Tag:barrier%3Dguard_rail (Abschnitte „Change direction description“ UND „Tagging guard rails with two "inner" sides“.)

Der Kommentar „Dass eine Leitplanke auf die „richtige“ Seite montiert wurde, ist eine Selbstverständlichkeit und daher nirgends im Wiki erwähnt. “ trifft nicht den Kern des Problems ... Es geht einfach darum, EXPLIZIT wiedergeben, was die glatte Seite ist und hat somit beim Wert „right“ den Informationsgehalt, dass die Linie entsprechend der aktuell im Wiki empfohlenen Richtung gezeichnet wurde, was beim Verifizieren von solchen Linien hilfreich sein kann ... die sind nämlich auch sehr oft falsch herum gezeichnet – sofern man denn überhaupt auf die korrekte Erfassung der „glatten“ Seite(n) Wert legt.

Ich verweise hier nur mal auf das Beispiel highway=steps, wo es längere Zeit auch hieß, die sollten IMMER in Aufwärtsrichtung gezeichnet werden (= implizite Annahme), was aber sehr sehr oft nicht beachtet wurde, bis dann der Zusatztag "incline=up/down" als RIchtungsangabe empfohlen und auch im Wiki dokumentiert wurde, so dass beim Zeichnen von Treppen die Richtung nicht mehr entscheidend war – eine gute und sinnvolle Weiterentwicklung. Das fände ich bei guard_rail eigentlich auch sinnvoll. Stellt man so z.B. eine falsch gezeichnete Linien vor Ort fest, müsste man nicht mehr unbedingt die Richtung der Linie ändern (oft eine nicht wirklich verständliche Änderung für andere – könnte z.B. auch bei einem falschen Verständnis der „richtigen“ Richtung fehlerhaft erfolgt sein –, sondern man könnte auch den Zusatztag entsprechend auf „left“ setzen (oder beides tun … also die Richtung ändern UND ihn zur Nachvollziehbarkeit der Änderung auf „right“ setzen).

Zusammengefasst: ein solcher Zusatztag würde Unklarheiten beseitigen (besonders nach Verifizierungen) und auch das Tagging besonders für Neueinsteiger erleichtern und ist nur ein erster (aber auch nicht aus der Luft gegriffener) Vorschlag, der wie nw520 auch argumentiert, der „Any tags you like“ Richtlinie folgt ... Siehe osm.wiki/DE:Any_tags_you_like

Der Revertierung dieses Changesets kann ich daher nur zustimmen ...

Ich hab's jetzt geändert in map:description, auch wenn das wahrscheinlich nicht viel besser ist. Ich würde es in Zukunft wahrscheinlich eher mit 2 getrennten Nodes mappen ...

Wieso access=private auf Wegen vom Abenteuerspielplatz Meiersdell (z.B. way 918365318)? Das erscheint mir etwas seltsam ... Was soll da private sein? Oder hast du da aus Versehen zuviel damit getaggt? Denn es ist ja kein „Gelände der Bahn-Landwirtschaft“, wie dein Änderungssatz-Text lautet – es ist doch ein öffentlicher Spielplatz der Landeshauptstadt Saarbrücken (siehe auch Web-Link bei der Spielplatz-Fläche). Ich war im März 2021 dort und checke normalerweise die Zugangsbedingungen bei Spielplätzen. Dadurch werden die Wege auf OSM-Carto z.B. grau dargestellt – das sollte bei öffentlichen Straßen/Wegen eigentlich nicht sein. Oder wolltest du damit angeben, dass keine Fahrzeuge erlaubt sind (denn foot=yes ist ja noch gesetzt). Ich würde es trotzdem nicht so taggen, und soweit ich weiß, sind Fahrräder auch nicht ausdrücklich verboten (falls doch, eher bicycle=no setzen statt access=private). Denn die werden durch access=private ja mit ausgeschlossen. motor_vehicle=no macht vielleicht noch Sinn bei einem Spielplatz (wobei bei highway=path sowieso als Default gilt, dass keine 2-spurigen Fahrzeuge erlaubt sind ... also höchstens Mofa/Moped/Motorrad).

Auch beim Weg runter durch die Schrebergärten war glaube ich kein ausdrückliches "Privat"-Schild o.Ä. Nur ein Tor, was aber offen stand. Wobei sich das ja geändert haben kann ... und auch etwas seltsam war (ich hatte deshalb dort an dem Tor foot=permissive gesetzt, was in so einem Fall wohl am passendsten ist – siehe node 8529335640).

Vielleicht kannst du das mit access=private ja nochmal überdenken/ändern oder nochmal checken vor Ort ... Oder ich mach es, wenn ich mal nochmal in der Nähe bin dort ...

Viele Grüße!

I have a different opinion or taste here ... I have explained enough I think ... I will also tag sidewalk=separate together with foot=use_sidepath, because these are 2 different things. One is describing the sidewalk infrastructure, the other is an access tag for pedestrians ...

I think that not always the goal is "as few tags as possible".

And I deliberately wrote "you COULD have changed..." and not "you SHOULD have changed...". That was meant literally.

Also ich hab mir mal eingeprägt, bei tourism=information, information=map den Tag name zu benutzen für die Bezeichnung der Karte und nicht title (wie bei board:title üblich – aber es ist ja kein information=board). Laut Taginfo bei information=map / Tagkombination auch 35.000x benutzt (in 41% der Fälle). Siehe https://taginfo.openstreetmap.org/tags/information=map#combinations
Daher hier so getaggt, und nicht einfach als name=*, weil es ja nicht der Name der poster_box ist ... Vielleicht wäre name:map auch korrekter (da ist ein Suffix auch eher ein Sprachensuffix wie :de)? Beides ist unschön ...

Wobei ich dieses Doppeltagging advertising/tourism bei den Citylights (poster_box) eh unschön finde, auch wenn es EIN physikalisches Objekt ist. Aber es sind dennoch 2 sehr verschiedene Features bzw. ("a map in a box" – parent/child – dafür gibt es leider keine grundsätzliche Systematik). Deshalb hab ich den Namen der Karte wohl auch nur 1x so getaggt und hatte keine Lust, das zu wiederholen bei anderen solchen Karten ...

Es wie bei advertising bei Bushaltestellen-Unterständen. Das führt zu vielen Problemen beim Tagging wie etwa bei diesem simplen Namenstag ...

Oder beispielsweise ist das Icon dann auch nur eins von beiden beim Rendering (je nach Stylingpräferenzen) und das andere fällt dann unter den Tisch. Bzw. es müsste eine Doppel-Icon-Darstellung für sowas geben z.B. mit einem größeren + einem kleinen Icon daran gesetzt, in JOSM z.B. kann man das ja recht leicht realisieren, aber Praxis bei Kartenstyles ist das ja nicht gerade.

Ja, sowas passiert, ist mir nicht unbekannt ... und hab ich mir fast gedacht (vielleicht ein bissl mehr Text im comment in so einem Fall investieren ... es erschreckt ja schon, wenn man es im ersten Moment sieht, auch weil es für Außenstehende nicht klar zu erkennen ist, ob sich da wirklich nix geändert hat am Ende ... oder ob doch großflächige Geometrie-Änderungen beabsichtigt waren, z.B. Anpassungen Satellitenbilder o.Ä.). Viele Grüße!

It always makes sense as an explicit information I would say ... althought it is perhaps not strictly necessary (like many other things) ... For me, it's a completion to make things 100% clear ... perhaps it can be helpful for data consumers, you never know ... Or for human users (mappers) to not set cycleway=track again ...

A low use it not an argument for me ... it makes much sense because it corresponds very well to sidewalk=separate, which is widely used. So what is the argument, that sidewalk=separate makes sense (you can also set foot=use_sidepath!), but cycleway=separate not?

For my feeling, it fits very well in the systematics for road tags in general ...

Huch? Was ist denn da passiert? 10000 Knoten (+ noch ein paar im Changeset danach)? Da wären ein paar Infos mehr im Changeset-Comment ja nicht schlecht ... Die Changesets davor mit über 9000 geänderten Knoten hab ich auch schon mit Erstaunen gesehen ... War da was verrutscht und dann nochmal rückgängig gemacht?

Small note: you could have changed cycleway=track to cycleway=separate (according to sidewalk=separate which is also set there) ... (See osm.wiki/Tag:cycleway%3Dseparate).

The Osmose warning could also mention this, I think. I set this tag now for the ways there. And I also just discovered this tag in November of last year... Best regards!

Erst mal … puh …

Mir fällt es ehrlich gesagt sehr schwer, so tief in eine Diskussion einzusteigen, ich mache das nicht gerne (auch wenn das vielleicht so wirken mag ...).

Und dies ist einer der Fälle, wo ich zu 99,9% davon ausgegangen bin, dass es eigentlich sehr auf der Hand liegt, was die bessere oder schönere Variante des Mappings von Ampel (für den fließenden Verkehr) und Fußgängerüberwegen (mit Fußgängerampeln) ist. Weil dies auf den entsprechenden Wiki-Seiten ja auch immer wieder ganz gut klar gemacht wird.

Es gibt Dinge, das verwundert es mich immer wieder, zu welch unterschiedlichen Interpretationen und Sichtweisen kommen kann selbst bei eigentlich ziemlich rationalen und gut dokumentierten Dingen …

Also ich versuche es nochmal:

• Es gibt Ampeln für den fließenden Verkehr und es gibt Fußgängerüberwege mit und ohne Ampeln.
• Für mich sind das grundlegend 2 sehr verschiedene Objekte mit recht unterschiedlichen Funktionen, man könnte auch sagen 2 Konzepte. (Bei dem einen liegt der primäre Fokus auf dem Verkehr-Stoppen/Freigeben), bei dem andern darauf, eine Überquerung eines fließenden Verkehr zu ermöglichen – dort sind die Ampeln nur sekundär und kommen ja auch nicht bei ALLEN (Fußgänger-)Überwegs-Typen vor.
• Schon alleine daher würde ich die nur im absoluten Ausnahmefall bei „pelican crossings“, also reinen Fußgängerampeln an NICHT-Kreuzungen, also auf einer geraden Straßenstrecke, mit EINEM Knoten taggen, und selbst da stellen sich bei mir ganz leicht die Nackenhaare vor Unbehagen.
• Spätestens wenn z.B. Fußwege als footway=crossing (mit eigener Linie) eingezeichnet sind, finde ich es sehr sehr irritierend, wenn dann mitten auf diesem highway=footway eine Ampel für fließenden Verkehr getaggt wäre (und diese bei OSM-Carto auch dort angezeigt wird). Während ein crossing-Tag da ja völlig Sinn macht. Als Fußgänger laufe ich ja nie über die Ampel-Haltelinie für Autos, ich gehe über einen ÜBERWEG.
• Ich kann auch nicht nachvollziehen, warum für dich highway=crossing keinen Sinn macht. Wieso nicht – wo ist das Problem? Das müsstest du mir noch genauer erklären. Ich finde es geradezu SEHR sinnvoll, denn es gibt explizit an, dass sich an dieser Stelle ein Überweg (Fußgänger/Radfahrer) befindet. Und crossing=XY ist der dazu gehörende UNTER-Tag, der die ART des Übergangs angibt (mit/ohne Lichtzeichen, markiert/unmarkiert usw.). Solche Ober-/Untertag-Kombinationen finde ich eigentlich immer sehr der Klarheit dienlich, auch wenn das nicht immer zwingend so sein muss.
• Unpassend ist eigentlich die Kombination highway=traffic_signals + crossing=traffic_signals, weil der Untertag zu highway=traffic_signals traffic_signals=XY ist, und für crossing=XY ein Haupt-Tag fehlt (und auch noch weil traffic_signals=XY sich auf BEIDES beziehen kann, s.u.!).

Also für mich sind – auch rein vom Gefühl her – diese Kombinationen am passendsten und logischsten und naheliegensten:
1.) highway=traffic_signals + traffic_signals=XY (+ natürlich weitere Detail-Tags, v.a. die direction …)
2.) highway=crossing + crossing=XY (+ natürlich weitere Detail-Tags inklusive traffic_signals=XY)

Und ich frage mich: wie klar soll das Wiki da noch sein? Auf der deutschen Seite zu crossing (osm.wiki/DE:Key:crossing) heißt es:

„Die Übergänge sollten entsprechend ihrer Zugehörigkeit zuerst als highway=crossing oder railway=crossing gekennzeichnet werden.“

Und auch das bereits von mir zitierte:

„Für alle (ampelgesteuerten) Überwege wird empfohlen, die Fußgängerüberwege separat von den Ampeln für den Fahrbahnverkehr zu mappen (siehe Beispiel in der nächsten Zeile). Vor allem die Kombination aus highway=traffic_signals + crossing=traffic_signals auf demselben Node wird mitunter kritisch gesehen, da crossing=traffic_signals ein Untertag von highway=crossing sein sollte.“

Und ich hatte ein Problem zu verstehen, auf welchen Passus du dich beziehst in deinem Abschnitt:

„M.E. widerspricht das "osm.wiki/Tag:highway=traffic_signals#:~:text=Vehicle traffic signals before intersection, pedestrian crossings not separately mapped"
Ferner wird auch dargestellt, dass bei Auto-Ampeln ausschließlich für Überwege (statt Kreuzungen) eigentlich highway=crossing zu nutzen sei. Bisher gehörte ich eher mangels Wissen der "some mappers use: highway=traffic_signals"-Fraktion an.“

Denn der Link mit Anker springt zu keiner Stelle, ich lande da ganz oben … Also du meinst wohl das zweitletzte Beispiel mit Titel „Vehicle traffic signals before intersection, pedestrian crossings not separately mapped“ … ich musste etwas suchen …

Und mit dem zweiten Satz meinst du wohl, dass typische „pelican crossings“ eigentlich mit highway=crossing zu taggen seien. Ich fange mal damit an …

Ich habe das nochmal nachgelesen und muss dir recht geben. Wobei ich da auch zu der „einige Mapper benutzen: highway=traffic_signals + crossing=traffic_signals“-Fraktion gehöre … Das hat aber seinen Grund – vielleicht schaust du dir das mal an:
• Das Beispiel „Pedestrian crossing without intersection“ auf osm.wiki/Tag:highway=traffic_signals zeigt 2 mögliche Varianten.
• Beim obersten („Pedestrian crossings not separately mapped “) ist nur EIN Knoten mit highway=crossing + crossing=traffic_signals getaggt und das Icon ist eine Dreifach+Zweifach-Ampel.
• Bei der 2. Variante („Pedestrian crossings separately mapped“) ist der Knoten mit dem Überweg IMMER NOCH mit highway=crossing + crossing=traffic_signals getaggt, aber das Icon ist plötzlich nur noch eine Zweifachampel => DIESE DARSTELLUNG IST VÖLLIG UNLOGISCH! WARUM IST DAS ICON HIER ANDERS?
• Ich hatte das mal weiter überprüft, weil es mir sehr komisch vorkam. Meine Schlussfolgerung war diese: Die Screenshots stammen wohl augenscheinlich aus JOSM, mit dem Stil „JOSM Standard (MapCSS)“. Also habe ich dort probiert, und siehe da: das Icon aus Variante 1 (Dreifach+Zweifach-Ampel) wird in JOSM angezeigt, wenn der Knoten mit highway=traffic_signals + crossing=traffic_signals getaggt wird (also die „some mappers use …“-Variante). Oder die Screenshots stammen doch aus einem anderen Editor, trotzdem bleiben die 2 verschiedenen Icons bei GLEICHEN Tags unlogisch – sieht sehr nach einem Fehler in der Tabelle aus! Oder übersehe ich da etwas?
• Ich habe jedenfalls daraus geschlossen, dass diese Beispiele mit dem JOSM-Screenshots auf der traffic_signals-Seite nicht 100% sauber sind und ich auch dem Rest nicht ganz traue, und ich für mich daher nur noch an der „BEST-EFFORT-LÖSUNGSVARIANTE“ orientiere (also am bestem IMMER getrennt mappen) – denn die scheint zuverlässig OK zu sein.
• Und mir würde bei der für pelican-crossings „empfohlenen“ Variante auch wirklich die Ampel für fließenden Verkehr bei den Tags fehlen, wobei das vielleicht noch die Logik hat, dass sie so in Routing-Software, welche für normalen Ampeln an Kreuzungen einen Wartezeit-Wert miteinrechnet, diese Wartezeit an solchen „Nur-Fußgänger-(button-operated?)-Ampel-Übergängen“ zu vernachlässigen ist und gar nicht erst gerechnet wird, wenn keine Ampel für Fließverkehr bei den Tags vorkommt … Ich weiß aber auch die genauen Hintergründe nicht, WARUM highway=crossing dort empfohlen wird oder wieso das so Einzug ins Wiki gefunden hat. DAS habe ich noch nicht nachrecherchiert. Scheint mir aber v.a. mit dem Unbehagen der Vermengung zweier Tagkonzepte und dem nicht korrekten (Ober-/Untertag) zu tun zu haben (bei highway=traffic_signals + crossing=traffic_signals).
• Und mir fehlt in der Tabelle auch ganz klar ein Hinweis, warum vielleicht Variante 2 zu bevorzugen sei, also welche Vorteile das getrennte Mappen bietet. Hier werden Varianten einfach nur aufgelistet ohne Einordnung/Bewertung, was sie als 100% gleichwertig erscheinen lässt, was sie aber nicht sind. Mir gefällt daher diese Tabelle insgesamt nicht sehr gut. Sie verwirrt meiner Meinung nach mehr als sie klarstellt in Bezug darauf, welche Vorteile/Nachteile eine Variante hat. Und hat wahrscheinlich sogar grobe Fehler wie bei der pelican crossing.
• Auch hier gilt für mich: das nur minimal aufwändigere GETRENNTE Tagging (also Variante 2 hier) befriedigt eigentlich bei allen Beispielen ALLE denkbaren Bedürfnisse bestmöglich und verletzt kein Unbehagen (jedenfalls keins, das mir einfällt, außer dem kleinen Mehraufwand) … daher mein leichtes Unbehagen, wenn ICH pelican-Crossings auch nur mit EINEM Knoten tagge (oder vorhandene nicht ändere), weil ich auch manchmal zu faul bin … bessere wäre es aber schon, denke ich. Ich sollte mir das angewöhnen, denke ich jetzt …

Aber zurück zu dem Punkt, auf den der Link führen sollte:
Ich verstehe nicht ganz, wieso du dich auf DIESES zweitletzte Beispiel und sowieso auf diese Tabelle mit ALLEN Mapping-Varianten beziehst. Ich finde die sowieso sehr unglücklich (s.o.). Sie dienen eigentlich nur dazu, ALLE Varianten darzustellen, wie man theoretisch mappen KANN, wobei von oben nach unten aber eine Verfeinerung stattfindet, die ich im Sinne einer Verbesserung lesen würde. Sie zeigt also eher die Evolution hin zu der eigentlich sinnvollsten Lösung und alle denkbaren (irgendwie möglichen, aber doch schlechteren Zwischenschritte). Ist also wohl eher dafür geeignet, das zu interpretieren, worauf man bei bereits gemappten Kreuzungen stoßen kann, und wie man es noch besser machen könnte, als klar zu erläutern, was warum vorzuziehen wäre – das muss man sich selbst zusammenreimen.

Also von oben nach unten würde ich es von „so kann man“ hin so „so ist es am genausten und wünschenswertesten“ lesen … dieser Hinweis fehlt aber.

Daher orientieren ich mich direkt an dem Beispiel, was für mich die letzte „Evolutionsstufe“ darstellt, und lasse alle weniger ausgereiften Zwischenstufen am liebsten gleich ganz weg. Also meine Richtlinie wäre SOFORT und GANZ KLAR das letzte Beispiel: „Vehicle traffic signals before intersection, pedestrian crossings separately mapped“…

Und wenn man dann weiter sucht im Wiki nach Empfehlungen, WIE denn Fußgängerüberwege IDEALERWEISE gemappt werden sollten und da nach der besten, klarsten (klar getrennt von anderen Objekten/Funktionen), flexibelsten Lösung sucht, was ich gemacht habe, dann landet man ziemlich unweigerlich bei der von mir favorisierten Lösung, Fußgängerüberwege und Ampeln für fließenden Verkehr so gut wie immer getrennt zu taggen. Oder sogar am besten IMMER getrennt.

Ist nebenbei gesagt auch am einfachsten zu merken, wird dann auch optimal gerendert (auch wenn wir nicht für den Renderer taggen, ich weiß …), nämlich Ampel als primär das, was man als Mensch unter „Ampel“ versteht, und ein Fußgängerüberweg als Überweg (bei dem die FußgängerAMPEL eher ein sekundäres Merkmal ist im Gegensatz zur Ampel für fließenden Verkehr).

Mit „rendern“ meine ich primär vor allem die Darstellung in allen mir bekannten Editoren (ich benutze v.a. JOSM und Vespucci) – wobei ich mir in JOSM immer noch den Stil ”Potlach2“ unter „JOSM Standard (MapCSS)“ einschalte, wodurch highway=crossing mit einem noch deutlicheren blauen Crossing-Icon angezeigt werden (stat Zweifach-Ampel). Und sekundär meine ich mit „rendern“, dass bei getrennten Tagging bei OSM-Carto kein Ampel-Icon mitten auf einem highway=footway (footway=crossing) angezeigt wird, sondern ein Stück davor, wo im Normalfall die Ampel für den fließenden Verkehr auch steht.

Ich will damit nur sagen, dass die von mir präferierte Methode eigentlich überall nur Vorteile hat. Einziger Preis, den man dafür zahlen muss, sind 2 getrennte Nodes, was ich aber für keinen großen Preis halte. Ich denke, das sollte jetzt deutlich geworden sein.

————————————————————
Nun noch zur Kreuzung in Schafbrücke:
————————————————————

Ich habe https://overpass-api.de/achavi noch nie benutzt … ich habe einfach in der Chronik eines der Fußgänger-Überwege-Nodes (z.B. 1392275443) nachgeschaut und gesehen:

• 25.04.2901 (meine letzte Bearbeitung; Details zum Übergang hinzugefügt): highway=crossing + crossing=traffic_signals (war auch schon seit Version 2 im Jahr 2011 highway=crossing).
• 31.08.2021: deine Bearbeitung änderte highway=crossing zu highway=traffic_signals

Dass die Ampel (highway=traffic_signals) vorher in der Kreuzungsmitte war, konnte ich mir nicht vorstellen. Normalerweise ändere ich sowas auch, wenn ich es sehe und versetze die dann an die Haltelinien. V.a. wenn ich extra dort bin, um Details zu Überwegen hinzuzufügen.
Scheint aber dort doch so gewesen zu sein – da hab ich mich wohl doch nur um die Überwege gekümmert und die Ampel in der Mitte vergessen, was sehr ungewöhnlich ist. Ich hatte mir den KREUZUNGSKNOTEN in der Mitte + dessen Chronik in JOSM nicht angeschaut, weil ich auf diese Idee gar nicht gekommen bin, dass die Ampel noch dort getaggt gewesen sein könnte. Mein Fehler … Dann wäre ich drauf gekommen, was du dort gemacht hast, nämlich deiner Systematik treu zu bleiben.

Du hast also Recht, dass (nach deiner Logik) keine Information verloren gegangen ist und keine Ampel-Nodes entfernt wurde (was ich vermutet hatte), für mein Gefühl wurde nur die Eindeutigkeit/Separation der ÜBERGÄNGE verwischt durch die Vermischung Übergang + Verkehrsampel, wo vorher Übergänge und Ampel (für Fließverkehr) immerhin getrennt waren. Das ist für mich eigentlich auch schon ein Informationsverlust oder besser gesagt eine Informationsverschlechterung.

Wenn ich die Wahl hätte, würde ich da sogar die Ampel auf dem Knoten in der Mitte präferieren, denn dies sagt exakt genauso viel aus wie sie auf die Übergänge zu setzen. Wobei ja durch das Fehlen der DIRECTION-Tags noch ein Taggingfehler hinzugekommen ist, der durch die Ampel in der Mitte nicht gegeben war.

Deine Änderung war nach MEINER SICHTWEISE:
• Kein streng logischer Informationsverlust, aber eben auch NULL Informationsgewinn (+ neuer Fehler …).
• Die Erhöhung der Anzahl der Ampeln (= Anzahl wie in der realen Situation) ist KEIN Informationsgewinn, wie du es dargestellt hast, denn das lässt sich direkt aus der Anzahl sich kreuzender Straßen ableiten (denn Ampeln, die ÜBER den Kreuzung hängen, gibt es in Deutschland meines Wissens nach nicht). Ergo: kein wirklicher Informationsgewinn.
• Annäherung an die reale Position der Ampel sehe ich hier auch nicht als Fortschritt, denn ist es bleibt EXAKT so unklar wie vorher, wo sich die Ampeln (besser: Haltelinien) befinden. Dass sie ungefähr, also irgendwo VOR den Überwegen sein müssen, ist auch vorher klar und wird durch die Verschiebung AUF die Überwege nicht klarer. Eher wird dadurch suggeriert (z.B. Ampel-Icon bei OSM-Carto), dass eine Verkehrsampel sich EXAKT da befindet (oder ganz kurz vor dem Überweg), sie kann aber u.U. 10 m weiter weg sein je nach Kreuzungssituation.
• Ich sehe darin wirklich NUR und AUSSCHLIESSLICH eine Verschlechterung durch Vermengung der vorher (sinnvoll) getrennten Konzepte „Übergang“ / „Ampel für fließenden Verkehr“ zu etwas weniger Sinnvollem, was dann wieder getrennt werden muss für den nächsten Verbesserungsschritt (dann muss man z.B. die Tags für traffic_signals=XY/direction usw. umständlich „händisch“ rausfiltern, also die Tags, die man auf die Verkehrsampel übertragen und die Tags, die beim Übergang verbleiben sollen – mach das bitte mal ein paar Mal, dann weißt du, wie das ist … nicht schön … man hat immer Angst, etwas zu übersehen und es lässt sich kaum automatisieren – außer vielleicht mit intelligentem Javascript in Vespucci-Presets … das kann man dort benutzen und müsste man sich programmieren).
• Und die große, entscheidende Frage für mich ist: wenn schon Verschiebung vom Kreuzungspunkt auf die sich kreuzenden Straßen, warum dann nicht gleich eine Platzierung an die exakte Ampel-Haltelinie? Also nach dem einfachen Motto: „Wenn schon, denn schon!“ (Die Haltelinien sieht man meist sehr leicht + gut auch per Bing.) Die Antwort auf die Frage scheint für mich nur zu sein, dass du eine Präferenz hast, Verkehrsampel und Überweg zusammenzulegen zu EINEM Knoten, also diese Objektvermengung, wie ich es nennen würde. Oder den kleinen Mehraufwand scheust. Ist eben deine Next-Step-Systematik und sehr drin bei dir. Oder du müsstest es mir erklären … Und für eine solche Präferenz kann ich den eigentlichen (Hinter-)Grund nicht ganz nachvollziehen. Es ist für mich nicht der letzte Schritt in der vielleicht schrittweisen Optimierung von Kreuzungen mit Übergängen, sondern ein Zwischenschritt, den man leicht überspringen könnte mit nur sehr wenig Mehraufwand (und großem Gewinn). Da haben wir wohl unterschiedliche Vorgehensweisen oder anderen Fokus.

Also um es zusammenfassend zu sagen:
Ich fände es ja toll, wenn ich dich für meine präferierte Methode irgendwie gewinnen könnte und du auch ganz neu von dir getaggte Kreuzungen auf die Art mappen würdest, also am besten gleich mit der leistungsfähigsten Methode! Da würde ich mich richtig freuen, wenn ich auf so eine stoße, und z.B. noch Details zu den Übergangen hinzufügen könnte (z.B. die arrows für Blinde oder die Vibration usw.) …
So hab ich immer Bedenken, dass es dir nicht gefällt, wenn ich Ampel + Übergang trenne, die du so getaggt hast. Denn bei mir stellen sich wirklich dann die Nackenhaare, wenn ich zu so einem „Doppel-Bedeutungs-Knoten“ Details für die Überwege hinzufüge. Ich will dann immer erst die Verkehrsampel abtrennen, weil das für mich noch wichtiger ist als Detail für die Übergänge, also der Schritt vor „weitere Detail-Tags“ ist.

Oder du müsstest mir einmal sagen, dass das absolut OK ist, es so zu ändern … dann kann ich mich da drum kümmern vielleicht … :-)

Abschließend noch ein weiterer Grund für das getrennte Tagging:
Bei speziellen Ampelsignalen stößt man auch auf den Fall, dass traffic_signal=XY bei dem Ampel für fließenden Verkehr (1) anders sein kann als bei der Fußgänger-Überwegsampel (2), dass es den Tag „traffic_signals=XY“ aber sowohl für Ampeln für fließenden Verkehr als auch für Fußgänger-Überwegsampeln gibt (hier ist also die Tag-/Ober-Unterreihenfolge 1A=1B + 1B=XY versus 2A=2B + 2B=2C +2C=XY – also „traffic_signals=XY“ ist einmal 1B, und einmal 2C).
• highway=traffic_signals + traffic_signals=XY
• highway=crossing + crossing=traffic_signals + traffic_signals=XY

Z.B. hast du ja das“ traffic_signals:override_indicator=white_a“ eingeführt, soweit ich weiß – das bezieht sich auf die Ampel für fließenden Verkehr. Oder es gibt „traffic_signals=blink_mode“ (= auch nur für Ampeln für fließenden Verkehr). Bei solch gemischten Knoten ist NICHT ganz eindeutig, ob jetzt die Fußgängerampel irgendeinen „white_a“ Indikator hat oder die andere Ampel … Und dann noch mit highway:traffic_signals:override_indicator=white_a anzufangen oder crossing:traffic_signals=XY fände ich auch etwas too much …

Ein „traffic_signals=tram_priority“ z.B. bezieht sich dagegen immer auf eine Fußgängerampel (verwendet z.B. bei vielen Saarbahn-Übergängen, wird nur rot, wenn eine Bahn kommt + wird auf railway=crossing-Knoten angewendet, was übrigens auch nochmal eine Parallele und ein Grund dafür ist, dass highway=crossing ein sehr sinnvoller Tag ist – weil es auch railway=crossing gibt – was wichtig ist, um es von railway=level_crossing zu unterscheiden.)

Also wenn beide Knoten getrennt gemappt und getaggt sind, dann ist SOFORT klar, worauf sich traffic_signals=XY bezieht, im Vermengungsfall muss man es immer ableiten von dessen Wert, was ich unschön finde – es ist nicht 100% eindeutig und kann zu Irritationen oder (menschlichen) Fehlern beim Aufsplitten führen.

Viele Grüße!

Hallo!

Ich hätte eine große Bitte an dich ... also eigentlich eine kleine, aber wäre mir wichtig ....

Mir fällt immer wieder auf, dass du an Kreuzungen, die ich sehr sorgfältig mit GETRENNTEN highway=crossing- und highway=traffic_signals-Tags versehen hatte (oft vor Ort oder per Bing die Positionen der Ampeln und Überwege gecheckt), die Ampel für den Verkehr und für den Übergang zusammenlegst zu highway=traffic_signals + crossing=traffic_signals.

Aktuell ist mir das an der Kreuzung in Schafbrücke aufgefallen (node 157362127), und ich habe es wieder zurück geändert ...

Außerdem fehlten dort dann auch die traffic_signals:direction-Tags, die an so einer Kreuzung sehr wichtig sind für Routing usw. Ich bin mir ziemlich sicher, dass ich die gesetzt hatte (kann es nur schwer nachprüfen, weil die alten nodes mir den Ampeln scheinbar auch weg waren).

Wäre es möglich, dass du das nicht mehr tust? Mir tut das immer etwas weh, wenn ich das sehe ... weil ich es schade finde, dass da Information verloren gegangen ist (die auch Arbeit bedeutet hat).

Es scheint mir, dass du da unbedingt vereinfachen möchtest ... was ich in dem Fall aber nicht für angebracht haten würde und auch nicht ganz verstehen kann, warum das gut sein soll.

Ich hatte das mal vor einiger Zeit recht gründlich recherchiert und bin zu dem Ergebnis gekommen, dass highway=traffic_signals + crossing=traffic_signals sehr überwiegend nur für REINE Fußgängerampeln benutzt werden sollte/empfohlen wird, die sich eigentlich nie an Kreuzungen befinden (engl. „pelican crossings“). Also eher sehr selten ... Beispiel etwa hier vielleicht: node 7590456635.

Im deutschen Wiki heißt es auch recht klar:

(osm.wiki/DE:Tag:highway%3Dtraffic_signals#Fu%C3%9Fg%C3%A4ngerampeln)

„• Bei reinen Fußgängerampeln (Fahrzeugverkehr wird nur für die Fußgänger gestoppt) kann derselbe Punkt gleichzeitig mit highway=crossing und crossing=traffic_signals gekennzeichnet werden. Zusätzliche, präzisierende Keys für crossing=* sind natürlich möglich und erwünscht.
• Bei komplizierten Kreuzungen wird stattdessen ein Punkt an der Position der Haltelinie für Autos mit highway=traffic_signals gekennzeichnet und Überwege (möglichst an ihrer korrekten Position) dann auf separaten Punkten mit highway=crossing und beispielsweise mit crossing=traffic_signals (oder mit anderen Attributen des crossing-Keys). Auch hier natürlich am besten mit zusätzlichen, präzisierenden Keys für crossing=*.“

Also das ist eigentlich das, wonach ich mich immer richte und was ich auch gut und schön finde ...

Zusammengefasst in dem Satz aus dem Wiki: „Für alle (ampelgesteuerten) Überwege wird empfohlen, die Fußgängerüberwege separat von den Ampeln für den Fahrbahnverkehr zu mappen“

Und grundsätzlich sollte doch auch gelten: ein präzisieres, detailgenaueres Mapping (= gibt exakte Position der Ampel-Haltelinie wieder, getrennt vom Überweg) ist einem gröberem Tagging vorzuziehen.

Wäre schön, wenn wir da zu einer Meinung finden könnten!!!

Viele Grüße + weiterhin frohes und ausgiebiges Mapping!!!

Hi everybody!

I hope it's OK if I only write in english ... you can use Google translator or something like that.

I was also surprised of the editing (because of Osmose warnings in Saarbrücken where I live).
I checked it now, and I think there is some kind of chaos in these routes and the route master … Here are my results of the checks:

--- Problem 1 ---
Mario Quinta added segments to the route master "GR 5G" (osm.org/relation/11888292) instead of the sub-route with the SAME NAME "GR 5G" (osm.org/relation/11856184).

This sub-route ends now north of Cocheren in France. And the new elements added to the route master starts there and end in Saarbrücken.

--- Problem 2 ---
This sub-route "GR 5G" was missing some segments in France which were contained in the route „GR 5G Nord“ (osm.org/relation/11894631)

--- Conclusions ---
• The sub-route "GR 5G" should indeed be "GR 5G Nord" (which also has more details keys as the sub-route "GR 5G“. e-g. „osmc:symbol=red:white:red_lower:5:black“. So these two routes should me merged in one ("GR 5G Nord")
• The route master should only contain 3 elements at the end: GR 5G Nord, GR 5G Sud, GR 5G (Nord) variante

---

So I made the correction just now ... because it's clear what has to be done.

--- Other fixes: ----

• I also closed some other gaps of the route in France.
• One path in Saarbrücken was part of the route which is certainly a PRIVATE way: osm.org/way/215304828. I removed it from the route and added the shortest allowed ways instead (I am living there and know theses places).
• Mario Quinta added a footway in Saarbrücken which definitively does NOT exist: osm.org/way/956356777 (there is only wood there and an embankment and so on ...). It started here: osm.org/node/2182626891. I removed this way and added the shortest allowed ways instead.
• Optimisations of the route in Saarbrücken (e.g. added separate footways instead of street segments with no sidewalk)

Hallo!

Mal wieder eine Frage … Muss vorausschicken, dass ich kein kein Busroutenspezialist bin (hab in letzter Zeit nur ab und an mal Haltestellen in Routen korrigiert, weil die öfters mal auf der falschen Seite zugeordnet sind usw.).

Du hast da glaube ich schon wesentlich mehr gemacht als ich.

Ich bin bloß schon mehrmals stutzig geworden bei einem check_date=2017-12-10 bei vielen Busrouten in Saarbrücken (z.B. relation 7850904 – da hast du gerade vor 2 Stunden noch was dran geändert).

Da hattest du wohl in diesem Änderungssatz das note:timetable=2017-12-10 geändert in check_date ...

Aber ist das wirklich sinnvoll? Bzw. ist überhaupt ein check_date bei einer Busroute sinnvoll? Ich vermute mal, das Datum 10.12.2017 war mal das Datum auf den Fahrplänen, was auch an den Haltestellen aufgedruckt ist à la "Gültig ab 10.12.2017". Nach Fotos von mir von Januar 2021 (z.B. Linie 126) ist das mittlerweile meist 31.08.2020. Und als die Routen erstellt wurden (wohl meist oder immer NACH dem 10.12.2017, weswegen das ja streng genommen auch nicht das richtige check_date ist) war das wohl das Gültigkeitsdatum der Fahrpläne ...

Jetzt steht aber an den Routen immer noch check_date=2017-12-10 , obwohl da doch meist einige Updates stattgefunden haben + niemand traut sich anscheinend das zu ändern ... vielleicht weil keiner die ganze Route durchcheckt ... Oder (wie ich) nicht ganz sicher ist, was dieses check_date zu bedeuten hat ...

Aber irgendwie ist das ja schon irritierend, insbesondere weil danach ja doch Checks/Updates/Korrekturen stattgefunden haben (wenn auch nur von Teilen vielleicht).

Sollte man daher nicht vielleicht besser komplett auf das check_date verzichten (= es entfernen)? Oder es doch ähnlich wie am Anfang in eine gut lesbare (erklärende) note umwandeln wie z.B. note="Route erstellt auf Basis des Fahrplans vom 10.12.2017. Bei einem erneuten Komplettcheck note aktualieren." o.Ä. ...

Wie am Anfang schon gesagt: mir ist das Prozedere bei Busrouten + Änderungen daran nicht sehr vertraut; ich weiß nicht, ob es da eine übliche/verbreitete "last complete check"-Angabe in irgendeiner Form gibt ... oder ob check_date da üblich ist und eine bestimmte, spezielle Aussage hat (und z.B. genau das meint).

Wollte das trotzdem mal anmerken ...

Ja, ich denke schon, dass highway=path hier das Richtige wäre. Bzw. sonst ja eigentlich nichts in Frage kommt im Wald.

Oder eben highway=track, falls der Weg von mehrspurigen (Motor-)Fahrzeugen befahrbar ist ... (abhängig v.a. von der Wegbreite, aber ggf. auch Steigung und surface) – so hab ich mir das eingeprägt. In Zweifelsfällen, insbesondere bei ca. 2 m breiten Waldwegen, habe ich mich meist für path entschieden – oder man sieht es an (alten) Reifenspuren/Spurrinnen z.B. vom Förster ...

Vielleicht gab es dort ja auch ausgeprägte Hufspuren plus starke Steigung usw., weswegen der Weg als Reitweg getaggt wurde (ist mir nicht aufgefallen, als ich zuletzt vor einigen Wochen mal dort war). Ich würde da aber auch nach der Beschilderungssituation, also letzlich der rechtlichen Situation, taggen ...

Daneben kenne ich die Regelungen aber auch nicht genau, wann ein Waldweg zum Reiten benutzt werden darf oder nicht bzw. ausschließlich oder vorzugsweise dafür vorgesehen ist – es gibt da aber glaube ich auch Regelungen (wäre auch verwunderlich, wenn nicht ...).

Hallo! Meinst du mein fixme bei Weg 36736696? (Ich erinnere mich nicht mehr genau, ob ich das noch bei anderen Wegen gemacht hatte. Und eine overpass turbo Abfrage mit fixme:Reitweg ergab eine runtime Überschreitung ... prima ...)

Zu diesem Weg wollte ich aber seit einiger Zeit mal nochmal hin und mal von unten bis oben durchgehen, um zu schauen, ob da irgendwo ein Reitschild steht ... Es muss ja eigentlich irgendeinen Grund geben, warum das jemand als Reitweg getaggt hat (was ich aber auch seltsam fand).

Falls du es weißt, kannst du den Weg ja gerne ändern. Ich hab es als normalen Pfad in Erinnerung mit 1 bis 2 m Breite glaube ich (ich war nur unten, also am Weganfang, daher das fixme).

Viele Grüße!

Hallo nw520!

Ich hätte da mal ein ein paar Fragen und Überlegungen zu cambio CarSharing (weil du da ja viel getaggt hast in SB und weil mich in Vespucci Osmose-Warnungen etwas nerven, die um Ergänzung eines operator:wikidata-Attributs "bitten", wenn operator=cambio CarSharing gesetzt ist):

Hintergrund: Das ist ja etwas verzwickt bei Cambio ... ich stelle mir da so ein paar Fragen, die "brand" und "operator" sowie "brand:wikidata" und "operator:wikidata" betreffen. Die operieren in Städten wohl unter eigenen GmbHs (oder haben Partnerunternehmen), in Saarbrücken ist das „cambio CarSharing Betriebsgesellschaft mbH“. Das wäre dann wohl die eigentlich korrekte Angabe für "operator" hier. Dann ist der Wikidata-Eintrag Q1028155 eigentlich ein Eintrag, der sich auf das Unternehmen bezieht, nicht auf die Marke („instance of enterprise“) – aber das muss man vielleicht nicht so streng sehen, bzw. ist vielleicht auch nicht ganz korrekt. (Die Mutterfirma wäre nämlich streng genommen „cambio Mobilitätsservice GmbH & Co KG“ in Bremen, nicht „cambio CarSharing“). D.h. es müsste vielleicht bei Wikidata geändert werden in „instance of brand“ (vgl. Q5266289 bei Deutsche Post) ...

Vielleicht wäre das Sinnvollste, brand=cambio CarSharing zu setzen plus brand:wikidata=Q1028155 (wie es meist schon ist) und operator=cambio CarSharing Betriebsgesellschaft mbH (in Saarbrücken). Vgl. z.B. Stationen in Bremen – dort wurde das wohl in diesem Schema gemacht (z.B. n4131449512). Es geht da in SB derzeit um 15 nodes und 1 way, findet man ja leicht mit overpass turbo (z.B. http://overpass-turbo.eu/s/18kc).

Anmerkung 1: Es gibt noch einen OSM Name Suggestion Index identifier (https://nsi.guide/?t=operators&k=amenity&v=car_sharing#cambiocarsharing-c92445), wo operator=cambio CarSharing, operator:wikidata=Q1028155 und short_name=Cambio vorgesehen ist ... Mir kommt das aber eigentlich nicht korrekt vor. Ich würde mich am ehesten an der "Bremen-Methodik" orientieren, glaube ich. Ich weiß aber nicht, wo diese identifier herstammen bzw. wer die pflegt ... Damit habe ich mich noch nicht beschäftigt.

Anmerkung 2: operator:wikidata=Q1028155 ist nur 2x in Bielefeld und 1x in Saarbrücken von mir benutzt worden (was man wohl auch besser ändern sollte, klar), ansonsten noch in Belgien, wo die auch tätig sind.

Was meinst du? Sollte man das in Saarbrücken mal vereinheitlichen (inkl. short_name=Cambio vielleicht, das ist ja ganz sinnvoll ...)? Und auch das Büro (n6139152121) nochmal prüfen – jemand hat da name auf "Cambio" geändert, das kommt mir seltsam vor. Du hattest da vorher "Cambio CarSharing Geschäftsstelle Saarbrücken" – hört sich korrekter an. Und da könnte dann auch noch operator=cambio CarSharing Betriebsgesellschaft mbH dazu und auch short_name=Cambio.

Viele Grüße!

Oh! Mist... Copy/Paste-Fehler... Danke! Ist korrigiert!