Multipolygone und maxgrösse von landuse

Skinfaxi · 2015-09-20 21:31:44

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.

slint · 2015-09-20 21:55:41

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.

wambacher · 2015-09-20 22:16:44

Skinfaxi wrote:

Multipolygone lassen sich mit Id fast garnichts bearbeiten.

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

Gruss
walter

gormo · 2015-09-21 08:09:41

wambacher wrote:

Skinfaxi wrote:
Multipolygone lassen sich mit Id fast garnichts bearbeiten.
Klaro, der ist für sowas auch nicht gedacht/geeignet. Solltest dich mal langsam von dem Newbie-Editor distanzieren.

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.

kreuzschnabel · 2015-09-21 08:55:04

gormo wrote:

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.

… dann würde sich iD daran anpassen, also einen brauchbaren Relationseditor einbauen müssen :-)

--ks

seichter · 2015-09-21 11:50:20

kreuzschnabel wrote:

… dann würde sich iD daran anpassen, also einen brauchbaren Relationseditor einbauen müssen :-)

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.

Skinfaxi · 2015-09-21 13:11:38

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.

Last edited by Skinfaxi (2015-09-21 13:25:53)

Skinfaxi · 2015-09-21 13:29:54

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.

Last edited by Skinfaxi (2015-09-21 13:30:39)

GeorgFausB · 2015-09-21 13:31:15

Skinfaxi wrote:

Die Elemente von einem Multipolygon in ein anderes zu verschieben, ist mir noch nicht gelungen in JOSM.

Tip:
Erst die Relation kopieren - ist eine Schaltfläche im Relationseditor.
Anschließend kann man alte und neue Relation getrennt bearbeiten:
- Ändern des outers
- Löschen der unnötigen Elemente

Gruß
Georg

slint · 2015-09-21 14:45:19

Skinfaxi wrote:

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ß.

Skinfaxi · 2015-09-21 15:37:32

slint wrote:

Skinfaxi wrote:
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?

gormo · 2015-09-21 16:34:55

slint wrote:

Skinfaxi wrote:
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ß.

Genau das ist mein Gedankengang gewesen. In meinen Gebieten kenne ich aber auch keine dieser übergroßen Wälder, oder ich ignoriere sie einfach.

Last edited by gormo (2015-09-21 16:35:32)

seichter · 2015-09-21 17:11:22

GeorgFausB wrote:

Tip:
Erst die Relation kopieren - ist eine Schaltfläche im Relationseditor.
Anschließend kann man alte und neue Relation getrennt bearbeiten:
- Ändern des outers
- Löschen der unnötigen Elemente

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.

wambacher · 2015-09-21 19:03:04

Skinfaxi wrote:

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.

kann ich absolut nicht bestätigen. das funktioniert sauber.

ABER: es gibt da was mit Nodes und dem Zoom in Josm. Da ist eine Voreinstellung gewählt, die mMn nicht optimal ist. Eventuell ist das das Problem.
siehe : http://osm.wno-edv-service.de/index.php … s-zu-klein

ich würde das umstellen, da es auch sonst nur Schwierigkeiten bei Nodes in kleinen Zoomstufen gibt.

Gruss
walter

Last edited by wambacher (2015-09-21 19:04:44)

streckenkundler · 2015-09-21 20:25:40

Skinfaxi wrote:

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.

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...

Sven

wambacher · 2015-09-21 21:49:08

streckenkundler wrote:

Skinfaxi wrote:
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.
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.

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.

gruss
walter

Last edited by wambacher (2015-09-21 21:49:49)

Chrysopras · 2015-09-23 08:36:45

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:

streckenkundler wrote:

Wenn mich der Kleister packt, schnipple ich schon mal solche Dinger klein... Vor allem Straßen und Gewässer sind meine favorisierten Schnittkanten.

+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.

streckenkundler wrote:

Polygone mit mehreren einzelnen Outer löse ich eigentlich riegeros auf.

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.

streckenkundler wrote:

Polygone mit outer aus mehreren Liniensegmenten versuche ich zu vermeiden... klappt abet nicht immer.

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 )

streckenkundler wrote:

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...

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 ...

Edit: ergänzt.

Last edited by Chrysopras (2015-09-23 08:49:28)

streckenkundler · 2015-09-23 08:53:19

Chrysopras wrote:

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.

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.

Hier mal ein Beispiel mit einigen Totalreservatsflächen:
https://www.openstreetmap.org/relation/4763363

Den TR-Flächen habe ich die Rolle subarea beigegeben, diese sind ja Teilflächen des NSG mit anderen Regelungen, gehören aber eben zum NSG dazu.

Sven

Chrysopras · 2015-09-23 08:57:43

streckenkundler wrote:

Chrysopras wrote:
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.
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 ...

Last edited by Chrysopras (2015-09-23 09:02:16)

Swen Wacker · 2015-09-23 09:17:13

Chrysopras wrote:

(aber 'einigen' und 'OSM' sind, glaube ich, zwei konfligierende Größen )

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).

Chrysopras wrote:

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.

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.

Chrysopras · 2015-09-23 10:04:19

Swen Wacker wrote:

Chrysopras wrote:
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.
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.

Siehe dazu diesen Thread, v.a. Posting #7 von Tordanik. Ich denke, dass er (leider) recht hat: de facto wird gerade landuse=forest oft (meistens?) im Sinne von landcover=trees verwendet.

Ich schließe mich der Unterscheidung von landuse=* und landcover=* ja gerne an; nur zwei Anmerkungen dazu:

* Es wäre eben toll, wenn wir mal eine Abstimmung zu landcover=* hinbekommen würden, um landcover=* endgültig und klar definiert hinzubekommen. Ich weiß, wie umstritten die Abstimmungen sind, aber gerade in diesem Fall wäre es echt schön ... irgendwie ist das Tag noch nicht so recht etabliert und definiert.

* Die Unterscheidung von landuse=* und landcover=* wird nicht alle Unklarheiten in den existierenden Daten lösen. Das zeigt sich gut am angesprochenen Beispiel des Waldsees: schon bisher haben wir in der Datenbank viele Seen, die aus dem Wald ausgestanzt sind, und viele, die es nicht sind. (Ich kann keine Statistik bieten, aber es gibt auf jeden Fall zumindest hier in Baden-Württemberg von beiden Varianten eine ganze Menge Vorkommen.) Sollen wir alle Waldflächen dann in landcover=trees umtaggen? Zumindest besser nicht automatisch. Ansonsten müssen wir, gerade im Fall von landuse=forest, die Ambivalenz beibehalten. Denn wenn wir landuse=forest wirklich rein als landuse verstehen und nicht mehr als "von Bäumen bedeckt", dürfte ein Renderer es ja eigentlich nicht mehr automatisch mit Bäumchen o.Ä. rendern, oder? Dafür bräuchten wir dann lauter extra landcover=trees-Flächen. Auch nicht gerade einfach

Last edited by Chrysopras (2015-09-23 10:05:05)

Chrysopras · 2015-09-23 10:44:57

Nachtrag: und hier ist noch ein Thread u.a. zu diesem Thema. Ich schlage vor, dass wir die Diskussion über auszustanzende Waldseen etc., die ich da versehentlich angestoßen habe (ich wollte doch bloß ein einfaches Bsp. nennen ... Mist, danebengegangen ) ggf. in den anderen Threads fortführen und uns hier auf Skinfaxis Thema: die Maximalgröße von landuse-Flächen und -MPs beschränken. (Ich sage das, weil ich leider Mitschuld bin, dass das Thema hier ausufert. Sorry!)

Skinfaxi · 2015-09-24 18:19:20

ich fand den Seitendraht sehr erhellend und gut. Danke fuer den Hinweis! Letzlich ist die Frage der Grösse von landuse Flächen ja _eine_ Möglichkeit, die Kompelität der Daten zu verkleinern.

Die andere ist die Unterscheidung. Und die Frage, wieso wir automatisch wissen, das Häuser und Strassen nicht bewachsen oder unter Wasser liegen, das ei anderen Elementen aber nicht, ist fuer mich sehr interessant. Wieso sind Sportplätze nie bewachsen - Seen aber?

Letzlich verstehe ich auch denn Vorteil dieses ausschneidens (oft) nicht. Was macht dass denn an der Datenstruktur klarer? Was sich logisch herleiten lässt muss doch nicht redundant i die Datenbank eingetragen werden, dass macht doch nur unsinnig Arbeit.

Thoschi · 2015-09-24 19:42:48

Es ist m.E. grundsätzlich nichts gegen das Ausstanzen von Seen oder anderen "Inseln" aus landuse-Flächen etc. mittels Mulitpolygonen auszusetzen. Worüber man sich eher Gedanken machen sollte, sind zum einen teilweise sich über mehrere Quadratkilometer erstreckende Flächen, die zum einen manchmal gar nicht so stimmen (da werden landwirtschaftliche Flächen als forest bezeichnet und dann obwohl gar keine Insel die landwirtschaftliche Fläche "ausgestanzt"), zum anderen sollte man sich über eine stringentere Formulierung und Abgrenzung von landuse, landcover, natural etc. verständigen.
Wenn ich natural scrub habe, ist es dann z.B. Teil von landuse=farmland oder landuse=forest oder steht es allein ohne ein landuse. Und wenn dem so ist, dann müsste das Wiki auf jedenfall die Abgrenzungen und Zusammenhänge genauer darstellen, damit da nicht nur die landcover-Spezialisten eine Chance haben, dies so umzusetzen. Mich verwirrt es jedenfalls häufig, bei mir vor allem, weil die Abgrenzung bzw. die Zusammenhänge nicht klar sind.

RadFr · 2015-09-25 13:54:52

Thoschi wrote:

Es ist m.E. grundsätzlich nichts gegen das Ausstanzen von Seen oder anderen "Inseln" aus landuse-Flächen etc. mittels Mulitpolygonen auszusetzen. Worüber man sich eher Gedanken machen sollte, sind zum einen teilweise sich über mehrere Quadratkilometer erstreckende Flächen, die zum einen manchmal gar nicht so stimmen (da werden landwirtschaftliche Flächen als forest bezeichnet und dann obwohl gar keine Insel die landwirtschaftliche Fläche "ausgestanzt"), zum anderen sollte man sich über eine stringentere Formulierung und Abgrenzung von landuse, landcover, natural etc. verständigen.
Wenn ich natural scrub habe, ist es dann z.B. Teil von landuse=farmland oder landuse=forest oder steht es allein ohne ein landuse. Und wenn dem so ist, dann müsste das Wiki auf jedenfall die Abgrenzungen und Zusammenhänge genauer darstellen, damit da nicht nur die landcover-Spezialisten eine Chance haben, dies so umzusetzen. Mich verwirrt es jedenfalls häufig, bei mir vor allem, weil die Abgrenzung bzw. die Zusammenhänge nicht klar sind.

Auch natural=scrub gehört ausgestanzt.
Als Argument für das Ausstanzen wurde hier mal das Berechnen von Flächen genannt.

Announcement

#1 2015-09-20 21:31:44

Multipolygone und maxgrösse von landuse

#2 2015-09-20 21:55:41

Re: Multipolygone und maxgrösse von landuse

#3 2015-09-20 22:16:44

Re: Multipolygone und maxgrösse von landuse

#4 2015-09-21 08:09:41

Re: Multipolygone und maxgrösse von landuse

#5 2015-09-21 08:55:04

Re: Multipolygone und maxgrösse von landuse

#6 2015-09-21 11:50:20

Re: Multipolygone und maxgrösse von landuse

#7 2015-09-21 13:11:38

Re: Multipolygone und maxgrösse von landuse

#8 2015-09-21 13:29:54

Re: Multipolygone und maxgrösse von landuse

#9 2015-09-21 13:31:15

Re: Multipolygone und maxgrösse von landuse

#10 2015-09-21 14:45:19

Re: Multipolygone und maxgrösse von landuse

#11 2015-09-21 15:37:32

Re: Multipolygone und maxgrösse von landuse

#12 2015-09-21 16:34:55

Re: Multipolygone und maxgrösse von landuse

#13 2015-09-21 17:11:22

Re: Multipolygone und maxgrösse von landuse

#14 2015-09-21 19:03:04

Re: Multipolygone und maxgrösse von landuse

#15 2015-09-21 20:25:40

Re: Multipolygone und maxgrösse von landuse

#16 2015-09-21 21:49:08

Re: Multipolygone und maxgrösse von landuse

#17 2015-09-23 08:36:45

Re: Multipolygone und maxgrösse von landuse

#18 2015-09-23 08:53:19

Re: Multipolygone und maxgrösse von landuse

#19 2015-09-23 08:57:43

Re: Multipolygone und maxgrösse von landuse

#20 2015-09-23 09:17:13

Re: Multipolygone und maxgrösse von landuse

#21 2015-09-23 10:04:19

Re: Multipolygone und maxgrösse von landuse

#22 2015-09-23 10:44:57

Re: Multipolygone und maxgrösse von landuse

#23 2015-09-24 18:19:20

Re: Multipolygone und maxgrösse von landuse

#24 2015-09-24 19:42:48

Re: Multipolygone und maxgrösse von landuse

#25 2015-09-25 13:54:52

Re: Multipolygone und maxgrösse von landuse

Board footer