piebro/osm-data huggingface dataset:
Alex798 (2024-08-02 09:19:44+00:00): Okay, danke für den Input, dann nehme ich die Ampeln und und die gesamte Baustelle einfach wieder raus.
ManuelB701 (2024-08-02 11:31:19+00:00): Ich würde dennoch die Ampeln an der Stelle beibehalten, da die Baustelle an der Stelle längerfristig (für 9 Monate) andauern.

@309_308_307 Wenn die Ampeln nur existieren, um den Verkehrsfluss zu steuern (d.h. kurzzeitig in die eine Richtung, dann in die andere Richtung) dann ist es sehr wohl ein "oneway=alternating".
309_308_307 (2024-08-02 11:53:44+00:00): Ich hab mir die Seite im Wiki angeschaut und da wurden denke ich zwei verschiedene Sachen zusammengeschmissen.

Es gibt Straßen (ich kenne das hauptsächlich von den Alpen) die nur einspurig sind und wo der Verkehr per Ampel so geregelt wird dass nur abwechselnd in eine Richtung gefahren werden kann, z. B. der Gebirgspass Staller Sattel oder der Munt-la-Schera-Tunnel. Dort muss man dann 15 bzw. 30 Minuten warten bis die Fahrtrichtung umgedreht wird. Da ist es sinnvoll wenn die Wartezeit bei der Routenplanung berücksichtigt und die Reisezeit entsprechend berechnet wird. Für diese Fälle ist so ein Tag dann richtig sinnvoll.

Eine Baustellenampel ist etwas anderes. Da muss man in der Regel keine 15 bis 30 Minuten warten bis die Fahrtrichtung umgedreht wird. Es ist eigentlich wie eine Verkehrsampel mit ggfs. etwas längerer Rotphase. Dadurch dass aber beides in einem Tag zusammengeschmissen wurde denkt der Router gleich "oh gott, ich muss hier 30 Minuten warten" und versucht dann eben durch die Altstadt mit Spielstraße zu fahren weil das aus Sicht des Routers schneller ist. Und da liegt eben der Unterschied zu den Alpenpässen wo es häufig gar keine Alternative gibt und man die Wartezeit in Kauf nimmt.
Und dann gibt es in der Presse Beschwerden über OSM wenn die Fahrer tatsächlich entsprechend des Routenvorschlags durch die Spielstraße fahren und die Anwohner unter Lärm und Verkehrsaufkommen leiden.

Das ist nur mein Gedanke dazu. Ich halte gar nichts davon Baustellenampeln zu taggen, schon gar nicht mit einem Tag für Alpenpässe.
Alex798 (2024-08-02 19:33:41+00:00): Also durch die Altstadt und die Spielstraße, die auch ein Schulweg für eine Grundschule ist, sollte auf keinen Fall dadurch geroutet werden. Am Ende verirren sich da noch LKW und fahren sich fest...
Ich habe soweit den Ausgangszustand widerhergestellt.
Passt das so, wie es jetzt ist? Also v.a., dass nicht mehr durch die Spielstraße geroutet wird?
ManuelB701 (2024-08-04 05:46:41+00:00): @309_308_307: Ich glaube nicht, dass der Nutzen davon verwechselt wird. Das Wiki nennt "Straßenbaustellen" als einier der Nutzen davon, zusammen mit schmale Brücken aber irgendwelche "Alpenengpässe" (vielleicht verwechselst nicht DU irgendwelche Konzepte).
Außerdem sagt oneway=alternating auch an sich nichts sagt, wie lange in eine Richtung geschaltet wird, nur DASS so etwas existiert. Tastächlich glaube ich auch nicht, dass mind. 15 Minuten zu warten auch der Standard ist und nur bei längere Abschnitten vorkommt während die Baustelle eben kurz ist und die Schaltung alle 5 Minuten kommt (was eher der Fall sei).
Ich glaube kaum, dass Router bei oneway=alternating automatisch durch den Kirchplatz führen, da dieser indirekter und eben verkehrsberuhigt ist.

Zum kontext: In Nierstein gibt es ebenfalls eine solche Regelung (K45 Oberdorfstraße). Alle drei Router führen die Autos immer noch durch diese anstelle in das nahegelegende Fronhof, trotz keiner allgemeinen Zugriffsregelung letzterer (und das ist eine Wohn- und keine Spielstraße und wird somit stärker von Routern gewichtet als hier).

PS: Die Baustelle dauert über 9 Monate an, da ist es schon m.M.n. sinvoll, die Baustelle zu taggen.
KarttaMursu (2024-08-01 13:50:52+00:00): Hei nimumane!

Huomasin tarkastuspyyntösi ja muutoksiasi katseltuani huomasin, että olit lisännyt Näsinpuistolle pisteen. Pistettä ei mielestäni tarvitsisi, sillä koko Näsinpuiston kattava Park-alue sisältää jo nimen. Nyt Näsinpuistoa hakemalla löytyy kaksi tulosta, joka tuskin on toivottavaa.

Myös lisäämäsi nimi Torpparinpuiston Natural Wood-alueelle johtaa sen löytymiseen kahdesti. Käsittääkseni Torpparinpuiston pitäisi kattaa jo aiemmin merkityn Park-alueen sekä nimeämäsi Natural Wood-alueen. Tämän suhteen nimen voisi kenties jättää paikalleen, kunnes joku osaavampi muokkaisi koko alueen yhdeksi Torpparinpuistoksi.
nimumane (2024-08-01 16:14:53+00:00): Kiitos havainnosta. Poistin Näsinpuiston pisteen, mutta park-alueen nimi ei näy.
KarttaMursu (2024-08-01 17:25:38+00:00): Aivan, nimeä ei nyt tosiaan näy.

Ongelma on varmaankin tavassa millä karttatilet renderöidään. Yleinen käytäntö taitaa olla, ettei tietoa kartoitettaisi useaan kertaan vaikka renderöinnissä olisikin ongelmia. Tulee mieleen artikkeli OSM-wikistä, joka on vähän tähän ongelmaan liittyvä (vaikka keskittyykin väärään tietoon, josta ei tässä tapauksessa ole kyse): https://wiki.openstreetmap.org/wiki/Tagging_for_the_renderer

Kenties poikkeuksiakin voi tehdä. En ole täysin varma tälläisessä tilanteessa.
Aleksandar Matejevic (2024-08-01 14:16:15+00:00): Hi osminng, 
you have created a lot of admin_level=7 relations while creating island multipolygons of islands in Greece. Why have you been creating relations of islands while they were already tagged on a way?
osminng (2024-08-01 16:40:57+00:00): Hi Aleksander,

admin_level=7 was already on these ways (in many cases without its boundary=administrative pair tag)

During multipolygonization, all these values were kept, as it might had been put there with a purpose of the original editor. 

If they doesn't fit according to someone's local knowledge (of the Greek admin system of such small island), they can be challenged of course
osminng (2024-08-01 16:44:58+00:00): For other islands, where multipolygons were already used, the common practice was having all tags on the relation (e.g. name, place=island, wikidata, etc.), except the natural=coastline, which is kept on the way by default

JOSM's multipolygon creator actually function this way
Aleksandar Matejevic (2024-08-01 16:48:58+00:00): Yes, I am familiar with that, but why have you created relations for islands that are already tagged on a polygon?
osminng (2024-08-01 17:56:42+00:00): I see what you mean now. In those cases where only the way was present (without existing multipolygon relation for the island), JOSM carried out all the copying.

In those cases you mentioned, the standalone admin_level=* tag left on the way was put into the relation role. As it was the practice in case of other islands (where only natural=coastline and source=* was left on the way). Some examples: https://www.openstreetmap.org/relation/17825226 ; https://www.openstreetmap.org/relation/4143917 ; https://www.openstreetmap.org/relation/3591870 ; https://www.openstreetmap.org/relation/6914328 ;https://www.openstreetmap.org/relation/1815263 ) 

Examples (best practice?) were checked, as I haven't seen exact statement on this (https://wiki.openstreetmap.org/wiki/Tag:place%3Disland ; https://wiki.openstreetmap.org/wiki/Tag:natural%3Dcoastline ; https://wiki.openstreetmap.org/wiki/Relation:multipolygon ; https://wiki.openstreetmap.org/wiki/Relation:boundary)

If there is a consolidated approach on this and they should be kept on the way instead of the multipolygon relation, I'm glad to put them back.
Aleksandar Matejevic (2024-08-02 07:44:56+00:00): As you mentioned with tag [place=island](https://wiki.openstreetmap.org/wiki/Tag:place%3Disland) it should not be used on a relation but to be drawn as a counterclockwise area (because water is always on the right hand side). Relation should be created when the coastline is split into several smaller segments, for example, for creating smaller admin divisions or coastline of the island has more than 2000 nodes (for very detailed or large islands). Then you need a relation for the whole island. In some cases, the relation is used to group some close islands which have the same name but are not archipelagos. 
Another thing I want to point out: I am not saying that what you did is a unique example, but per OSM Wiki and some general mapping rules, we should not use relations for these simple small islands. I just stumped upon your edits because there is a fair amount of them, and I was in the region at the moment. 
Also, read this: Relations are not categories - OpenStreetMap Wiki
pitscheplatsch (2024-08-02 12:07:39+00:00): Should be reviewed by the local community. Thanks!
Fizzie-DWG (2025-03-14 03:02:07+00:00): Reverted by DWG - undiscussed OEG Import from unknown source

https://www.openstreetmap.org/changeset/163594729
GretaMN (2024-08-05 10:07:20+00:00): Liebe:r ChMenges,
bitte ergänze hier (https://www.openstreetmap.org/way/1295712407) die Eigenschaften des Straßenschildes. Und bitte überarbeite auf allen Abschnitten für die das Straßenschild DE:240 gilt die highway Angabe. Beim richigen Tagging für Verkehresschilder kann dieses Tool helfen: https://osmtools.de/traffic_signs/.
Danke! :)
#lgmaps
GretaMN (2024-08-05 10:10:33+00:00): P.S. Und bitte ergänze noch die Breite des Weges für ein vollständiges Tagging.
Mateusz Konieczny (2026-01-29 13:30:36+00:00): Hello! https://www.openstreetmap.org/node/12087027186/history has shop = garden_decoration that was added in this edit
Is it shop=garden_centre ? If not, how it differs from shop=garden_centre? See https://wiki.openstreetmap.org/wiki/Tag:shop=garden_centre
BCNorwich (2024-08-01 15:25:34+00:00): Hello, Welcome to OpenStreetMap.

OSM had the highway tagged as a track, third party apps are to blame for your problems. OSM has not implied that the track is a "public footpath/bridleway/permissive path". Your grievance ought to be taken up with apps that lay false claims about access to your track.

I've amended the tags to access=agricultural, foot=no, highway=track, vehicle=private. I've added the gates at each end as well taging them as access=private, barrier=gate, foot=no, vehicle=private. With this tagging OSM would consider there to be no public access whatever.

Regards Bernard.
BCNorwich (2024-08-01 15:29:01+00:00): I forgot to say OSM only uses formal verifiable names, thus I've removed the name.
BCNorwich (2024-08-01 16:09:55+00:00): The section joining to the roundabout is part of a cycleway route.
Dimitar155 (2026-04-15 19:58:20+00:00): Вече имаме нови снимки от МЗХ. На тях се виждат новия паркинг и новата сграда.
mcliquid (2024-08-01 13:12:42+00:00): Danke dir!
BCNorwich (2024-08-01 17:16:36+00:00): Hi, You somehow added duplicated footpaths. I've removed the duplications and tweaked the path line to the definitive line as shown on the Highway Authority website. I added the appropriate tags for a PRoW. The crossfield section of path is removed.
BCNorwich (2024-08-01 17:17:53+00:00): Duplicated paths removed.
Endres Pelka (2024-08-02 18:23:56+00:00): These giant, island-wide multipolygons:
relation 13087932 (landuse=residential) and relation 13104906 (landuse=grass) should be cut up into independent polygons sometime... It doesn't make any sense keeping them like this.
Silva1989 (2024-08-12 20:30:49+00:00): Hello Endres,
Thanks for your insights. In fact, the multipolygons have been growing in members over time.
I already started implementing a multipolygon separation workflow, in order to make the multipolygons smaller.
For now, the idea is to have a multipolygon per parish. That's going to make things better.
Thank you
Friendly_Ghost (2024-08-25 23:26:22+00:00): I can help you to split up the large multipolygons. 

Why are they so huge in the first place? Wouldn't it make more sense to turn them into closed ways, one for each individual area?
Silva1989 (2024-08-26 10:40:19+00:00): Hello Friendly_Ghost,
Thanks for commenting this changeset.
I've been mapping Faial island over the last 9 years as a leisure activity on free time. At such a scale, you can see that at some point some growing pains are going to occur and consequently, a mapping style had to be implemented in order to make the database more maintainable and scalable. This is a continuous process.
Individual areas are effective and simple to implement, but much less scalable and maintainable. Imagine that you have a forest next to a meadow. There's now a duplicate line, sharing the same geometry. Add a wall or fence between the two, now it's a triple line. Now imagine that somewhere in the future someone build a house that occupies part of the meadow next to said forest. That'd be a big challenge to unglue things and then map the house's residential area. That's a situation where multipolygons can be very powerful. You can easily map at scale. You set a forest tag scheme for a eucalyptus forest for instance, and you just need to add the corresponding loops to the multipolygon. No need to tag every tag to every area every time.
The multipolygons became bigger over time as mapping naturally progressed. What's a big multipolygon to you? These follow the complex combination of features as described in
https://wiki.openstreetmap.org/wiki/Relation:multipolygon#Members
There doesn't seem to be a limit to the number of members, but I can see that doing multipolygon geometry validation on some computers would be very slow.
I'm currently transitioning into one multipolygon per parish in Faial island. This process is happening as I map, but feel free to help! But please don't split a multipolygon with thousands of rings into thousands of multipolygons, as It'd make editing in JOSM close to impossible, as the user would have to endlessly scroll on the relations panel.
Good mapping
Thanks
Friendly_Ghost (2024-08-26 19:53:45+00:00): Thank you very much for providing this detailed insight into your workflow. 

You mentioned how overlapping edges of ways would be challenging to unglue, but I don't see how this would be true. With a simple alt + left-click on the edge in JOSM you can easily select the next object in cases of overlap. It's not like you'll ever see five or more ways with overlapping edges, so I don't see how this would be a limiting factor to your (or anyone’s workflow).

On the other hand, these very large multipolygons are an issue for many mappers and data users alike. This method of mapping violates the "One feature, one OSM element" principle we have, which dictates that each field should be represented by its own polygon, where you have mapped all fields together as a single object. This gives data analysts the wrong idea that there are only a handful of landuse polygons mapped on the entire island, while the map clearly shows thousands of polygons. It’s also a substantial problem for other all other OSM mappers, who have never mapped like this, might fail to understand the complexity of these multipolygons and will undoubtly have trouble loading the data into their editors. 

We do have a technical limit imposed on the number of members in a relation, although you’re not likely to hit that anytime soon: https://wiki.openstreetmap.org/wiki/Relation#Size. This Wiki page also recommends keeping relations small whenever possible. 

My suggestion to you is that you change your mapping style to work with lines and areas that may have overlapping edges. This will improve the map for users and will make it easier for other mappers to contribute. 

I (together with several mappers that I spoke to on Discord) would also like to see the existing multipolygons being converted into closed ways with the exception of cases where multipolygons are strictly necessary. If this is technically challenging for you, I’ll be happy to lend a hand, as I have experience with reconstructing large and complex multipolygons.

Let me know what you think of this, so we can figure out a plan that can satisfy everyone.

Best regards,

Casper
Silva1989 (2024-08-29 11:23:31+00:00): Hello Casper,

I will change my mapping style according to your suggestions.
My intent is to map according to the best practices.
Feel free to help, I will do what I can as well but it will take time to rearrange everything as there's a lot of data to manipulate and not so much free time.
Thanks
flohoff (2024-08-02 07:50:12+00:00): Moin,
ich habe da mal fragen:

https://tmp.zz.de/20240802-SubleaseEarthy/Screenshot_from_2024-08-02_09-49-04.png

Hier hast du das residential verkleinert und oben und unten das dreieck abgespalten - Das ist doch aber deren Garten? Das ist und bleibt doch dann residential?!?

Und dazu geht der landuse split mitten durch das Gebäude - das sieht irgendwie nicht gesund aus.

Flo
BCNorwich (2024-08-01 17:18:49+00:00): Duplicate paths removed.
BCNorwich (2024-08-01 17:20:19+00:00): Duplicated paths removed.
NorthCrab_upload (2024-08-01 12:00:27+00:00): Zauważyłem, że Twoja zmiana zawiera niepoprawne adresy. Przygotowałem listę obiektów do poprawy oraz dodatkowe informacje:

Adres jest niekompletny, brakuje informacji o nazwie ulicy. Jeśli adres ma nazwę ulicy, dodaj ją w addr:street. Jeśli nie, zamień addr:city na addr:place - tak oznaczamy adresy bez ulic.
https://www.openstreetmap.org/way/1204807595

Dokumentacja adresów (po polsku):
https://wiki.openstreetmap.org/wiki/Pl:Key:addr:*

W razie problemów lub pytań, proszę pisać. Chętnie pomogę.
Pozdrawiam! 🦀
flohoff (2024-08-01 13:12:50+00:00): Moin,
ich hab hier deinen changeset gerade gesehen. Ich weiss das da an der Ecke ein Kinderspielplatz entstanden ist. Deine Schaukel ist jetzt aber "ausserhalb" der Fläche des Spielplatzes. Ist das richtig? Ich denke der SPielplatz ist größer als aktuell eingezeichnet oder?

Flo
rskedgell (2024-08-01 12:32:13+00:00): For residential gardens, you might find that leisure=garden + garden:type=residential + access=private works better than landuse=grass.

If you're going to micromap planted areas in private gardens, landuse=flowerbed (rendered in Carto) or natural=shrubbery (not currently rendered) are better than natural=scrub.

https://wiki.openstreetmap.org/wiki/Tag:leisure%3Dgarden
https://wiki.openstreetmap.org/wiki/Tag:landuse%3Dflowerbed
https://wiki.openstreetmap.org/wiki/Tag:natural%3Dshrubbery
eggie (2024-08-01 12:13:29+00:00): Dag Gerben Hoe kom je erbij dat dit deel een tunnel zou zijn?

MVG
eggie
eggie (2024-08-01 12:17:02+00:00): Gerben ik heb de tunnel omgezet naar cutting=yes
Ook straatnaam toegevoegd.
Groet
eggie
GerbenV2 (2024-08-01 12:17:37+00:00): Hallo Eggie, Je hebt gelijk, dit deel is nog de weg ernaartoe. En geen tunnel idd.
eggie (2024-08-01 12:27:16+00:00): 'k Vraag me zelfs af of dit een fietspad is. 
Denk eerder een highway=path
Het eerste stukje is een doodlopende highway=residential 
tot het paaltje. Het is een doodlopende weg muv tweewielers.
DE rest zal een highway=path zijn met foot=yes moped=yes mofa=yes bicycle=yes

Maar wellicht is het een fietspad geworden?
https://smoothefiets.ddns.net/html/verkeersbordenkaart/index.php?lat=51.531841015&lng=5.985531807&z=17
Laatste check 2021 door de gemeente.

Je zou de weg kunnen splitsen bij de bollard en dan het wegtype aanpassen Ook surfacetag toevoegen, want anders ziet de router het als onverhard. 
surface= paving_stones en gedeeltelijk asphalt?
Groet
eggie
eggie (2024-08-01 13:34:48+00:00): Ik heb het aangepast naar highway=path en residential. Bron Obliekfoto  18-04-2024  Slagboom&Peeters
Roelieboelie (2024-10-27 17:20:33+00:00): Dit is absoluut hier in de regio een fietspad. Zelfs deels met een stoepje ernaast. Liever fietspad taggen...?
eggie (2024-10-27 18:04:23+00:00): Hoi,
Ik heb er een fietspad van gemaakt.
Groet
eggie
eggie (2024-10-27 18:11:10+00:00): Roelieboelie,
Voor wie staat dat fietspad open?
Welk bord staat er vooraan?

Groet
eggie
Roelieboelie (2024-10-27 18:32:47+00:00): Nou, het stomme is dat er dus geen enkel bord staat. De weg inrichting is echt wel zo gemaakt als fietspad (asfalt) met daar langs een voetpad (bestrating). Kijk maar eens beide zijde op Streetview. Dat tunneltje word eigenlijk ook alleen maar als fietspad gebruikt door iedereen met 2 wielen (mofa..mopa..) voetgangers lopen vaak om (eng tunneltje). Ik zou het lekker cycleway houden met voetpad aan 1 zijde. Mocht er ooit een duidelijk bord komen dan passen we het direct aan. Het doodlopende bord rode T impliceert misschien zelfs unclassiefied of residential, maar dat gaat me te ver...
eggie (2024-10-27 18:42:51+00:00): We laten het fietspad... Ducktagging.
Het kwaakt als eend dus is het eend.
Het eerste stuk is tot het paaltje een residential. Daar is nog een oprit voor nr 20.
Dat verder als een ducktagging fietspad.
Lijkt me een goede oplossing.
Denk wel dat er dan mofa = en moped = designated erbij moeten maar dan zonder g12a bord?
Toevoegen?
Roelieboelie (2024-10-27 18:52:06+00:00): Keep it simple is mijn persoonlijke voorkeur bij dit soort vreemde eend in de bijt weggetjes. Maar ik ga absoluut niet tegen jou voorstel in. Jij mag hem voeren om te kijken of ie hapt.
eggie (2024-10-27 18:57:06+00:00): Hap zei die....
Roelieboelie (2024-10-27 19:04:16+00:00): Super! Fijn dat we het op deze manier hebben opgelost! Alle eendjes zwemmen in het water .....
BCNorwich (2024-08-05 08:03:55+00:00): Duplicated highway removed, public footpath aligned and tagged.
BCNorwich (2024-08-05 08:06:40+00:00): A second duplicated section removed.
Spaghetti Monster🍝 (2025-10-10 08:52:13+00:00): The bridge should not be connected to the road it crosses.
            ---
            #REVIEWED_BAD #OSMCHA
            Published using OSMCha: https://osmcha.org/changesets/154692517
messpert (2025-05-19 20:17:38+00:00): Although you did not originally map these paths/footways, most really do not exist in any meaningfull way.
Especially 841759797. 
These routes vary from year to year and even month to month and are mainly sheep tracks. It is misleading and even dangerous to suggest that someone lost in low cloud or whatever will be able to find a clearly defined path.

I have known and mapped this area over many years so have local knowledge.
Solderdot (2025-05-20 05:17:21+00:00): Hi, 
well, I just added the surface. 
IMHO it's quite a good thing to have the paths on the map. Even if they are not at exact positions they allow for a general planning of a hike. The map shows that in general it is possible to get from A to B, how that is to be done in detail you see only when you reach the spot. Quite normal, from my perspective. 
But since you are the local and I'm just a tourist I would not object if you removed the tracks.
geo_thom (2024-08-07 17:43:20+00:00): Hallo "Tourist Info Aschau i.Ch.",
das hinzufügen von zusätzlichen Nodes wie in dem anderen Changeset (https://www.openstreetmap.org/changeset/154693316) ist nicht nötig, da bereits beide Spielplätze seit längerer Zeit korrekt eingetragen sind!

Hier ist bspw. der Spielplatz schon eingetragen in seiner flächenmäßigen Ausbreitung (https://www.openstreetmap.org/way/1019375986) mit dem korrekten Tag leisure=playground. Der zusätzliche Node mit leisure=park und name=Spielplatz ist falsch, da Spielplätze so nicht getaggt werden. Außerdem wird in name=... wirklich nur der Name erfasst. 

Bitte die beiden Einträge löschen und für zusätzliche Einträge dem Wiki die korrekten Tags entnehmen. Anderenfalls sollte auch der Editor (ID) beim hinzfügen eines Punktes und Eingabe von Spielplatz die richtigen Tags setzen.

Viele Grüße
aharvey (2024-09-19 00:41:34+00:00): Hi, I just wanted to point out that SIX Maps still include some non CC BY terms https://maps.six.nsw.gov.au/js/sixmaps/app/coreTerms.html which we'd prefer to err on the side of caution and not use directly.
The data via https://www.spatial.nsw.gov.au/products_and_services/web_services and the Spatial Collaboration Portal for example https://portal.spatial.nsw.gov.au/portal/home/item.html?id=01de8834e88a45a1a673b120aa00c82e is explicitly covered by CC BY 4.0 and the OSMF CC BY waiver we have, so a safer choice. I realise it's likely the same data so in this case it's okay.
NorthCrab_upload (2024-08-01 13:20:25+00:00): Zauważyłem, że Twoja zmiana zawiera niepoprawne adresy. Przygotowałem listę obiektów do poprawy oraz dodatkowe informacje:

Adres jest niekompletny, brakuje informacji o nazwie ulicy.
https://www.openstreetmap.org/way/1305050690

Pozdrawiam! 🦀
flohoff (2024-08-02 07:48:12+00:00): Moin,
mit dem seasonal - Werden die wirklich im Winter weggeräumt?

Flo
Buschmann (2024-08-02 08:07:12+00:00): Ja, werden sie. Sowohl der Picnic-Tisch mit Bank als auch diese Wellenliegen (oder wie die heißen).