wie soll man Ortschaften einzeichnen

Die residential-Fläche für den ganzen Ort ist ja nur ein Behelfskonstrukt, damit man bei leeren Ortschaften auch was sieht. Eigentlich sollte das nur dort verwendet werden, wo Wohngebiete sind. Und wenn man das so macht, muss man da nichts “ausklinken”. Dann sind die Flächen nämlich alle überschneidungsfrei nebeneinander.

Übliches Argument: Weil wir kein Rendering-only-Projekt sind, sondern auch beliebige andere Dinge erlauben wollen. Etwa statistische Auswertungen (“wie viel Prozent der Fläche im Ort sind Industriegebiet”), Heuristiken für Navigationsgeräte (“befinde ich mich in einem Wohngebiet?” => “oh, dann gibts hier vermutlich viele parkende Autos und andere Hindernisse”) und so weiter.

Was ein Renderer erkennen kann, kann auch ein Statistik-Programm erkennen.

Ausserdem könnte man jederzeit vollautomatisch alle übereinanderliegenden Flächen in Multipolygon-Konstrukte umwandeln, wenn das gewünschte ist. Darüber sollen sich diejenigen Gedanken machen, die sich um die OSM Datenstrukturen und um die Auswertung kümmern. Ich werde mir als gemeiner Feld-, Wald- und Wiesen-Mapper da jedenfalls keinen Wolf mappen. :wink:

Detlef

Ein Statistik-Programm, das sich mit landuse beschäftigt, will aber nicht die Bedeutung aller für Löcher möglichen Tags kennen (und soll sie nicht kennen müssen). Außerdem ist noch lang nicht gesagt, dass ein Renderer das tatsächlich kann. Sobald du einen Renderer hast, der übereinander liegende Flächen nicht deckend, sondern transparent malt, ist das Ergebnis vielleicht nicht mehr so toll. :wink:

Ein building=yes ist kein Loch im Wohngebiet. Ein landuse=industrial schon. Ganz zu schweigen von Problemfällen mit layers: Ich habe hier z.B. einen Parkplatz, der einen Teil der Fläche eines Supermarkts bedeckt (weil er auf dem Dach ist) und einen anderen layer hat. Da soll dann natürlich kein Loch in den Markt gestanzt werden. Das gilt wohl eigentlich für alle Flächen auf unterschiedlichen Ebenen. Leider fallen damit auch alle der Einfachheit halber mit layer=-5 versehenen landuse=residential durch das Verfahren.

Kurz: Das ordentlich hinzubekommen, erfordert Wissen um die Bedeutung der Tags und die Situation in der Realität, keine doofe Automatik.

Kann man auch nicht von dir verlangen. Sollte nur klar sein, dass es sich nicht um eine “geht doch problemlos automatisch”-Situation handelt, sondern eine “mir unwichtig, erfasse ich nicht”-Situation.

Hier kommt dann aber wieder unser alter Spruch zum tragen: “Wir mappen nicht für den Renderer”.
Soll bedeuten das diese Programme wahrscheinlich noch nicht ihren Endstand in der Entwicklung erreicht haben. Von daher sollten sich die Renderer eher dem Mapper (der Praxis) anpassen, als umgekehrt. Voraussetzung ist natürlich das die z.Zt. bestehenden Regeln in der Form wie sie in den Features und auf How to Map gelistet sind, eingehalten werden das sollte selbstverständlich sein!
Wo jedoch kein Konsenz besteht ist guter Rat teuer.
Wo steht eigentlich das landsue=residential nur für noch nicht vollständige Wohngebiete verwendet werden soll? In den Features jedenfalls nicht. :expressionless:
Georg

Das Ding ist, dass landuse=residental nur für Wohngebiete verwendet werden soll, und nicht für Industriegebiete etc. Wenn ich meinem Renderer z.B. sage, dass er nur Wohngebiete rendern soll, dann hätte ich dann schonmal ein Problem, denn dann erscheinen auf einmal alle Industriegebiete als Wohngebiete…

Für das “Dass man schonmal was sieht” sollte man lieber dem Renderer beibringen place-polygone zu rendern.

Ok, aber doch nur wenn die landuse=industrial und landuse=residential übereinander liegen oder verstehe ich da etwas falsch? Ich habe es bisher immer so gemacht das ich die Gebiete nebeneinander gelegt habe und nicht übereinander…?!
Georg

… oder Du benutzt Multipolygone mit entsprechenden “Löchern” für landuse=industrial etc.

In diesem Fall ergibt sich das ja noch relativ klar. Aber wie sieht das aus, wenn da ein Park in einer Ortschaft liegt? Ist da, wo der Park ist, auch gleichzeitig ein Wohngebiet, wenn rund um den park herum Wohnhaeuser stehen? Wie sieht es aus mit einem See im Wald? Gehoert die Wasserflaeche mit zum Wald?

Sobald sich Flaechenpolygone ueberschneiden ist die Sache einfach nicht mehr eindeutig und kann unterschiedlich interpretiert werden. Meiner Meinung nach sollte sowas aber vermieden werden. Am besten entscheiden, was gemeint ist, kann grundsaetzlich nur der Mapper vor Ort. Und damit eine eindeutige Umsetzung garantiert ist, gilt fuer mich, dass sich Flaechenpolygon nicht ueberschneiden duerfen.

Kleine Einschraenkung dazu: Das gilt natürlich nur fuer “gleichwertige” Polygone. Es gibt auch ein paar Ausnahmen, bei denen eine hierachische Struktur selbstverstaendlich oder (noch besser) klar definiert ist. Die wichtigste Ausnahme ist sicherlich building=yes, bei dem eindeutig klar ist, dass es sich um einen lokalen Zusatz zum landuse handelt und nicht getrennt von diesem gesehen werden soll.

Gruss
Torsten

In Traveling Salesman wird “place” für die Adress-Suche und die Entscheidung ob man sich innerorts befindet genutzt.
Gerendert wird dagegen natürlich nur landuse. Wobei natürlich beide Polygone existieren können und auch problemlos
ein Polygon als beides gleichzeitig getagged sein kann.

Einige verwenden statt place= auch boundary=administrative mit admin_level=8 . Ich unterstütze beides. (auch gleichzeitig)

Ja genau das meinte ich. Also wenn der ganze Ort als residental eingezeichnet ist, und dann darin ein industrial liegt, dann ist das ein Problem. Die Gebiete nebeneinander zu legen ist genau richtig. Oder wie Rundling schon sagt mit Multipolygonen, die sind bloß momentan noch ziemlich kompliziert.

Es geht primär um die landuse tags, die sich eigentlich nicht überlagern können. Seen und Parks werden ja mit natural bzw. leisure beschrieben. Ein kleiner See oder Park kann natürlich genausogut in einem Wohngebiet liegen wie ein Haus. Bei größeren Seen oder Parks sieht das dann natürlich wieder anders aus. Da muss dann der Mapper vor Ort entscheiden, ob er der Meinung ist, dass der Park noch zum Wohngebiet gehört, oder nicht…

Häh…?
Unter JOSM hat man die Dinger schneller angelegt, als wie drei Bier im Ballermann zu bestellen.

Ich mache das über Multipoloys.

Der ganze Ort bekommt seine Fläche als geschlossene Ortschaft. Dieser Weg ist der Place mit den Informationen zum Ort und begrenzt damit deckungsgleich auch die Straßen mit ihren Ortseingangsschildern. Damit hat man die genaue Abgrenzung zwischen geschlossener Ortschaft und Umland.

Dieser Weg wird gleichzeichtig als Landuse Residential und Outer im Multipoly genutzt. Residential stellt in den allermeisten Fällen ohnehin die größte Fläche. Darin als Inner alle anderen Flächenutzungsarten. Kein Ort ist wie der andere, das verschachteln in Multipolys funktioniert immer. Irgendwie daneben oder drumherum dagegen weniger. Drauf schon garnicht, außer man missbraucht die Layer. Spätestens Sportanlagen und einige andere Flächenutzungsarten, kann kein Renderer ohne Hilfe vernünftig sortieren. Da bleibt nur Layer missbrauchen oder eben in Multipolys verschachteln.

Ein großes Problem sind die vor allem die teilweise mehrfach vorhandenen Nutzungsarten. Ein Park in einem Wohngebiet gehört eigentlich zum Wohngebiet dazu. Man kann diesen aber nicht direkt in die eigentliche Nutzungsfläche einbetten. Man kann ihn nur als eigenständige Nutzungsfläche per Multi ausschneiden oder eben darüber legen.

Und warum glaubst du dass sich die Semantik des Multipolygons dabei nur auf die landuse-Eigenschaft und nicht auf die place-Eigenschaft ausweitet?
Das kann man genausogut als Stadt mit Löchern interpretieren.

Marcus

Viele Mapper haben Probleme damit, und die Renderer ganz offensichtlich auch. Ich gehe aber davon aus, dass sich das in Zukunft ändern wird.

Das ist wahr. In dem Fall würde jede andere Flächennutzung im Ort, die als inner in der Relation steht, als Loch im Ort angesehen, und gehört damit nichtmehr zum Ort.

Parks und Seen sind keine Landuses. Wenn die zum Wohngebiet gehören musst du also genausowenig ausschneiden, wie die einzelnen Häuser…

Ich glaube hier garnichts. Das ist nur die einzig mir sinnvoll erscheinende Möglichkeit, das ganze gebündelt und einigermaßen geordnet unter einen Hut zu bringen. Das ganze daneben, drüber, drunter drumherum bringt es auch nicht und ist dann teilweise schwer zu bearbeiten und kaum zu durchblicken.

Es liegt an euch Softwareschubbsern da mal etwas brauchbares einheitliches auszutüfteln. Am besten gleich noch Software welche die 90% Windows Nutzen auch nutzen können, ohne das sie sich ganze virtuele Server installieren müssen, was kein normaler Anwender machen wird und OSM links liegen bleibt. Gut anderes Thema.

Im Moment kann man alles oder nichts. Und solange nichts einheitliches steht, wird sich daran auch nichts ändern. Und wie Inner ausgewertet wird, Loch oder innenliegend, entscheidest doch letzendlich du. Wenn du deiner Software Loch beibringst, wird sie das als Loch werten. Da musst du uns schon sagen was Sache ist. Die Mapper können es nicht riechen. Wir mappen nur, wenn wir Programmierer wären, würden wir Routingsoftware schreiben.

Ein inner einer Multipolygon-Relation besagt, dass es ein Loch ist. Genau dafür gibt es diese Relationen. Für place und landuse den gleichen way mit der gleichen Multipolygon-Relation zu benutzen macht garkeinen Sinn. Wenn ich der Software sage, dass inner ein Loch ist, dann gehören die inner-landuses nichtmehr zum Ort. Wenn ich der Software sage, dass inner “innenliegend” bedeutet, dann bräuchte man 1. die Relation überhauptnicht, und 2. würden dann die inner-landuses immer zum Wohngebiet gehören, was auch falsch wär.

Mal etwas aus der Praxis.

Zeichne mal einen Park im Wohngebiet, in dessen Mitte steht ein Haus, was auch noch einen Innenhof hat. Daneben ein Sportzentrum, darauf einen Fußballplatz mit umlaufendem Laufweg, ohne diesen künstlich zu teilen. An einem Spielfeldende zwischen Spielfeld und Laufweg einen Anlaufweg mit Sprunggrube. Das ganze ohne Layer zu missbrauchen oder per Multipoly. Wenn das der Renderer sauber verarbeitet, gibts tausend Gummipunkte. :smiley:

Das wiederum ist ein Problem der Softwareschubser der Renderer. Denn der Fußballplatz und die Sandgrube gehören ja z.B. ganz offensichtlich zum Sportzentrum… Einzig das Haus mit dem Innenhof wäre ein Fall für eine Multipolygon-Relation.

Das Haus wird dir auch unterm Park verschwinden… Und wenn man nach deiner Logik geht, müsste der Innenhof ja auch automatisch erkannt werden.

Relationen dienen der Zusammenfassung. Deswegen erfassen wir Dinge die mehrere Wege nutzen in Relationen und malen keine virtuellen Wege nebeneinander. Aber auch das kommt vor.

Inner ist auch nicht hole oder clip. Vielleicht sollte man desshalb das ganze erweitern und unterscheiden. Innenliegend und ausgeschnitten.

Doch, denn Place grenzt als Way den Place ein. Gleichzeitig begrenzt es die Landnutzung. Alles ein leicht zu handelnder Abwasch. Sinnvoller wäre dann also einen seperaten Weg nah an die Flächen um den Ort zu pinseln. Wo man dann beim ändern über Stunden jede Doppelnode rumzuppeln muss, und dabei höllisch aufpassen muss, nichts zu übersdchneiden oder gar falsch zu verknüpfen? Das wäre eher etwas für den Razor Award, Usability ist anders.

Ich sage inner und nicht cut. Hier hinkt wie schon geschrieben die Umsetzung der Idee Multipoly.

Aha, damit wären Relationen als Zusammenfassung komplett hinfällig. Alle reden darüber, nur bisher hat noch keiner etwas in der Richtung umgesetzt. Ich sage nur geschlossene Ortschaft usw. Es gibt keine Software die Zusammenhänge automatisch erkennt. Nur über Hilfen wie is_in z.B. Zwei übereinanderliegende Flächen sind derzeit technisch einfach zwei übereinanderliegende Flächen ohne Bezug zu irgendwas, haben ja keine Hilfe die einen Bezug herstellen kann.

Meine Idee war eben diesen Bezug per Relation herzustellen, ohne an jedes Element eine Bezugshilfe heften zu müssen. Gleichzeitig ist das leichter zu bearbeiten, als ein Flickenteppich aneinander gewürfelter Flächen, wo Fehler fast unvermeidbar sind.