JOSM Warnung "is_in ist veraltet"

Sofern der Wetteraukreis als boundary erfasst ist und das entsprechende Objekt da drin liegt kann man das is_in entfernnen. Ich würde das aber nur machen, wenn ich eh an dem Object was ändern will.

Eine geospatiale Datenbank kann selbst feststellen, wo ein Objekt drin ist - vorausgesetzt die umgebenden Grenzrelationen sind vorhanden. Dann ist is_in überflüssig.

In NL werden diese is_in tags gerade mechanisch gelöscht: https://forum.openstreetmap.org/viewtopic.php?id=73675
In DE sind sie, vermute ich, genau so nutzlos (heutzutage).

Grundsätzlich wird `is_in` nicht mehr gebraucht, wenn die Grenzen komplett erfasst sind. Direkt an den Grenzen, vor allem mit niedrigen `admin_level` macht es aber durchaus noch Sinn.
Z.B beschwert sich JOSM bei mir fälschlicherweise regelmäßig über die inkorrekte Rechtschreibung von "Straße", weil die nationalen Grenzen nicht hochauflösend vorhanden sind. Da kann `is_in` helfen.

Wie hilft is_in denn da?

Im konkreten Fall kann ich eine andere Warnung ausgeben wenn is_in vorhanden ist oder eventuell gar die Warnung unterdrücken.

Hier einmal ein gutes Beispiel, wo es wohl schwierig ist das Land anhand vereinfachter Grenzen zu erkennen.

Die vereinfachten Grenzen gibt es ja nur in JOSM, da wäre es doch ziemlich absurd, wenn man dann die OSM Daten manipuliert, um eine falsche Warnung loszuwerden. Das nächste QA Tool meckert dann wieder über was anderes.

Ich betrache is_in seit Jahren als veraltet... Da findet sich in den Tiefen des Forums auch entsprechende Aussagen...

Situtation Brandenburg: https://overpass-turbo.eu/s/1bKn eine größere Zahl von is_in-Tags hab ich bereits vor 7 Jahren (!) entsorgt, als es bereits hinreichend saubere Admingrenzen gab.

smootheFiets wrote:

In NL werden diese is_in tags gerade mechanisch gelöscht: https://forum.openstreetmap.org/viewtopic.php?id=73675
In DE sind sie, vermute ich, genau so nutzlos (heutzutage).

Das würde ich mir für Deutschland auch wünschen... Aber Ach... Die Daten sind eh veraltet, es pflegt sie keiner mehr... Genauso wie dieser openGeoDB:*=* - Schrott... Real verwendbar snd diese Daten nicht.

Sven

skyper wrote:

Im konkreten Fall kann ich eine andere Warnung ausgeben wenn is_in vorhanden ist oder eventuell gar die Warnung unterdrücken.

Hier einmal ein gutes Beispiel, wo es wohl schwierig ist das Land anhand vereinfachter Grenzen zu erkennen.

Schlechtes Beispiel! Der Weg liegt komplett auf Deutschen Gebiet und schneidet keine Grenzen. Oder was meinst du mit "vereinfacht"?

Laut Wiki kann der Schlüssel entfernt werden sobald admin-Grenzen sauber gepflegt sind. Da sowohl die Schweizer als auch Deutschen admin-Grenzen gepflegt sind erübrigt sich dieser auch hier.

Die "is_in" Dinger die mir unterkommen (die ich dann auch lösche) sind häufig unvollständig. Beispiel: is_in=Wersten, Düsseldorf, Nordrhein-Westfalen. Dieser ist nicht nur unvollständig sondern da fehlt der Stadtbezirk... Da habe ich eher die Befürchtung daß durch unvollständige tags Fehler bei der Geocodierung passieren! Von mir aus können wir die Dinger auch gerne per Bot komplett entfernen.

GerdP wrote:

Die vereinfachten Grenzen gibt es ja nur in JOSM, da wäre es doch ziemlich absurd, wenn man dann die OSM Daten manipuliert, um eine falsche Warnung loszuwerden. Das nächste QA Tool meckert dann wieder über was anderes.

Keine Ahnung wer alles vereinfachte Polygone verwendet. Dass wir Tags verwenden um u.a. auch QA Tool und StreetComplete zum Schweigen zu bringen ist jetzt aber auch nicht neues, siehe `no_exit`, `noname`, `noref` oder `cycleway:both=no`.

EinKonstanzer wrote:

skyper wrote:

Im konkreten Fall kann ich eine andere Warnung ausgeben wenn is_in vorhanden ist oder eventuell gar die Warnung unterdrücken.

Hier einmal ein gutes Beispiel, wo es wohl schwierig ist das Land anhand vereinfachter Grenzen zu erkennen.

Schlechtes Beispiel! Der Weg liegt komplett auf Deutschen Gebiet und schneidet keine Grenzen.

Bitte schau nochmal nach. Hast Du jetzt einen Weg über mehrere Grenzen erwartet?

EinKonstanzer wrote:

Oder was meinst du mit "vereinfacht"?

Vereinfachte Polygone, die dann eben nicht mehr 100% exakt sind.

skyper wrote:

Dass wir Tags verwenden um u.a. auch QA Tool und StreetComplete zum Schweigen zu bringen ist jetzt aber auch nicht neues, siehe `no_exit`, `noname`, `noref` oder `cycleway:both=no`.

Ich verstehe die Kritik, aber.
no_exit ist ein tagging, was (mind.!) 50/50 falsch gemappt ist. QA und Kommunikation ist dort notwendig
noname oder noref sind imho reine QA-Tags und sinnvoll. Mapper die QA machen und nach Problemen mit name und ref schauen und korrigieren, können noref aus ihren Abfragen ausschliessen und somit nicht bei jeder Prüfung 10,20 oder 50%+ false positive nachkontrolliern.

EinKonstanzer wrote:

skyper wrote:

Im konkreten Fall kann ich eine andere Warnung ausgeben wenn is_in vorhanden ist oder eventuell gar die Warnung unterdrücken.

Hier einmal ein gutes Beispiel, wo es wohl schwierig ist das Land anhand vereinfachter Grenzen zu erkennen.

Schlechtes Beispiel! Der Weg liegt komplett auf Deutschen Gebiet und schneidet keine Grenzen. Oder was meinst du mit "vereinfacht"?

Ach echt? Bei mir liegt der komplett in der Schweiz ;-)
Aber durch vereinfachen von Linien kann es passieren, dass halt dieser Ausläufer des Grenzverlaufs halt entfällt und dann bei Berechnungen etwa bei dem Weg die Grenze verläuft. Sprich stellt dir vor, du sollst die dt. Grenze zeichnen, darfst aber nur 30 Geraden zeichnen (weil vereinfacht). Zwangsweise wird dann manches falsch sein.
Kannst z.B. auch mal schnell in UMap auch ausprobieren, dort gibt es den Punkt "Vereinfachen" in den Ebeneneigenschaften. Denn es macht halt Sinn, wenn in einer Europaansicht z.B. nicht JEDER Node aus den eigentlichen Grenzverlaufs-Ways versucht wird darzustellen.

Ziemlich OT:
Um Darstellung geht es allerdings nicht. Die Vereinfachung der (internen) Grenzverläufe in JOSM hat mindestens drei gute Gründe:
- Vollständige Grenzen würden erheblich mehr Speicher verbrauchen, und der ist notorisch knapp.
- Die Zeit, die der Test braucht, ob ein Objekt innerhalb eines (Grenz-)Polygons liegt, hängt direkt von der Komplexität ab. Je genauer desto langsamer.
- Die exakten Grenzverläufe in OSM ändern sich vermutlich täglich. Diese Daten aktuell zu halten wäre sehr viel Arbeit mit sehr wenig Nutzen.

BLE wrote:

Auf Grund der o.g. Warnung bin ich auf folgenden Tag gestoßen:
is_in=Wetteraukreis,Darmstadt,Hessen,Bundesrepublik Deutschland,Europe

Im Wiki bin ich dann auf folgende Erklärung für DE:Tag:place=town https://wiki.openstreetmap.org/wiki/DE:Tag:place=town gestoßen:
Einfaches Beispiel:

place=town
name=Otley

Dies kann man mit Informationen erweitern, um zum Beispiel die Suche zu unterstützen:

place=town
name=Otley
is_in:country=UK
is_in:county=West Yorkshire
is_in:region=Wharfedale
population=14000

Ist dann wohl auch veraltet.

Und in der englischen Beschreibung Tag:place=town gibt es keine Möglichkeit mehr die Verwaltungsstruktur zu erfassen.

Wie gehe ich nun am Besten vor?
😐

Ich habe vor Jahren mal die is_in regelmäßig auf korrekte Hierarchie geprüft und korrigiert. is_in ist veraltet aber ich würde die nicht Löschen.

Defakto gibt es für Stadtteile die keine festen Grenzen haben keine schöne Lösung. D.h. ab Admin Level 8 haben wir in D ziemlich genau festgelegte Grenzen, darunter gibt es oft keine oder nur geratene. Da kann is_is zumindest helfen eine Hierarchische Einordnung zu treffen. (Stadtteile die zu Stadtteilen gehören etc)

Flo