Eine kleine Frage zu einem street_cabinet (Node 7313009966): Ist (oder war?) da wirklich eins? Oder stimmt die Position nicht? Ich war jetzt mehrmals am Ludwigskreisel, aber konnte dort keins finden. Hatte da letztes Jahr schon ein fixme hinzugefügt, jetzt ist es mir nochmal aufgefallen ...

Siehe z.B. https://www.mapillary.com/map/im/pO-rxS-hbuEsSF0U3_hdQQ

Viele Grüße!

Hi!
Ersatzloise Löschung war wohl ein Versehen von mir. Sorry ... Ich wollte es in eine ref umwandeln, habe ich bei anderen Briefkästen auch gemacht.

Denn: Briefkästen haben keine Adresse ... so heißt es auch im Wiki: "Die bei der Deutschen Post im Feld ref=* angegebene "Adresse" sollte am Briefkasten nicht mit dem addr=*-Schema abgebildet werden. Der Postkasten besitzt keine Adresse im üblichen Sinne, sondern wird durch diese in der Datenbank unterschieden."

Ist eigentlich wie bei den Stromverteiler-Häuschen ... oder öffentlichen Telefonen ... oder Parkscheinautomaten ...

Hier wäre also wohl ref=Faktoreistraße/Hafenstraße, 66111 Saarbrücken die richtige Angabe, wenn das so drauf steht.

Viele Grüße!

Kleine Info zu saarriva-Briefkasten (Node 7921031683 und andere …):

Das Q1270345 ist kein operator:wikidata, sondern brand:wikidata.

Denn der Operator bei saarriva heißt "BS Saar-Mosel GmbH" ... "saarriva" ist nur ein Geschäftsbereich dieser GmbH (und eine Marke, wenn auch seltsamerweise scheinbar keine eingetragene Marke, nur eine gelöschte: siehe https://register.dpma.de/DPMAregister/marke/register/304301264/DE – die BS Saar-Mosel GmbH hat nur 2 Marken eingetragen; "zero Mail" und "TBS" – merkwürdig …).

Ich hab es bei dem 7921031683 Briefkasten mal entsprechend geändert ...

Und zu den collection_times kann man bei saarriva mit gutem Gewissen"PH,Sa,Su off" hinzufügen, denn die leeren nicht an Feiertagen, und Samstag/Sonntag glaube ich auch nie (es steht auch extra drauf: – "Keine Leerung an Feiertagen").

Ich müsste auch nochmal die saarriva-Briefkästen, die ich getaggt habe, checken … siehe http://overpass-turbo.eu/s/15wk ...

Da wäre z.B. noch einer in Dudweiler glaube ich ...

Viele Grüße!

Hallo!

Hmm ... kein ganz einfacher Fall. Ich bin da auch hin und her gerissen. Habe gesehen, dass du auch Bushaltestellen, in deren Unterstand ein Citylight (poster_box) integriert ist, mit „advertising:“ Präfixen getaggt hast (z.B. Node 310784070 – Foto siehe https://www.mapillary.com/map/im/P8V86CLa1sEJKdYw2djtkz).

Eigentlich ja keine schlechte Idee, auf der anderen Seite nirgendwo klar dokumentiert – es wäre ein ganz neues Präfix, von denen es ja nur wenige etablierte gibt (wie z.B. die lifecycle-Präfixe) … Habe jedenfalls nix dazu gefunden. Ich würde es daher nicht einfach so benutzen. Vielleicht könntest du da mal auf der TALK-Seite von „advertising“ (am besten englisch) eine Nachfrage stellen, ob man das so machen oder einführen sollte + dann auch entsprechend dokumentieren im Wiki (osm.wiki/Talk:Key:advertising) … Ich halte es aber eher für schwierig, das durchzusetzen. Und fraglich, ob es wirklich sinnvoll ist ….

Das Passendste, was ich dazu gefunden habe, steht jedoch hier: osm.wiki/Key:advertising#Tips: „advertising=yes could be added for bus stops (amenity=bus_station) that have advertising on them (or with benches amenity=bench). But to be able to fully characterize the advertising device, it is preferable to add one OSM node on the transit shelter, and add advertising characteristics on this supplementary node.“

Auf der deutschen advertising-Seite steht nur: „advertising=yes zum Ergänzen von Bushaltestellen, welche mit Werbung ausgestattet sind.“

Daraus könnte man eigentlich schlussfolgern: an dem Haltstellenknoten sollte nur „adverting=yes“ hinzugefügt werden (das fehlt meiner Meinung nach auch bei z.B. obiger Haltestelle in der Eisenbahnstraße, ebenso wie dort auch fehlt, um WAS für ein advertising-Objekt es sich handelt – z.B. billboard oder poster_box, d.h. man müsste eigentlich zumindest z.B. „advertising=poster_box“ statt „advertising=yes“ hinzufügen…) und das advertising-Objekt dann in einem extra Knoten genauer taggen, Hätte schon einige Vorteile, z.B. bleibt man im dokumentierten advertising-Schema (ohne Präfix), und man findet auch advertising-Objekte zuverlässig z.B. mit overpass-Turbo-Abfragen, ohne nochmal extra nach Präfix-Varianten zu suchen … und es würde auch auf Karten überhaupt dargestellt … allerdings dann eng beieinander, aber warum nicht? Das gibt es bei anderen Objekten ja auch …

Also ein bisschen wäre ich vielleicht dann doch für ein GETRENNTES Taggen mit 2 Nodes + „advertising=yes“ auf dem Haltestellen-Knoten … Oder eben ausdiskutieren im Wiki …. Was meinst du?

Solche kombinierten Nodes sind ja immer etwas problematisch am Ende, selbst wenn es die Realität eigentlich am besten abbildet … gilt z.B. auch für Shops, die eine Paketabholung/-abgabe integriert haben – das tagge ich mittlerweile auch immer als 2 Knoten, denn es sind eigentlich 2 getrennte Dienstleistungen unter einem Dach, von einem Operator angeboten (dann erscheinen auch 2 Icons auf der Standardkarte, was ich eigentlich sinnvoll finde) … so ähnlich ist es bei so einer Haltestelle/Platform ja auch … 2 Funktionen an einer Stelle …

Und es gibt ja sogar Haltestellen, wo der UNTERSTAND extra gezeichnet ist als amenity=shelter und shelter_type=public_transport … (als node oder way), z.B. 401039336 (https://www.mapillary.com/map/im/QQIFZ3kE4nbDmHqT-gl1DA) oder 400928353 – da könnte man ja dann auch noch einen advertising-Knoten dazusetzen (oder DRAUF bzw. verbunden damit bei einem als way gezeichneten Unterstand).

Am absolut saubersten (und natürlich aufwändigsten) à la Microtagging wäre es wohl, solche Unterstände maßstabsgerecht als geschlossene Wege zu zeichnen, die eigentliche Haltstelle dicht daneben (wo sie eben steht) und den Werbung-Knoten dann AUF einer der Wände des Unterstands (oder wenn man es NOCH weiter treiben will: Unterstand aus mehreren getrennten Linien zeichnen, die Linien in einer Relation zusammenfassen zu EINEM geschlossenen Objekt, und die Seitenlinie, die z.B. aus einem Citylight besteht, dann als advertising-Objekt taggen als ein Bestandteil der Relation … aber das fände ich dann auch etwas ZU extrem …).

Nebenbei bin ich noch skeptisch geworden mit dem access-Tag bei advertising generell. Das benutze ich eigentlich immer, weil ich mir das so eingeprägt und mal gelesen hatte. Auf der advertising-Wiki Seite DE+EN steht es aber gar nicht als Zusatztag … nur z.B. bei der englischen billboard-Seite: „access=*: can everybody change the content of the billboard?“ …. Auch etwas seltsam … Ist auch wohl nicht das wichtigste Tag bei advertising. Bei 99% gilt da ziemlich sicher: access=no … Aber das ist nochmal ein anderes kleines Thema … man kann es ja trotzdem setzen …

So, jetzt reicht es aber mit den Gedanken dazu …

Kannst ja mal schreiben, ob du dich da an die Arbeit machen willst und vorhandenes anpassen ... zumindest in Saarbrücken (und Umgebung?) :-) Diese Abfrage könnte dabei helfen: http://overpass-turbo.eu/s/15vK (Wizard-Query: ~"advertising:"~".*" in Saarbrücken).

Oder mal recherchieren, wie das in anderen Städten gemacht wird … ist manchmal auch sinnvoll, aber auch nicht immer …). Eine overpass-Turbo-Abfrage über ganz Deutschland (http://overpass-turbo.eu/s/15vL, Wizard-Query: ~"advertising:"~".*" in Deutschland) ergibt interessanterweise, dass das in der Form wohl NUR in Saarbrücken benutzt wird … von dir? :-) Aber vielleicht noch sonstwo auf der Welt?

Viele Grüße!

Hallo!
Oh, das ist natüriich ungünstig ...
Ja, das ist eine ganz seltsame Bushaltestelle. Wirklich eine Werbetafel mit nach vorne abstehendem Dach als eine Art Bus-Shelter-Ersatz, alles in einem.

Sollte man wohl am besten in 2 Punkte aufteilen, vielleicht die Werbetafel ganz dicht HINTER der Haltestelle .... Könntest du machen, wenn du möchtest ... oder ich mach es demnächst ...

Viele Grüße!

Hallo! Was bedeutet denn fixme=hagen bei Saargemünder Straße 9 (#123228186)? Bin nur neugierig... Grüße!

Hallo!
Du hast bei „Zur Ostspange“ in Saarbrücken turn:lanes und lanes angeben, die so nicht stimmen, z.B.: "turn:lanes=left|throuleft|through|throughgh|right" auf diesem Wegstück: openstreetmap (Syntax ist falsch + dort sind so weit ich weiß gar keine turn:lanes, erst weiter vorne).

Oder hier: osm.org/way/294449173 (lanes von 2 auf 3 geändert es sind aber 2 + ich glaube, da sind auch keinerlei turn-lanes, schon gar kein nach links – "left|through|through"). Ich hab es mal entfernt und die alte lane-Anzahl nochmal hergestellt. Ich bin da öfters unterwegs, bin mir ziemlich sicher, dass es so wie es jetzt ist, stimmt … und auf Mapillary sieht es auch so aus …

Falls du es für angebracht hältst, vielleicht vor Ort nochmal checken (weiß nicht ob du aus Saarbrücken bist ... ich schon ...).

Viele Grüße!

Sehr gut! Es lag ein Zettel im Schaufenster, wo die neue Adresse drauf stand (Eröffnung 01.10.2020) ...

Hallo! Ja, das stimmt wohl ... das Ladenlokal ist schon ziemlich "abandoned" und steht schon ewig leer.

Ich habe am 22.08. auch von einem Mieter im Innenhof erfahren, dass das GESAMTE Vorderhaus seit geraumer Zeit leer steht (also komplett unbewohnt ist) und stark renovierungsbedürftig sei. Habe deshalb am Gebäude disused=yes hinzugefügt (extra NICHT als Präfix, wie es im Wiki auch empfohlen wird für Gebäude ... finde ich auch sinnvoll). "abandoned=yes" wäre hier vielleicht auch angebracht, aber ich benutze es eigentlich nur, wenn ein Objekt komplett und dauerhaft aufgegeben und dem Verfall ausgesetzt wurde und auch sehr verfallen aussieht (kann man hier nicht genau sagen bzw. wäre sehr verwunderlich in der Lage).

"(Freibad Walsheim und Umgebung)" gehört da nicht hin in den Kommentar ... war ein Versehen ...

Du hast da am Südring Überwege eingezeichnet, wo gar keine sind... Auch geht da kein Bürgersteig-Weg weiter rechts (stadteinwärts)... ich ändere es heute noch...

Hello! fee=yes is not correct on this parking as a general key. There is a time_intervall (Mo-Fr 08:00-20:00; Sa 08:00-14:00), where parking is only für residents and only THEY pay a fee per year. But at the other times, parking is FREE for everyone (see the tag "parking:condition:default=free")

The fee tag is a problem (and wrong in general) in this case. IMHO it should not be used here ... It is implicated in parking:condition=residents, that they have to pay a yearly fee for the parking ...

Or it should be changed in fee:conditional=yes @ (Mo-Fr 08:00-20:00; Sa 08:00-14:00) ... if you really want to have a fee tag ...

What do you think?

Hallo!
Das war ein Fehler von mir mit dem oneway=yes. Habe es gerade wieder entfernt.

Ich hatte auch kurz überlegt, die Kreuzung anders zu zeichnen, aber ich denke, man sollte sie so lassen. Wird sonst nur wieder ein ziemliches Wege-Durcheinander. Es müsste ja so jetzt alles stimmen.

Ja, da ist eine Insel bei dem Übergang und dann aufgemalte Sperrfläche – die Fahrspuren sind da optisch/baulich schon etwas getrennt bis Ausfahrt vom SaarBasar ... aber es nur deswegen anders zu zeichnen von da an bis zur Kreuzung ist vielleicht übertrieben und unnötig verkomplizierend.

Danke fürs Fehler-Erkennen!

Viele Grüße!

Hallo! Deine Bearbeitung der Wilhelm-Heinrich-Brücke hat mich etwas gewundert ... sie hat kein Loch? Was ist das dann am westlichen Ende? Das macht meiner Meinung nach wenig Sinn. Da ist ja eine kreisförmige Öffnung, und der Brückenkopf dort muss ja irgendwo aufliegen – und das zählt doch wohl zur Brücke dazu (ich hatte das 2019/11 zuletzt überarbeitet nach recht gründlicher Besichtigung vor Ort samt Fotos; auch von unten). Bitte mal von unten (Leinpfad) aus schauen ... da sind Brückenteile zu sehen, die bis zur Stützmauer dort reichen. Ich fände es gut, du änderst das wieder zurück ... Wo genau die Brücke westlich endet, ist schwer zu sagen, aber sicher ein Stück westlich von dem vorhandenen Loch ... und den gesamten Kreisverkehr dort kann man denke ich sicherlich zur Wilhelm-Heinrich-Brücke zählen.

Auch die Entfernung des Straßennamens "Wilhelm-Heinrich-Brücke" von den Straßen ist denke ich nicht gut + nicht empfehlenswert. Auch wenn das man_made=bridge-Objekt den Namen trägt. Z.B. für Navigationssoftware sicherlich wichtig, um Straßennamen anzusagen o.Ä. Außerdem bringt JOSM Fehlermeldungen, dass die Straßen keinen Namen haben, müsstest du eigentlich auch bekommen haben. Und im Wiki zu man_made=bridge steht auch: "Die Namen der Verkehrswege verbleiben dort." (Abschnitt "Brücken mit einer Ebene"). Ich habe das schon mal rückgängig gemacht. Viele Grüße!

PS: Was heißt "Wall-E 4.0 Korr."?

Ich war heute nochmal zufällig dort ... zur Zeit ist der Gegenrichtungs-Radweg nur noch in die EINE Richtung frei gegeben wegen ner Baustelle ...

Und das Stück Fuß-/Radweg ist tatsächlich eher ein "straßenbegleitender Weg", also wie ein normaler Bürgersteig. Nur Parkplätze davor (ganz normal, parallel zur Straße). Aber auch in beide Richtungen für Fahrrad frei gegeben, mit extra Schild vor der Einmündung der Straße "Am Schönetal" ... Ist also wohl so gedacht, dass man dort mit dem Rad links rüber fahren soll, wenn man aus Richtung Rußhütte kommt und nach links will zum Kreisel ... Da kommt aber sicher so gut wie niemand drauf.
Viele Grüße!

Oh ... das ist ein weites Feld mit der Disussion ob nun highway=path oder highway=footway richtig oder besser ist ...

Du hast sicher recht, footway sollte glaube ich NUR bei Zeichen 239 (ausgewiesener Fußweg) verwendet werden, das wird aber von sehr vielen auch nicht beachtet; ich bin da manchmal auch etwas nachlässig geworden. Aber bei gemischten Wegen (Fuß/Rad) sollte eigentlich path verwendet werden.

Hier lag es glaube ich daran, dass es eine OSMOSE-Fehlermeldung an der Stelle gab, weil du footway=sidewalk gesetzt hattest aber highway=path war ... was wohl nicht zusammenpasst (und OSMOSE nicht gefällt; siehe auch osm.wiki/DE:Tag:footway%3Dsidewalk),
Ich habe es daher ohne groß zu überlegen in highway=footway geändert, um diese Osmose-Fehleranzeige (in Vespucci) weg zu kriegen ... es fehlt halt ein path=sidewalk Tag ...

Du kannst ja gerne überlegen, ob du es anders taggen würdest oder das footway=sidewalk wieder weglassen würdest ...

Evtl. müsste es sowieso wohl eher als "straßenbegleitender Weg" (osm.wiki/DE:Bicycle/Radverkehrsanlagen_kartieren#Stra.C3.9Fenbegleitende_Wege) getaggt werden (ich glaube, der ist nicht wirklich groß abgetrennt von der Staße, bin aber nicht mehr sicher) .

Übrigens: auf dem Teil der Straße "Am Ludwigsberg" vorher ist auch noch Radfahren auf dem Radstreifen (nur mit weißer Linie von Fahrbahn für motorisierten Verkehr getrennt) in GEGENRICHTUNG erlaubt, was ich auch etwas irre finde (und das geht dann auf Fuß-/Radweg weiter so bis unter der Eisenbahnbrücke am Kreisel durch, ziemlich ungewöhnlich) ... hab ich aber jetzt mal noch eingetragen mit oneway:bicyle=no.

Viele Grüße!

Hallo Toni!

Oh je … genaues weiß ich da nicht mehr. Nur noch, dass das eine ziemlich umfangreiche Bearbeitung war mit vielen Korrekturen an lanes, Abbiegeregeln, Fahrradspuren usw., soweit ich mich erinnere, an der ich mehrere Stunden bis in die Nacht gesessen habe. Würde es nicht ausschließen, dass dabei ein Fehler passiert ist ... Die Straßensituation an der Stelle und den Kreuzungen dort ist nicht ganz unkomplex, und ich hatte trotz sehr guter Ortskenntnis und vielen Fotos vor Ort viel Arbeit damit. War froh, als es erledigt war, das weiß ich noch.

An eine Flixbus-Relation kann ich mich allerdings gar nicht erinnern. Normalerweise achte ich schon auf Relationen und Probleme damit, die beim Löschen von Nodes oder Ändern/Aufsplitten von Wegen o.Ä. auftreten (was dort bestimmt öfters nötig war) und korrigiere das dann auch mit. Aber vielleicht habe ich da etwas übersehen. Da gibt es zahlreiche Bus-Routen an der Stelle (plus Saarbahn etc.).

Ich hoffe, es macht nicht allzuviel Arbeit, das nochmal zu reparieren.

Viele Grüße,
Patrick

Sorry, war eine falscher Comment bei dem Änderungssatz. Ich habe den Plan doch nicht benutzen müssen. Es ging auch so.

Gibt es einen Grund, warum hier ganz vielen Straßen (nur in Deutschland?) eine Menge von access-Keys zugewiesen wurde, die nach den implizit geltenden Zugangsbeschränkungen unnötig sind? z.B. access=yes, foot=yes, bicycle=yes, horse=yes. Das führt doch nur zu überfrachteten Tags.

Hello! Thank you. I know the wiki. I found it so important to mark this way also with a name (and added also sac_scale and trail_visibility) to make it visible as really bad and dangerous although it doesn't correspond to the principle "never tag for the renderer". I know...

But when I was there, this way was tagged as a normal path and I took it therefore and was really very much in trouble after that (even with good equipement). So it was perhaps a very personal decision.
So if you think, the rules should be followed in any case, don't hesitate to change it!

Note: I used LocusMap on that trip, which is a quite good app, but trail visibility is not rendered there as far as I know (or not very good).