Oh, bei way/283545011 geht es um das Stück zwischen Fahrweg und Radweg. Das kann ich auftrennen, Da hat es einen breiten abgesenkten Bürgersteig.

highway=footway verhindert kein Fahrradrouting, e.g. osm.org/directions?engine=fossgis_osrm_bicycle&route=51.228585%2C14.047667%3B51.228401%2C14.045618 und der Zugang zum Bahnsteig ist von dem, was ich gesehen habe, nicht ohne Absteigen zu machen. Daher der Downgrade auf highway=footway. Auf access-Tags habe ich explizit verzichtet, weil eben nichts ausgeschildert ist.

way/171075300: oben auf dem Walberg gab es keinen offensichtlichen Weg und auch kein Schild. Nur der von mir eingezeichnete MTB-Trail war sichtbar, den wir dann natürlich für den in OSM eingezeichneten Absteig gehalten haben. Ich kann aber nicht ausschliessen, dass wir etwas halb überwachsenes übersehen haben. Unten, wo der Weg laut OSM losgeht, sieht es so aus: https://lonvia.de/misc/walberg.jpg Da ist alles dicht zugewachsen. Die Schilder zur Schönen Aussicht gibt es noch, aber gefunden haben wir sie nicht. Unten bei 'unter der Goldgrube' zeigt das Schild den Oberförster Piechota Weg entlang. Daher die Annahme, dass man da hinten herum aufsteigen muss via Südaufstieg.

Ich würde das eigentlich ungern ohne erneute Verifizierung vor Ort wieder eintragen. Der Abstieg war abenteuerlich genug. Strava-Heatmap und Komoot sind immer mit Vorsicht zu geniessen, weil sie selbsterfüllende Prophezeihungen sind, was Trampelpfade betrifft.

Leicht umsotiert wieder hergestellt in changeset/181307808

Über die Namen könnte man noch diskutieren. Offiziell sind vermutlich nur die unterliegenden Wege benannt.

Ah, gibt es da inzwischen einen Unterschied zwischen schwarzen und grünen Dreieck? Dann würde ich das wieder herstellen, aber im Bereich Affensteine mit echten Routen.

Du hast hier mit deinen Änderungen aus Versehen ein Stück der Elbe entsorgt: way/29435179/history#map=15/50.89238/14.24550

Hi, in diesem Changset haben sich Hausnummern eingeschlichen, die verdächtig nach einem Mapping-Unfall aussehen: node/2220089506 node/9362874522 node/12048015782

Vielleicht wäre es möglich, die nochmal anzuschauen? Oder ist es okay, die einfach wieder zu löschen?

Started a discussion at https://community.openstreetmap.org/t/administrative-boundaries-for-non-administrative-areas-in-sydney-and-melbourne/140931

I've removed relation/17893357, relation/17893358 and relation/17893359 so that these islands stop being their own country. I've moved the tags back to the way, so no information should be lost.

Looks like EveryDoor has full lifecycle prefix support since 6.0. Should prevent this in the future.

> In my case the app I help maintain relies on the full administrative boundary hierarchy that it delivers.

If that is the reason for the change, then you should adapt your app to get along with the data as mapped in OSM, not the other way around. My comment in https://github.com/osm-search/Nominatim/issues/3814 was not meant as an invitation to change a long-standing tagging practice without community discussion.

Backen tun sie da wohl noch, aber den Verkauf haben sie in Filialen gelegt, die günstiger gelegen sind.

Ich glaube, hier gibt es ein Missverständnis. Das Problem war weder mit den Edits des vorherigen Nutzers, noch mit meinen. Das ist ein ganz normaler Fall von einem Geschäft, was es mal gab und jetzt zugemacht hat.

Das Problem war einfach ein komisches Verhalten vom Editor EveryDoor, wenn man einen POI löscht. Ich habe die Daten in OSM korrigiert und das Problem gemeldet (https://github.com/Zverik/every_door/issues/861). Damit sollte das erledigt sein.

Interessant. Das sieht nach einem EveryDoor Bug aus. Danke für den Hinweis.

Diese Gleise gehören nicht nach OpenStreetMap, da es davon keinerlei Spuren mehr zu sehen gibt. Bitte verschiebe die Daten nach https://www.openhistoricalmap.org/

The "City of Perth" and "Perth" are not the same. The node must not be label member of the relation in this case. See discussion in https://github.com/osm-search/Nominatim/issues/3573

This change has a few typos in the housenumbers. I've already removed node/12120613756 but node/12120613783 looks wrong too. Would you mind rechecking?

This changeset imports broken address interpolation lines where the house number is missing on one end of the line. I understand that this is due to tile boundaries of CanVec but still shouldn't be added to OSM in this broken state. Can you please join the discussion on https://community.openstreetmap.org/t/address-interpolation-imports-from-canvec/113119/5 what to do about this problem.

According to the comment and the source, you have been tracing from USGS maps in this changeset. Among others, you have added administrative boundaries like that of Los Limones (relation/17495479).

I've tried to trace the changes back to the USGS map but Los Limones is not even on this map. So can you elaborate where the data comes from?

I've stumbled upon the change because the administrative boundary relation is problematic. First of all, it contains multiple 'label' members. That should not be the case. There must only be exactly one place node per locality. Second of all, it seems unlikely that an administrative unit just covers a couple of unconnected areas containing one or two houses. Are you really meaning to tag some unit of government administration here or did you in fact mean to just tag landuse=residential, i.e. the areas with houses?

Oh well, now you have inspired me to look closer at the boundary ways. The tagging there is slightly odd as well. There is an 'area=no' tag, so I guess you mean to only map the linear boundaries (as you also say above). But the way also has a place=village tag. That is a contradiction to area=no because a place tag can only appear on nodes or areas. It is not allowed on linear ways.

If I understand the situation right, then the usual tagging for your situation would be as follows:
* remove all tags from the way except boundary_administrative and admin_level=9
* create a relation with a tag type=boundary and all the other tags that are currently on the way except for area=no.
* add the way to the relation

The result is a way with the boundary line and a relation with the village/administrative area.

First node in this changeset: node/11237047754 has boundary=administrative, area=no, admin_level=9