JOSM empfiehlt Löschung von is_in. Ist das sinnvoll?

[Tirkon]

JOSM empfiehlt Löschung von is_in. Ist das tatsächlich sinnvoll? Große Gebietsrelationen sind häufig von Beschädigungen betroffen. Würde im Falle einer Beschädigung die automatische Bestimmung der is_in Informationen nicht verunmöglicht?

[ma-rt-in]

Klar empfiehlt es sich is_in zu löschen, da es durch Auswertung mit Grenzrelationen überflüssig macht.

[wambacher (Walter Nordmann)]

Ich halte diese Vorgehensweise (obsolete Tags per Editor zu bereinigen) für sehr gut.

Zum “Korrigieren”:

Iirc “flickt” osm2pgsql defekte Geometrien, indem ein Outer um die vorhandenen Daten gelegt wird und unter bestimmten Umständen damit die Daten korrigiert werden. Zum Glück kann man das mit der Optiom --exclude-invalid-polygon abschalten

Irgendwelche diffusen Informationen aus is_in-Tags zu verwenden, halte ich für unsinnig. U.a. weil die in den is_in-Tags verwendeten Bezeichnungen “Freitext” sind. Dort werden mitunter Namen verwendet, die es im OSM-Datenbestand garnicht gibt (Z.B. Freiburg anstatt von “Freiburg im Breisgau”).

osm2pgsql macht sowas zu Glück nicht und da die Entwicklung fast eingestellt worden ist, wird das wohl auch nicht passieren.

Weiterhin werden is_in-Tags sehr oft nicht angepasst, falls es eine Veränderung der Hierarchie gegeben hat (z.B. Eingemeindungen) und sind somit nach einiger Zeit definitiv falsch. Eine ähnliche Situation wie bei den “so beliebten” associatedStreet-Relationen.

Nominatim verwendet is_in-Tags nur in “Notfällen”:

@sarah

Nominatim happily processes boundaries and always prefers
it over any other hierarchy information.

It is true that it still understands is_in:* tags but prbably not in
the way you would think. First of all, they are completely ignored
on anything at building level (e.g address points and POIs). For
everything else Nominatim always uses a geospatial match when
computing the address. is_in:* is just good to help make a decision
when there are two equally well suited candidates, generally when, say,
a road is right between two city place nodes. As soon as there are
boundaries, multiple candidates don’t happen anymore, so that is_in:*
is ignored for all practical purposes.

Frederik hatte sogar den weitergehenden Vorschlag gemacht, die is_in-Tags automatisch von den Editoren löschen zu lassen, aber das wurde (noch?) nicht realisiert. (finde leider das Zitat nicht)

Gruss
walter

ps: Ich habe in letzten Jahren schon sehr oft is_in-Tags bei den Admin Boundaries gelöscht - allerdings mit einem Hauch von Schlechtem Gewissen; das hat sich gerade geändert.