[Talk-de] landuse=road War:[viel Text zu landuse-handling..]

[Garry]

Am 14.09.2011 03:14, schrieb Christian Müller:
> Am 13.09.2011 17:14, schrieb Martin Koppenhoefer:
>> ich würde das Gebiet zweier dauerhaft bewohnter Häuser im Wald als
>> landuse=residential kennzeichnen. In Deutschland kommt so was aufgrund
>> des Verbots, im Aussenbereich zu bauen, allerdings extrem selten vor.
>
> welchen Sinn soll das haben?  so kommen wir nicht weiter..
Es ist ein Alleinstellungsmerkmal und erhöht die Auffindbarkeit solcher 
Besonderheiten.
Wenn Du z.B, eine OSM-Garminkarte verwendest in der aus Platzgründen 
keine Häuser dargestellt werden siehst Du an der Stelle
des Hauses nur Wald, ohne eigenem landuse ist so ein Haus dann auf der 
Karte unauffindbar.
Und nein, ich sehe dass nicht als Mappen für den Renderer an sondern ein 
Mappen der Realität zur besseren Nutzubarkeit der Daten.
>
> Die Granularität von landuse=*  ist in OSM einfach nicht die von 
> building=*  und wenn sie das wäre, wäre landuse=*  für die meisten 
> Datennutzer useless=*
Ich versteh Martin mit "das Gebiet zweier dauerhaft bewohnter Häuser"so 
dass er die Summe der beiden Grundstücke als eine landuse=residential
Fläche mappen und nicht die Gebäude selbst als einzelne landuse-Flächen 
mappen will.
>
>> Das Liegenschaftsamt sieht das anders: die mappen sogar Teilflächen
>> wenn sie unterschiedliche Nutzungen haben auch getrennt. Ich würde das
>> weder fordern noch pauschal ausschließen wollen.
>
> Ja, können sie ja machen - haben wir die Ressourcen?  Macht das in OSM 
> Sinn?
In Bezug auf Einzelhäuser im Wald ist das nicht wirklich ein Argument
> Ich denke nicht, wir sollten bei dem 'vorrangig' in der Definition zur 
> Bodennutzung bleiben.
Bei so einer gravierende Nutzungsänderung wie hier die kleine bewohnte 
Fläche in einem riesigen unbesiedelten Gebiet sollte man schon 
differenzieren...
>
>
> Beim Taggen von landuse=*  über seine Grenzen, macht aber auch ein 
> amtlicher Datenimport keine Probleme.  Man legt das einfach über das, 
> was in OSM da ist, taggt die ways des Imports als
>
>     border=administrative
>     source=official
>
> und erstellt Multipolygone mit
>
>     type=multipolygon
>     landuse=xyz
>     official_key1=*
>     official_key2=*
>     official_key3=*
>     source=official
>
>
> Ich denke nicht, dass diese Granularitätsebene, auf der die Ämter 
> mappen für eine OSM-Definition von landuse=* geeignet ist.  Natürlich 
> gibt's kein Verbot, diese Granularität in OSM zu benutzen, aber uns 
> geht es hier um eine brauchbare Wiki-Definition, die würde ich nicht 
> "strikt" gestalten.
>
>     "'vorrangige', reale Flächennutzung"
>
> Du musst auch mal überlegen, welche Konsquenzen das hätte:  landuse=*  
> würde evtl. nur noch auf dem letzten Zoomlevel renderbar sein, auf 
> allen anderen gibt's ein verrauschtes  "noise" bitmap.   Weiterhin 
> hatte sich jemand über die Fülle der Daten in Frankreich durch den 
> Import aufgeregt.  Wenn die Flächennutzung auf der Granularitätsebene 
> von Baufenstern (oder nahe diesen) arbeitet, hätten wir zum Schluss 
> 25*Anzahl der building Polygone an Daten in der Stadt (für jedes 
> Gebäude finde ich unter Garantie 25 verschiedene Bodennutzungsarten 
> ringsum).  Das ist für landuse=*, useless=*..
>
> Wenn landuse=* auf Dauer nicht über Flächengrenzen mittels 
> multipolygon gemappt wird, womit sich 'genaue' und 'vorranige' 
> Flächennutzungsgebiete vereinen ließen, sollte man ein anderes Tag 
> aufmachen, um landuse micromapping zu betreiben..
>
>
> Denn landuse micromapping erhöht Eintrittsbarrieren, anstatt sie zu 
> senken..
>
>
>
>
>> Je kleiner man
>> diese Einheiten macht (bis zu Flächen, die keine Straßen mehr
>> beinhalten, einzelne Blumenbeete meine ich damit nicht), um so
>> einfacher wird es für die folgenden Mapper, dort weiterzuarbeiten.
>
> Irrglaube, denn Du hast dann statt Struktur, "rohe" Komplexität 
> abgebildet.  brute-force, statt elegance.  Es gibt keinen Bezug deiner 
> Mini-Flächen untereinander.  Man sieht sprichwörtlich den "Wald vor 
> lauter Bäumen" nicht mehr.  Wenn deine Mini-Einheit was bringen soll, 
> dann nur über die Multipolygon-Methode, mittels derer diese 
> Mini-Flächen wieder zu groben, fassbaren Flächen gruppiert werden 
> können, bis zu dem Punkt, wo man wieder von 'vorrangiger', realer 
> Flächennutzung sprechen kann, was landuse=* jetzt ist.
>
>
>> woher kommt eigentlich dieser Wunsch, die Realität in diesem Punkt 
>> nicht (in unserem Rahmen) möglichst genau abzubilden, sondern grobe 
>> unfragmentierte Gebiete haben zu wollen? Kann man das nicht durch 
>> Datenverarbeitung hinterher machen, wenn man gerne vereinfachte 
>> Geometrien haben will?
>
> Nein, aus dem gleichen Grund, aus dem Du die Erfassung der 
> Siedlungsfläche (nach deiner Definition) "explizit" wünschst.
>
> Um es mal auf dein Beispiel mit der dt. Staatsgrenze zu übertragen:
>
>     Die ist auch explizit erfasst, obwohl man sie aus der Summe aller 
> nächsttieferen Grenzen berechnen kann.
>     Und die nächsttieferen Grenzen wiederum aus den nächsttieferen..  
> ad absurdum
>
>
>     Der Grund weshalb man das nicht berechnet, ist, neben dem 
> Rechenaufwand, dass wir in OSM selbst die Information der Realität 
> haben wollen, in der DB.
>     Würden wir rechnen, hätten wir das Wissen um die Struktur der 
> Daten (die Definitionen /was/ ist eine Staatsgrenze, usw.),  nicht /in 
> den Daten/, sondern -off-site- /in den Algorithmen/.
>
>     (Außerdem müßte dann eben jeder rechnen, selbst wenn die gleiche 
> Information benötigt wird.  Auf die Weise lassen sich abh. 
> Strukturdaten in OSM vll als "gecachte, vorberechnete Daten" verstehen.)

Zwischen den administrativen Grenzen und landuse Grenzen gibt es einen 
kleinen Unterschied:
Administrative Grenzen stammen häufig aus Importen und es kümmern sich 
relative wenige um deren Pflege. Sie haben langfristig bestand und es 
besteht für den Durchschnittsmapper keine Notwendigkeit sie anzufassen. 
Landuse-Flächen werden dagegen ständig angefasst, modifiziert, 
korrigiert, ergänzt - nicht zuletzt auch wegen der vielen 
unterschiedlichen Meinungen dazu. Die Verwendung von Multipolygonen 
führt dabei regelmässig zu Problemen.
Entweder es geht was beim editieren kaputt oder Anpassungen werden aus 
Angst etwas kaputt zu machen gar nicht erst vorgenommen.

Garry