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
_______________________________________________
Talk-de mailing list
[email protected]
http://lists.openstreetmap.org/listinfo/talk-de
