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

[Christian Müller]

Hi,


Am 14.09.2011 11:23, schrieb Georg Feddern:
>
>>
>>     "'vorrangige', reale Flächennutzung"
>
> Das ist durchaus eine sinnvolle, nicht-strikte Definition.
> Aber warum erwartest Du dann, das man sich _strikt_ an eine nicht 
> näher angegebene Größenordnung hält?
> Wo muss man diese Größenordnung ziehen?

Erwarte ich nicht -> siehe letzte mail + die mail zur Datenhaltung

'vorrangig'  bezieht sich sowieso nicht auf die Größenordnung, denn 
'vorrangig' oder 'überwiegend' ist auf bel. Größe/geograph. Ausdehnung 
ermittelbar..


Das Problem ist, dass die momentane Datenhaltung von landuses=*  mittels 
"closed ways"  "uns" nicht erlaubt, die Micromapper mit den Makromappern 
zusammenzubringen.


Deshalb kommt Quark dabei heraus, wenn sowohl ein Micromapper, als auch 
ein Makromapper landuse=* verwendet.
Der Micromapper zerlegt das Gebiet des Makromappers, obwohl die größere 
Fassung (Du schreibst, Deutschland besteht 'vorrangig' aus Agrarfläche), 
doch wohl auch Sinn macht!
Und -vice versa- killt der Makromapper mini-landuses von der 
OSM-Bildfläche, weil er der Meinung ist, ein landuse=*  sei  kein building=*


Nur aufgrund dieses Mißstands bestand von Anfang an der Wunsch 
landuse=*  größenordnungsmäßig zu begrenzen.
Weil wegen der technischen Art der Erfassung Micromapper und Makromapper 
nicht oder nur schlecht (overlapping ways..) koexistieren können.


>> .. verrauschtes  "noise" bitmap.
> Nein, dass wären 'falsche' Renderregeln.

Angenommen ich würde jedes Grundstück mit einem einzelnen landuse=* 
taggen.  Stell Dir Mischgebiet vor.  Nun wird gerendert.  Ich zoome 
heraus, und voila:  Noise.  Der nächste Schritt ist, dass die 
Renderregeln angepasst werden, und erst auf einer tieferen Ebene 
landuse=* gerendert wird


> Die Granularität bestimmt die Breite der definierten landuses. (Leider 
> wird/wurde bei OSM oft zu schnell in die Breite gegangen, statt zu 
> staffeln. :-( )

+1  bessere Staffelung ist eine Lösung des Problems..  zuviele Werte in 
einem key sind schlecht..  schlecht strukturierbar, schlecht für Einsteiger


> Erstens endet die landuse-Granularität z. Z. spätestens an der 
> Grundstücksgrenze - den so sinnlosen landuse=grass mal außen 
> vorgelassen - und gleiche Nutzungen nebeneinander ergeben eine 
> gemeinsame Fläche, im Zweifelsfall den von Martin angesprochenen Block 
> (zwischen Verkehrswegen) - den man ja nicht auf Krampf unterteilen 
> muss. Aber setzt sich der landuse=road durch, ist dort dann sowieso 
> Schluss, falls sich der Schwebe-Ansatz nicht durchsetzt.

Mit multipolygons besteht das Problem nicht..  Da schwebt alles Makro 
dann über Micro, ohne sich zu stören.  Die Frage ist nur, ob man die 
Editoren soweit bringen kann, dass Mapper damit keine Probleme haben..


> Und zweitens werden ab einem gewissen Zoomlevel landuses rendermäßig 
> zusammengefasst (landwirtschaftlich, bebaut/besiedelt) sowie kleine 
> Flächen weggelassen.

Das ist interessant.  Machen Renderer tatsächlich den Aufwand 
Flächengrößen zu berechnen, bevor gerendert wird?


> .. (für jedes Gebäude finde ich unter Garantie 25 verschiedene 
> Bodennutzungsarten ringsum).
>
> Hier hätte ich gerne Belege für (diese Übertreibung) ...

;-)


>>   Das ist für landuse=*, useless=*..
>
> Allerdings - aber in meinen Augen eben auch nicht zwangsläufig zu 
> befürchten.
> Insbesondere nicht, wenn man sinnvoll staffeln würde, statt weiter nur 
> (oft unüberlegt) in die Breite zu gehen.

The thing is..  Staffelst Du sinnvoll, erhälst Du kleinere Flächen, weil 
die Staffelung dann ja (hoffentlich) auch für die Ausdifferenzierung der 
verfügbaren Fläche genutzt wird.  Damit gehen aber (ohne overlapping 
ways und ohne multipolygons) die Flächen verloren, welche die gröbere 
Einteilung, die gröbere Staffelung beinhalten.

Dein wie auch mein Argument dazu würde sein, dass man sich die gröberen 
Flächen ausrechnen kann - das zieht hier aber nicht:

     - zum einen sind die Gebiete nicht immer ausrechenbar sind (z.B. 
dann nicht, wenn das gröbere Gebiet einen Namen hat - den müsstest Du 
dann auf jedem feingranularen Gebiet auch angeben, und das 
feingranularere Gebiet könnte dann keinen eigenen Namen mit name=* mehr 
erhalten)
     - zum anderen sehr viele Leute die gröberen Gebiete verwenden (es 
damit Verschwendung wäre, wenn jeder für sich rechnet)

Wird ein grobes Gebiet unter Nutzung der Grenzen der feineren Gebiete 
mittels multipolygon erfasst, kann man auch nicht direkt davon sprechen, 
dass redundante Information in der DB wäre, denn es ist nur die 
Information enthalten, wie aus den feineren Gebieten, dass größere 
konstruiert wird).  Die Regel an sich ist redundant in der DB ("wie 
konstruiere ich die Siedlungsfläche aus den micro-landuses"), aber keine 
Daten.


>
>>
>> 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.
>
> Sehe ich - mittlerweile - anders. Multipolygone oder riesige Flächen 
> schrecken da eher ab, nach meiner bisherigen Erfahrung.

Schade..  ..habe ich aber erwartet (siehe mail zur Datenhaltung..)  Es 
ist ein echtes Problem, dass multipolygone mystifiziert werden (wodurch 
auch immer..).


> Angrenzende Flächen (mindestens zwei in Reihenfolge liegende 
> gemeinsame Punkte) lassen sich automatisch zusammenfassen.
> Multipolygone lassen sich automatisch erstellen.
> JOSM macht es jeweils vor.

Soll ich damit dann die Arbeit der Micromapper zerstören?
Es geht um die Möglichkeit der Zusammenfassung /in den/ Daten, nicht im 
Editor.
D.h.  grobe Fläche  /und/  ihre Teilflächen in der DB, nicht entweder oder..


>>     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/.
>
> Richtig - aber was hat eine _Gebiets_-Struktur mit dem landuse zu tun?

Das habe ich schon geschrieben, sehr, sehr viel..  Die Gebiete der 
Bodennutzung sind, wenn man nicht nur eine bodenlose, nach unten offene, 
micro gemappte  Mosaikfläche haben will, ähnlich strukturiert, wie die 
Gebiete der administrativen Flächen.  Ähnlich deshalb, weil 
administrative Flächen eine Hierachie bilden (mit disjunkten Flächen auf 
jeder Ebene) und Bodennutzungsflächen ein Netzwerk (mit nicht 
notwendigerweise disjunkten Flächen, auf einer wie auch immer 
gestaltenen Granularitätsebene).


> Zwei Gebiete nebeneinander können den gleichen landuse haben - ihre 
> Struktur muss aber unabhängig davon erfasst werden. (boundary, place, 
> site ...)
> Aber die _Außen_-Struktur eines identischen landuses muss ich nicht 
> explizit erfassen - die kann man automatisch erstellen.

Die kannst Du nicht (immer) automatisch erstellen.  Und selbst wenn Du 
es könntest, ist es oft nicht erwünscht, dass sie dann jeder, der sie 
nutzen will, jedesmal erstellen muss.


Gruß
Christian