Hmm, wie gesagt old_name=* und wheelchair=* werden vermutlich von SC gelöscht, wenn es sich um ein neues Lokal handelt...

Was den outdoor_seating Flächen angeht, da muss ich zugestehen, so ein Objekt ist mir völlig neu... In SC werden die gar nicht angezeigt.

Ist es dir denn lieber, dass ich weiter so mit SC editiere (was ggf. diese Korrekturen erfordert) oder nur Notizen eröffne? Mir wäre beides recht. VG

Nee, also ich habe noch nie etwas über Hiking-Routen in SC gesehen. Das ist dann wohl auch ein Bug. VG

Danke fürs Korrigieren. Hier war ich mir nicht ganz sicher, was genau dem Weg gehörte oder nicht...

Hi, danke, dass du dir die Zeit nimmst, die Edits zu überprüfen. Also mein Hauptfokus liegt auf die POIs und ich versuche, alles zu mappen, was nützlich sein könnte, auch wenn ich dabei einige Fehler mache (sei das wegen mangelndes Wissen oder bloß aus Versehen). Halbrichtige Daten sind ja schon besser als gar keine, und man kann es ja auch immer nachträglich anpassen / verfeinern / korrigieren.

Zu deinen Fragen allgemein: Wie du auch gesehen hast, nutze ich StreetComplete für die meisten Edits. Ich weiß, dass es in gewissen Kreisen keinen guten Ruf hat, aber ohne die App würde ich wohl echt weniger beitragen... Bei jedem einzelnen Laden nach den richtigen Tags googlen zu müssen, ist ja sehr unpraktisch.

Ein paar andere Anmerkungen:
- Dass zB die wheelchair=* und old_name=* Tags verschwinden, room=restaurant aber nicht, liegt an SC. Wenn das falsch ist, dann sollte man es am besten den Entwicklern melden.
- SaaRental wird in SC bei mir nicht in der POI Maske angezeigt. Ich habe es mir noch in CoMaps angeschaut und der Knoten sieht da wie eine Ausleihstation und nicht wie ein Laden aus. Sollte man da nicht auch shop=rental hinzufügen?
- Bei leisure=sports_hall habe ich mich tatsächlich vertan. Ich sehe, dass SC eben leisure=fitness_center verwendet, wenn man nach "pilates" sucht. sport=pilates wird da aber nicht hinzugefügt, vielleicht könnte man das auch den Entwicklern melden.
- "lost property" ergibt keine Treffer bei mir in SC... Deswegen war office=yes halt das beste, was ich da wählen konnte.

Ich hoffe, dass das Korrigieren dir nicht viel stört. Wie gesagt, ich denke, es ist schon besser, einiges da zu haben als gar keine. Persönlich empfinde ich POIs in einer Karte zur Orientierung sehr wichtig; ein Nutzen haben sie also auch wenn die Daten nicht 100% stimmen.

Einen schönen Abend wünsche ich noch!

>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.

Sure, this approach is more than routine to us by now. That being said, if we detect some clear inconsistency in the results, then it feels appropriate to do the correction in OSM directly so others also profit from it. Indeed, some months ago we detected vandalism in UK counties that had managed to stay under the radar, and helped correct it.

To add to the latest comment, this is what I already pointed out in my first reply: If the counties still have practical use, then a "historical" tag sounds inadequate. Seeing this tagging next to the information on Wikipedia, I (erroneously) assumed the counties were evidently no longer in use, hence the edit.

It was never my intention to step on other people's toes. If the changes are incorrect, then by all means please feel free to rollback them. In retrospect, certainly we could have started this conversation on better footing. Still, I hope this has sparked some constructive discussion and I'm glad to see the boundaries are taken seriously by the community. (In my experience, not every OSM community cares as much about them, sadly.)

Well, yes, in general I don't hesitate to contact the community if there is some ambiguity. But in this case to me the edit was clear: The boundaries were consistently tagged as historic (so no longer in use) and that agreed with the information to be found on Wikipedia saying they had been abolished. It's by far not the first case I see where the admin structure changes and boundaries become obsolete, but not all of the related tagging is updated, potentially causing inconsistencies on data consumers' end.

Nominatim has more uses than just address data. In my case the app I help maintain relies on the full administrative boundary hierarchy that it delivers. Objects marked as historic shouldn't even appear in Nominatim results. In this case it was only due to the inconsistent tagging that counties were still appearing there.

Yes, like I wrote in the previous comment, if the counties are still used in practice by local communities, then boundary=historic sounds wrong. That being said, the tag was not introduced in this changeset. I think the best way to proceed is to take the matter to the relevant OSM communities, discuss why the tag was added in the first place, and figure out what is the most appropriate way of representing truth on the ground.

The counties were tagged with boundary=historic and Wikipedia mentions they were abolished at some point, so I assumed they were no longer in use. If as you say they are indeed used in practice, then it seems that the boundary=historic tag is incorrect. It sounds like boundary=place would be more appropriate then?

コメントしてくれてありがとうございます。はい、確かに誤字です。修正しました。

Thanks for clarifying. I noticed there are a couple more such place=suburb like 麻布. Those should probably be deleted too.

Hi, yes, I'm familiar with the address structure. I was just adding these via the overlay in StreetComplete. Is it tagging it the wrong way? (If so, it might be a bug.)

丁寧な説明してくれてありがとうございます。さて、ウィキによるとウェイに（boundaryなどを重複するより=*）https://wiki.openstreetmap.org/wiki/Key:sourceを付けるほうが推薦なのでこれからそれにします。

こんにちは、編集を確認していただき、ありがとうございます。OSMウィキによるとタグを追加しなくてもよいなんですが(osm.wiki/Relation:boundary#Way_tags)。日本ではこんな場合必ずタグを付ける方針になっていますか？