Ich kann mir kaum vortellen, dass man in Italien so eine geradlinige Forstpflege betreibt :D.
Was steckt hinter diesen rechtwinkligen Waldformen? Ist das irgend ein Bearbeitungsfehler, der sich durch einen Fachmann (ich habe da nichts angefasst, da mir die tiefgründigeren Kenntnisse fehlen) schnell beheben lässt oder ist das vielleicht immer noch ein “Rest” des Lizenzwechsels?
edit: Diese merkwürdigen Waldformen treten in einem großen Bereich bis Slovenien auf!
Ich konnte auf die schnelle keinen Taggingfehler entdecken. Auch scheint es schon einige Tage/Wochen so zu sein. Kann jemand prüfen ob da großfläschig gelöscht wurde?
Beim Auschnitt in Italien hat ein User offenbar blockweise Importe durchgeführt. Bei description zum Changeset steht
Regione_del_Veneto_LR28_16.7.1976_Formazione_CTR_auth_39164-5700-1100_23.01.2009.
Nein, hab doch geschrieben, dass es kein mapping/tagging-Fehler ist. Die Karte ist in allen Zoomstufen und auch im anderen Kartenstil ohne Wald.
Die Multipolygone sind so eckig gemappt. Es sieht eher danach aus, als fehlt jeweils das angrenzende MP (komplett). lso entweder gelösct oder nur es sind nur Teilimporte erfolgt…
Einen ähnlichen Multipolygon-Fehler gibt es seit einigen Wochen südöstlich von Berlin (http://www.openstreetmap.org/?lat=52.1755&lon=13.8505&zoom=12&layers=M). Habe kurz versucht, ein Problem mit den Daten zu finden, dann aber aufgegeben. Ich halte eh nichts von diesen geometrischen Riesenkonstrukten, nur um den einen oder anderen semantischen Zusammenhang deutlich zu machen.
Gefixt. Die Relation hatte nicht den Typ Forst, sondern die äußere Linie. Außerdem hat sich die äußere Linie selbst berührt und ein innenliegendes Auge gebildet. Dort habe ich die äußere Linie aufgetrennt, die inneren Elemente in die Relation eingebunden und die übrig gebliebene Forst-Linie um das Auge herum gelöscht. Changeset: http://www.openstreetmap.org/browse/changeset/15066164
Achja, und ich glaube, die äußere Linie war nicht geschlossen, sonst wären nämlich auch keine zwei äußeren Linien entstanden, als ich das Auge bearbeitet habe. Am Ende/Anfang der beiden Linien musste ich die Nodes vereinigen. Das hat zum Glück Josm gefunden, bei einer schnellen manuellen Durchsicht hatte ich die Stelle nicht erkannt.
Allerdings ist Mapnik manchmal auch toleranter gegenüber solchen Fehlern, sowohl was die Tags am Multipolygon angeht als auch nicht sauber geschlossene Ringe.
Freut mich, dass du ein paar Details im Luckauer Becken repariert hast.
Je mehr ich darüber nachdenke, desto weniger halte ich es für sinnvoll, alle diese Waldwiesen und Lichtungen auszustanzen, was der Hauptanwendungsbereich von Multipolygonen zu sein scheint (sie stattdessen einfach nur einzuzeichnen). OSM ist ja kein Kataster und auch kein Flächennutzungsplan. Alle guten traditionellen Karten, mit denen ich so unterwegs haben, haben Situationen auch immer so wiedergegeben, wie sie örtlich am meisten Sinn machen, und mit einem Liegenschaftsplan möchte niemand eine Radtour machen ;-).
Ich muss aber auch zugeben, dass ich zwar jetzt ein Gebiet kartiert habe, das ziemlich unterschiedliche Bereiche hat, aber noch nicht davon sprechen kann, weise geworden zu sein bzgl. der OSM.
Sehe ich auch so - aber ein Wald besteht aus Abschnitten, Hagen, Fortsbereichen, … und kann somit auch in kleinen Flächen angelegt werden. Und wenn ich neben einer Straße/Bach entlang den forest aufteile. Und auch Ackerland und Wiese …
Deswegen bin ich der Meinung, dass man für Landuseflächen durchaus mit Multipolygon arbeiten sollte. Jedoch bevorzugt mit “einfachen” Verschachtelten Multipolygonen und nicht mit “Mehrere Wege bilden verschachtelte Multipolygone”. Der Unterschied ist der, dass in der “einfachen” Variante geschlossene Way’s die Grundlage bilden (Wie bei einem Haus mit Loch ). Daher auch eine begrenzte Fläche verwendet wird. So ist es wesentlich einfacher für angrenzende Objekte (die dann nicht zwangsläufig ebenfalls in einzelne Way’s zerlegt werden müssen.) Ein weiterer Vorteil ist, dass die Landuse-Attribute am way bleiben können und somit auch eine optische Darstellung der Fläche im Editor erfolgen kann. Die way’s sind lediglich Mitglied (als inner oder outer) der Relation (Simples Beispiel von gestern: http://www.openstreetmap.org/browse/relation/2771934)).
Ihr habt ja recht, und ich mache das im Grunde auch so, aber es ist halt je nach Blickwinkel in der Wirklichkeit auch gerne anders. Weiden (meadows) im Wald unter Bäumen, Baumgruppen auf Wiesen mit Gras darunter, und eben die hier ja schon zur Genüge bekannten Diskussionen darüber, was nun als Forst gilt, also mit den Wiesen und Lichtungen. Die Systematik von OSM ist nun mal nicht systematisch, sondern historisch gewachsen und eh je nach Land/Gegend/Dorf unterschiedlich gehandhabt. Die Flächennutzung als ganze müsste Forst sein, und dann darin unterschieden zwischen Baumbestand und Heide, Wiese, Busch etc., mit default bei landuse=forest eben Baumbestand.
Wir müssen das hier aber nicht diskutieren, ich hoffe mal, dass OSM irgendwann mal eine klare und trotzdem flexible Ontologie bekommt. Ist ja zum Glück alles in digitalen Datenbanken.
). Daher auch eine begrenzte Fläche verwendet wird. So ist es wesentlich einfacher für angrenzende Objekte (die dann nicht zwangsläufig ebenfalls in einzelne Way’s zerlegt werden müssen.) Ein weiterer Vorteil ist, dass die Landuse-Attribute am way bleiben können und somit auch eine optische Darstellung der Fläche im Editor erfolgen kann. Die way’s sind lediglich Mitglied (als inner oder outer) der Relation (Simples Beispiel von gestern: