Ich verzweifel an kilometergrossen landuse forst flächen (20 x 15 km) die eine Komplexität erreichen die unglaublich ist…
Wäre es nicht gescheit maxgrenzen für landuse einzuführen?
Und endlich landuse hiarchisch zu organisiere? Ein mit Bäumen bewachsenen Acker gibt es nicht, genausowenig wie Seen. Und die Spezialfälle kann man mit eigenen Tags abdecken.
Ich finde im Moment erschweren wir den Einstieg völlig unnötig. Multipolygone lassen sich mit Id fast garnichts bearbeiten. Und seit dem mapnik update wird die Datenstruktur hier immer komplizierter.
Ich teile landuse forest Flächen gerne entlang größerer Straßen und Flüsse auf.
landuse/natural werte widersprechen sich eigentlich schon und sind ein Fehler wenn an einer Stelle mehrere vorhanden sind. Ausgeschnittene Seen erhöhen die Komplexität finde ich nicht sehr. Das fängt an wenn die Ränder in Teilstücke aufgeteilt sind die teilweise von mehreren Multipolygons verwendet werden.
Klaro, der ist für sowas auch nicht gedacht/geeignet. Solltest dich mal langsam von dem Newbie-Editor distanzieren.
Natürlich sind Riesen-MP generell “unschön” und die will ich auch garnicht verteidigen. Aber ich benutze auch keine Nagelschere um eine Hecke zurechtzustutzen
Das sehe ich genauso, aber wenn wir irgendwann alle Landuses als MP gemappt hätten, dann würde iD quasi nutzlos für Landuses, weil man damit nichts mehr editieren könnte. Die Gefahr sehe ich allerdings nicht in näherer Zukunft.
Oder man belässt es bei der Arbeitsteilung: iD als Anfangseditor mit niedriger Einstiegsschwelle und JOSM und andere, sobald es etwas anspruchsvoller wird. Es sollte halt nur gewährleistet sein, dass iD nicht unbemerkt MPs zerschießt, zu Kreisen/Rechtecken macht oder sonstige Edits aus der Wundertüte durchführt.
Nun gut, ich bin davon reäll frustriert. Da reist man Abendelang durch die Gegend um Mitstreiter zu finden, die die ersten zarten Gehversuche machen und dann frustiert man sie gleich wieder, weil man praktisch deren ganze Arbeit entwertet. Hier ist die Karte wahrscheinlich aus guten Gruenden noch weis - und man muss einfach aufpassen, dass mit der fortschreitenden Entwicklung von OSM nicht Gebiete ganz abgehängt werden.
Gibt es denn irgendwas, was dagegen spricht, Landusecluster auf 2 mal 2 Kilometer zu begrenzen - und in JOSM eine eindeutige Warung einzufügen “Du versuchst ein sehr grossen landusecluster anzulegen”… und im Wiki klar und deutlich zu schreiben, dass Cluster auf 2 mal 2 km beschränkt werden sollen? (Normalerweise sieht man in der grossen Zoomstufe von JOSM eh keine Details). Bei den wenigen Spezialfällen wo “Monstermultipolygone” Sinn machen, werden die am besten doch eh von jemanden angelegt, der versteht, dass nicht jede Warnung von JOSM gleichbedeutend mit einem Fehler ist (bei grossen Binnenseen macht das ja durchaus Sinn).
Ich finde jedenfalls Multipolygone mit 50 und mehr Mitgliedern (davon allein 8 “outer”) tierisch unnötig komplex.
Ausserdem habe ich bei der Bedienung von JOSM ein Problem: Markiert man einen Grenzknoten eines solchen Riesendings und zoom dann wieder raus, springt die Markierung des Knotens um auf Markierung des Multipolygons. Statt den Knoten verschiebt man dann oft Riesengebiete. Und rein offensichtlich passiert das nicht nur mir. Ziemlich nervig bei Riesenmultipolygonen die nur 4 Ecken haben aber die mit Kilometerlanger Seitenlinie. Dann kann ich nicht sehen, was ich eigentlich mache, da es mir nicht gelingt den Knoten markiert zu lassen und trotzdem die grosse Zoomstufe zu nutzen.
Die aus diesem komischen Verhalten resultierten Verschiebungen zu reparieren ist tierisch komplex - einfach weil man kaum herausfinden kann, was eigentlich passiert ist. Man merkt dass ja meist an komischen Zacken in Strassen - wenn die dann jemand rausmacht, ist es echte Dedektivarbeit zu verstehen, warum das sauber gemappte Gebiet eines Anfängers urplötzlich völlig chaotisch ist. Ein weiterer Frustfaktor.
Nä, ich bin fuer mehr und deutliche Hinweise, dass diese Multipolygone ein Spezialfall bleiben sollen.
Und um im Bild zu bleiben: Ich schneide meine Hecke nicht mit der Nagelscheere. Aber ich verwende auch ungern die Motorsäge dazu, bloss weil irgendwer eine blöde Verpackung um die Hecke rumgebaut hat
Ach ja: Und falls jemand eine einfache Methode kennt, die Dinger kleinerzumachen bin ich dankbar. Im Moment zerschneide ich den outerway, mache einen neuen, lösche aus dem Multipolygon die eine Hälfte raus, nehm êine neu anglegte Strecke als “Abkuerzung” als neuen Outerway mit dem verleibenden Teilstueck auf und lege ein neues Multipolygon an, mit der anderen Strecke und der Abkuerzung als outer und muss die eben gelöschten inner Elemente wieder dem neuen Multipolygon hinzufuegen. Die Elemente von einem Multipolygon in ein anderes zu verschieben, ist mir noch nicht gelungen in JOSM.
gormo: Seit dem Mapnik update werden in meinem Gebiet fast alle normalen Landuseflächen in Multipolygone ungemappt - einfach um die Acker und Seen vom Baumbewuchs zu befreien. Ich verstehe also nicht, wieso Du die Gefahr in nächster Zeit nicht siehst. Das “pineligere” Rendern boostet die Entwicklung doch geradezu.
Wenn ein paar Äcker/Seen aus Wald ausgeschnitten werden ist durch Multipolygone ist das doch kein Problem. Und wenn es eines ist, dann war das Waldstück auch zuvor schon zu groß.
tja genau. irgendwer hat riesenwaldstuecke angelegt, die mit der Zeit immer komplexer werden. Genau deshalb finde ich ja die Maxgrösse wichtig. kantenlänge 50 km (!!!) von Multipolygonen nerven echt…
Danke fuer den Tipp mit dem kopieren der Relation.
Hat jemand noch einen brauchbaren Tipp wie man die Multipolygone ueberhaupt ausseinanderhalten kann? ich vergebe temporär namen vom typ “wald unterhalb des xsees”, muss dass aber bei jeder Bearbeitung wieder neu machen. Und da dass so “Monster” sind sind es halt auch immer ewig viele Relationen, da ich gleich ein Riesengebiet laden muss. Kann man z.B. irgendwie Filtern, so dass JOSM nur die Relationen anzeigt, die beim aktuellen Zoomlevel auf den Bildschrim passen?
Bei einem MP mit Dutzenden von inner und outer artet das leider in Arbeit aus.
Das ist ein Paradebeispiel dafür, wie sich anfängliche Bequemlichkeit oder Unbedachtsamkeit später rächt.
Ja, das habe ich mit JOSM auch… ich habe mir angewöhnt, öfters Escape zu drücken und neu auszuwählen. Auch Ctrl+Z ist mein ständiger Belgleiter.
Monsterpolygone… Wenn mich der Kleister packt, schnipple ich schon mal solche Dinger klein… Vor allem Straßen und Gewässer sind meine favorisierten Schnittkanten. Ich teile an den genannten Stellen ändere die Inner-Polygone entsprechend und starte einen Hochladeversuch… die Fehlerprüfung von JOSM erkennt meiner Ansicht nach alle relevanten Geometrie- und MP-Zuordnungsfehler. Polygone mit mehreren einzelnen Outer löse ich eigentlich riegeros auf. Polygone mit outer aus mehreren Liniensegmenten versuche ich zu vermeiden… klappt abet nicht immer: http://www.openstreetmap.org/relation/5517607 hier wäre ich mit einem outer an die 2000-Node-Grenze gestoßen.
Polygon-Relationen, bei denen sich zwei (oder mehr) Relationen ein Liniensegment teilen, habe ich zum Glück nicht. Die wenigen, die ich hatte, habe ich recht schnell vereinfacht… in einigen Regionen gibt es davon aber noch eine Menge…
CTRL-Z hab ich in Josm noch nie verwendet - und Escape auch nicht.
Hast du mal den Parameter umgestellt? Das gab damals eine Riesendiskussion, weil bei den kleineren Zoomstufen die Nodes plötzlich ausgeblendet wurden und man die nicht mehr auswählen konnte.
Ich muss ja bekennen, dass ich so ein böser Bube bin, der in letzter Zeit allerhand Seen, Waldlichtungen u.Ä., die er kennt, in OSM sucht und sie, wo noch nicht geschehen, per MP aus dem Wald ausstanzt, damit in Mapnik die Bäume aus dem Wasser bzw. der Wiese verschwinden Wichtiger als das Mapnik-Rendering ist mir aber, dass diese Änderung wirklich auch von den Daten her ‘Sinn macht’, weil sie einfach der Realität entspricht. Wir verwenden landuse=forest wirklich im Sinne eines landcover-Tags, und wenn in einem See nicht gerade Bäume wachsen, ist der See daher m.E. wirklich kein Teil des landuse=forest, sondern sollte ausgestanzt werden. Das scheint mir zugleich eine der einfachsten, sinnvollsten und unentbehrlichsten Verwendungen von Multipolygonen (MPs) zu sein.
Was dagegen die komplexen und riesigen MPs angeht, kann ich Skinfaxis Ärger gut verstehen und schließe mich Sven an:
+1. Spätestens wenn die Straße auf einer 10 m breiten Schneise durch den Wald geht oder wenn ein breiter Gras- und Buschstreifen die Äcker teilt, sollte man m.E. Wald- bzw. Ackerland-Flächen aufteilen. Ich gehe inzwischen, wenn ich ein Gebiet genauer mappe, soweit, die Äcker meist auch schon an befestigten Straßen und Wegen aufzuteilen. (Dafür kriege ich jetzt sicher Haue! Wegduck …) Das mag Geschmackssache sein, es hält aber die Flächen klein und übersichtlich und macht MPs (außer für Löcher, s.o., wie z.B. See auf der Wiese) fast unnötig.
Eine der wenigen Ausnahmen, wo solche MPs sinnvoll sind, sind zusammengehörige Teile eines Naturschutzgebietes. Wenn also zwei naturnahe Wäldchen, leider durch einen Acker getrennt, zusammen als NSG/ND gelten, mappe ich sie als zwei Outers eines MPs, um die Zusammengehörigkeit explizit zu machen.
Es gibt einfach Ausnahmefälle, in denen so etwas sehr sinnvoll ist. Wir könnten uns ja darauf einigen, dass wir solche MPs meiden und sie nur in begründeten Fällen anwenden … (aber ‘einigen’ und ‘OSM’ sind, glaube ich, zwei konfligierende Größen ;))
Auch dafür gibt es ab und zu Ausnahmefälle, wo MPs, die sich einige Liniensegmente teilen, eine gute Lösung zu sein scheinen. Aber es wäre natürlich auch hier schön, dies als Ausnahme und Sonderfall zu betrachten …
Da mache ich wiederum eine Trennung… Wenn es um NSG’s geht, dann als type=boundary + boundary=protected_area. NSG-Grenzen erfasse ich unabhängig vom Landuse.
Das ist natürlich noch besser. Danke für die Korrektur! (Ich kam auf das Beispiel, weil ich einige bisher zugleich als landuse und NSG getaggte Flächen in dieser Weise umgetaggt hatte, um die Änderungen erst mal so gering wie möglich zu halten; aber natürlich wäre es viel korrekter mit einer boundary-Relation zu arbeiten.) Also vergesst mein Beispiel bitte …
Aktuell habe wir einen fachfremden “Bestimmer”, nämlich den Verantwortlichen eines Kartenstils. Dessen Kompetenz ist es, eine kartographisch korrekte Karte zu rendern. Es liegt m.E. weder in seinem Kompetenzfeld nochgehört es zu seien Aufgaben, Details der Datenhaltung zu erzwingen. Wenn die Füller der Datenbank sich einig(!) sind, dass Seen nicht ausgestanzt werden, dannkann (und muss) der Renderer damit bitte umgehen.
Wenn das jedoch der Preis für die gern hochgehaltene Monstranz “wir sind libertär und jeder kann beim mappen machen wie er will” ist (der Renderer also nachvollziehbar behaupten kann, er kommt mit dem Kuddelmuddel in der Datenbank nicht zurecht), dann wäre mir ein Hinwendung zur “Einigung” lieber. Denn das wäre allemal sinnvoller als das Diktat durch einen Kartenstil (Womit ich nicht Stellung beziehen möchte für oder gegen das Ausstanzen von Seen in Wälder - ich verstehe nur nicht, warum ein See anders gehandhabt werden solle als ein Haus oder eine Straße in einem Wald - sondern den faktischen Zwang hin zu einer Lösung nicht okay finde. Was passiert z.B., wenn der Renderer demnächst findet, dass er eine Straße nur noch farbig darstellt, wenn die Anzahl der lanes vollständig gepflegt ist).
Wenn das richtig ist, dann müssten wir diese Haltung auf jeden landuse=* übertragen und uns entweder fragen, was z.B. bei landuse=residential auszustanzen ist oder nicht - oder wir müssten uns fragen, ob wir zwischen landuse=* und landcover=* differenzieren.
