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