(Mammi71 möge mir das verzeihen, denn das folgende gehört eigentlich gar nicht mehr zum eigentlichen Thema, aber die Aussage
hat mich neugierig gemacht.)
@Bernhard Hiller:
Ich habe mir mal angesehen, was du meinst und würde dieser Aussage widersprechen. Ein Teil deiner erstellten MP sind m.M.n. unnötig und erschweren nachfolgenden Mappern die Arbeit. Warum kann man z.B. https://www.openstreetmap.org/relation/12217190 (aus https://www.openstreetmap.org/changeset/97901752, hier gibt es weitere solche MP) nicht als geschlossene Fläche mappen? Wo ist hier der Vorteil eines MP? Oder übersehe ich hier nur den eindeutigen Grund?
Ich sehe es wie aixbrick. Was sich als einfaches Multipolygon (Fläche) zeichnen lässt, sollte nicht als Multipolygon-Relation eingezeichnet werden. Das nehme ich auch als Konsens aus vielen anderen Diskussionen wahr.
Wartungsfreundlicher und weit weniger feherlanfällig ist es, wenn man zwei aufeinandeliegende Linien verwendet und nicht Fluss und Mangrove eine gemeinsame Linie teilen lässt.
Wobei es sich bei dieser MP-Relation nicht um einer Relation mit nur einem Mitglied handelt sondern um eine mit zwei Mitgliedern.
… und egal, welche Hürden Nachfolgern damit gestellt werden.
Beispielsweise die aus 2 outer-Linien multipolygonal zusammengezimmerte Friedhofsfläche in #2,
da stellt sich einem verantwortungsvollen Weiterbearbeiter zunächst mal die Denksportaufgabe
“Warum? Hat dies einen wichtigen Grund, den ich beachten muss?”
Mit dem sinnfreien Umbau zur Relation hat der Friedhof eine neue OSM-id bekommen, ggf. vorhandene Links auf die Geometrie funktionieren nicht mehr.
Mit dem Umbau zur Relation gilt der iD-Benutzer jetzt fälschlich als Erstautor im Jahr 2021, tatsächlich wurde der Friedhof aber wohl bereits vor 12 Jahren von einem ganz anderen Benutzer (mit anderem Editor) angelegt.
Klar kann man sich auf den Standpunkt stellen, dies sei alles “korrekt” und kein “Schaden”, persönlich sehe ich das aber anders und halte das für ganz großen Mist.
Ja, Freude über KI, Importe und Massenedits, wenn einem schon so ein “Einfachprogramm” derartige Fallen stellt.
Zu einer akzeptabeln Darstellung der Friedhofstors war es notwendig mehrmals die Linienbündel aufzuspalten.
Wann und wie da einen Relation erwachsen ist, habe ich nicht bemerkt.
Der Zaun als solcher besteht aus allen möglichen Elementen, teilweise doppelt und teilweise gar nicht vorhanden.
Viel Freude mit JOSM, da ist das Potential noch deutlich höher. Dann sage ich auch M…:(
@WegefanHB bitte nicht persönlich nehmen, Du warst anknüpfend an #2 nicht das Ziel mein Kritik.
Mal meine Erfahrung: bei meinem Einstieg bei OSM war iD mein Editor-Erstkontakt nach 2 oder 3 Tagen war ich schnell bei JOSM, einfach weil man da besseren Einblick in die Datengrundlage hat. Wobei die Produktion unnötig komplizierter Geometrien auch mit JOSM problemlos möglich ist, wenn denn der Nutzer das so will.
Es wäre schön wenn hier bezüglich Geometrie-Erfassung einfach der Grundsatz gelten würde “So einfach wie möglich - so kompliziert wie nötig” - also der komplexere Datentyp relation nur dann wenn er wirklich deutliche Vorteile bringt (Grenzrelationen mit x-facher Verwendung), oder wenn die Situation mit einfachen ways nicht sauber darstellbar ist (inner sind nötig, oder es gibt echte, also externe outer).
Ich wollte hauptsächlich unterstreichen, dass der Editor ganz unbemerkt eine Relation hinzugefügt bzw. ein Flächenelement in diese eigenartige
Relationsart umgewandelt hat. Da die Sache sehr anschaulich ist, kann sie auch gerne als abschreckendes Beispiel stehen bleiben.
Der iD Editor hat nur die Auswahlmöglichkeiten Punkte, Linien und Flächen. Ich suche auch nicht im “Untergrund” nach MPs, Relationen oder Site. Vielleicht sollte ein Fachkundiger einen Hinweis an die Programmierer geben, dass so etwas NICHGEWOLLTES abgestellt werden kann.
OT: Das muss man P2 und P3 zugutehalten: Im “Advanced”-Modus passiert nichts, was man nicht selber bewusst einträgt. Ich verstehe bis heute nicht, warum iD “der” Standard-Editor sein muss. Für mich ist das eine Black Box. Und JOSM ist mir für meine Zwecke zu komplex. OSM ist für mich bestenfalls Zweithobby.
Wenn ich irgendwo in meinem “Revier” oder knapp “übern Tellerrand” hinaus hinaus solche kleinen unnötigen MPs entdecke oder Geometriefehler von ID-Editor-Nutzern, so gehe ich mittlerweile davon aus, dass dies von diesen Leuten unbewusst erzeugt wird.
Wenn ich die Leute dann per Changeset-Kommentar kontaktieren würde, löst das bei denen dann meist nur Verwirrung oder Frust aus, also lässt man das.
ebenfalls OT:
Ich mappe momentan relativ exzessiv, aber OSM ist trotzdem auch bei mir eher Zweit- oder Dritthobby.
Das kann im Sommer oder in ein, zwei Jahren ganz anders sein.
JOSM ist komplex, aber ich selbst nutze nur wenig von seinen Möglichkeiten.
vielleicht sind es 5 oder 10 %, von dem was man nutzen könnte,
Aber die 5 bis 10 % reichen mir vollkommen aus.
Unabhängig von möglicherweise schon existierenden “komplexen Anleitungen” für das “komplexe JOSM” habe ich mal ein paar “JOSM-Anfänger-Tipps” erstellt (und auch schon an Nutzer verschickt).
Diese passen auf eine DIN-A4-Seite. Dies würde sich für einen ersten Einstieg eignen, für Leute, die (wie ich damals) noch eine Weile parallel mit ID arbeiten möchten.
Warum ID der Standard-Editor ist? Meine Vermutung: weil es keiner Programm-Installation bedarf. Und weil man dadurch mehr Leute erreicht, die bei OSM mit machen.
Ich stelle mir die Frage:
Warum muss JOSM die potentiellen Anwender mit “100% Möglichkeiten und der kompletten komplexen Bedienoberfläche” gleich zu Anfang erschrecken, wenn für den Einstieg in die Arbeit mit JOSM vielleicht 5% davon benötigt werden?
Ich mappe auch bevorzugt mit iD. Meine normale Mapping-Tätigkeiten kann ich mit iD schneller und einfacher erledigen. Ich habe mich einmal sehr darüber geärgert, dass jemand meine bewusst erzeugten MP (mit inner + outer) gelöscht hat ohne mich vorher zu kontaktieren. Da waren Fehler, die korrigiert werden mussten. Aber stattdessen wurden sie gelöscht. Ich habe das dann letztendlich revertiert und die Fehlerkorrekturen an den MP selbst vorgenommen.
Es hilft einem auch nicht weiter, wenn man auf die Problematik nicht hingewiesen wird. Ganz im Gegenteil, man erzeugt dann weiterhin fehlerhafte oder ungewollte MP.
An sich finde ich die, wohl meist versehentlich, erstellten MPs nicht so schlimm, kann man ja recht schnell bei darauffolgenden Änderungen zurückbauen.
Aber das dabei die Objektversionsgeschichte abgeschnitten wird, (wie Jo Cassel es erwähnt hat und wie es mir selbst häufiger aufgefallen ist) ist in der Tat recht suboptimal. (Ist generell gemeint und nicht auf den Beispielfall bezogen)
Wüsste allerdings auch nicht so recht, wie die Aufsplittung von Linien, die gleichzeitig Flächenumrisse sind, im iD generell anders praktikabel gehandhabt werden könnte. Möglich wäre wohl entweder eine entsprechende Prüf-Regel einzuführen, oder sogar die vollständige Verhinderung einer Aufsplittung zu implementieren (analog zu der Beschränkung: Wegsegmente die als Mitglied von Relationen sind können nicht gelöscht werden).
Es wäre ausreichend, wenn beim Aufsplitten eines ways in zwei Segmente die history an einem der Wegsegmente erhalten bliebe und, wenn man way wieder zusammenfügt, die history des älteren way übernimmt. Oder so ähnlich.
Oder die Entscheidung, welches Objekt die history vererbt bekommt, erst im Moment des Hochladens gefällt wird.
way (outer) 2x gesplittet → längstes Teilstück bekommt die ID
Teilstück gelöscht (ohne ID) und die beiden verbleibenden ways wieder zusammengefügt → MP wird automatisch wieder hergestellt und ID vom outer-way als auch vom MP bleiben erhalten.
Nach meiner Beobachtung macht seit einiger Zeit der iD das auch ohne “fremde Hilfe”:
Wenn man die Außenline einer Fläche splittet, dann alle Teilstücke der automatisch beim Splitten erzeugten Relation entfernt bis auf eins aus (durch Löschen der Linie, entfernen der Mitgliedschaft oder Zusammenlegen) wandelt der iD beim Zusammenfügen des verbleibenden einzige Mitglied der Relation wieder in eine einfache Fläche mit den Eigenschaften der zuvor automatisch erzeugten Relation.
Sie sind aus meiner Sicht besser handhabbar als die Alternative, nämlich wenn sich Waldfläche und angrenzende Flussfläche eine gemeinsame Linie teilen und dadurch teilweise sehr komplexe Relationen entstehen.
Ich bin in OSM sehr aktiv darin, Flächennutzungen zu ergänzen und zu korrigieren und beziehe mich insofern auf meine persönlichen Erfahrungen damit. Ich habe selber in der Vergangenheit öfter mit Linien gearbeitet, die ich zum Mitglied in zwei Multipolygon-Relationen gemacht habe. Ich habe aber festgestellt, dass dies bei mir zu mehr Fehlern und vor allem zu späteren Fehlern führte, wenn ich diese Flächen dann erneut bearbeitet habe.
Gerade dann, wenn man Flächen besonders detailreich einträgt, also z.B. auch einen breiten Grasstreifen zwischen Straße und Wald als eigene Fläche einträgt oder eine vielfältig gegliederte Landschaft mit Wiesen, Gebüschstreifen, kleinen Äckern… wird es sowieso ziemlich komplex. Das gemeinsame Verwendung von Linien durch mehrere Multipolygon-Relationen macht es dann noch komplexer.
Um Missverständnissen vorzubeugen: Wir reden nicht von dem zu Recht abzulehnenden Verkleben von Linienobjekten (Wege, Bachläufe, Straßen) mit Flächen (Waldflächen, Wiesen, Flussflächen) sondern von direkt aneinandergrenzenden Flächenobjekten.
Wir reden hier doch gar nicht von Linienbündeln, wie sie beispielsweise bei boundarys ohne Grenzrelationen entstehen würden, sondern von landuse/natural-Flächengrenzen.
Und dort liegen in der weit überwiegenden Zahl der Fälle nur genau 2 Linien “übereinander”, nämlich die der beiden benachbarten Flächen (z.B. Wasserfläche an Weidefläche, oder woanders halt Mangrovenfläche).
Als OSM-Anfänger war meine Region von fleißigen Kollegen bereits großflächig so erfasst, ich fand dies
intuitiv verständlich
gut weiterbearbeitbar
und habe noch nie gehört, dass irgendjemand damit Probleme hat.
Andere Konstruktionen muss ich auch heute noch erstmal analysieren, um den “Bauplan” zu verstehen. Das derjenige, der die bewusst nach seinem Plan erstellt hat, diesen Linien-Bauplan im Kopf hat, bezweifel ich nicht. Kann nur an dich appellieren, bei der Erfassung von Flächen diese auch primär als Flächen “zu denken”.
+1
Würde ich sofort unterschreiben. Da wo Flächen aneinander grenzen sollten die als einzelne Flächen gezeichnet werden… Ich empfinde auch ein “Abstandhalten”, was teilweise bei Parkplätzen an Gebäuden gemacht wird als faktisch falsch. Gleiches gilt bei vielen Landuses…
Also umgeht man das Problem, indem man es duch ein noch miserabler handhabbareres ersetzt, wo noch weniger Mapper durchsteigen. Wie steht eigentlich die thailändische Community dazu?
