> 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 osm.org/node/12120613756 but osm.org/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 (osm.org/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: osm.org/node/11237047754 has boundary=administrative, area=no, admin_level=9

Hi, you've added a number of villages in this changeset and added place tags as well as boundary=administrative tags to their nodes. This is unusual tagging and has Nominatim confused (https://github.com/osm-search/Nominatim/discussions/3306). The boundary=administrative and admin_level should only go on areas. If I see it right, you already have the areas (for example osm.org/way/1212880550), so a removal of the boundary and admin_level tags on the nodes won't loose you any information. I'd also get rid of the 'area=no' on the nodes. It doesn't do harm but also doesn't carry any additional information.

I've not edited anything myself because I suspect there might be other changesets as well that are affected. Happy to help, if necessary.

Ha, lustiger Eingabe-Fehler. Repariert. Danke.

It's been quite a while ago and I have no real photo proof for it, but looking at https://en.wikipedia.org/wiki/Kerikeri it has a mention of the oldest pear tree in NZ. I vaguely remember something about a 'notable tree' plate and might have added the tag because of that. Feel free to change/delete.

The wikipage for Lyncombe is already linked on osm.org/node/6535752381. Lyncombe Vale looks to be a part of Lyncombe. Might also be the other way around. I went by the article name.

Upper and Lower Swainswick are presumably only parts of osm.org/node/3596041357, which again has the wikidata/wikipedia correctly set already.

You have added a boundary=administrative with admin_level=2.5 here. This is an illegal value for admin_level and potentially breaks data for users. From what I read from the Wikipedia page, Mindanao isn't an administrative entity at all but just a group of islands. So my recommendation would be to remove the boundary and admin_level tag and just leave the place=archipelago.

I agree with PierZen that the Categorie does not belong in the name tag. You yourself explain that they describe administrative categories, not names. Move them to description or another tag agreed upon by the Canadian community. Official maps are then free to add the category or not. As it is, it breaks renderers and search engines and does not adhere to the OSM tagging standards.

Hi, I see that you have added postcodes to village places in this changeset. May I ask what the source for this is? Background is that I'm trying to figure out what the official format for postcodes in Niger is. Niger post only lists 4-digit postcodes while you've entered 8-digit numbers. So I wonder where they are from.

Schon klar. Ich bezog mich auf die Beschreibung des Eselswegs: "Eine Markierung (Kirche mit orangem Punkt) auf der Strecke ist bis auf ein Schild nicht oder nicht mehr vorhanden. Demnächst soll im Rahmen der Neukonzeption der Sch"

Ach so. Na das ist ja gut, dass ich das nicht einfach geändert habe. :) Es fragt sich natürlich, ob man dann den alten Eselspfad überhaupt noch drinnenlassen sollte. Besonders wenn es kaum noch Beschriftung gibt. Vielleicht auf route=hiking:disused oder soetwas setzen, während er neu konzipiert wird?