Geplante Verkleinerung einer riesigen Wald Relation (multipolygon)

Soweit ich es gesehen habe, war bei den Bearbeitungen auch iD beteiligt und bei iD und MP werde ich hellhörig…

… im Bett–liegende Grüße,

Sven

Das Thema iD und Relationen wollte ich gar nicht aufmachen. Habe wohl zu kurz zitiert:

Mir ging es darum, dass JOSM bei solchen Geometrieproblemen wie überschneidende Flächen und “inner” nicht umgeben von “outer” erkennt und deutliche (Fehler-)Warnungen ausgibt, wenn alle Mitglieder geladen sind.

Ich hoffe ich hab euch da jetzt keine Alpträume beschwert mit der Wortkombinationen Id und MP.

Problem bei mir ist halt die Zeit. Ich würde gerne josm nutzen, ist für mich aber für nebenbei zu komplex. Wenn ich Zeit habe ist das meist in der Mittagspause oder abends dann mal auf der Couch , aber da kann ich halt nur Id nutzen weil ich josm nicht installieren darf.

Für die Zeiten in denen ich dann mal an meinem stationären Rechner bin auf dem seit Jahren sogar josm drauf liegt, sind die Änderungen die ich dann mache meist zu trivial, als dass sich josm für mich zu dem Zeitpunkt gelohnt hätte.

Also nutze ich Id und lebe mit den gefahren und warne dann hier vor oder hoffe dass wie ja eigentlich auch passiert jemand unterstützt sonst wäre ja noch viel mehr Wald aktuell als Relation defekt. :slight_smile:

1 Like

@Pajopath mach Dir keine Sorgen. Auch ich arbeite aus unterschiedlichen Gründen bevorzugt mit iD und werde mit der Komplexität von josm nicht warm. Man kann auch mit iD große MP bearbeiten, die Funktionen in iD werden inzwischen auch besser. Man muss halt wesentlich sorgfältiger arbeiten und wissen was man tut. Auch hat man in iD kein so starkes tool zur MP-Bearbeitung und muss mehr händisch machen, aber gerade das ist es, was mir am Mappen Spaß macht. Der Weg ist das Ziel. Und auch josm oder deren Nutzer arbeiten nicht immer fehlerfrei.

1 Like

Ich habe das in letzter Zeit auch bereits ein paar Mal genau umgekehrt erlebt. ID prüft online ob inner- und outer-Flächen sich überlagern und erlaubt in diesem Fall keine Änderung. JOSM tut dies nicht unter allen Umständen, so dass Unachtsamkeit schnell einen großen Wald entlaubt.
Generell bevorzuge ich auch ID, wenn die Komplexität nicht die Notwendigkeit von JOSM erfordert.

Bitte also nicht wundern wenn demnächst einige Relationen als “kaputt” in der Region auftauchen, bis ich da drüber gegangen bin und der Wald vermutlich aufgrund defektem multipolygon nicht dargestellt wird

dass es während des Bearbeitens “kaputt“ geht ist ja völlig normal, nur sollte man es dann nicht hochladen sondern erst nachdem man es gefixt hat. Man muss das nicht unbedingt gleich perfekt machen, sondern kann das MP auch erstmal in kleinere immer noch „zu große“ Flächen teilen, aber die sollten schon jeweils geschlossen sein

1 Like

Schön, wenn das so ist. Allerdings ist es merkwürdig, da die kaputten Relationen doch mit iD bearbeitet wurden oder habe ich das falsch verstanden.

Du solltest die Relation schon vollständig geladen haben damit die Überprüfung auch funktioniert. Bei Multipolgonen warnt JOSM allerdings auch mit einer allgemeiner Warnung, wenn eine unvollständig Relation verändert wurde.

+1 … Dem stimme ich zu, kann dem ewigen ID-Bashing auch nicht viel abgewinnen. Ich habe mit ID ebenfalls bereits einige große MP aufgeteilt ohne dass dabei irgend etwas kaputt gegangen wäre.

Mir wird aus dem Thread nicht klar, welcher Mappingfehler im Detail begannen wurde.

ID verhindert sehr effizient das Berühren oder Kreuzen von outer und inner ways. Besser als JOSM. Falls das Rendering von großen Multipolygonen in die Brüche geht, ist das häufig der Grund. ID verhindert in der Tat nicht, dass Relationen ohne outer way erstellt werden. Dafür muss allerdings der outer way explizit aus der Relation entfernt werden. Das passiert nicht mal eben so.

Am Ende muss man bei der Bearbeitung von Multipolygonen immer Achtung walten lassen, egal mit welchem Editor.

1 Like

Für mich wurden keine Mappingfehler begangen. Ich sehe das als ganz normalen Prozess an, der vorkommt, wenn solche Objekte verkleinert werden, um sie besser bearbeitbar zu machen… Ich selbst kenne iD nicht. Ich hab gleich mit JOSM angefangen und da von Anfang an gelernt wie man damit mit MP’s umgeht. Auf der anderen Seite braucht man bei solchen MP-Monstern auch Ruhe und mitunter Zeit.

Wie Wahr! Das trifft es auf den Punkt!

Danke,

Sven

1 Like

Ich finde in diesem Faden kein Bashing. Was habe ich überlesen?

Ich kann hier auch nur raten und vermute, dass eben genau das passiert ist: Der/Ein “outer” wurde versehentlich gelöscht. iD sollte bei fehlenden “outer” und unvollständigen “outer” Ringen das Speichern verhindern.

Mir ist jetzt kein Fall bekannt, wo JOSM, bei vollständigen Daten, Fehler in MPs nicht bemerkt. Kannst Du mir bitte ein Beispiel geben, damit ich ein Ticket erstellen kann.

+1

Ich denke, die Aussage von @Mammi71 bezog sich auf die Meinungen und Äußerungen über iD über einen längeren (“ewigen”) Zeitraum…
iD ist also gar nicht so “schlecht” , wie er oft und auch schon ziemlich lange so dargestellt wird. :wink: