piebro/osm-data huggingface dataset:
emvee (2022-11-08 22:33:54+00:00): Yes, I did also some work to get campings in Europe cleaned up and a part of that is this change-set. Good to see you have a common interest.

I still see no reason why for this case a tourism=camp_site inside a tourism=camp_site is a good idea. 

If I read https://wiki.openstreetmap.org/wiki/Tag:tourism%3Dcamp_site, it describes the whole camp site including toilets, beaches and swimming pools and based on this I would say the site relation should be tagged with tourism=camp_site but the node not. Looking at it now, that is not what I did in this changeset.

The problem is indeed what kind of tag to give the nodes. If I read https://www.trekking-pfalz.de/service/faqs, I see only one tent is allowed so why not tourism=camp_pitch?
giggls (2022-11-09 17:03:09+00:00): We are not talking backcountry only sites here but tourist sites also. I will show you another example from the ones you broke in my map.

Have a look at the following site relation (currently with tourism=camp_site tag removed by your changeset):
https://www.openstreetmap.org/relation/13179921

The polygon here is clearly a camp-site rather than a pitch.

In fact josm would even give me errors if I would change this to tourism=camp_pitch because there would be lots of individual pitches inside a giant pitch then.

The members of the site relation are part of the camp-site as well but are located outside the polygon because they are also open to the general public.

I do not insist in taging the site relation *and* the polygon as tourism=camp_site but I do not know a better solution.

Abusing camp_pitch is not such a solution IMO, given the fact that the reason is compliance to a wiki page which even states that the principle they talk about there "is not absolute".

Fact is that my map is currently incomplete[1] because you removed the camp_site tagging of the site relation.
See here:
https://opencampingmap.org/#17/49.38275/9.83002/1/1/bef/way/757479565

I am open to better tagging ideas, but tagging camp_pitches inside camp_pitches is definitely not such a solution.

[1]Fast-food and playground are currently missing from my map.
emvee (2022-11-09 19:24:40+00:00): Okay, so for backcountry sites (6/15 of this commit), there is a solution.

I see your point of the problem with the site relation and a camp place for multiple tents/caravans but what I do not understand is:

> Fact is that my map is currently incomplete[1] because you removed the camp_site tagging of the site relation. 

Why? Instead of a relation=site with tourism=camp_site AND a node/way with tourism=camp_site that is part of the relation there is after my change only the node/way with tourism=camp_site

So instead of two camp_site's only one what is the "ground truth".

https://wiki.openstreetmap.org/wiki/Tag:tourism%3Dcamp_site clearly specifies that area mapped includes toilets and beaches so inside of using a poor supported site relation I would go for a mapped area as  tourism=camp_site including the parking spaces, reception and restaurant, see also the picture on the last page of https://www.waldcamping-hollenbacher-see.de/wp-content/uploads/2021/03/Waldcamping_Flyer_2021.pdf 

If you want to explicitly indicate that the cafe/playground/restaurant are also open to the general public then add "access=yes" to these objects.
giggls (2022-11-09 19:49:22+00:00): Did you even try to understand the problem I try to solve using site relations? Did you read my blogpost?

You broke my map and you are not providing me a reasonable tagging Alternative :(

Camp-sites with external features like showers, toilets etc. do exist in the wild and I think it is good to have a solution at hand to map this.
emvee (2022-11-09 21:31:53+00:00): Yes, I did read your blogpost, https://blog.geggus.net/2021/09/announcing-support-for-site-relations-in-opencampingmap/, quoting "On backcountry campsites there is often no well defined boundary. "

I did reply on that in the first alinea of my previous reply.

You are telling me multiple times I did break your map but you are not answering the question I did raise on that in my previous reply. It did solve the problem I saw.
giggls (2022-11-09 22:05:06+00:00): Will I really need to make a list of what is broken in all those objects.

However, it is quite easy. All the objects outside the polygon or in case of campsite_points all of them are not shown in my map as features of the campsite anymore as they are no longer related.

E.g. Hollenbacher See has no fast-food and no playground. Oh and they are not part of the fenced campsite area thus mapping them as inside the polygon is simply wrong on the ground.

Frankly I do not think that it is a good idea to use the "One feature, one OSM element" practise as a dogma if violating it does make sense as it is the case here.

P.S.: I would like to end this discussion in the changese and try to clarify this issue on the tagging Mailinglist. See my post there:
https://lists.openstreetmap.org/pipermail/tagging/2022-November/066389.html
giggls (2022-11-09 22:15:44+00:00): Oh now I seem to understand what you did not get yet. I do not consider a site relation representing an actual geometry of a campsite itself but forming a couple of scattered objects related to *the* site which is a member of the relation.

Thus in my map I just assign all the related objects types as a feature to the camp_site inside the relation.

My database table for drawing campsites does not contain site-relations anymore. They are just used for adding actual features to the sites (area or node) themselves.

E.g.: Site relation contains a restaurant -> Add restaurant=yes to node or area member tagged as tourism=camp_site

This is what breaks my map.
emvee (2022-11-12 07:18:03+00:00): > My database table for drawing campsites does not contain site-relations anymore.

That explains why you see it not as a problem, but to me it means that my change done in this changeset was not that strange. You do remove the site tourism=camp_site relations for your database, I think it is better to do that in the actual data.

I did read the tagging list, seems to me like there is no common support for tourism=cam_site relations.
giggls (2022-11-12 10:35:45+00:00): I do nor *remove* the site relations. I do evaluate them in a meaningfull way which means that they do not represent two camp-istes but onlytwo aspects of the same site.
emvee (2022-11-12 17:40:43+00:00): Sorry for using the word "removing" 🙃 You do some operation so that there are no two camp sites.

Wat is you conclusion form the tagging list discussion?
aTarom (2023-04-20 15:45:17+00:00): Hola, según el comentario de este changeset no cuadra con un raro
"tracktype"="grade24"
en
https://www.openstreetmap.org/way/498119540/history
¿Qué se intenta corregir en este caso?
Seraq (2023-04-21 10:43:42+00:00): Muchas gracias aTarom.

Solucionado.

Saludos,
Seraq
BG2ETV (2022-09-11 05:35:05+00:00): 已回退
Frans S (2022-10-07 10:24:43+00:00): Hello. I review chance sets at random.
a few remarks
* Pay more attention to accurate mapping over the rooflines. 
* Most buildings are strict rectangular. Please square them after you drawn it, and still selected, with the Q key. 
* Tagging of buildings. For HOTOSM projects, the standard tagging is 'building=yes' No text adding.  Please keep that in mind at further mappings.
Best regards
Glassman (2022-09-13 17:00:14+00:00): #TIP: add the wikidata as well as the wikipedia article. You can find wikidata Q code on the left hand panel in Wikipedia. The wikidata code is more permanent than the article name.
            ---
            
            Published using OSMCha: https://osmcha.org/changesets/126036395
Glassman (2022-09-13 17:00:35+00:00): #TIP: add the wikidata as well as the wikipedia article. You can find wikidata Q code on the left hand panel in Wikipedia. The wikidata code is more permanent than the article name.
            ---
            
            Published using OSMCha: https://osmcha.org/changesets/126036395
快乐的老鼠宝宝 (2022-09-11 11:37:02+00:00): Reverted in https://www.openstreetmap.org/changeset/126045682

提示一下：你要是想整个干净的纯路网地图，自己下载数据去渲染去。

要是直接动公开的公共数据，咱没完
快乐的老鼠宝宝 (2022-09-11 10:27:17+00:00): Reverted in https://www.openstreetmap.org/changeset/126043359
快乐的老鼠宝宝 (2022-09-11 10:26:46+00:00): Reverted in https://www.openstreetmap.org/changeset/126043352
快乐的老鼠宝宝 (2022-09-11 10:15:42+00:00): Reverted in https://www.openstreetmap.org/changeset/126043016
快乐的老鼠宝宝 (2022-09-11 10:59:20+00:00): Reverted in https://www.openstreetmap.org/changeset/126044419
nevw (2022-09-11 10:14:00+00:00): This is already mapped correctly.
https://www.openstreetmap.org/node/10015170847#map=18/-37.81636/144.85383
nevw (2022-09-11 10:18:42+00:00): fixed
快乐的老鼠宝宝 (2022-09-11 11:34:07+00:00): Reverted in https://www.openstreetmap.org/changeset/126045606
vasony (2023-02-16 08:40:58+00:00): Ez biztos, hogy k-val van és nem
Colorchemia lakótelep?
grozsa11 (2023-02-16 14:15:28+00:00): Bevallom nem emlékszem, hogy mi volt az utca (itt utcák) nevének pontos forrása... lehet hogy láttam egy táblát, de most kicsit próbáltam távolabbról utánaolvasni és mintha az lenne, hogy a régi hagyomásnyos írása a "környéknek" (buszmegálló, utca stb) az volt "Colorkémia", most meg mintha a "Colorchemia" lenne a legtöbb dolog nevében...  Van egy olyan érzésem, hogy föltehetően a hivatalos név is "chem" már és csak egy name_alt-ban kellene talán meghagyni a "kem"-est... de azt akár a buszmegálló nevére is rá lehetne írni, ott ugyanis egyértelműen úgy volt régen a volánbusz-megálló .. .
Mindenesetre talán a fenti lenne a jó, de az utcák nevére nem vagyok biztos a teendőben...  
Olvastam régen egy gázrobbanós ház-hír volt a telepen, akkor "Colorkémia" volt a cikkekben, de hát az lehet akár a name_alt is már...
vasony (2023-02-16 16:43:58+00:00): Földhivatal szerint pl:
PAPKESZI belterület 601		8182 PAPKESZI Colorchemia lakótelep 215/B.
Csak mielőtt módosítottad így is volt, ezért lenne jó emlékezni :)
vasony (2023-02-16 16:46:31+00:00): Pontosítok, a régi nevet is te vetted fel először ch-val, addig nem volt sehogy csak egy place node volt
grozsa11 (2023-02-16 20:53:41+00:00): Nos, akkor a "ch" a hivatalos ezek szerint, úgyhogy e szerint rendbehoztam, köszi! Gza
快乐的老鼠宝宝 (2022-09-11 10:03:01+00:00): Reverted in https://www.openstreetmap.org/changeset/126042542

（By http://revert.osmz.ru/7142）
literan (2022-09-11 11:19:36+00:00): добрый день. Вы дублируете существующий школы и детские сады (их теги уже стоят на зданиях). Это ошибка.

Согласно одному из базовых принципов OSM, один объект на местности - один объект в OSM.
literan (2022-09-11 15:39:04+00:00): здесь дубль кафе зачем-то сделали
kakiremora (2022-09-11 14:25:41+00:00): Geometria czego została zmieniona?

Zachęcam do bardziej opisowych nazw changesetów

Pozdrawiam
kukułka (2022-09-11 15:54:49+00:00): Geometria budynków Lastadia 2 i 41.
Słuszna zachęta, ale czasami boję się, że prądu zabraknie, więc szybko wysyłam ;)
Pozdrawiam
seewäldler (2025-08-11 20:37:36+00:00): Hallo mcliquid!

Weils mir gerade auffällt, ich glaube "deer" oder "wild animal(s)" sind auf dem  way 656284342 eher anzutreffel als "moose".
mcliquid (2025-08-12 14:40:24+00:00): Danke dir! Hab es hier geändert: https://www.openstreetmap.org/changeset/170345856

Referenz im Wiki: https://wiki.openstreetmap.org/wiki/Key:hazard:animal
gurglypipe (2022-09-12 08:33:53+00:00): Hi. I’ve removed this footpath way because it’s not necessary: the road way is already correctly tagged as being a public footpath, and there’s not a physically separate footpath apart from the road (as far as I know — please correct me if I’m wrong).

The foot=designated and designation=public_footpath tags on the road mean there’s a footpath right of way along it.

See https://wiki.openstreetmap.org/wiki/Tag:designation%3Dpublic_footpath for information

Thanks for your edits!
BCNorwich (2022-09-12 09:26:19+00:00): Hi, you've placed a long footpath Way: 1093514477 on top of existing highways. This is a duplication of highways which disrupts routing. Unfortunately, this is the second time you've inadvertently made this duplicate highway. I removed the first duplicate footpath 14 days ago. I tagged the existing service highways to reflect their public footpath status.

Thus I've now again removed the footpath. Please don't make duplicate highways, if a way needs amending it is the existing highway that should be amended. Thus the history of the existing ways are maintained.

Regards Bernard.
user_16720371 (2022-09-12 10:14:58+00:00): No problem, I wondered why it disappeared. Thanks for sorting.
eggie (2022-09-11 11:01:02+00:00): Hi ParDede

I merged your info with the present adressnode.
Your website http://deklaverhoeve@online.nl  was not correct. I fixed that.
Greetz,
eggie
Diacritic (2022-09-11 09:33:17+00:00): Hi Mlik Data.

In this edit, you've referred to TomTom data as a source.

TomTom data is not compatible with OSM's data license and cannot be used. You must not copy data from incompatible data sources when contributing to OSM.

Further, as discussed, these are descriptive names. They do not belong in the map. I have referenced the policy explaining why they are descriptive names. Official sources with compatible data licenses (such as Vicnames) has been provided as a source as to why these names are not "real".

This edit will be reverted for the above reasons.
            ---
            
            Published using OSMCha: https://osmcha.org/changesets/126038894
ortho_is_hot (2022-09-11 09:46:26+00:00): Agree with Diacritic here, source is incompatible and descriptive names that are not reflected in the real world do not belong in OSM. If you keeping adding this stuff back then getting the Data Working Group involved will be necessary.
aharvey (2022-09-11 22:33:09+00:00): Hi Milk Point,

TomTom is not a compatible data source so we'll need to revert these changes.

Further there is a community consensus around many of these name=* values not actually being names but rather descriptions (https://wiki.openstreetmap.org/wiki/Key:description) or destinations (https://wiki.openstreetmap.org/wiki/Relation:destination_sign) which are generally mapped using other tags and not as the name=* tag. If you don't think that's right please post back and join in the discussion, but otherwise in line with the community consensus these changes will be reverted.

-- aharvey, on behalf of DWG.
Mlik Point (2022-09-12 00:17:13+00:00): According to the 7ways navigation app, there are non-descriptive names there at Melbourne Airport that was updated as of 1st of September 2022 by provider "megamaps.org".

We need to put back those changesets on [https://www.openstreetmap.org/changeset/126009952] and make them so much better.

Mlik Point from OSM
Diacritic (2022-09-12 05:55:51+00:00): Hi Mlik Point;

The 7ways navigation app uses information sourced from OpenStreetMap; it is likely that the roads you are referring to are being sourced from the contributions you introduced yourself.

Again, I'm confused as to why you believe a road name like "Value Car Park", which drives through the centre of the carpark is a useful and valid name. The destination tag is used by most (or should be used by most) routing algorithms to provide the turn information data, even if you cannot see it render on the map: https://wiki.openstreetmap.org/wiki/Routing.

Dian

It may also be worth reading https://wiki.openstreetmap.org/wiki/Lying_to_the_renderer, which explains why mistagging or misusing tags (such as the name field) to force rendering is unhelpful.
skyper (2023-01-04 23:28:14+00:00): Hallo keiner,
stimmen jetzt die Ansagen?
Kann mir nicht vorstellen, dass das Spurtagging etwas damit zu tun hatte. Allerdings hast Du jetzt die Tags `change:lanes[:*]` alle für den langen Teil der Straße übernommen (https://www.openstreetmap.org/way/272803614). Gibt es dort einen durchgehenden Mittelstreifen? Auch machen `*:both_ways` keinen Sinn. Bitte frag doch nach, wenn Du Tags nicht verstehst.

Fragende Grüße,
skyper
keiner (2023-01-05 15:52:33+00:00): Hallo skyper (hat das was mit Microsoft zu tun?), ja die Ansagen stimmen jetzt. Ja es gibt einen durchgehenden Mittelstreifen, allerdings nicht für den ganzen jetzt ausgewählten Teil. An wen stelle ich wo Fragen, wenn die Dokumentation da anscheinend nicht deutlich genug ist?
Antwortende Grüße,
keiner
skyper (2023-01-05 17:30:52+00:00): Hey keiner,
danke für die Antwort.
(Nein hat nichts mit Mircroschrott zu tun.)
Fragen kannst Du an die Person stellen,welche die Tags eingetragen hat (https://www.openstreetmap.org/way/821246297/history) oder allgemein  in Maillisten (https://wiki.openstreetmap.org/wiki/DE:Mailing_lists) oder dem Forum (siehe u.a. https://forum.openstreetmap.org/viewtopic.php?id=75939).
Fahrspurtagging wird von iD nicht unterstützt daher empfehle ich JOSM mit entsprechenden zusätzlichem Darstellungsstil, dann wird das auch verständlicher und JOSM warnt bei einigen Fehlern.

Sieht mir jedoch stark nach einem Bug in OSMand aus den `change` (https://wiki.openstreetmap.org/wiki/Key:change) sollte nicht zu solchen Anweisungen führen.

Grüße skyper
skyper (2023-01-12 17:28:58+00:00): Habe ich zurückgesetzt:
https://www.openstreetmap.org/changeset/131198440
Falls OSMAnd erneut falsche Anweisungen gibt, bitte OSMAnd das Problem mit diesem Weg melden.
Grüße,
skyper
literan (2022-09-11 10:23:01+00:00): поломали, конечно вы тут все, что можно - здания, стройплощадки...
literan (2022-09-27 14:42:56+00:00): у этого участка нет такого высокого статуса в дорожной сети. Поэтому я верну минимальный статус.

Статусы дорог в РФ назначаются исходя из их значимости в дорожной сети: https://wiki.openstreetmap.org/wiki/RU:Highway_classification
快乐的老鼠宝宝 (2022-09-11 10:01:01+00:00): Reverted in https://www.openstreetmap.org/changeset/126042514

（By http://revert.osmz.ru/7141）
快乐的老鼠宝宝 (2022-09-11 09:58:48+00:00): Reverted in https://www.openstreetmap.org/changeset/126042469

（By http://revert.osmz.ru/7140）
快乐的老鼠宝宝 (2022-09-11 09:56:37+00:00): Reverted in https://www.openstreetmap.org/changeset/126042384

（By http://revert.osmz.ru/7139）
快乐的老鼠宝宝 (2022-09-11 09:56:12+00:00): Reverted in https://www.openstreetmap.org/changeset/126042332

（By http://revert.osmz.ru/7138）
Strubbl (2022-09-11 10:59:35+00:00): Hi kdeiger, bitte lies etwas Doku bevor du solch Änderung vornimmst: https://wiki.openstreetmap.org/wiki/DE:Tag:highway=path?uselang=de

Das bisherige Tagging war hier korrekt.
Strubbl (2022-09-11 11:01:25+00:00): Dies ist die Doku für cycleway: https://wiki.openstreetmap.org/wiki/DE:Tag:highway=cycleway?uselang=de

Die restlichen Tags passen nun nicht mehr oder path wäre richtig
kdeiger (2022-09-11 15:15:08+00:00): Du hast recht - das mit dem "Path" hatte ich so nicht gelesen/gewusst. Und ich war irritiert, weil der angrenzende Weg als "Radweg" markiert ist, obwohl das (kombinierter Rad-/Fußweg) dann eigentlich auch ein Path sein müsste. Deshalb habe ich dieses kurze Stück identisch zum angrenzenden Fuß-/Radweg klassifiziert, denn das ist der offizielle Zugang dazu.
Also aus der Sicht m.E. im Kontext dann doch richtig
kdeiger (2022-09-11 15:17:33+00:00): Alternativ könnte das kleine Stück komplett entfallen und die Luitpoldstr. direkt auf den quer laufenden Rad-/Fußweg münden (was auch mehr den örtlichen Gegebenheiten entspricht)
Strubbl (2022-09-11 15:22:40+00:00): Danke für dein Rückmeldung. Ja, das Tagging für Radwege/Fußwege ist leider nicht so selbsterklärend, sondern eher so historisch entwickelt.

Wenn das wie du schreibst der Realität mehr entspricht, klingt das doch gut, das so umzusetzen. Viel Spaß weiterhin & viele Grüße
快乐的老鼠宝宝 (2022-09-11 09:55:49+00:00): Reverted in https://www.openstreetmap.org/changeset/126042301

（By http://revert.osmz.ru/7137）
快乐的老鼠宝宝 (2022-09-11 09:52:03+00:00): Reverted in https://www.openstreetmap.org/changeset/126042135

（By http://revert.osmz.ru/7136）
快乐的老鼠宝宝 (2022-09-11 09:47:20+00:00): Reverted in https://www.openstreetmap.org/changeset/126042033

（By http://revert.osmz.ru/7135）
快乐的老鼠宝宝 (2022-09-11 09:38:10+00:00): Reverted in https://www.openstreetmap.org/changeset/126041808

（By http://revert.osmz.ru/7134）
kakiremora (2022-09-11 14:22:13+00:00): Twoja nazwa changesetu nie mówi nic o zmianach wprowadzonych do mapy.

Zachęcam do bardziej opisowych zmian changesetów, np. jakie obiekty zostały zmienione, jak i/lub dlaczego.

Pozdrawiam
快乐的老鼠宝宝 (2022-09-11 09:36:39+00:00): Reverted in https://www.openstreetmap.org/changeset/126041783

（By http://revert.osmz.ru/7133）
Syl (2022-09-11 10:14:11+00:00): Bonjour, pour information les images Ortho HR de 2020 sont plus à jour que Bing sur Rennes Métropole (le nom "Grand Rennes" n'existe pas).
快乐的老鼠宝宝 (2022-09-11 09:33:24+00:00): Reverted in https://www.openstreetmap.org/changeset/126041592

(By http://revert.osmz.ru/7132)

I'M SURE YOU WILL BE BANNED

搞破坏有瘾是吧？
Abdelrahman_mahmoud (2022-09-12 07:17:19+00:00): Hello Aaro Hart;
I noticed you added some ways from old satellite image and Maxar Premium Imagery" its most updated, Also you added unknown keys didn't match Wiki OpenStreetMap.
Could you check it please ?
Examples for Streets:
https://www.openstreetmap.org/way/1093522572
https://www.openstreetmap.org/way/1093522577
Regards
Abdelrahman_mahmoud
ToniE (2022-10-10 08:27:05+00:00): Servus,

weißt du zufällig, wie lange die Arbeiten dauern werden?

Beim MVV sehe ich keine Hinweise auf Fahrplanänderungen bei den Bussen N80, 851 und 852.

Gruß,
Toni
kdeiger (2022-10-10 09:33:26+00:00): Diese Änderung besteht schon seit längerer Zeit - mindestens seit 2021 (Umbau der Schule) und es wundert mich eigentlich, dass das noch niemand gemeldet hat. Ich gehe mal davon aus, dass das mindestens noch bis zum Frühjahr 2023 so sein wird. Sobald die Regelung aufgehoben wird melde ich mich wieder
ToniE (2022-10-10 10:06:01+00:00): Danke. Mich wundert nur, dass der N80 noch verkehrt herum durch die Straße fährt. Laut offiziellen GTFS-Daten der MVG zwischen Haltestelle 10 und 11

https://ptna.openstreetmap.de/gtfs/DE/single-trip.php?feed=DE-BY-MVG&release_date=&trip_id=2.UN.3-N80-G-012-1.2.H
kdeiger (2022-10-10 10:49:09+00:00): Also ob der N80 da wirklich (noch) fährt, weiß ich gar nicht. Aber der 851 und 157 fahren dort - aber eben nur in die eine Richtung. Auf dem Weg zurück fährt er über die Münchner Straße und bedient nur die Haltestelle am GEP.
kdeiger (2022-10-10 10:54:28+00:00): Ich sag's ja ungern - aber die MVG-Daten sind in diesem Fall definitiv nicht aktuell - Die Wittelsbacher ist seit mindestens 2021 und aktuell immer noch zwischen der Kurfürsten und der Maximilianstr. eine EIN-spurige Einbahnstraße (was manche Autofahrer trotz ausreichender Beschilderung nicht daran hindert entgegen der Richtung zu fahren ....)
kdeiger (2022-10-10 11:27:09+00:00): Sorry - ich glaube überhaupt nur der 851 fährt dort im Moment - nicht der 157 (ich bin eher der Autofahrer ...). Kann gerne Fotos zur Lage vor Ort beisteuern. Die Haltestelle in der Gegenrichtung ist "deaktiviert"
ToniE (2022-10-10 12:22:01+00:00): Kann gut sein, dass die N** Linien nicht aktuell sind.
Fotos braucht's nicht. Passt schon.
UT93 (2024-10-19 09:36:28+00:00): Du hast sowohl in diesem Änderungssatz, als auch im https://www.openstreetmap.org/changeset/127092517 eine Festung Castels erstellt. Es gibt sie also jetzt zwei Mal an fast der selben Stelle.
RBB-RK (2022-09-11 15:25:49+00:00): Danke!
Scout Jens (2022-09-12 15:08:32+00:00): Ich hoffe, es hilft Dir weiter. Und herzlich willkommen bei OSM.
wislander (2022-12-07 03:58:43+00:00): Hi 0wu,

I think you're being much too generous with what counts as a "footway" in changesets like this. I just walked along Dayton Ave N an hour ago, and some of the sections you've tagged as footway are just a gravel shoulder. The east side, just north of N 85th St, doesn't even have a shoulder, and pedestrians have to walk in the street there currently.
            ---
            
            Published using OSMCha: https://osmcha.org/changesets/126041250