piebro/osm-data huggingface dataset:
commented by ASRvwde (2024-11-18 01:50:10+00:00): Guck Dir das https://www.openstreetmap.org/way/1317379201 mal genau an und wirf vielleicht auch in der Bearbeitungsansicht nen Blick auf die Pfeile.

Es kommen auf der Südseite von Westen, aber der Einmündung Niedernfeld zwei Fahrspuren, quasi als Einbahnstraße, Richtung osten den Berg hoch, während auf der Nordseite eine Fahrspur von Osten nach Westen den Berg herunter führt.

An dieser Engstelle erweitern sich Richtung Westen die beiden Fahrspuren um eine Linksabbiegerspur Richtung L81, auf der aber quasi auch Einbahn Richtung Osten gilt.

Eingezeichnet aber ist, dass die nach Westen führende Fahrspur, als "Einbahnstraße" in die nördliche der beiden nach Osten führenden Fahrspuren mündet und die Gesamtbreite der Straße auf der Nordseite durch einen "Bürgersteig" eingeengt wird, was aber nicht der Fall ist und so bestehen bleibt, bis sich die westwärts führende Fahrspur hier https://www.openstreetmap.org/way/1317129852 wieder abtrennt.

Westwärts war die B229 früher ab der Brücke zweispurig, was heute nicht mehr der Fall ist
https://www.mapillary.com/app/?pKey=1066698195134744

Heute wird sie erst mit der Einmüdnung "Niedernfeld" Richtung Westen zweispurig
https://www.mapillary.com/app/?pKey=537988928640047

Und der Schlenker, den sie dort macht ist bedingt durch die Linksabbiegespur in der Gegenrichtung.

Ab da ist die Straße dreispurig, zwei Spuren Richtung Osten, eine Richtung Westen
https://www.mapillary.com/app/?pKey=1736785003524100

Eingezeichnet aber ist, dass es zwischen hier https://www.openstreetmap.org/way/1317129852 und hier https://www.openstreetmap.org/way/1317379201 die Westwärts führende Spur nicht vorhanden ist.

Diese Einengung
https://cloud.asrvw.de/index.php/s/by9nXsGYkQFYymB
existiert da nicht. Die Richtungen Ost und West teilen sich da keine Fahrspur.
commented by ASRvwde (2024-11-18 01:52:49+00:00): Korrektur:

Streiche "Heute wird sie erst mit der Einmüdnung "Niedernfeld" Richtung Westen zweispurig"

Setze "Heute wird sie erst mit der Einmüdnung "Niedernfeld" Richtung OSTEN zweispurig"
commented by Negreheb (2024-11-25 09:53:54+00:00): Die Optik (=der Renderer) ist natürlich nicht so schön, aber bei OSM mappen wir nicht für den Renderer, das sei mal vorweg gesagt. 

Du schreibst:
"Eingezeichnet aber ist, dass es zwischen hier https://www.openstreetmap.org/way/1317129852 und hier https://www.openstreetmap.org/way/1317379201 die Westwärts führende Spur nicht vorhanden ist"
https://www.openstreetmap.org/way/1317379238 der Weg nach Westen ist korrekt mit zwei Fahrspuren gemapped, von Osten kommend https://www.openstreetmap.org/way/1317379250 korrekt als eine Spur. 

Wenn ich dich korrekt verstehe, dann hast du ein Problem mit dem Rendering von https://www.openstreetmap.org/way/1317129852 und https://www.openstreetmap.org/way/1317379201 - oder habe ich das falsch verstanden?
commented by ASRvwde (2024-11-28 07:03:44+00:00): Moin.

Also, so wie ich das hier sehe, ist das Problem das "placement"-Tag. Die Straße hat hier 3 Fahrstreifen, zwei forward, einer backward. Der OSM-Track liegt in der Mitte des mittleren Fahrstreifens und damit auch in der Mitte der Straße insgesamt. Ein "placement" zum Versatz ist hier überhaupt nicht erforderlich.

Wiki: "Whenever the OSM-way is not drawn in the middle of a road the key placement can be used to specify this."

Aber "middle of the road" meint meiner Auffassung nach nicht zwingend die Mittellinie im Sinne der Fahrbahnmarkierung, sondern die Mittellinie im Sinne der Gesamtbreite der Straße. Und hier liegt der OSM-Track über die Mittellinie bezogen auf die Gesamtbreite der Straße, was das "placement" hier überflüssig macht. Zumal sich die Gesamtbreite der Straße in diesem Bereich auch nicht ändert.

Das Render-Problem mit dem vermeintlich verbreiterten Randstreifen nördlich, ergibt sich einzig durch den real nicht vorhandenen Versatz mittels "placement".
commented by ASRvwde (2024-11-28 07:20:30+00:00): Nachtrag: Das eigentliche Problem ist, hier ist "placement" "middle_of:2" gesetzt. Lanes sind hier aber 3.
commented by RubenKelevra (2024-11-28 08:16:55+00:00): Wenn der Weg in der Mitte von 3 Fahrstreifen ist, ist `middle_of:2` korrekt. Middle of 2 bedeutet in der Mitte des zweiten Fahrstreifens, nicht in der Mitte von zwei Fahrstreifen. 

In dem Fall ist der Placement Tag optional, aber guter Stil, da er dann bei Shifts dem Renderer erlaubt explizite Informationen zu nutzen.

Unterstützt Mapnik überhaupt schon placement Tags?
commented by ASRvwde (2024-11-29 09:13:24+00:00): Scheint, Du hast für alles ne Antwort. Nur nicht dafür, warum das hier so Schei**e aussieht - und vor allem nicht dafür, warum das NUR HIER so Schei**e aussieht.

Ich hab mir inzwischen den gesamten Verlauf der B 229 angesehen, die sich zig mal auf mehr Spuren erweitert und auf weniger Spuren kastriert wird und die an zig Stellen zwei Spuren in die eine und nur eine Spur in die andere Richtung hat und NIRGENDWO sonst wird sie dabei SO dargestellt.

Euer Renderer in allen Ehren, aber die Logik sagt mir, dass HIER was falsch, was anders sein muss, denn es wird eben NUR HIER so seltsam dargestellt.
commented by Negreheb (2024-11-29 09:43:14+00:00): Das sieht nur hier so aus, weils eben so eingezeichnet wurde. Wenn an einem anderen Ort das noch(?) nicht getrennt wurde, dann sieht es dort auch nicht so aus. 

placement-tag höre ich hier das erste mal davon, hätte ich noch nie genutzt und der tag ändert vermutlich(!) auch nichts am Rendering. 

"die Darstellung ist nicht gut" - das ist egal. Ignorier das bitte. Ich weis, das kann äußerst nervig sein - aber das ist eben nur ein Renderer. Es gibt aber extrem viele Renderer. Und deswegen ist das Sache des Renderers das Problem zu beheben.

Sind die Daten falsch? Ist das Routing falsch? Wenn nein und wenn dich die Darstellung stört, dann musst du beim Renderer ein Issue aufmachen und der muss das beheben. Vielleicht gibt es sogar schon andere Renderer, die das besser anzeigen.
commented by ASRvwde (2024-11-29 10:23:26+00:00): Nun gut, dann nehme ich das halt mal so hin, dass der "Renderer" das auf den 137 km Gesamtlänge der B 229 NUR HIER falsch darstellt. OK.

Was die Daten angeht, scheint der Bereich der B 229 zwischen "Niedernfeld" und der L 81 dennoch ein Problem zu haben, denn in RS-Lennep, auf der Rader Straße Höhe der Bushaltestelle "Stadion" gibt mir OSMand Richtung Radevormwald-Zentrum navigierend die Anweisung "in 3km nach links auf die B 229" zu fahren; im weiteren Verlauf vor der Kreuzung "Niedernfeld" bei Beginn der Linksabbiegespur Richtung Lorenzhaus dann die Anweisung "Links einordnen, um auf die B 229 zu fahren" (die B 229 ist an der Stelle noch einspurig in Richtung Radevormwald) und weißt dann unmittelbar vor der Kreuzung "Niedernfeld" mit Zeichen 511-10 eine verschwenkung nach links aus, die es auf dieser Fahrspur nicht gibt, weil sich die B 229 hier nicht nach links, sondern nach rechts um eine Spur erweitert.

Keine Ahnung, ob das in unmittelbarem Kontext zu diesem Problem steht, aber auf jeden Fall ist in den Abschnitt noch was anderes falsch.
commented by RubenKelevra (2024-11-29 10:39:37+00:00): Klingt so als würde OSMAnd eine falsche Annahme machen welche Spur aus welcher Spur hervorgeht. Diese Informationen lassen sich mit einer connectivity-Relation explizit taggen. Hab damit allerdings keine Erfahrung und weiß auch nicht ob OSMAnd die schon parst für sein Routing.


Ich schau mir mal an, ob etwas anderes OSMAnd hier stolpern lassen könnte.
commented by hsc666 (2024-11-29 14:20:25+00:00): Ausgelöst wurde das Ganze ja dadurch, dass Du das vorhandene Spurmapping aufgelöst hast (was auf den ersten Blick jetzt nicht all zu falsch aussah) durch Auftrennung in getrennte ways für die jeweilige Richtungsfahrbahn. Dort liegt aber keine bauliche Trennung vor und die kurzen Sperrflächen rechtfertigen kaum die Trennung. Welches Problem wolltest Du denn damit überhaupt lösen?
commented by RubenKelevra (2024-11-29 14:30:01+00:00): Das Ziel des Edits war mehr Details hinzuzufügen, beispielsweise das Mapping der Sperrflächen, Bordsteine und Verlehrsinseln.

Wenn man die Sperrflächen mappt macht es logisch wenig Sinn, die Straße dann in der Mitte durchzuziehen bzw. auf einer Seite mit Placement-Tag, oder überseh ich hier etwas?

Ansonsten ist es ja völlig normal die Straße in zwei einzelne oneways aufzuteilen, wenn in der Mitte eine Verkehrsinsel wäre, ohne das die Tags anders wären. Das beschriebene Routing-Problem oder angesprochene Darstellung vom Mapnik wäre dabei identisch.
commented by hsc666 (2024-11-29 14:54:56+00:00): Hmm. Dennoch gibt es dort keine bauliche Trennung der Spuren. Das bleibt mein Hauptkritikpunkt. Die getrennten ways führen zu "Knicken" im Verlauf, die nicht existieren. Wir müssen wohl froh sein, wenn ein Router daraus nicht "links abbiegen/halten" macht. Ein einzelner way mit Spurmapping wäre auch in Mapnik nur eine Linie (ohne Knicke), würde daher natürlich anders aussehen, aber darum geht es ja nur sekundär.  Für Verkehrsinseln brauchst Du die Trennung auch nicht. Und ob der konkrete Nutzen der vermeintlich höheren Detaillierung (welcher Auswerter verwendet das in der Form?) gegenüber einem abstrakten Mapping die gewöhnungsbedürftige Darstellung mit nicht existierenden Winkeln/Abbiegungen in Verbindung mit erhöhtem Pflegeaufwand durch mehr restrictions rechtfertigt?

Was ist mit "das beschriebene Routing-Problem" gemeint? Finde hier in der Beschreibung kein Hinweis drauf.
commented by RubenKelevra (2024-11-29 15:04:59+00:00): Für Verkehrsinseln die Spuren aufzuteilen ist, zumindest hier in der Gegend völlig normal. Hier Beispiele:
51.2658942, 7.1819003
51.2675406, 7.1942197
51.2714909, 7.212625

Die "Knicks" in der Straße dabei ebenfalls, dafür ist ja der `placement=transition` Tag, um dem Router mitzuteilen, dass hier lediglich die Straße aufgesplittet wird, um ein Feature herumzuleiten.

Ab einem gewissen Detailgrad lässt sich das nicht anders lösen, fürchte ich.

"welcher Auswerter verwendet das in der Form?"

Die Berliner Straßenraumkarte stellt das beispielsweise dar.

"Was ist mit "das beschriebene Routing-Problem" gemeint? Finde hier in der Beschreibung kein Hinweis drauf."
@ASRvwde hat  davon gesprochen, dass OSMAnd Probleme mit dem Routing hat.

Hab grade die Spuren durchgeschaut und mich beim Zählen vom Placement-Tag an ein paar Stellen vertan. Das hab ich grade korrigiert. Das könnte die Ursache für die Probleme gewesen sein.
commented by RubenKelevra (2024-11-29 15:06:42+00:00): "welcher Auswerter verwendet das in der Form?"

Ach so und natürlich "Enhanced road and lane attributes" in JOSM rendert das ebenfalls seit ein paar Jahren.
commented by hsc666 (2024-11-29 15:26:53+00:00): Du gaukelst eine bauliche Trennung vor, die nicht existiert.

JOSM ist kein Datenauswerter (und Rendern keine Auswertung) und placement ist seit Jahren als Draft nur proposed, ich kann mir kaum vorstellen, dass OSMAnd das verwendet. 

Ich glaube, dass der Nutzen der Daten mit einem einzelnen way und entsprechenden Eigenschaften und Spuren höher wäre, als der Versuch ein optisch exaktes Abbild von Sperrflächen zu schaffen zu Lasten der Verfälschung der Geometrie der eigentlichen Straße.

btw: Hab nochmal alles gelesen, aber finde nix von einem Routingproblem.
commented by girisadresim (2024-12-12 05:14:42+00:00): Ich stimme zu, dass die Daten in OpenStreetMap (OSM) die Realität so genau wie möglich widerspiegeln sollten. Dennoch stellt sich die Frage, wie wir das Gleichgewicht zwischen visueller Darstellung und praktischer Datennutzung finden können.

1. **Bauliche Trennung**  
   Eine bauliche Trennung darzustellen, die in der Realität nicht existiert, kann in der Tat irreführend sein. Andererseits könnten solche Daten für spezifische Anwendungsfälle (z. B. Navigation) durchaus nützlich sein. Wichtig ist, dass wir Lösungen finden, die die Realität korrekt abbilden und gleichzeitig praxisnah sind.

2. **JOSM und OSMAnd**  
   Es stimmt, dass JOSM kein Analysetool ist und dass die Unterstützung für das Tag *placement* derzeit begrenzt ist. Dennoch können neue Tags und Konzepte durch die aktive Unterstützung der Community in Zukunft größere Akzeptanz finden. Es wäre sinnvoll, solche Tags zunächst in kleineren Projekten zu testen, bevor sie breiter angewendet werden.

3. **Sperrflächen**  
   Eine optisch präzise Darstellung darf niemals auf Kosten der Datenintegrität gehen. Der Vorschlag, einzelne Wege mit detaillierten Attributen und Spuren zu versehen, scheint eine praktikable Lösung zu sein, um die tatsächliche Geometrie der Straße nicht zu verfälschen. Gleichzeitig sollten wir überlegen, ob es alternative Methoden oder neue Tags gibt, um Sperrflächen effektiv und gleichzeitig realitätsgetreu darzustellen.

Insgesamt denke ich, dass ein Ansatz, der sowohl die Datenintegrität bewahrt als auch die Nutzbarkeit erhöht, ideal wäre. Dies erfordert jedoch eine offene Diskussion in der Community sowie die Bereitschaft, neue Ansätze zu entwickeln und auszuprobieren.
commented by ASRvwde (2024-12-12 05:42:11+00:00): Moin.
Das Navigationsproblem mit der Ansage, links auf die B 229 einzuordnen / zu fahren, ist inzwischen behoben. Das beruhte schlicht darauf, dass die Straße in dem Bereich zwar mit Lanes getaggt war, aber die Destination nicht. Ein Problem was ebenfalls im Bereich der Kreuzung Ringstraße in Lennep bestand. Beide habe ich entsprechend korrigiert und auch die Navigation entsprechend gestestet, funzt jetzt fehlerfrei.

Was allerdings die sowohl in OSMand wie auch iD dargestellte Einengung der Fahrbahn auf der Nordseite auf den westlichen 300m angeht: Weiter östlich, zwischen Schmalenbach und Umgehung Halver hat die Straße die gleiche Spurverteilung, aber nicht dieses Problem. Und gut 100 Straßen gleicher Spurverteilung, die ich in den letzten Tagen im Editor gesehen oder draußen navigiert habe, haben dieses Problem auch nicht.

Ich habe inzwischen in einem Umkreis von 80 km diese seltsame Darstellung nirgendwo sonst gesehen. Das legt schon recht deutlich nahe, dass dieses Darstellungsfehler seine Ursache genau hier hat und hier irgendwas nicht so ist, wie auf all den anderen Straßen gleicher Spurverteilung, die allesamt eben korrekt dargestellt werden.

Davon ab: Klar macht es Sinn, neue Tags und Konzepte zu entwickeln und einzusetzen. Aber: Die sollten dann vorab mit allen, deren Software / Geräte diese später auch korrekt rendern muss, abgesprochen, dort implementiert und gestestet sein. Denn: Wenn Anwender von Navigationsgeräten und -systemen, die sich dort, wo sie unterwegs sind in der Regel eben nicht auskennen, durch fehlerhafte Darstellung fehlgeleitet werden oder in eine falsche Fahrspur geraten oder gar schlimmeres passiert, dann werden die nicht nur das Gerät schlecht reden, sondern OSM insgesamt. Und damit tut sich wirklich niemand einen Gefallen, oder?
commented by ASRvwde (2024-12-12 05:53:26+00:00): Machen wir es mal ganz simpel:

Wozu existieren die beiden?
1317379201
1317129852

Links und rechts davon funktioniert alles wunderbar. Warum als müssen die hier unbedingt sein?
commented by Negreheb (2024-12-12 07:13:44+00:00): > s Sinn, neue Tags und Konzepte zu entwickeln und einzusetzen. Aber: Die sollten dann vorab mit allen, deren Software / Geräte diese später auch korrekt rendern muss, abgesprochen, dort implementiert und gestestet sein. 

Nein. 

Und nochmal, die Darstellung ist zu ignorieren. Nur weils nicht toll aussieht, können die Daten dahinter richtig aussehen. Das muss der Renderer richten. Ebenso wie der Router sein Routing richten muss, wenn(!) die Daten dahinter richtig sind.

Das Problem ist, es gibt halt gefühlt 378 Renderer und 37 Routing-Engines. Deswegen gibt es ja auch den Grundsatz "Kein Mapping für den Renderer" und erweitert könnte man sagen "und für den Router". Dann würde OSM nicht mehr wirklich funktionieren, wenn man das machen würde. 

Ich habe das Gefühl, dass diese Diskussion ins Forum sollte - da gibt es dann auch mehr Einblicke von anderen, die vielleicht da mehr Ahnung haben.
commented by Im Fokus (2025-06-26 12:40:54+00:00): Wo das Hinweis-Fähnchen steht, gibt es bei mir keine Verengung (mehr). Ist der Hinweis also inzwischen erledigt?
closed by ASRvwde (2025-06-26 20:59:55+00:00): Jo. Scheint sich erledigt zu haben.
opened by Mateusz Konieczny (2024-10-24 16:35:03+00:00): https://www.openstreetmap.org/way/563677472/history has cc = rura

What was intended to express by using this unusual key? Is this tag needed?
Or maybe can it be expressed in a more typical way that would be easier to understand?
Or maybe this key can and should be documented as useful tagging schema?
opened by qwertzMA (2024-10-24 16:35:38+00:00): Unable to answer "What is the widest gap one can pass through here?" – Block – https://osm.org/node/558065041 via StreetComplete 59.2:

Kein Poller begrenzt den Durchgang.

Attached photo(s):
https://westnordost.de/p/247977.jpg
commented by cuzi (2024-10-25 08:40:25+00:00): Aktuell ist da ein "Block" als Barriere eingetragen. Auf dem Luftbild ist auch kein Block erkennbar, aber an der Einmündung scheinen Poller zwischen Straße und Gehweg zu stehen. Stimmt das?
commented by qwertzMA (2024-10-25 08:58:52+00:00): Das stimmt. Diese Poller grenzen den Gehweg zur Straße ab. Sie behindern allerdings nicht den Durchgang.
closed by cuzi (2024-10-25 09:13:43+00:00): Ok, habe es so geändert, danke.
opened by Geovelo_Notes (2024-10-24 16:36:12+00:00): Double sens cyclable
Petite rue de la rize (This note has been created from Geovelo: https://amenagements-cyclables.fr/fr/contributions/81195)
commented by Geovelo_Notes (2024-11-28 11:15:32+00:00): Un commentaire a été ajouté par un cycliste Geovelo : "Bonjour
est-ce qu'un il y a un panneau indiquant "interdit sauf vélo "ou des marquages au sol ? Merci"
commented by Geovelo_Notes (2024-11-28 11:25:45+00:00): Un commentaire a été ajouté par un cycliste Geovelo : "En sortie de rue (entrée voiture) il y a un vélo en marquage au sol en contre sens
Rien de notifié à l'entrée (sortie voiture)"
opened by Mateusz Konieczny (2024-10-24 16:36:42+00:00): https://www.openstreetmap.org/node/11280686890

Is "Chattogram" really a part of its actual name? It seems that someone put address description into name field
opened by Mateusz Konieczny (2024-10-24 16:37:24+00:00): https://www.openstreetmap.org/way/563746189/history has cc = rura

What was intended to express by using this unusual key? Is this tag needed?
Or maybe can it be expressed in a more typical way that would be easier to understand?
Or maybe this key can and should be documented as useful tagging schema?
opened by  (2024-10-24 16:39:02+00:00): Pridať domy a adresy v celej IBV Horná pažiť
closed by Dodko (2024-10-25 10:04:54+00:00): Pridané
https://overpass-api.de/achavi/?changeset=158329323
opened by Phil Koch (2024-10-24 16:40:12+00:00): This road is not East St. Rd 252. That is miles further south. This stretch (between Conservation Club Road and South Hickey Road) is named Hickey Road as per the google street view: https://www.google.com/maps/@39.4108353,-86.3040071,3a,75y,49.55h,65.45t/data=!3m7!1e1!3m5!1sg9wDYHRv4twFD4W4cUJDCA!2e0!6shttps:%2F%2Fstreetviewpixels-pa.googleapis.com%2Fv1%2Fthumbnail%3Fcb_client%3Dmaps_sv.tactile%26w%3D900%26h%3D600%26pitch%3D24.552650401471666%26panoid%3Dg9wDYHRv4twFD4W4cUJDCA%26yaw%3D49.55362795392714!7i16384!8i8192?coh=205410&entry=ttu&g_ep=EgoyMDI0MTAyMS4xIKXMDSoASAFQAw%3D%3D
closed by Hypsometric (2025-01-08 21:11:15+00:00): Thanks for the note. Unfortunately Google Maps cannot be used as a source of data. https://wiki.openstreetmap.org/wiki/Google
commented by Phil Koch (2025-07-31 14:44:57+00:00): This can be seen in the county GIS:
https://morganin.elevatemaps.io/#extent=3178707.803331728,3168707.803331728,1518222.3628642326,1513128.6128642326,2245
Reference parcel number: 	55-14-10-100-016.000-012
closed by dannmer (2025-07-31 15:18:37+00:00): updated, Esri address data showed South Hickey Road, added some houses and addresses
opened by  (2024-10-24 16:40:20+00:00): Hinweis zu Skigebiet "Homberg" bzw. gelegen am "Zum Homberg"; derzeitiger Name: "Mein Homberg" / alter Name: "Snow World Züschen": Betreiber ist lt. dieser Seite seit Juli 2024 insolvent: https://www.sauerlandkurier.de/hochsauerlandkreis/winterberg/insolvenz-winterberg-skigebiet-mein-homberg-sauerland-nrw-skifahren-zueschen-93231927.html
opened by joel1972 (2024-10-24 16:40:41+00:00): In context of overlay "Places" – https://osm.org/node/9573693962 via StreetComplete 59.2:

Punkt kann gelöscht werden, gibt es hier nicht (mehr).
opened by joel1972 (2024-10-24 16:42:43+00:00): In context of overlay "Places" – 3XM (Clothing Store) – https://osm.org/node/3669140268 via StreetComplete 59.2:

Öffnungszeiten Mo bis Samstag 10 bis 19 Uhr
opened by  (2024-10-24 16:43:09+00:00): Staring point of the trail
closed by Fjellrev (2024-10-27 08:29:05+00:00): Personal note without any use for updating the map
opened by  (2024-10-24 16:44:07+00:00): End point of the trail
closed by Fjellrev (2024-10-27 08:28:52+00:00): Personal note without any use for updating the map
opened by Osmwithspace (2024-10-24 16:44:08+00:00): Beschränkungen des Straßenabschnitts siehe Foto.

via StreetComplete_ee 59.2

Attached photo(s):
https://westnordost.de/p/247978.jpg
closed by Osmwithspace (2024-11-17 08:59:30+00:00): https://www.openstreetmap.org/changeset/159233550
opened by fettsack (2024-10-24 16:49:25+00:00): Unable to answer "Are credit or debit cards accepted here?" – Sama Beirut (Fast Food) – https://osm.org/node/11687802227 via StreetComplete 59.2:

Zahlung bar oder mit PayPal
closed by kjon (2024-10-26 19:42:13+00:00): fixed
opened by  (2024-10-24 16:52:24+00:00): ponte du Gama NE
closed by DressyPear4 (2024-11-01 13:25:12+00:00): Ponto irrelevante
opened by ASRvwde (2024-10-24 16:53:08+00:00): Hier führt eine Treppe mit Geländer den Hang hinaus zu einem Tor, vgl. https://ogy.de/fyh4
closed by RubenKelevra (2024-11-25 12:46:24+00:00): Eingetragen: https://www.openstreetmap.org/changeset/159571923
opened by mtexaco (2024-10-24 16:54:03+00:00): Unable to answer "What can be left here for recycling?" – Limasam (Recycling Bin) – https://osm.org/node/9592692704 via StreetComplete 59.2:

Es una papelera

Attached photo(s):
https://westnordost.de/p/247984.jpg
https://westnordost.de/p/247985.jpg
closed by dcapillae (2024-10-24 17:37:58+00:00): Actualizado. Gracias por la nota
opened by  (2024-10-24 16:54:06+00:00): Ponte de Gama NW
closed by DressyPear4 (2024-11-01 13:25:27+00:00): Ponto irrelevante
opened by  (2024-10-24 16:54:52+00:00): Keine Verbindung von Neue-Heimat-Gasse und Bergmannsgasse an dieser Stelle.
closed by wolfgang8 (2024-10-24 18:23:33+00:00): https://www.openstreetmap.org/changeset/158308694
opened by MrIndianaJones (2024-10-24 16:54:58+00:00): 241 Kahawa Sukari Avenue
opened by tbo47 (2024-10-24 16:55:05+00:00): 325

#OsmAnd
opened by tbo47 (2024-10-24 16:55:06+00:00): 275

#OsmAnd
opened by tbo47 (2024-10-24 16:55:06+00:00): 266

#OsmAnd
opened by tbo47 (2024-10-24 16:55:07+00:00): 256

#OsmAnd
opened by tbo47 (2024-10-24 16:55:07+00:00): 246

#OsmAnd
opened by tbo47 (2024-10-24 16:55:08+00:00): 195

#OsmAnd
opened by gurglypipe (2024-10-24 16:59:16+00:00): New unmarked crossing, tactile paving, kerb a bit higher than road

via StreetComplete 59.2
closed by gurglypipe (2024-10-24 18:13:38+00:00): Added in https://www.openstreetmap.org/changeset/158308351
opened by Kays (2024-10-24 16:59:39+00:00): solar power plant (under construction)
commented by Stahlmann (2024-12-03 17:43:10+00:00): That's right and already mapped partly
opened by  (2024-10-24 16:59:51+00:00): die Brücke heisst Schönerlinder Brücke

siehe 
https://viz.berlin.de/en/aktuelle-meldungen/dauerhafte-einschrankungen-auf-der-schonerlinder-brucke-uber-die-a114/
closed by kjon (2024-11-04 21:05:25+00:00): fixed
opened by BON2BOS (2024-10-24 17:00:04+00:00): Clipper City Rail Trail connects along Parker St through the rotary. Recent project extends the shared use path, and adds new crosswalks to cross Route 1.
opened by  (2024-10-24 17:00:58+00:00): Tesco mobile
closed by OSM Warrior (2025-10-30 09:56:46+00:00): added to map https://www.openstreetmap.org/changeset/173967101
opened by Sukray (2024-10-24 17:01:41+00:00): Mata ikan