[Talk-de] Wohngebiete, landuse=residential Verwendung - continued

Do Sep 8 13:35:18 UTC 2011

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