Wald in Sächsische Schweiz verschwindet?

Rongel · 2022-12-07T18:34:07.495Z

Hallo

Habe soeben festgestellt, dass ein Multipolygon forest in der Sächsischen Schweiz nicht mehr richtig dargestellt wird, der Wald verschwindet. Was könnte da passiert sein?
https://www.openstreetmap.org/relation/1750661#map=15/50.9270/14.2532
Ich hatte kürzlich hier einige Wanderwege, Wanderschilder und Grünflächen etwas bearbeitet. Ich finde da aber keine Fehler.

whb · 2022-12-07T18:53:31.852Z

Das Multipolygon scheint keine Fehler zu haben, alle seine Elemente sind geschlossen und überlappen nicht, genau ein outer und der Rest inner.
Etwas seltsam finde ich das natural=valley an der Relation, das ist aber schon seit 2019 da, scheint mir aber dennoch falsch zu sein?

Rongel · 2022-12-07T19:08:34.886Z

Dieses natural=valley ist aus meiner Sicht sogar eher falsch am MP. Es beschreibt auch dieses Waldgebiet nicht präziser. Ich hatte mich aber nicht getraut es zu löschen, da es schon längere Zeit vorhanden ist. Sinnvoll ist es hier sicherlich nicht.

lonvia · 2022-12-07T20:01:58.495Z

Dieser Node ist der Schuldige: Node: 2300525283 | OpenStreetMap An der Stelle liegen jetzt zwei Nodes übereinander, die fast aber nicht vollständig die gleichen Koordinaten haben. Dabei enstehen sich leicht überlappende Polygone. Ich fixe das mal gerade.

Allerdings sollte dieses Monster-MP vielleicht ohnehin einfach mal in besser handhabbare Stücke geteilt werden.

EDIT: es war nur ein Node, der die Linie darunter nicht genau getroffen hat. Das Ergebnis ist aber das selbe.

Rongel · 2022-12-07T20:24:37.600Z

SUPER!! Jetzt wird mir klarer warum ich einen Fehler nicht finden konnte.

streckenkundler · 2022-12-08T07:28:49.452Z

siehe auch OSM-Inspector (noch bis heute Vormittag)
Das MP-Konstrukt schreit aber nach leichter Vereinfachung: den Waldstreifen nördlich der Kirnitzsch und die Gewässerfläche selbst würde ich rausnehmen.

Sven

Galbinus · 2022-12-08T08:52:21.995Z

Den OSM-Inspector kann ich für solche Fälle wärmstens empfehlen. Er findet in der Regel die Fehler, die dazu geführt haben, dass eine solche Waldfläche plötzlich nicht mehr in der Standard-Karte angezeigt wird.

Ich weiß aus eigener Erfahrung, dass es sinnvoll ist, solche riesigen Waldflächen in kleinere Flächen aufzuteilen, da solche Muliti-Poligon-Relationen mit sehr viellen Inners und Outers sehr fehleranfällig sind. Da verschiebt man an irgendeiner Stelle nur eine Linie und schon verschwindet einige Tage später der Wald aus der Kartenansicht.

Ich bin gerade dabei, diese komplexe Wald-Realition in kleinere Relationen aufzuteilen und arbeite mich von Norden nach Süden durch… Relation: 5303738 | OpenStreetMap

Discostu36 · 2022-12-08T09:32:50.426Z

Stopfst du am Ende noch in eine Master-Relation oder lässt du die einzeln?

Mammi71 · 2022-12-08T09:55:40.109Z

Wozu soll hier eine Master-Relation gut sein?
m. E. braucht es das nicht.

Discostu36 · 2022-12-08T10:01:57.424Z

In diesem Fall wahrscheinlich nicht. Aber wenn der Wald benannt wäre. z.B.?

Galbinus · 2022-12-08T10:29:10.957Z

Um einem Wald einen Namen zuzuordnen halte ich “boundary=forest +
name=*” für die bessere Wahl als eine Relation. Ich hatte in der Vergangenheit mal den “Stadtwald Horn” als “landuse=forest + name=Stadtwald Horn” eingezeichnet. Dies wurde aber mit zunehmendem Detailgrad immer problematischer. Später habe daher auf die “boundary-Lösung” umgestellt. Der Name “Stadtwald Horn” wird dadurch zwar nicht mehr in der Standard-Karte angezeigt, die Suche findet den Stadtwald aber problemlos: Way: ‪Stadtwald Horn‬ (‪1062848966‬) | OpenStreetMap

Bei der hier diskutierten Wald-Relation (mit der Beschreibung “Wälder in der Sächsischen Schweiz” ist aber gar kein Name eingetragen.

chris66 · 2022-12-08T10:48:37.453Z

whb:

Etwas seltsam finde ich das natural=valley an der Relation, das ist aber schon seit 2019 da, scheint mir aber dennoch falsch zu sein?

Also wenn damit das Elbtal gemeint sein sollte: Dies befindet sich weiter unten an der Elbe…

Ich kann’s gerade nicht abrufen wer das eingetragen hat wegen timeout.

whb · 2022-12-08T11:24:27.255Z

Galbinus:

Den OSM-Inspector kann ich für solche Fälle wärmstens empfehlen. Er findet in der Regel die Fehler, die dazu geführt haben, dass eine solche Waldfläche plötzlich nicht mehr in der Standard-Karte angezeigt wird.

Bei diesem habe ich gestern auch nachgesehen, da war der Fehler aber noch nicht zu sehen. Wird vermutlich nur einmal am Tag aktualisiert?
Auch der JOSM Validator hat den Fehler nicht gefunden und auch keine Warnung angezeigt, obwohl ich das komplette Multipolygon und auch alle Daten des Gebietes herunter geladen hatte.
Nachdem ich dann die von Rongel bearbeiteten Objekte durchgesehen hatte, ist mir der fragliche Knoten auch aufgefallen, @lonvia war dann aber schneller. Zumal ich dann erst durch Ausprobieren herausgefunden hätte, dass der Fehler tatsächlich dort lag.

whb · 2022-12-08T11:30:44.339Z

chris66:

Also wenn damit das Elbtal gemeint sein sollte: Dies befindet sich weiter unten an der Elbe…

Das natural=valley habe ich jetzt entfernt.

chris66:

Ich kann’s gerade nicht abrufen wer das eingetragen hat wegen timeout.

Hier: Changeset: 67809059 | OpenStreetMap

Galbinus · 2022-12-08T13:09:45.212Z

whb:

Bei diesem habe ich gestern auch nachgesehen, da war der Fehler aber noch nicht zu sehen. Wird vermutlich nur einmal am Tag aktualisiert?

Ja, die Daten werden nur einmal am Tag aktualisiert. Datum und Uhrzeit des Datenstandes wird links unterhalb der Legende angezeigt. Es ist also kein Tool, mit dem man einen Fehler sofort erkennen
oder sofort auch die Wirkung der Fehlerkorrektur überprüfen kann.

Galbinus · 2022-12-08T13:10:12.050Z

whb:

Das natural=valley habe ich jetzt entfernt.

Das finde ich richtig.

streckenkundler · 2022-12-08T14:58:54.543Z

Galbinus:

Ja, die Daten werden nur einmal am Tag aktualisiert.

Nein, hier gibt es zwei Durchläufe, Zur Zeit einmal mit Datenstand 7:00 Uhr und dann mit Datenstand 19:00Uhr.

Sven

whb · 2022-12-08T15:26:59.980Z

streckenkundler:

Nein, hier gibt es zwei Durchläufe, Zur Zeit einmal mit Datenstand 7:00 Uhr und dann mit Datenstand 19:00Uhr.

Ok, aber UTC, also 8 und 20 Uhr MEZ, da habe ich dann geschätzt 15 Minuten zu früh nachgesehen (mein Beitrag ist von 19:53 MEZ). lonvia konnte es dann 1 Stunden später wohl sehen.

streckenkundler · 2022-12-08T15:30:21.242Z

Die zweite Auswertung ist für unsere OSM-Nachtschicht…