Hallo SvenML, ich bin ganz bei dir: Diesen Asphaltstreifen sollte man nicht als "Radweg" bezeichnen und auch nicht als solchen nutzen. Allerdings ist er baulich als solcher vorhanden (durch die baulichen "Einfahrten" an den Enden auch als solcher erkennbar), nach welchen völlig veralteten Standards auch immer er vor langer Zeit mal angelegt wurde.

In der Berliner OSM-Community sind wir seit einiger Zeit dabei, den Ausbauzustand von Radwegen in Berlin systematisch zu erfassen, um insbesondere auch "schlechte" Radwege als solche identifizieren zu können. Da sind solche Informationen wie zu diesem Streifen hier recht hilfreich.

Daher hab ich den Radweg wieder hergestellt.

Um Routing über solche Wege zu verhindern bzw. ihre Qualität beurteilen zu können, können wir vielfältige physische Angaben (Breite, Oberflächenbeschaffenheit/-qualität, Pufferbreiten etc.) detailliert erfassen - das war hier bereits der Fall. Ich habe nun noch "bicycle=discouraged" als "Empfehlung zur Vermeidung" ergänzt. Mit diesen Angaben können Router (theoretisch, in der Praxis nicht immer) den Weg vermeiden bzw. feststellen, dass die Nutzung der Straße attraktiver ist.

two minor comments (just details :)

It's better to use two different nodes for a street lamp with a waste basket attached to it: One for the lamp post and one for the waste basket next to the street lamp. If you tag "support=street_lamp" on the waste basket, it will be clear that they belong together. Otherwise, with detailed information such as height, colour, material, etc., it is not clear to which object this attributes refer.

Also, you don't have to tag "foot=no" on a cycleway, as this is already implied by "highway=cycleway".

Both are no mistakes, just little "style tips", as you seem to have a talent for good mapping anyway :)

Best, Alex

(ich hoffe also, dass man das Issue in einem Jahr nochmal aufmachen kann, wenn die Zahlen entsprechend gestiegen sind... Bei "street_side" hat es ja damals auch ne Weile gedauert.)

Hallo geozeisig,

"parking=on_kerb" war kürzlich Teil des Street Parking Proposals, um die beiden Varianten des Straßenparken-Mappings (Straßenlinie vs. separate Geometrie) miteinander zu synchronisieren. Denn beim Mappen an der Straßenlinie gibt es "on_kerb"-Parking bereits seit langem. So wie "parking=lane" ist es ein Value, der sich (meiner Meinung nach) nicht für den Regelfall anbietet, sondern z.B. wie hier eher für "fragmentierte" Flächen, die man nicht gut/genau genug an der Straßenlinie abbilden kann.

Siehe osm.wiki/Proposed_features/street_parking_revision.

Was die Symbole an den Parkplätzen angeht: Ich habe schon versucht, ein angepasstes Rendering wie bei "street_side" zu erwirken, aber derzeit noch erfolglos, da der Tag erst einen Monat alt ist und daher noch kaum in Verwendung (https://github.com/gravitystorm/openstreetmap-carto/issues/4754).

Hab mal "barrier=parking_lane" aus den "parked_cars" gemacht - das ist der Wert, der sonst benutzt wird... Wobei das irgendwie alles semantisch nur so halb passt...

Hey momabebra, kleiner Hinweis (weiß nicht, ob du es vielleicht nur vergessen hast): Den Wegen über die Straße solltest du zusätzlich zu "highway=footway" noch "footway=crossing" geben.

Siehe auch osm.wiki/Berlin/Verkehrswende/Gehwege.

lg, Alex

Hallo karaga, du hast nun schon mehrfach Änderungen von User:Mapillox gelöscht, die vielleicht nicht immer in dieser Form sinnvoll waren, aber bist du denn auch schonmal mit ihm in Kontakt getreten, was es mit diesen Änderungen auf sich hat?

Hallo Stefan, vielen Dank für deine vielen Beiträge zu OSM in letzter Zeit! Eine Anmerkung zu dieser Änderung: In der Teetzlebener Straße in Altentreptow (way/23653989) hast du mit StreetComplete die Option "Radweg" ergänzt, allerdings war hier der Radweg bereits als separate Linie in OSM enthalten.

Vermutlich ist das in StreetComplete nicht immer gut zu erkennen (und es ist auf jeden Fall auch kein Weltuntergang ;), aber ich wollte dich trotzdem darauf hinweisen.

Beste Grüße und Danke für deine Beiträge!
Alex

Hallo geozeisig, ich hatte hier an der in Bau befindlichen Gedenkstätte zum Friedhofslager bewusst "monument" statt "memorial" gewählt, da es sich um eine recht große, begehbare Fläche handeln wird, die insgesamt den Gedenkort bilden wird. Laut Wiki sind die Größe und Begehbarkeit zentrale Kriterien, die für "monument" sprechen. Was spricht deiner Meinung nach eher für "memorial"?

Für optische Eindrücke (leider noch nicht fertiggestellt) siehe auch https://kkbs.de/blog/112054/kirchliche-gedenkstatte-zur-ns-zwangsarbeit-fur-die-kirche-berlin-neukolln-fast-fertig sowie https://commons.wikimedia.org/wiki/File:Gedenkst%C3%A4tte%20Friedhofslager%20Berlin-Neuk%C3%B6lln%20Baustelle%20November%202022.jpg.

Danke Toni und Lukas! Wenn behoben, könnt ihr auch note/3494037 wieder schließen? Lg, Alex

Hallo webpassenger, danke für die Ergänzung der Infotafeln zum Rundgang Stasi-Zentrale! Zur Info: Ich habe gerade den Namen und die Beschreibung der Tafeln getauscht, da der Name dem jeweiligen Thema einer Infotafel entsprechen sollte. Auf vielen Kartendarstellungen wird "name" auch gerendert, sodass keine irreführenden Beschriftungen entstehen (darüber bin ich darauf aufmerksam geworden: note/3493602).

Du hattest den Tafeln jeweils eine Nummer gegeben - sie sind vermutlich stationsartig durchnummeriert? Ich habe das versucht durch die Ergänzung von "Tafel Nr. X" in der Beschreibung kenntlich zu machen sowie durch Ergänzung einer "ref". Beispiel: node/9810594725

Vielleicht kannst du ja mal einen Blick drauf werfen, ob das so in Ordnung ist.

Danke jedenfalls fürs ergänzen!
lg, Alex

Hallo goaned,
danke für die Anpassung - ich kann die Begründung gut nachvollziehen und habe bei kurzer Prüfung keine Probleme entdeckt.
Allerdings ist das eine Änderung in ziemlich großer Größenordnung, bei der es vielleicht besser gewesen wäre, vorher kurz die lokale Community zu informieren, z.B. via Mailingliste. (Oder gab es irgendwo anders dazu eine Diskussion?)
Ich hoffe trotzdem, dass passt so, auch wenn ich nicht bis ins letzte Detail nachvollziehen bzw. prüfen kann, ob die Änderung irgendwo zu Problemen oder Inkonsistenzen führen kann.
lg, Alex

Ich habe es mal mit Abbiegerelationen versucht (es sind 4, nicht 2 - in jede mögliche Richtung eine). Das Problem dabei ist, dass das Routing durch den mittleren Schnittpunkt läuft, an dem eigentlich ein Poller stehen sollte. Den hab ich dort nun auch mal eingetragen. Ein Poller müsste im Routing aber eigentlich als motor_vehicle=no interpretiert werden - und ich weiß nicht, ob das auch beim Abbiegen gilt... Müssen wir mal ausprobieren. Extra einen "vehicle=yes"-access zu setzen mit Verweis auf die Abbiegerelationen fände ich auch schräg...

(siehe auch changeset/129926888)

Hab mir gerade nochmal die Verteilung in Europa angeschaut - es gibt beide Verwendungen. Also ein paar Orte, in denen es jemand nur an größeren Straßen getaggt hat, und einzelne Städte, in denen es überall verwendet wird. Dazu gehört neben dem Berliner Südwesten (hier hab ich es weiträumig rund um Neukölln und Friedrichshain-Kreuzberg gemappt und auch schon gelegentlich in Auswertungen berücksichtigt) Krakau (Mateusz Konieczny ;) oder Bremen.

Ich hatte bisher nur mit Mateusz dazu Austausch und habe quasi seine "Lesart" übernommen. Hab gesehen, dass er aber die Wiki-Seite gar nicht ursprünglich angelegt hatte. Also falls du Bedenken zu dieser Art der Verwendung hast, müsstest du vielleicht nochmal ne größere Diskussion starten.

Ich finde es aber super praktisch und habe es wie gesagt schön öfter mal berücksichtigt (sowohl bei Längenberechnungen als auch in Renderings).

Siehe auch changeset/129946411.

Achso, auch die Wikiseite zum Key ist schwer zu finden: dual_carriageway=yes

Im OSM-Kontext wurde es eigentlich insbesondere auch für "klassische" urbanen Straßen eingeführt - primär die Hauptstraßen, aber nicht nur. Bei Schnellstraßen und Autobahnen ist - wenn sie oneways sind - ja meistens ohnehin klar, dass sie in diese Kategorie fallen.

Aber in der Tat ist die Dokumentation noch mau und es gibt nur sehr wenige die es verwenden.

Aber es ist verdammt praktisch :) (z.B. wenn man mal die Länge des Straßennetzes ermitteln will - da würden nämlich sonst die ganzen Zweirichtungsfahrbahnen doppelt reinfallen und es ist utopisch, das geometrisch zu lösen). lg, Alex

Vielleicht sollten wir einfach zwei Abbiegerelationen nutzen? Auf jeden Fall kann ich das Anliegen gut nachvollziehen, die Fahrradstraße nicht zu unterbrechen, denn alles andere wäre ja eine Auto-zentrierte Sicht auf die Straße ;) Ich denke, Abbiegerelationen wären eine gute Wahl.

Können ja beim nächsten Verkehrswendetreffen auch mal einen Dokumentationsvorschlag für verschiedene Fälle überlegen. Mich wurmt es ja auch sehr, das es derzeit noch keine Möglichkeit gibt, Diagonalsperren und modale Filter auf einfache Weise "abzufragen"... bzw. überhaupt irgendwie sinnvoll herauszuinterpretieren.

Hallo kjon, du hast hier "dual_carriageway" als Attributierung der Zweirichtungsfahrbahnen gelöscht. War das Absicht oder ein Versehen? Habe es wieder hergestellt, da zumindest auf der v.-Richthofen-Str. der Fall klar ist (z.B. keine Einbahnstraßenschilder). Bei "Rumeyplan" könnte man sich vielleicht streiten, ob es in diese Kategorie fällt, aber da hast du es sowieso nur an einem kurzen Stück entfernt....
lg, Alex

Sehr gut :) Das ist ja auch ein sehr ungewöhnlicher Fall, dass sich so ein Tagging grundlegend ändert. Also entschuldige eher die Umstände meinerseits ;) StreetComplete wird dann wahrscheinlich bald aktualisiert. Lg, Alex