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. node/4131449512). 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 (node/6139152121) 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!

Hallo! Ich habe heute deine Lösung für Bäume in der Straße „Auf der Werth“ gesehen, weil ich da vor Ort unterwegs war und auch was gemappt hatte...
Willst du das wirklich so lassen? natural=wood ist da glaube ich nicht die beste Wahl, denn das sind fast alles einzelne Bäume, die in kleinen Grasflächen wachsen – und die sind deutlich kleiner als die jetzigen wood-Flächen (z. B. eher ca. 2x2 m oder noch weniger als jetzt ca. 7 m lang)...

Ich denke einzelne nodes als natural=tree (wo man auch noch gut die Baumart angeben könnte!) ware da die bessere Wahl... und wenn man Mikrotagging machen will auch noch mit landuse=grass Flächen drumherum...

Wollte das nur vorschlagen... dann würde es sich auch in das übrige Tagging in der Gegend besser einfügen... so sticht es schon etwas seltsam raus...

Ich würde natural=wood nur bei etwas größeren Waldflächen, wo wirklich mehrere Bäume auf einer Fläche nebeneinander wachsen, verwenden. Sonst natural=tree oder tree_row...

Viele Grüße!

Hallo! Wollte dich nur drauf hinweisen, dass du in dem Änderungssatz einen Teil der Viktoriastraße von Tempo 20 auf 50 geändert hast, was aber nicht stimmt. Dort steht ein Tempo 20 Schild vor der Kreuzung (und ein Tempo 50 danach)! Ja, sehr selten, und das sieht dort auch glaube ich kaum jemand. Ich hatte das vor ca. 3 Jahren korrekt eingetragen... jetzt nochmal zurück geändert... Und das Schild jetzt auch mal eingetragen... bitte sorgfältig sein mit Änderungen... Viele Grüßel

Hallo mal wieder ... kleine Frage zu dem Weg 748863973 (von dir von 2019 und in diesem Satz nochmal geändert) und anschließendem Fuß-/Radweg 748863967: ich hatte mir das dort vor einiger Zeit mal genauer angeschaut und war etwas verblüfft, dass ein Fußgänger-plus-Fahrrad-frei-Schild auf dieser Seite (DE:239,1022-10) erst hier steht: node/7779161347. Und ich hatte daraufhin auch das bicycle=yes auf dem sidewalk-Stück davor (way/251991502) entfernt, nicht aber noch weiter davor. Aber müsste es da oben am Schneidershof auf dieser Seite nicht auch weg? Ich denke schon … (Und so ein kleines Stück cycleway-Zufahrt könnte man vielleicht an der Stelle, wo das Schild steht, hinzufügen.) Das ist alles etwas seltsam und nicht gerade sehr fahrradfreundlich dort in der Ecke ... Oder ist das Schild weiter vorne vielleicht nur verloren gegangen? Der Bürgersteig ist dort jedenfalls auch nicht breiter oder schmäler als weiter unten auf dem für Radfahrer frei gegeben Stück (aber insgeamt ziemlich schmal für einen Fuß-/Radweg – vielleicht sind die Verkehrsplaner der Ansicht, dass weiter unten eh kaum jemand langläuft oder Fußgänger dann eher zu „Am Halberg“ wechseln werden, weil dort auch die Zugänge zu den Gebäuden dort sind ... während es bleibt wohl rätselhaft, was man sich dabei gedacht hat.)

Siehe z.B. auch dieses Mapillary-Foto: https://www.mapillary.com/map/im/OUx6Z-bJpslqVHU_In9taw

Viele Grüße!

Oh ... ja, das ist nicht schön ... hätte ich auch nicht gedacht. Es lebe die Vielfalt! Bei den Größen der Citylights, die so einzeln rumstehen, ist das übrigens auch so ... da gibt es einige Typen ...

Ich wollte dir noch schreiben, dass ich mir mal den Spaß gemacht habe, einen der Unterstände mit Citylight in der am häufigsten vorkommenden „Standard-Größe“ (sag ich jetzt mal gewagt so) mit Maßband auszumessen (Mainzer Straße; Haltestelle „Halberg“; Richtung stadteinwärts); weil ich bei meinen Anfangsangaben zu den Maßen es nur abgeschritten bin und auch davon ausgegangen bin, dass die 3 Glasflächen, aus denen die Rückwand besteht, je 1 m breit sein dürften. Sind sie aber nicht (ich glaube 1,15 m + Zwischenraum – und das Citylight steht auch noch ca. 15 cm über) ... Man sollte von gar nichts ausgehen ...

Gemessen hab ich (sicher nicht auf den cm genau!):
Länge = 3,90 m, Breite = 1,60 m, Höhe = 2,45 m, wobei das Dach rundum je ca. 15 cm übersteht (ist in den Maßen mit drin).
Das Citylight allein, falls man das als "size" bei advertising angeben will (= mit Rahmen, ohne Stützen, s.u.) hat 1,30 m x 1,85 m, da wäre also "size=1.3*1.85" korrekt ... Höhe mit Stützen unten = 2,15 m.

Die Höhe kann immer auch leicht variieren, weil Höhenunterschiede des Bodens vor Ort mittels der Stützen ausgeglichen werden, klar. Man muss es ja auch nicht auf den Zentimeter genau angeben, denke ich, etwas runden kann man ja, die Höhe vielleicht auf 2,50 m ...

Etwas Off-Topic: Das mit Maßangaben bei advertising ist übrigens auch so eine Sache ... falls man das angeben will ... da bin ich auch kürzlich erst drüber gestolpert. Ist nicht sehr präzise definiert, aber laut proposal soll size wohl inkl. Rahmen, aber ohne Stützen angegeben werden (sinnvoll z.B. bei billboards, signs, poster_box usw.), height aber MIT Stützen etc., also Höhe über alles ... Und eine Breitenangabe sollte per "length", nicht "width" erfolgen, wird sonst von Osmose angemeckert (siehe Definition von 3D-Maßen bei size im Wiki) – oder nur size und/oder height angeben ... wenn überhaupt, denn man kann das meist ja eh nur schätzen und es variiert auch stark.

Noch ein kleiner Fehler von mir: „size“ wird mit „*" angeben, nicht mit „x“, also z.B. size=1*2 ... und meint die Größe eines Werbeobjekte MIT Rahmen, aber ohne Stützen ....

Bei "height" soll eigentlich die Höhe eines Werbeobjekts MIT Stützen angegeben werden – so steht es jedenfalls im ursprünglichen Proposal ... siehe osm.wiki/User:Barnes38/advertising_draft#size_or_format_values

Kleine Info zu von dir getaggter Litfaßsäule (node/8446089085) … weil ich auch öfters Litfaßsäulen tagge:

Der Key "width=1" wird von Osmose angemeckert als verdächtiger Wert auf einem Objekt ... nach einiger Recherche hab ich rausgefunden, warum … "width" meint in OSM bei 3-dimensionalen Objekten anscheindend immer die räumliche TIEFE, nicht, das, was wir meist unter Breite verstehen im Sinne von "Höhe x Breite x Tiefe" (siehe z.B. Illustration auf size=*). Das ist etwas verwirrend, aber wohl streng bei OSM ... Man muss also immer von „Länge x Höhe x Breite“ ausgehen, wobei Breite (also „width“) die räumliche Tiefe ist.

Bei einer Litfaßsäule wäre "width" als Tiefenangabe zwar auch korrekt (Durchmesser ist ja Breite wie Tiefe), aber man müsste es also wohl als "length=1" angeben, damit es von Validierungssystemen wie Osmose nicht mehr gemeldet wird – auch wenn deren Meldungen ja nicht immer korrekt sind, so folgt es wohl dieser strengen OSM-Vorgabe. Das mit „width“ steht im Wiki leider auch noch irreführend bei advertising=column und anderen advertising-Objekten ... ich denke jedenfalls stark, da müsste von „length“ die Rede sein.

Oder man kann es alternativ mit dem Tag "size" in der Form "size=1x3" angeben (das wird viel benutzt für advertising-Objekte) – das mache ich in letzter Zeit, insbes. bei Litfaßsäulen, weil ich "length" da auch komisch finde für den Durchmesser.

Das gleiche betrifft billboards etc., auch da wird "width" angemeckert, man müsste da auch height + length angeben für das intuitive "Höhe x Breite".

Ich schreibe dir das nur (ist ja nichts Wichtiges und eigentlich auch kein wirklicher Fehler), weil diese Litfaßsäule von dir derzeit die *EINZIGE* verbleibende WELTWEIT ist, die den Tag "width" hat ... :-)

Ich habe meine heute gerade alle geändert (die meisten davon in Saarbrücken), daher bin ich darauf gestoßen …

Siehe:
http://overpass-turbo.eu/s/16i4

Vielleicht willst du es ja auch ändern ...

Und übrigens: Litfaßsäulen in Deutschland haben meist einen Umfang von ca. 3,60 bis 4,30 m – das entspricht Durchmessern von 1,15 m bis 1,4 m (ich nehme meist 1,4 m) und Höhe ist meist 4 bis 4,5 m. Deine mit 1 m Durchmesser wäre schon eine recht dünne ...

Viele Grüße!

Vorm Theater (Tblisser Platz) ist ja auch ein etwas spezieller Unterstand – da gibt es wohl schon so einige Ausführungen. Der ist grob wohl so ca. 4 x 2 m groß (weil das Dach weiter übersteht vorne als bei anderen).

Noch ein Nachtrag:
Da gibt es ein interessantes "issue" der openstreetmap-carto Community, auf das ich durch ein fixme auf einem Unterstand in der Dudweiler Landstraße aufmerksam geworden bin (way/540259202):

https://github.com/gravitystorm/openstreetmap-carto/issues/2431

Das ist allerdings seit 2016 offen … :-( Aber da gab es jetzt im Januar nochmal Beiträge.

Es betrifft das Problem, dass das Haltestellen-Icon nicht gerendert wird, wenn ein shelter zu nah ist (wie hier zum Beispiel: node/273533270 – dort ist es aber auch nur 0,6 m weg vom shelter, was sicher auch zu wenig ist … in der Dudweiler Landstraße ist es 1,10 m).

Ich kenne mich nicht sehr gut aus mit den technischen Beschränkungen beim Rendering, ich verstehe in so einem Fall bloß nicht, warum ein ÜBERLAPPEN von Icon und einer builing/amenity-Fläche (mit Icon) wie dem shelter nicht zugelassen wird (also einfach das Haltestellen-Icon in einer Zeichenebene ÜBER dem Unterstand rendern). In anderen Fällen gibt es ja auch Überlappungen von Icons, z.B. historic=memorial und natural=tree. Vielleicht muss ich das dort mal nachfragen ...

Hallo!

Sehr sinnvoll, was du vorhast ...

Ein Gedanke, der mir noch kam: weil es schwer sein dürfte, feste (einheitliche Werte) für traffic_signals:symbol zu definieren, und es da zu einer großen Variabilität (hoher Varianzfaktor … vielleicht auch bei Schreibweisen zu ein und demselben Symbol?) kommen dürfte – wäre da nicht fast ein simples traffic_signals:description geeigneter (und dadurch weit gefasster, also noch weitgehender anzuwenden), wobei ja sozusagen Freitext qua Definition von "description" schon vorgesehen ist? Könnte man ggf. die Community fragen ... wobei es mit "symbol" natürlich präzise EINE Eigenschaft betrifft, und sich in "description" alles mögliche finden könnte. z.B, auch Beschreibungen zur Sequenz (oder dem "Layout"), aber die Frage wäre, ob das schlimm wäre?

Und wegen deines Vorschlags mit "traffic_signals:configuration" ... tja ...Das wäre ja eigentlich die Signal-Sequenz, in Deutschland gehört der Rot-Gelb-Zustand schon dazu, ist auch weltweit glaube ich speziell ... Den Begriff "configuration" für die Farben oder die Sequenz finde ich aber auch etwas schwierig ... Da denke ich zuerst an Zeitschaltungen, unterschiedliche Tag/Nacht-Konfigurationen (manchmal sind Ampeln z.B. nachts aus) oder intelligente Steuerungen per Kontaktschleife/Verkehrsdichte/Witterungsbedingungen etc.

Und ich hatte mit speziellen Ampeln auch kürzlich meine Freude (auch noch nicht geklärt): siehe Ludwigskreisel. Obwohl ich da X mal war, sind mir erst kürzlich die nachgeschalteten 4 Ampeln aufgefallen, die nur Rot und Gelb anzeigen (und auch nur 2 Felder haben) und ich habe sie eingetragen – z.B. node/933137690 ... fand ich sehr eigenartig. Dafür gibt es auch noch keinen passenden traffic_signals-Wert ...

Siehe auch https://www.mapillary.com/map/im/ZBsqX-23MD-2rVGm3CqKDQ

Ich habe da auf der Talk-Seite im Wiki was gepostet, hast du ja vielleicht schon gesehen, aber noch keine Antwort ... osm.wiki/Talk:Key:traffic_signals#Traffic_signals_with_2_aspects_.28red_and_yellow.29_.E2.80.93_NOT_for_cyclist.2Fpedestrians

Viele Grüße!

Also hier bin ich nicht so streng und habe die genau Definition von "ARAS" auch nur einmal vor längerer Zeit gelesen – ich weiß nicht genau, wie das definiert ist – spielt ja auch für die OSM-Definition letztendlich (wahrscheinlich) nicht ausschlaggebend, auch wenn da v.a von einer AufstellFLÄCHE die Rede ist (eine kleine Fläche ist ja aber auch hier … ca. 1 Fahrradlänge, also eigentlich ist man ja voll in der Definition ...).

Ich kartiere da auch einfach im Sinne des Begriffs "advanced stop line" – denn die ist ja nun mal extra vorversetzt, was ja schon speziell für Radfahrer vorgesehen ist und gedacht ist (und halt nicht überall so ist, klar). Für eine größere Fläche VOR der Autospur ist vielleicht nicht überall Platz – oder es wird nur bei mehrspurigen Fahrbahnen gemacht, damit man auch sich auch weiter links hinstellen kann, v.a. zum Linksabbiegen denke ich. So kenne ich es auch von der Paul-Marien-Str. ... bin da auch öfters mit Fahhrad unterwegs. Oder noch etwas besser in der Bleichstraße – node/5758974938. Wobei du dort den als-Knoten VOR die Ampel gesetzt hast. Ich denke, es muss HINTER die Ampel, also umgekehrt. Denn eine Ampel sollte ja an die Halteposition der Fahrspur gesetzt werden (für die Hauptverkehrsteilnehmer würde ich mal sagen), und die asl ist ja nun mal davor ...

Nebenbei: Ich kann mich jetzt gar nicht erinnern, ob ich eine volle große Fläche bei einer einspurigen Fahrbahn mal gesehen habe – gibt es da ein Beispiel?

An der Kreuzung Paul-Marien-Str./Mainzer Str. ist es eigentlich schön zu sehen: von nördlicher Richtung = Fläche (nicht sehr großzüg) – dort kann man auch links abbiegen. Von südlicher Richtung = nur verlängerter Fahrradstreifen, dort auch keine Linksabbiegemöglichkeit (obwohl es für Radfahrer schön wäre, da wäre eine Linksabiegemögl. vorgesehen – auf den Radweg der Mainzer Str., aber wir sind in Saarbrücken ...). Wobei da von südl. Richtung noch keine asl getaggt ist, sehe ich gerade.

Ich würde es so sehen: Bei einspurigen Fahrbahnen genügt das ja so auch in der Regel, wenn man auch nicht ganz so weit vorne steht wie bei einer Fläche. Aber Haupt-Sinn dieser vorversetzten Linie (neben einer komfortablen Links-Abbiegemöglichkeit bei einer Fläche) ist ja wohl, dass das erste wartende Auto den Radfahrer wahrnimmt bzw. dieser einen kleinen Vorsprung hat ... und dafür ist es egal ob größere Fläche oder nur vorversetzte (Radstreifen-)Linie. Und denke, die Verkehrsplaner (in Saarbrücken?) wählen da immer die auto-freundlichste Lösung ... was möglichst wenig Platz für PKW weg nimmt ...

Und wie sollte man solch eine vorversetzte Linie auch sonst taggen? Denn gar nicht taggen wäre ja auch schade, und ein extra Tag dafür auch etwas übertrieben ... fände ich (obwohl ne Möglichkeit ... à la asl=area, asl=line oder so was). Aber der cycleway=asl-Tag an sich ist ja fast schon exotisch, hab ich das Gefühl ... und da denke ich eher, das genügt für beide Fälle ...

Und zum Wiki: das Wording dort bzw. die ganz genaue Definition ist nicht immer zu Ende gedacht auf alle weltweit vorkommenden Varianten, oft zu eng gefasst, weil die Anfangsautoren bestimmte Fälle im Sinn hatten udn die ganzen Vartianten erst später nach und nach mal zur Sprache kommen (wenn ünerhaupt). Und Beispielfotos suggerieren auch oft EINE bestimmte Variante, was verbesserungswürdig wäre ...
In vielen Fällen könnte man bei den Formulierungen da nachbessern (oft genügt schon ein Wort oder ein Nebensatz), ich habe das in einigen Fällen auch schon gemacht, wo es für mich ganz klar war. Wäre hier fast auch so, denke ich ...

Der Begriff "bike box" oder "advanced stop box" ist auch auch seltsam und unglücklich gewählt, finde ich ... vielleicht üblich im englischsprachigen Raum (?), aber ich würde da eher an eine Fahrradabstell-Box bei einem Fahrradparkplatz denken ... eine "box" ist ja nun mal etwas Dreidimensionales (ich denke auch im Englischen). Eigentlich trifft es die der Begriff "Linie" ja am besten, oder "stop point", denn es wird ja auch als node getaggt ...

Viele Grüße!

Hallo!
Also die Saarlodris müssen natürlich beim Tagging berücksichtigt bleiben. .. :-)

Ich hab heute (gestern Abend) auch nochmal was an den Überwegen zur Alten Brücke hinzugefügt, und insbesondere die Auto-Ampeln separat getaggt (eine aus Rtg. Finanzamt war bereits eingetragen, so dass es am Überwegen doppelt war...)

Für die Ampelsymbole würde sich eigentlich eine Erweiterung von traffic_signals=* anbieten, denn den Tag gibt es ja schon für versch., vor allem spezielle Ampel-Typen. Ich habe hier mal traffic_signals=pedestrian_crossing gesetzt, was die normale Fußgängerampel mit 2 Signalen bedeutet.

Für das Symbol würde sich wie von dir benutzt ja wirklich traffic_signals:symbol=Saarlodri anbieten, was natürlich noch kein verbreiteter Tag ist. Das "crossing:" davor könnte man jetzt entfernen, weil ich beide Ampeln ja nun getrennt getaggt habe (würde ich in so einem Fall immer machen, finde ich generell besser).

Dann hat man schön die Hierarchie:
highway=crossing
crossing=traffic_signals
traffic_signals=pedestrian_crossing
traffic_signals:symbol=Saarlodri

Hier ist auch eine Diskussion, wo jemand vage "traffic_signals:layout" vorschlägt:

osm.wiki/Talk:Key:traffic_signals#cyclist.2Fpedestrians

Siehe Absatz "Physical appearance". Aber "symbol" trifft es eigentlich besser... Layout ist für mich mehr ein Seitenaufbau oder eine Anordnung oder ein Gestaltungsschema...

Vielleicht willst du es ja noch entsprechend ändern bei diesen Überwegen (und anderen mit Saarlodris?). Ich wollte da nicht Hand anlegen...

Und ggf. könntest du ja auch was zu der Diskussion beitragen oder es konkret als Vorschlag machen in einem extra Abschnitt ... Vielleicht findet es ja Anklang. Ich würde es unterstützen.

Viele Grüße!

Hier noch ein paar Infos, vor Ort gecheckt:

• Citylights sind an den Unterständen eigentlich immer in Fahrtrichtung (also wenn man davorsteht) LINKS, und rechts ist eine Gaswand. Macht ja auch Sinn ... für den Busfahrer, um wartende Fahrgäste sehen zu können ...
• Und das Haltestellenschild steht wohl i.d.R. rechts daneben, meist in 1–2 m Abstand zum Unterstand, manchmal auch weiter weg.
• Solche Unterstände sind ca. 3 bis 3,3 m x 1,5 m groß (Grundfläche).
• Die (wohl meist alten) Unterstände aus einer "billboard"-Rückwand mit 90°-Dach sind ca. 4 x 2 m groß (Grundfläche) und ca. 3 m hoch. z.B. bei node/368399122, 5230936027.
• Standard-Plakatgröße ist ja auch 3,6 m x 2,5 m, Citylight-Plakate sind 1,20 x 1,80 groß. Beides plus Rahmen, und das Dach steht noch etwas über …)

Hmmm ...
Also Area + Knoten fände ich auch am Besten. Gleichzeitig genau und der KISS-Maxime folgend (keep it simple stupid).
Wobei diese Multipolygone aus getrennten Linien zusammengesetzt, die man dann einzeln taggen kann, natürlich auch ihren Reiz haben ... das müsste eben einfacher in den Editoren machbar sein, oder man müsste sich eine Bibliothek mit vorgefertigten Objekten anlegen können, die man schnell kopieren und irgendwo hinsetzen kann – sowas fehlt mir schon seit langem .... Dann müsste man es EINMAL machen + hätte es schnell hingesetzt ...

Ich hab's jetzt auch einmal gemacht bei diesem Unterstand als Fläche + Knoten für Werbung (+ Knoten für die Haltestelle): way/401039336. Dort aber noch keinen advertising-Key zur Haltestelle hinzugefügt, sehe ich gerade (eigentlich müsste der ja dann zum shelter auch noch dazu, fällt mir gerade ein …). Da bin ich übrigens auch noch etwas unschlüssig, ob ich da IMMER nur "advertising=yes" hinzufügen soll oder in dem Fall "advertising=poster_box". Ich tendiere ja eher zu "advertising=yes" (KISS!), denn alles Genauere findet sich ja dann bei dem advertising-Knoten. Und ansonsten fängt dann doch noch jemand an, bei der Haltestelle weitere advertising-Attribute hinzuzufügen ... macht man ja bei "bench" auch so bei Haltestellen. Was meinst du dazu?

Etwas unschön bei dieser Lösung: zumindest bei der Standard-OSM-Karte (openstreetmap.org/openstreetmap.de) sieht man nur noch ein Unterstand-Symbol, und nicht mal die Haltestelle, die ja eigentlich wichtiger wäre ... weil der maximale Zoomfaktor zu klein ist .. schade ... Und das "shelter-Icon" ist auch fast größer als die Outline des Unterstands, den man kaum als Fläche sehen kann (wobei der ca. 1,5 x 3 m groß gezeichnet ist, man müsste mal einmal nachmessen, ob das stimmt, könnte aber hinkommen ...).
Aber wir taggen ja nicht für den Renderer ... trotzdem ein Wermutstropfen. Es sieht nicht doll aus, und das nach dem Aufwand dann ... v.a. wenn die Haltestellen dadurch "unsichtbar" werden. Da müsste der Renderer besser werden, und die trotzdem zeichnen oder z.B. eine Priorisierung nach Wichtigkeit vornehmen ... Vielleicht gehört sie aber auch ein Stück weiter weg vom Unterstand und würde dadurch auf auf der Standard-Karte wieder sichtbar, wäre mal zu checken ...

Und Knoten/Knoten – könnte man ja als Zwischenlösung schon machen (sehr nah an Haltestelle), ggf. mit einer note oder fixme à la "Bitte Positionen Werbung/Haltestelle/Unterstand überprüfen, ggf. korrigieren und/oder Unterstand als Fäche zeichnen mit shelter_type=public_transport)."

Wobei ich es mir wohl eher für Vor-Ort-Runden vornehmen werde, wenn ich dann Zeit dafür habe ...

Bei Knoten/Knoten würde zumindest auch das "Haltestelle-Unsichtbar-Problem" auf der Standardkarte entfallen, weil advertising-Objekte ja eh nicht dargestellt werden ...

Man sollte beides mal testen, denke ich.

Nee, es war am 26.07.2020, seh ich gerade. Aber egal ...

Danke für die Info! Dann lösch ich den mal.

Und ja, ich denke, du hast den, der da vorm Mauerpfeiffer steht, versehentlich verschoben beim Eintragen am 20.03.2020.

Ich hab den dann am 20.07.2020 nochmal eingetragen ...

Auf die Idee, mal nach der ref zu suchen, bin ich nicht gekommen – dann hätte ich das wohl auch gemerkt ...