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.
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.
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.
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.
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.
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.
Bitte schau nochmal nach. Hast Du jetzt einen Weg über mehrere Grenzen erwartet?
Vereinfachte Polygone, die dann eben nicht mehr 100% exakt sind.
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.
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.
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)