Du meinst also AL10 (nach Semantik kein Ortsrat o.ä.) sollte dann gar kein “boundary=administrative” sein?
Keinesfalls generell von heute auf morgen: Dazu ist das Tagging viel zu verbreitet. Aber für die Fälle, in denen das gewünschte Gebiet in Konflikt mit “offiziellen” admin-leveln kommt, wie z.B. bei dem “unechten” AL9 weiter oben oder aber bei Hierarchiestufen, die bei den weltweit definierten AL zwischen die Stufen fallen. Da gab es ja schon missglückte Versuche mit Halbstufen.
Ich habe den Eindruck, dass es gerade bei den ordinalen (Ganzzahl-) Kategorien verstärkt zu Einordnungsproblemen kommt, seien es die grade beim track oder die AL bei den boundaries.
Folgende Relationen sind geometrisch defekt:
1142090 | 86679 Ellgau
und
445853 | Ellgau
Jemand hat mit viel Zerstörungstalent die Grenzen falsch mit den Wegknoten von benachbarten tracks vereint, und dabei die Geometrie beschädigt, wodurch es mir glücklicherweise auffiel. Ich sage jetzt nicht, was ich immer sage, aber denken tue ich es doch…
Benachbarte Grenzen der Gemeinde Ellgau im Westen und Süden sind auch in Mitleidenschaft gezogen. Mein Reverttalent ist für diesen Fall zu begrenzt. Kann da jemand aushelfen und die exakten Grenzen wiederherstellen? Danke!
schaue mal nach… ich glaube, es dürfte wieder gut sein… da waren Grenzen mit Wegen verklebt und im Zuge dessen… naja das übliche… überschneidende Linien beim Wegekorrigieren.
Sven
Die Überschneidung hätte ich noch hinbekommen. Es geht mir um die verschobenen/falschen Grenzverläufe. Die sind noch immer auf den Wegen und nicht daneben.
ich könnte das manuell ändern, aber dann wäre es nicht mehr exakt. Die Daten kommen ja von der Bayerischen Vermessungsverwaltung.
2 Grenzsegmente konnte ich aus Revertdaten neu erzeugen. Way 191314169 ist falsch und verklebt.
Der User ist übrigens bisher uneinsichtig.
EDIT: Update
– snip –
hattu ja inzwischen erledigt, danke.
Killerargument gegen Grenzen auf Wegen: Welche Gemeinde ist für den Unterhalt/Reinigung/Beleuchtung/Haftung/… zuständig?
Und zusätzlich bei Strassen: Welche Häuser liegen in welcher Stadt?
Da müssen die meisten passen.
Gruss
walter
Ist dem so? Die Grenze in Form von Way 191314169 war auf jeden Fall noch bezüglich aller Koordinaten verschoben und mit den Wegen verknüpft. Ich habe den Grenzverlauf in der Variante von vor Changeset 33533366 wiederhergestellt (Revertierung von Changeset 33534153 und 33533366 bezüglich der Grenze) und anschließend das dadurch verursachte Wegechaos entwirrt (da die Wege an die Punkte geknüpft waren, die wieder zurückgeschoben wurden, waren sie dadurch natürlich ordentlich durcheinandergewirbelt und mussten von der Grenze getrennt und richtig gezogen werden).
Bitte mal anschauen, ob das so nun wieder in Ordnung ist!
Sieht wieder richtig aus. Danke für den letzten Schritt! Mein letzter war auch sehr mühsam wegen der Verklebungen.
Das einzige, was ich gerade festgestellt habe: Das Lösen der Wege von der Grenze hat leider für die Grenze ebenfalls an der gleichen Position jeweils einen neuen Punkt erzeugt, so dass leider die Chronik dieser Grenzpunkte verlorengegangen ist. Wenn das kritisch ist, muss der letzte meiner zwei Edits nochmals rückgängig gemacht werden. Dann bin ich mir leider aber noch etwas unsicher, wie man das besser macht.
Dazu sehe ich keinen Grund. Das sind ja nur Wegpunkte keine POIs.
Also wenn das so geht, muss ich sagen, dass das gar nicht sonderlich mühsam war (ich habe mich zunächst nur nicht wirklich rangetraut): In JOSM mit dem Revert-Tool zunächst Changeset 33534153 komplett in eine neue Ebene revertiert. Anschließend die überschaubare Anzahl an Konflikten (5) gelöst, indem jeweils auf die alte Version gesetzt wurde. Dann das ältere Changeset 33533366 ohne neue Ebene komplett direkt in die bereits bestehende aktive Ebene von Changeset 33534153 revertiert. Dann die Konfliktliste durchgegegangen und gesehen, dass weder Weg 191314169 noch einer seiner Knoten aufgeführt ist. Die Ebene verdoppelt und sich damit sämtlicher Konflikte entledigt (sonst lässt einen JOSM nicht hochladen) und anschließend nur Weg 191314169 per “Auswahl hochladen” aus der soeben kopierten Ebene hochgeladen. Damit stimmte die Grenze wieder, nur das Wegenetz natürlich nicht. Also nochmals heruntergeladen und die Wege von der Grenze gelöst und per Hand gerichtet, was nun kein so kritischer Aufwand war.
Habe beim Fixen defekter Grenzen mal wieder viel unnötige Zeit aufwenden müssen, weil Mapper es so toll finden, Grenzen mit den highway und landuse zu verkleben bzw. zu verheiraten. Dabei ist mir egal, ob es sachlich vielleicht stimmt (tat es wie meist nicht). Ich finde es einfach schei*e. Es ist gehört sachlich schlicht nicht zusammen (Konkretes/Abstraktes). Sogar Grenzsteine gehören somit eigentlich nicht mit Grenzen verklebt.
Oder wir schmeißen einfach alle Grenzen aus OSM heraus und machen es zu einer reinen DB für POIs, Gullideckel etc. (strikt OTG). Da spricht der Frust.
Aber aber, du willst den Kollegen doch nicht diese schönen Lila Linien wegnehmen? Wenn die diese nicht mehr sehen, flippen sie aus. Ob die topologisch/geographisch/geometrisch “sauber” sind, ist doch nicht soooo wichtig für einen “Real Mapper” 
Gruss
walter
ps: Hakst du die bitte kurz in der “Missing Boundaries”-Liste ab?
pps: Wir sollten mal eine “Real Mapper”-Liste ins Wiki stellen, analog zu “Real Programmers”.
Start: “Real mappers only use iD” …
Ich kann das nicht nachvollziehen. Wenn eine Grenze durch den Flussverlauf definiert ist, dann gehört sie mit dem Fluss “verklebt” bzw. ich will den Fluss in der Grenzrelation sehen und nicht irgendeinen extra-Way. Denn sollte der Fluss seinen Lauf ändern, ändert sich auch die Grenze, und wieso sollte man dann zwei Geometrien verändern müssen. – Ist die Grenze natürlich unabhängig vom aktuellen Flusslauf definiert, dann kann man die auch separat mappen.
Meiner Ansicht nach ist die Verklebbarkeit von Grenzen und Features der einzige Grund, Grenzen in OSM zu haben (wären sie in zwei Datenbanken, müsste ich, wenn sich der Flusslauf ändert, die Daten in der zweiten Datenbank auch nachziehen). Wenn jemand argumentiert, dass Grenzen grundsätzlich nie mit physikalischen Features verklebt werden sollen, auch dann, wenn sie durch diese definiert sind, dann ist das m.E. zugleich ein Argument für das Entfernen von Grenzen aus OSM, denn dann haben sie mit unseren Daten nicht mehr zu tun als beispielsweise Anflugpatterns auf einen Flughafen.
Bye
Frederik
Das kann man durchaus so sehen. Ich wollte aber nur diese Extremposition verdeutlichen, ohne das konkret zu fordern.
Dennoch finde ich Fluss und Grenze sind in der Regel etwas anderes. Gemeindegrenzen sind (in DE) ALKIS-mäßig exakt definiert und nicht à la “entlang dem Bachlauf” (wie es irgendwer in OSM geschätzt hat). Auf unteren Ebenen ist das ggf. anders (vgl. Bielefeld, wo sich Bezirksgrenzen auch nicht an Flurstücke halten).
EDIT: Typo und “DE”
Wenn man, so wie du, mit “in der Regel” Deutschland meint, magst du ja Recht haben. Aber DEU ist nicht die Welt. Weltweit sind sehr viele Grenzen durch natürliche Gegebenheiten (Flüsse, Küsten, Bergkämme, …) definiert. Mit allen Vor- und auch Nachteilen.
Und das wird auch noch lange so bleiben.
Gruss
walter
Und soll es gerne auch. Im Übrigen beachte man den Thread-Titel - und meinen aktuellen Frust.
Dann lass es doch mal einige Tage schleifen. Es gibt genug Kollegen, die täglich die Missing Boundaries abarbeiten - ja , du hast deine eigenen (nicht öffentlichen?) Auswertungen und schläfst nicht so lange wie ich - und nicht vor den deutschen Grenzen zurückschrecken.
Das bewirkt manchmal Wunder.
Gruss
walter