Mit der OSM-Carto-Version 2.33.0 vom 14.08.2015 (Internationaler Kartenstil) wurde das Rendering von Waldflächen geändert.
Das Baum-Muster wird jetzt generell über die gesamte Waldfläche gezeichnet.
Dies hat zur Folge, daß es auch auf ALLEN Flächen erscheint, die die Waldflächen überlagern, aber nicht ausgeschnitten sind.
Beispiel:
Gruß Klaus
Ist so gewollt. Hauptproblem ist dass ein landcover=trees kaum verbreitet ist damit landuse=forest so interpretiert wird dass die Fläche überall mit Bäumen bedeckt ist. Weiterhin problematisch ist es dass natural=water viele Einsatzgebiete umfasst (vom Teich zum großen See) und damit eine Definition was zum Wald gehört und was nicht schwierig ist.
Hier das Issue: https://github.com/gravitystorm/openstreetmap-carto/issues/1754
nicht schlecht für Waldfriedhöfe und Mangroven 
. War schon Thema im Nachbar-Mapnik-Thread.
Ich werde bei Teichen die man zum Wald gehörend definieren kann still halten und weitere Entwicklungen abwarten anstatt jetzt losrennen und lauter Multipolygone erstellen.
Auf der Wiese unten im Bild scheinen auch reichlich Bäume zu stehen.
Ließen sich potentielle Problemflächen irgendwie per Overpass-Abfrage ermitteln?
Gruß Klaus
landuse=forest bedeutet gegenwärtig tatsächlich “ist mit Bäumen bedeckt”. Ja, es passt nicht zum Schlüssel “landuse”, aber wurde eben vor Jahren entsprechend umdefiniert. Von daher sollte dort tatsächlich ein Multipolygon angelegt werden.
Speziell den landcover-Fans sei gesagt: Einen neuen Schlüssel führt man nicht ein, indem man in diversen Threads so tut, als sei er existent und etabliert. Unternehmt bitte mal konkrete Schritte (z.B. eine Abstimmung) zur Einführung des Schlüssels.
Kann mir jemand erklären, warum
area[name="Lüneburg"]->.b;
way(area.b)["landuse"="forest"];
map_to_area -> .a;
way(area.a)[natural=water];
(._;>;);
out meta;
nur teilweise funktioniert? http://www.openstreetmap.org/way/44064845 wird gefunden, http://www.openstreetmap.org/way/27822178 aber nicht.
Ich weiß zwar nicht, wie man Deine Abfrage besser macht, aber der Unterschied zwischen den beiden Wäldern ist, dass der eine Wald Teil einer Relation ist (Relation: Böhmsholz (1321003) | OpenStreetMap - allerdings mit dem landuse auf dem Outer, statt an der Relation) und der andere nicht.
Hallo,
das hängt mit den Regeln für der Erstellung der Areas zusammen. Diese Regeln beschreiben, aus welchen Relationen und Wegen überhaupt eine Area berechnet wird. Nur wenn diese Area vorliegt, klappt auch die beschriebene Art der Query. Als “Endkunde” kann man an diesen Regeln allerdings nichts unmittelbar ändern, das müsste Roland direkt auf dem Server anpassen.
Wie man hier sieht, werden zwar Relationen mit type=multipolygon berücksichtigt. Das geschieht allerdings nur dann, wenn die Relation auch ein name-Tag trägt. Analog gilt das auch für die Ways mit landuse=* - auch dort muss ein name-Tag gesetzt sein.
Gruß,
mmd
Hallo nochmal,
alternativ kann ich noch folgendes anbieten, was allerdings zur Zeit ausschliesslich auf der dev-Instanz läuft: http://overpass-turbo.eu/s/b29
Damit werden auch landuse=forest Ways ohne name-Tag berücksichtigt. Was hier natürlich noch fehlt ist die Betrachtung von Relationen…
Leider kann ich in der foreach-Schleife kein out meta; für ein Editieren in JOSM einbauen, da die Query sonst sehr langsam wird (Ticket dazu gibt es auf Github).
Gruß,
mmd
Danke, mmd, für die Hinweise. Wieder was gelernt.