[Talk-de] Wald aufteilen um Namen anzuzeigen?

[Roland Olbricht]

Hallo zusammen,

> Wenn du möchtest, dass der Käfertaler Wald wieder gerendert wird, musst
> du ihn so eintragen, wie es gute fachliche Praxis ist.

Aus wessen Fach? Ich kenne andere Meinungen.

> Für den gesamten Käfertaler Wald legst du ein Multipolygon an, das aus
> zwei outer-Inseln besteht – eine nördlich der A 6, eine südlich davon,
> ggf. noch weitere Inseln, falls es zwischendrin breite Schneisen durch
> Straßen/Stromleitungen/... gibt. Das Multipolygon trägt die Tags

Generell sind großflächige Relationen aus technischer Sicht heikel, und daher 
ist von deren Gebrauch eher abzuraten.

OSM unterstützt drei Arten von Gliederung. Das eine ist String-Gleichheit, das 
zweite ist räumlicher Bezug, das dritte sind Relationen.

String-Gleichheit ist effizient zu komprimieren, robust gegen Fehler und 
einfach zu verstehen. Z.B. trägt ein Großteil unseres Straßennetzes Tags wie 
highway=residential oder highway=motorway. Auch Filialen eines verteilten 
Systems lassen sich gut identifizieren, z.B. operator=Sparkasse.

Räumlicher Bezug entsteht dadurch, dass ein Objekt in einem anderen enthalten 
ist. Wenn man z.B. alle Sparkassen-Filialen in Mannheim finden will, kann man 
mit PostGIS, QGIS, der Overpass API etc. einfach den Umriss von Mannheim 
anlegen. Das ist für Datennutzer etwas anspruchsvoller als String-Gleichheit, 
aber für Mapper sehr bequem, denn die Bezüge stimmen ebenfalls automatisch, 
wenn man das Objekt am richtigen Ort plaziert. Und umgekehrt hilft die Lage 
geographischer Objekte oft, andere zu plazieren. Wenn ich weiß, dass mein 
Lieblingsrestaurant rechts im Einkaufszentrum XY ist, kann ich den Node 
ausreichend genau legen, ohne das Einkaufszentrum ausmessen zu müssen.

Das dritte Kriterium zur Gliederung sind Relationen. Sie haben erhebliche 
Unfallgefahr: man sieht der Relation nicht automatisch an, welche 
Eigenschaften wie Tags und räumliche Ausdehnung sie haben und schlimmer, man 
sieht einem Objekt nicht automatisch an, dass es Teil einer Relation ist. 
Ändert man die Geometrie des Objektes, so zerstört man oft die Relation.

Daher ist aus der Sicht von Editoren, Tools zur OSM-Datennutzung, 
Datenformaten und dem Renderer sinnvoll, Relationen nur dann zu benutzen, wenn 
weder String-Gleichheit noch räumlicher Bezug vorhanden sind.

Im konkreten Fall liegt aber in jedem Fall räumlicher Bezug vor. Ein Baum 
steht im Käfertaler Wald, weil er sich innerhalb der scharfen oder unscharfen 
Grenzen des Käfertaler Waldes befindet und nicht, weil ihn irgendeine 
besondere Eigenschaft mit den übrigen Bäumen im Käfertaler Wald verbindet. 
Denkprobe: Wenn zu Weihnachten Weihnachtsbäume im Käfertaler Wald 
eingeschlagen werden, verteilt sich dann der Wald danach auf ein paar hundert 
Wohnungen? Wohl eher nicht.
Zweite Denkprobe: Einen hypothetischer See im Wald würde ich als "liegt im 
Käfertaler Wald" bezeichnen. Spricht ebenfalls für räumliche Zugehörigkeit.

würde es sich eher anbieten, außen herum die Grenze als place=locality, 
name="Käfertaler Wald" zu taggen und die einzelnen Gebiete mit landuse=forest, 
name=[jeweils passender Name] taggen.

Schneisen sind eine schlechte Idee, da sie wiederum die Arbeit mit den Daten 
dazwischen enorm erschweren. Sie erwecken zudem den Eindruck, man hätte die 
genaue Straßenbreite berücksichtigt. Ich habe mehrmals die Freude gehabt, 
Straßen zwischen landuse-Nutzungen zu editieren, was enorm mühselig ist, weil 
der Editor nicht weiß, dass man jetzt Straßennodes und nicht landuse-Nodes 
anfassen möchte und schon gar nicht, dass die landuse-Nodes bei Verschiebungen 
den Straßennodes folgen müssten.

Auch da gilt: Dem Datennutzer ist durchaus bekannt, dass mitten auf der A6 
keine Bäume wachsen, und die Straßenbreite ist entweder an der Straße 
spezifiziert oder nicht genau bekannt.

Viele Grüße,

Roland