[Talk-de] Gebiete bezeichnen

[Falk Zscheile]

Am 26. September 2014 12:43 schrieb Martin Koppenhoefer
<dieterdreist at gmail.com>:
> Am 25. September 2014 22:46 schrieb malenki <osm_ at malenki.ch>:
>
>> Kürzlich wurde ich im Hilfe am Westerwald (ein Mittelgebirge)¹ gebeten;
>> der war aber bereits ohne mein Zutun repariert worden. Regionen werden
>> also durchaus schon gemappt.
>>
>> ¹
>> http://de.wikipedia.org/wiki/Westerwald
>> http://www.openstreetmap.org/relation/3273435
>>
>
>
> wobei das im Detail natürlich fragwürdig ist. Wenn ich mir hier ansehe,
> dass die Basaltwerke noch mit einem Zipfel im Westerwald sind:
> http://www.openstreetmap.org/?mlat=50.68842&mlon=7.32396#map=17/50.68842/7.32396
> oder diese Einfamilien(?)-Häuser zum Teil ja, zum Teil nicht:
> http://www.openstreetmap.org/?mlat=50.68359&mlon=7.31864#map=18/50.68359/7.31864
>
> dann wird klar, dass so was eigentlich keine schönen Daten sind, meint: der
> Datentyp Polygon mit seinen klaren Grenzen passt nicht nur Natur dessen,
> was beschrieben werden soll. Das kann man zwar verfeinern, aber richtig
> klar wird es nie, weil man vermutlich auch in der Realität beide
> Standpunkte vertreten kann (Ist im Westerwald bzw. ist nicht im WW).
>
> Z.B. manche Vororte von Koblenz sind im Westerwald, Koblenz aber nicht?
> Dieser Punkt hier ist im Westerwald:
> http://www.openstreetmap.org/?mlat=50.3191&mlon=7.5918#map=15/50.3191/7.5918
> der hier aber nicht?
> http://www.openstreetmap.org/?mlat=50.3203&mlon=7.5874#map=15/50.3203/7.5874
>
> Solche Gebiete den Fluss durchschneiden zu lassen halte ich eher für eine
> schlechte Idee, der Fluss(abschnitt) wird doch ganz oder gar nicht
> dazugehören?
>
> Ziemlich sicher werden solche Konstrukte auch alle Nas' lang kaputtgehen
> (ähnlich den politischen Grenzen).
>
> Ich bin nach wie vor der Meinung, man sollte dafür einen neuen Datentyp
> erfinden, z.B. eine Sammlung von beliebigen Dingen (Nodes und vielleicht
> auch ways), die dann entweder als drin oder draußen bezeichnet werden
> (Rolle), bzw. in Fällen einer "harten" Grenze (Fluss, Bergrücken, Küste
> etc.) auch als echte Grenze (in Teilbereichen).
>

Ein Polygon zur Strukturierung solcher Gebiete erscheint mir auch
ungeeignet. Genau wie der Anspruch mittels Relation alle Wege erfassen
zu wollen, die das Gewiet umgrenzen.

Würde es nicht reichen, wenn man einzelne Nodes zu einer Relation
packt. Also "diese Stadt oder dieser Berggipfel liegt im Erzgebirge"
oder, wem das zu sehr nach Sammelrelation klingt einfach etwas
analoges zu "is_in=value". Dann kann man auf der Auswertungseite die
Ausdehnung dieses Bereichs ermitteln und vom Renderer entsprechend
beschriften lassen. Damit geht man auch dem Streit aus dem Weg, wo die
Grenze genau verläuft und es entspricht unserem Crowdsourcingansatz.
Keiner muss wissen, wo "Erzgebirge" genau anfängt oder aufhört. Es
reicht, dass ich weiß dieser Berg oder diese Stadt liegt im Erzgebirge
und bekommt dann das Tag/Relation. Die Region ergibt sich dann erst
mit der Zeit aus der Zuordnung einzelner Nodes zu einem Region-Tag
durch eine Vielzahl von Mitwirkenden.

Der Nachteil ist, dass sich keine festen Grenzen unmittelbar aus der
Datenbank extrahieren lassen, sondern man nur eine Datenwolke erhält.
Aber gerade für so einen Anwendungsfall, wo eine klare Grenzziehung
ohnehin nicht möglich ist, finde ich das ganz vernünftig. Besser
jedenfalls als riesige Waypolygone oder Relationen mit Ways zu haben,
die ständig kaputt gehen. Für Verwaltungsgrenzen geht das nicht, aber
für difuse Grenzen wie Namen von Regionen schon.

Gruß Falk