Hi,
ich denke wir bewegen uns aufeinander zu, obwohl deine Lösungsansätze
umwälzender und unverträglicher mit bisherigem sind, als meine. Ich bin
nicht der Meinung, dass wir das gewonnen Verständnis in der Mailingliste
begraben sollte, denn ein geringeres Maß an Interpretationsfreiheit
bestimmter Tags kommt allen zugute und führt zu hochwertigeren Daten,
mit denen man auch wieder kreativer sein kann.
+1 zu deiner begrifflichen Klarstellung von 'Wohngebiet' im allg.
Sprachgebrauch und 'Wohngebiet' im Sinne Baunutzung. Ich habe, sofern
letzteres gemeint war, häufig von 'Wohnfläche' gesprochen, um den
engeren Bezug zur Flächennutzung herzustellen.
Am 07.09.2011 20:09, schrieb Martin Koppenhoefer:
Es gibt einen Unterschied zwischen administrierter Fläche
(boundary=administrative) und Siedlungsfläche (place-polygon), daher
braucht man auch beide. Als best_practice würde ich vorschlagen, für
places eine Relation zu machen und den place-node mit der Rolle
settlement_centre dort mit der Place-Fläche zu verknüpfen.
au contraire: Siedlungsfläche != place-polygon (siehe unten)
Außerdem kämpfst Du an der Stelle mit dem falschen Menschen. Ich habe
die "best practice" auf der englischen Wiki-Seite, die übrigens
_durchaus_ den allg. Fall und nicht den speziellen beschreibt, nicht
verfasst. Ich stimme ihr nur zu, weil sie Sinn macht, und habe
lediglich die Unstimmigkeit zwischen dieser best practice und der
Definition der place area beseitigt. Du bist wieder einmal dagegen, sel
a vi..
Auch empfinde ich es als groben Unfug /Siedlungsfläche/ als place=*
getaggte area zu erfassen. I.A. lassen sich für die meisten place=*
_nodes_ zugehörige, administrative Grenzen angeben, eine Zuordnung
place -> administrative boundary
existiert also - anhand zahlreicher, bereits existierender Relationen zu
sehen. Hauptsächlich deshalb, weil ja auch die Ortsnamen von
__administrativer Stelle__ für die Gebiete innerhalb administrativer
Grenzen vergeben werden, i.e. ein place=* node ist oft in der Tat sogar
als admin_centre amtlich mit dieser Grenze verknüpft. Genau diesem
Aspekt trägt (und trug bereits vor meiner Änderung) die Wiki-Seite
Rechnung. Ich werde das also nicht rückgängig machen.
Was soll denn die 'Siedlungsfläche' deiner Meinung nach sein? Laut
Wikipedia [1] ist der Begriff der 'Siedlungsfläche' genau definiert und
zwar als Oberbegriff bestimmter Flächen, für welche wir in OSM direkte
landuse=* Entsprechungen haben. Sie als place-polygon zu erfassen wäre
unnötig und falsch, sowohl nach [1], als auch nach dem Begriff an sich,
der mit dem Kopf des Kompositums -fläche- anzeigt, in welche Kategorie
er zu stecken ist. Nach dem durch Dich favorisierten (und durchaus
sinnvollen) Verständnis von landuse als /Flächennutzung/ gehört der
Begriff der "Siedlungsfläche" abermals zum Namespace landuse=*.
Was sonst soll also als place-polygon erfasst werden, wenn nicht die
administrative Grenze, die zu den meisten place=* nodes gehört? Es gibt
Ortsnamen, die nicht von admin. Stelle vergeben und gepflegt werden, die
in OSM leider auch unter den Namensraum place=* fallen - z.B.
place=locality. Aber selbst da macht ein place-polygon m.E. wenig Sinn,
weil eine genaue Grenze für eine locality selten ermittelbar sein
dürfte. In Ausnahmefällen ist eine Erfassung einer
nicht-administrativen Grenze sinnvoll, dann aber kein Grund, die
locality mit der /Flächennutzung/ zu vermischen.
Ein 'Ort' /ist/ keine Grenze. Das Tag heißt place=* und nicht
place's_border=*. Ein 'place-polygon' kann der Renderer aus dem
'place-node' willkürlich erstellen, z.B. als disc, deren Größe eine
Eigenschaft des Ortes wiederspiegelt - e.g. population, das hätte aber
in der DB nichts zu suchen. Reale Ausgestaltungen des Begriffs sind
bereits an andere Tags vergeben: Ein Ort /besitzt/ sowohl eine
Flächenaufteilung, als auch eine administrative Grenze, für diese Fälle
gibt es in OSM landuse=* und border=administrative. Für diese
Thematiken bliebe 'place-polygon' also unbesetzt und der POI-Charakter
von place=* begründet.
[1] http://de.wikipedia.org/wiki/Flächenverbrauch
redundant wäre das nur, wenn man zusätzlich noch mal eine große
landuse-Fläche drum rum bauen würde. Redundante Geometrie würde im
Gegenteil dann entstehen, wenn man _nicht_ die Grundstücksflächen
(Hypothese aus Deiner Mail, man hätte sie) dafür verwenden würde
sondern nochmal extra ein Polygon drum rum zieht.
Das ist nicht wahr. Das taggen ein und der gleichen Information an
jeder parcel ist redundanter, als diese Information genau einmal für
eine große Summe an parcels zu beschreiben.
Ich sprach nicht von redundanter Geometrie, sondern von redundanter
Information. Eine Polygon-Geometrie, die extra um die Parcels gezogen
wird, um landuse=residential zu pflegen ist genau dann nicht redundant,
wenn diese Information an den einzelnen parcels fehlt. Das macht
insbes. dann Sinn, wenn es eine überwiegende Flächennutzung gibt, aber
das hatte ich schon geschrieben.
Eher andersrum: Ich würde das Tag maximal an einzelne Grundstücke vergeben,
die eine Ausnahme der Regel darstellen.
+1, schrieb ich ja bereits und ist genau das, worum es hier geht. Wir
verstehen uns langsam.
Ja, wenn Du das auch so siehst, musst Du dem groben Erfassen der Regel
in einem Extra-Polygon, so wie es gerade beschrieben wurde auch
zustimmen, ansonsten gäbe es diese Ausnahmen ja nicht.
jede Neuerung fängt erstmal von Null an, das ist aber kein Grund, sie
nicht zu machen, wenn sie die Lage verbessert.
Neuerungen bei OSM fangen nicht mehr bei Null an. Es ist ja bereits was
da. Das was da ist zu konkretisieren, ohne bestehende Arbeit zunichte
zu machen, ist die Kunst. Deshalb wäre es wichtig, in der Definition
nur wenig von bisheriger Nutzung abzuweichen, dieses "wenig" aber genau
zu präzisieren. Das macht der Ansatz meiner letzten mail als Destillat
unserer längeren Diskussion.
Wir können z.B. Daten vom jetzigen Zustand in einen nächsten
transformieren, indem
- das name=* Tag bestehender landuse=residential Flächen an einen
- place=neighbourhood node gehangen wird, der admin_centre von
einem als
- boundary=administrative erfassten Wohngebietes wird
- (ganz im Stile der "best practices" in
http://wiki.openstreetmap.org/wiki/Key:place)
- die landuse=residential Fläche wird dann vergrößert, indem sie
mit ihren unmittelbaren Nachbarn verbunden wird
- Ausnahmen innerhalb dieses größeren landuse=* Gebietes werden
dann wie gehabt
- über multipolygon aufgenommen (falls nötig, manchmal ist
evtl. auch landuse über landuse tolerierbar)
- oder einfach drauf gezeichnet (amenities, leisure, natural)
- name=* und landuse=* zusammen als Tags an einem Polygon wären
ein Indikator für Alt-Daten
- man könnte sich darauf einigen, diese Alt-Daten so zu
interpretieren, dass die
administrative Grenze des Wohngebietes und die
Flächennutzungsgrenze
an der Polygongrenze zusammenfällt
- .. und das dort, wo das tatsächlich der Fall ist, z.B. in kleinen
villages, dieses gemeinsame Polygon ausreicht
- admin_centre des Wohngebietes wäre dann identisch mit
admin_centre des Dorfgebietes
- also, komplett im Überblick
- [DG] Dorfgrenze (boundary=administrative admin_level=X)
- [PLC] Name (place=village name=Bornsdorf)
- [WG] Wohngebiets- und Flächennutzungsgrenze
(boundary=administrative admin_level=X+1 landuse=residential)
- 2x Admin-Relationen
- members: DG, PLC als admin_centre
- members: WG, PLC als admin_centre (anstatt extra node
mit place=neighbourhood name=Bornsdorf)
- weitere Implikationen
- Wohngebietsgrenzen könnten mit dem Verfügbarwerden amtlicher
Information verfeinert werden,
ohne gleich die gemappte Flächennutzung zu beeinflussen
- wir hätten eine striktere Trennung zwischen einer politischen
und einer thematischen Flächenverbrauchs-Information
- Unterschiede in politischer Nutzungswidmung und realer
Nutzung wären später evtl. einmal aufzeigbar
- beide Informationen ( politisch / thematisch ) sind getrennt
wartbar
- die Diskussion um die korrekte Erfassung korrekter
Polygon-Grenzen beider Informationen wäre getrennt fortführbar ;-)
- die Menge der argumentierenden MapperInnen aber kleiner
- ("landuse-mappers can coexist aside admin-mappers with
less conflict")
Die Argumentation wäre also, dass der momentane Stand der Daten
Spezialfall eines dann umfassenderen Datenmodells ist. So ähnlich, wie
das auch mit dem ÖPNV-Schema passierte, welches sich die Tags
highway=bus_stop und railway=halt als Sonderfall im umfassenderen
Datenmodell einverleibte, aber nur wenig von der ursprünglichen
Interpretation abwich, so dass Alt-Daten halbwegs kompatibel waren und
nicht über Nacht umgemünzt werden mussten.
[2]
http://wiki.openstreetmap.org/wiki/User:Oxomoa/ÖPNV-Schema#Kompatibilit.C3.A4t_des_Modells
Bitte sieh Dir das mit den administrativen Grenzen nochmal an. Fluren
haben damit nicht direkt zu tun. Eine Grundstücksgrenze ist keine
administrative Grenze.
Wieso das denn schon wieder nicht? Wer, wenn nicht die Administration,
sichert Dir denn ihre Gültigkeit zu? Ist das Grundbuchamt
http://de.wikipedia.org/wiki/Grundbuchamt
etwa keine administrative Stelle? Ich habe nicht behauptet, dass sie
bereits in OSM als administrative Grenze verstanden/genutzt werden, aber
im Grunde sind sie in einer Hierachie anderer Grenzen am unteren Ende zu
finden (Flurstücksgrenze < Grundstücksgrenze < Flurgrenze < polit.
Wohngebietsgrenze < Stadteilgrenze < Gemeindegrenze < Landesgrenze) -
ohne Anspruch auf Vollständigkeit. Wo sie in dieser Hierachie stehen
ist ein anderer Diskussionspunkt, aber Grundstücksgrenzen sind
administrative Grenzen.
...nicht das Grundstück bestimmt die Nutzung, sondern /wo/ das
Grundstück liegt (in einem Wohngebiet/Industriegebiet/etc.).
falsch. Jedes Grundstück hat eine (zulässige und reale) Nutzung. Wenn
für ein bestimmtes Grundstück nichts zugewiesen ist, dann gilt das
Einfügungsgebot. Wenn aber eine Nutzung zugewiesen ist, dann ist diese
entscheidend und die Umgebung ist egal.
Du bist schon wieder beim Baurecht. Wenn eine Nutzung zugewiesen wurde,
die abweichend von der Flur ist, ist das Ausnahme und es ist völlig in
Ordnung diese Ausnahme zu taggen. Das führt wieder auf die Diskussion
zurück, ob für jedes Grundstück die Flächennutzung einzeln zu taggen
ist, oder nicht - das haben wir bereits erörtert, und Du warst bei +1
für das Ausnahmentagging, damit musst Du auch für ein Regeltagging sein,
also größtmögliches Gebiet. Denn ohne Regel keine Ausnahme.
Ja, sie stellen dann aber eine Ausnahme von der Regel dar. Siehe oben, Du
könntest dann dem einzelnen Grundstück ein landuse=* mit der Ausnahme
zukommen lassen. Grundsätzlich:
"Wenn ein Grundstück/eine Flur in einem Wohngebiet liegt, ist erstmal
davon auszugehen, dass es sich um ein Wohngrundstück handelt."
und wenn eine Flur zur Hälfte in einem Wohngebiet liegt? Fluren würde
ich auch in place einordnen, das sehe ich genauso von landuse
getrennt.
Ja. Fluren sind genauso admin. Grenzen, nicht bei place=*, aber bei
border=*. Wenn eine Flur in der Mitte geteilt ist und die Flurstücke
auf der einen Seite eine andere Nutzung als die der anderen haben,
spricht das doch nur dafür, die Flächennutzung als landuse=* in einem
Extra-Polygon zu erfassen, welches mit der politisch-administrativen
Grenze von Grundstück/Flur/etc. nichts zu tun hat. landuse=* soll der
realen Flächennutzung entsprechen. Admin. Grenzen hingegen sollen
admin. Grenzen bleiben.
Während oft admin. Grenzen mit einer realen Flächennutzung
zusammenfallen, ist das eben nicht immer so. Deshalb plädiere ich für
die Trennung: Flächennutzungsgrenze (der Realität) und polit.-admin
Grenze (ohne amtl. Daten Annäherung durch den Mapper). Eine exakte
Erfassung der Flächennutzungsgrenze ist dann fast immer mit guten
Luftbildern zu bewerkstelligen, wobei man sich MapperInnen keine
Gedanken mehr machen, ob diese Grenze der polit.-admin. Grenze
entspricht, denn die würden extra erfasst.
Missverständnisse zwischen MapperInnen, welche die bisher unklar
definierte Grenze je nach Interpretation in die admin. Richtung oder in
die andere Richtung verschieben würden vermieden. Und auch
Zeitverschwendung durch passive edit wars (z.B. zittern der Grenze in
Halbjahresabständen) würde vermieden werden. Weiterhin würde nicht alle
Nasen lang die gleiche Diskussion auf der Mailingliste hochkeimen, was
ohne Lösung binnen eines Jahres, evtl. in anderem Gewand, wahrscheinlich
passierte.
Wenn wir diese Trennung einmal haben, können wir in den einfachen
Fällen, in denen diese Dinge zusammenfallen, immer noch Geometrie
einsparen, indem wir politische tags und die der Flächennutzung zusammen
an eine Basisgeometrie/Area heften. Aber den komplizierteren Fall zu
erfassen, muss erstmal möglich sein. Dann können wir endlich auch
genauer taggen, weil ein Verständnis da ist, was begrifflich wo
hingehört. E.g.
Wohngebietsname -> politisch -> place node
Wohngebiet -> politisch -> boundary=administrative admin_level=?
Grundstück -> politisch -> boundary=administrative admin_level=?
Flur -> politisch -> boundary=administrative admin_level=?
Flächennutzung -> thematisch -> landuse=* (Grenzen nach bestem
Wissen durch den Mapper bestimmt, wenn sie von den politischen Grenzen
abweichen, e.g. Luftbild)
Im Falle eines Disputs, wäre der einfache Fall durch die getrennte
Erfassung beider Features aufzulösen. Mehr Detail entsteht, anstatt
Frust über verschiedene, aber berechtigte Sichtweisen zwischen MapperInnen.
Gehen wir davon aus, dass eine Straße einen landuse=traffic impliziert,
den wir bisher nicht taggen, lässt sich evtl. auch wieder zu einer allg.
Regel finden. Falls landuse=* als /Flächennutzung/ im Sinne von Nutzung
einer Fläche durch den Menschen verstanden wird, wäre eine allg., recht
lose gehaltene Regel ohne wenn und aber wäre dann:
"Eine landuse=* Grenze existiert nur dort, wo die Flächennutzung
wechselt."
Als Ziel könnte man sich einen nahtlosen Mosaikteppich von landuse=*
Flicken vorstellen, in welcher für jeden Flicken die jew. Nutzung durch
den Menschen angegeben ist. Nutzungsfreie Gebiete wären mit
landuse=none explizit erfassbar oder durch die Abwesenheit des Tags
ersichtlich.
#########
Nur Straßen wären ein Sonderfall. Egal ob sie als Linie oder Fläche
erfasst werden: Ich schlage vor, dass dies ein erlaubtes landuse über
landuse ohne multipolygon-Erstellung darstellt, weil sich ansonsten der
Flickenteppich an _jeder_ Straße teilt. Zusätzlich hätte es den Charme,
dass landuse=* nur genau dann an highways=* geklebt werden, wenn der
highway zwei Flächennutzungsarten trennt (e.g. Industriegebiet auf der
einen, Wohngebiet auf der anderen). In allen anderen Fällen wird die
Grenze einer landuse=* Fläche mit einer anderen landuse=* Fläche
zusammengklebt, dort wo die Flächennutzungsarten wechseln. Politische
Grenzen werden unabhängig davon erfasst.
#########
Nutzt man das, lassen sich sowohl lückenlose Landnutzungskarten, mit,
als auch ohne Straßenflächen ohne viel Aufwand erzeugen. Einzig, wenn
bei der Flächengrößenberechnung eines Flächentyps die Straßenfläche
abgezogen werden soll, wäre zu rechnen. I.d.R. würde man solche
Berechnungen, wenn man sie braucht, aber eher mit admin. Grenzen
durchführen, als mit der nicht-admin. Landnutzungsgrenze. Die Daten
wären sehr redundanzfrei. Für alle erdenklichen Renderingaufgaben sind
die Daten ohne weiteren Aufwand zu gebrauchen.
Natürlich würde ich auch für alles, was innerhalb eines mit
landuse=residential getaggten Gebiets liegt, davon ausgehen, dass es
landuse=residential ist. Das ist die einfachste Konvention. Eine die
nicht im Laufe der Zeit zu immer mehr Extraregeln führen wird, sondern
klar und einfach ist.
+1 siehe weiter oben ;-)
so lapidar steht das im Wiki. Wie groß dieses Gebiet sein soll, steht
da aber nicht. Logisch aus meiner Sicht wäre das einzelne Grundstück
als atomare Größe für Landnutzung (weil es der gesetzlichen Realität
entspricht).
Ja, Du bist für: "Es gibt Grundstücke. Grundstücke werden
zweckgebunden genutzt." Du bist dafür, landuse=* an die kleinste
polit.-admin., sprich gesetzliche Einheit zu koppeln. Das ist aber von
den Standpunkten des Erfassungsaufwands und der Datenhaltung
unpraktikabel. Es ist äußerst redundant und einfache Anfragen nach
größeren Gebieten arten in enormem Rechen-, sowie
Datenübertragungsaufwand aus. Zudem widerspricht es der bisherigen
Nutzung _extrem_. Das ist alles nicht nötig, wenn man zusammenfasst und
stattdessen Ausnahmen notiert.
Eine Trennung nach politischer und nutzungsabh. Information würde es in
Zukunft ermöglichen, Grundstücks- und Flurgrenzen z.B. _nicht_ zu laden,
aber dennoch, z.B. anhand eines Luftbildes die Flächennutzung zu
erfassen, ohne dass ich mir die Parzellierung im Detail überhaupt
anschauen muss. Derjenige, der die Parzellierungsdaten pflegt wird
zudem dankbar sein, dass nicht jeder, der Flächennutzungen einträgt,
Parzellengrenzen verschiebt. etc. pp.
Meines Erachtens steckt mehr Wissen in
"Es gibt Wohngebiete. Die Grundstücke eines Wohngebietes werden zum Zweck
des Wohnens verwendet, aber es gibt Ausnahmen."
als in
"Es gibt Grundstücke. Grundstücke werden zweckgebunden genutzt."
Ich will das nicht quantifizieren, für mich hört sich beides
vernünftig und sinnvoll an und ich würde das beides auch abbilden
wollen in OSM.
Ersteres enthält eine Abbildung des zweiten, umgekehrt ist das leider
nicht so, bzw. bedeutet die Erstellung der fehlenden Information dann
Aufwand, siehe oben.
Wohngebiete ergeben sich nicht durch die zusammenhängende Wohnnutzung.
Es sind verschiedene Faktoren dafür ausschlaggebend, was zu einem
Wohngebiet zusammengefasst ist, und es gibt sehr häufig (je nach
Kontext, in der Stadt mehr als auf dem Land, wo das Wohngebiet oft an
Ackerland grenzt) den Fall, dass eine zusammenhängende Fläche aus
angrenzenden Wohnnutzungen mehrere Wohngebiete darstellt (insbesondere
dann, wenn man auch größere Straßen einbezieht).
+1. Das wiederum wäre aber ein Plädoyer dafür, Kuchen zu erfassen und
keine Kuchenstücke, weil sich die Kuchenform, angeregt durch deine
Ausführungen, nicht immer aus den Stückchen errechnen lässt. Die
Landnutzungsgebiete zu erfassen und zusätzlich an _jeder_ Parzelle die
Landnutzung zu erfassen, ist nicht nur in der Wartung aufwändig, sondern
bedeutet durch die sehr hohe Redundanz auch, dass massiv Daten hin- und
hergeschaufelt werden, wobei es eigentlich nicht notwendig wäre.
Falls Du für die strikte Trennung zwischen admin. Grenzen und der
Flächennutzung bist, schlage ich vor, den Satz "Eine landuse=* Grenze
existiert nur dort, wo die Flächennutzung wechselt." in das Wiki
aufzunehmen. Selbstverständlich nur, wenn auch andere Mapper finden,
dass das eine gute Sache für die Zukunft ist. Dann wäre nur noch der
Abschnitt oben zwischen ######### ein Diskussionspunkt - ob landuses an
jeder Straße aufgeschnitten werden, oder ob der landuse der Straße als
Sonderstatus über den restlichen landuses "hovern" darf. Ich bin für
letzteres.
Gruß,
Christian
_______________________________________________
Talk-de mailing list
Talk-de@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-de
