Wir brauchen feste Regeln für die Verwendung von Multipolygonen!

Genau das ist der springende Punkt. In den Beispielen sind erkennbar alle befestigten Flächen auf Privatgrundstücken ausgespart.
Es gibt wie im OSM-Wiki nachzulesen ist, derzeit zwei zulässige Nutzungen von landuse=residential.
Die eine entspricht dem, wie z.B. Bebauungspläne aufgebaut sind. Ein bestimmter Bereich wird als Wohngebiet ausgewiesen inklusive der Wohngebietsstraßen (Zone 30), die durch dieses Wohngebiet führen und es erschließen.
Die andere Nutzung will die tatsächlichen Wohngrundstücke darstellen. Bei dieser müssten dann alle öffentlichen Straßen, Wege, Fußwege, Plätze ausgespart werden.
Das Wohngrundstück selber besteht aber auch aus verschiedenen Elementen: Haus, Garage, Fahrzeugabstellfläche, Grundstückszufahrt, Terrasse, Rasen, Vorgarten, Hecken, Fußweg zur Haustür…
addresshistoryorg spart nun alle auf den Luftbildern als befestigte Fläche erkennbaren Flächen aus. Und dies ohne Rücksicht darauf, ob sie Teil des Wohngrundstücks sind oder öffentliche Fläche. Dabei sind diese privaten Wegeflächen eindeutig Teil der Wohngrundstücks. Teilweise spart er sogar die Wohngebäude aus.
Ebenso hält er es bei Bauernhöfen. Doch auch hier gilt: Die befahrbaren Wirtschaftsflächen sind untrennbarer Bestandteil des Bauernhofs ebenso wie die dort befindlichen Scheunen und Ställe.
Er begründet dies damit, dass dadurch erkennbar sei, wo man z.B. als Postbote hergehen könne, um zur Haustür zu gelangen oder wo z.B. das Müllfahrzeug herfahren kann. Das ist aber ein Trugschluss (und “tagging for renderer”). Denn die tatsächliche Information ist nicht: “Dort ist eine befahrbare Fläche” sondern “diese Fläche ist nicht Teil des Wohngrundstücks” oder “diese Fläche gehört nicht zum Bauernhof”. Zum Darstellen von befahrbaren Flächen gibt es geeignete Möglichkeiten, die man über den landuse=residential oder landuse=farmyard hinüberlegen kann, nämlich "area:highway=
" oder “highway=* in Verbindung mit area=yes”. Und wo man tatsächlich zur Haustür gehen kann oder mit dem Postauto reinfahren, kann man hinreichend durch lineare ways darstellen mit dem acces-tag “private”. Dadurch, dass man diese Wegeflächen ebenso wie die Gebäudeflächen über die landuse-Fläche legen kann, werden die landuse-Flächen als netter Nebeneffekt auch einfacher bzw. nicht so stark zerstückelt.
In einem anderen Beispiel führt addresshistory*org einen Supermarkt auf, bei dem der Parkplatz in OSM als Punkt eingetragen ist und stellt eine andere Kartenbasis dagegen, bei der die Parkplatzflächen dargestellt werden. Er meint, durch das Aussparen der Parkplatzfläche aus landuse=retail oder landuse=commercial würde hier die Information über die Parkplatzfläche. Aber auch hier wird nur durch die vom Renderer farblos dargestellte Fläche etwas vorgegaukelt. Denn auch hier enthält die ausgesparte Fläche keinerlei Informationen darüber, was sich dort befindet. Dagegen ist das eintragen von Parkplätzen als Fläche (und nicht als Punkt) absolut gebräuchlich und wird von allen Renderern auch dargestellt und zwar als die landuse-Fläche überlagernde Fläche. Und auch hier gilt: Der Kundenparkplatz ist Teil des Supermarktgeländes. Er gehört demnach keinesfalls ausgespart.

+1 zu allem. Und dann funktioniert’s auch in anderen Anwendungen als der gerenderten Karte.

–ks

So ungefähr ab Beitrag #416 sind alle Beiträge o.T.
Warum hier vom Moderator noch nicht eingegriffen wurde, ist mir ein Rätsel.
Das ganze hat doch nichts mehr zu tun mit Multipolygonen, sondern nur noch um verschiedene Ansichten vom Flächentagging.
Es sollte von den Moderatoren ein eigener Thread aufgemacht werden.

Die Aussparungen der Wege, erst recht an Privatgrundstücken aus dem landuse=residential ist imho Quatsch. Privatgründstücke und deren Flächen inkl. Wege. sind eben bewohnte Flächen. Aber ein area der größeren privaten Einfahrten ist ok. Natürlich kann man streiten über die öffentlichen Strassen. Aber das Tagging mit landuse und dem area:highway Tagging beisst sich keineswegs. Das kann alles bestimmt zusammenbleiben. Fragt sich nur, wenn man Strassenflächen erfasst, wo setzt man die Grenze an (Ab welcher Straße / Straßenbreite), ab der es Unsinn wäre, diese Fläche als bewohnt anzusehen. Mit der Möglichkeit der immer besser werdenden Luftbilder ist es durchaus nicht die schlechteste Überlegung, alle Strassen über highway=residential hinaus aus dem landuse=residential auszuschneiden. Dadurch würde aber u.U. das landuse Tag durchgeschnitten. Was erhebliche Nachteile bringt bei Weilern, sehr kleinen Orten oder Ortsteilen. Man kann dann keinen Namen mehr auf dem landuse Tag verdaten, sondern braucht ein Node.

oder ein Multipolygon.:slight_smile:

siehe https://forum.openstreetmap.org/viewtopic.php?id=64923

Kennt jemand von euch schon das “Multipolygon des Grauens”? https://www.openstreetmap.org/relation/35867

Ich fass da sicher nichts an, aber dass das Gebilde überhaupt noch gerendert wird, ist erstaunlich.

Jetzt, wo Du es erwähnst (schöner Fund! danke!), erinnere ich mich, dass ich schon mal über dieses MP gestolpert bin, als ich bei Würzberg etwas korrigieren wollte. Ich habe dann ganz schnell das Weite gesucht, als ich gesehen habe, mit was ich es da zu tun habe. Das war feige, sicher, aber es belegt, dass solche MPs auch einigermaßen erfahrene Mapper abschrecken …

Das Ding sollten wir wirklich in beherrschbarere Einheiten zerlegen. Ich fürchte übrigens, dass es durchaus noch gruseligere MPs in unseren Daten gibt …

Ich finde das gar nicht mal so besonders. Hat gerade mal knapp über 4000 Nodes. Das ist doch nun wirklich kein Grund zum Davonlaufen.
Man könnte allerdings wohl zumindest mal die winzigen Stücke zusammenkleben, um die Anzahl der Member zu verringern.

Das ist doch gar nichts – Ganz Ungarn und Rumänien bestehen aus solchen MPs. Hier gibt es eine Liste (komischerweise unter “Ungarn” im Wiki platziert, obwohl sie auch Rumänien enthält): Klick

Das sind diese ominösen “CORINE Land Cover (CLC)”-Importe, über die ich auch schon in Finnland gestolpert bin. Gibt es vermutlich überall in der EU.

Die Idee dahinter ist ja nicht schlecht, da wollte jemand den Odenwald komplett als ein Waldgebiet dargestellt haben. Doch hat ja die Diskussion hier: https://forum.openstreetmap.org/viewtopic.php?id=64923 gezeigt, dass es dafür bessere Möglichkeiten gibt, als ein landuse-multi-Poligon. Ich möchte hier nur eins einwerfen: Bei landuse=forest ist ja u.A. vorgesehen, die Baumart anzugeben. Nadelwald, Laubwald und Mischwald werden dementsprechend in der Standartkarte auch unterschiedlich dargestellt, Wenn man das umsetzen möchte, muss man Waldflächen entsprechend der Bestandsflächen sehr kleinflächig eintragen.

Damit entfällt zwar die Notwendigkeit, den gesamten Odenwald als ein Objekt zu erfassen, an Multipolygonen kommt man trotzdem nicht vorbei. Zumindest habe ich für solche Fälle in diesem langen Faden, in dem zur Abstimmung gestellten Empfehlungen und auch nicht in Frederiks Checkliste keinen Hinweis gefunden, wie man solche Situationen ohne MP in OSM abbilden kann. Vielleicht kann das mal jemand beispielhaft an dem Gebiet zwischen St2311, MIL7 und der Verbindungsstraße Würzberg-Hesselbach machen.

Ach, wo denkst Du hin :wink:

https://www.openstreetmap.org/relation/3957497 ist eine Insel mit 460.000 Punkten.

Insgesamt gibt es rund 50 Polygone mit mehr als 100.000 Punkten (Grenzen dabei nicht mitgezählt). Auf den ersten Blick scheinen mir die meisten davon Seen oder Inseln zu sein, der größte Wald ist

https://www.openstreetmap.org/relation/8319625

mit 280.000 Punkten. Da kann schonmal der Lüfter im Laptop hochdrehen, wenn man die URLs anschaut :wink:

Bye
Frederik

Mein Laptop stand kurz vorm explodieren… :stuck_out_tongue:

Hallo Zusammen,

klammert man mal eine mögliche Namensverwendung aus, welche Gründe könnte es denn dann noch geben z.B. ein Landuse-MP (als type=multipolygon) mit mehreren in sich geschlossenen Outer-Rollen anlegen zu müssen? Mir fallen keine ein…

Das ist genau der Hintergrund, daß OSM diese Möglichkeit zum detailierten Mapping bietet und ich sehr dafür bin, dies auch zu nutzen… Sehr oft sind noch MP’s anzutreffen, wo nichts detailiert ist… man gerade ist ein See als inner vorhanden, nicht aber ein am See angrenzender Moor-Bereich, mit ggf. Bruchwald, ect… Da funktioniert das mit dem Namen am MP oft nicht mehr, da nach detaliertem Mapping aus einer erfassten Waldfläche gerne mal 2,3 oder 4 werden können… Die Namensgeschichte muß in meinen Augen in einer völlig separate Datenebene sein.

Es geht doch nicht darum einen Weg völlig ohne MP’s zu finden. Es geht darum, daß diverse Dinge, die bisher als MP erfasst worden sind, dafür aber unnötig sind und simple Flächen (geschlossene Linienzüge) ausreichen und daß übergroße und nicht mehr händelbare MP’s verhindert werden.

Sven

Gerade gefunden: wofür meiner Ansicht nach MP’s nicht gedacht sind:
https://www.openstreetmap.org/relation/9187648
da wäre type=site besser… habs mal kommentiert…

Sven

Richtig, es geht darum, die Größe von (Landuse-)Flächen auf ein handhabbares Maß zu beschränken, so dass man sie nicht in MPs zu packen braucht oder nur MPs überschaubarer Größe bilden muss.

Da kommt man auch ohne site aus, weil zur Siedlung sicherlich auch die Gärten zwischen den Häusern gehören :wink: Also einfach einen RIng um das Ganze und place=neighbourhood dran…

Naive Frage: Gibt es evtl. eine sinnhafte Möglichkeit, in einem solchen Fall analog zu “Superrouten” bei Fernwanderweg-Relationen eine Art “Super-MP” anzulegen, das Teil-MPs/-Teilflächen zum einem Konstrukt namens “Odenwald” kombiniert und dann - was offensichtlich von einigen hier gewünscht wird - auch in den gängigen Renderern als “Odenwald” angezeigt wird?

Ich würde dafür im Moment boundary=region nutzen… ggf. Bei Bedarf auch als Relation… Eventuell sollte das auch auf mittel- bis großflächig definierte Wald- oder Offenlandbereiche spezifiziert werden.

Sven