Am 10.09.2011 14:46, schrieb Martin Koppenhoefer:
Selbst wenn da etwas Redundanz da
wäre, dann machte das die Daten stabiler in einem Projekt, wo zig
Tausend Leute unkoordiniert editieren.
So ein Unsinn, dazu gibt es die history und nicht umsonst werden
Changesets erstellt, so dass sich Änderungen nachvollziehen lassen.
Redundanz macht Daten nicht "stabiler", was auch immer Du damit meinst.
Tagge ich ab jetzt jede Fläche innerhalb Bornsdorf, mit (name=Bornsdorf
place=village) damit sich irgendeine wahllose, willkürliche Zuordnung
erleichtert? Sorry, das ist fernab jeglicher ratio. OSM war von Anfang
an ein Klassifizierungsprojekt, musste es sein, damit sich ein Abbild
der Realität überhaupt schaffen lässt. Redundanz ist an begründeten
Stellen unverzichtbar. Solche Gründe liegen hier mitnichten vor und Du
hast auch keine vorgeschlagen.
Davon rede ich doch die ganze Zeit. Es gibt keinen Bedarf für ein
place-polygon. Was sollte es auch abbilden? Die 'Siedlungsfläche' ist ein
landuse=*.
Das Landuse ist die Bodennutzung. Übrigens laut Wiki sogar die
geplante Bodennutzung. --> tagging
Warum schreibst Du nicht einfach +1.. Deine Aussage ergänzt meine doch
nur, die Siedlungsfläche ist ein Verbund bestimmter Bodennutzungen. Wir
waren schonmal bei Flächennutzungen, ich weiß jetzt nicht, weshalb Du
daraus Bodennutzung machst. Willst Du dich von deiner Aussage landuse=*
ist Flächennutzung wieder distanzieren?
"Siedlungsfläche von Bornsdorf ist die Gesamtfläche innerhalb seiner
Verwaltungsgrenze, abzgl. aller Betriebs-, Verkehrs- und Abbauflächen."
"Siedlungs- und Verkehrsfläche von Bornsdorf ist die Gesamtfläche
innerhalb seiner Verwaltungsgrenze, abzgl. aller Betriebs- und
Abbauflächen."
Damit wären wir wieder beisammen. Nur haben wir keine lückenlose
Erfassung der Verwaltungsgrenze abzgl. aller Betriebs-, Verkehrs- und
Abbauflächen.
Klar haben wir eine lückenlose Erfassung der Verwaltungsgrenzen, für
Gemeindegrenzen auf jeden Fall, oft sind die Gemarkungsgrenzen
eingemeindeter Dörfer auch vorhanden. Wo sie fehlen, wären sie zu erfassen.
Weiterhin ist die lückenlose Erfassung des landuse=* (z.B. in der
Ausgestaltung "reale Flächennutzung") möglich.
Jetzt
- nimmst Du die Verwaltungsgrenze (Gemeinde, Gemarkung,
whatever), und
- schneidest alle Daten außerhalb dieser Grenze weg.
- Übrig bleiben die Flächen mit ihren landuse=* innerhalb der
Grenze.
- Von denen entfernst Du alle Betriebs- und Abbauflächen.
- Alles was übrig bleibt ist Siedlungs- und Verkehrsfläche.
Einfacher wird es nicht. Die Siedlungsflächengrenze extra zu erfassen
bringt nur Redundanz und weitere Fehlermöglichkeiten, denn
'Siedlungsfläche' innerhalb einer Verwaltungsgrenze muss geometrisch
nicht zusammenhängen, politisch aber evtl. schon.
Für den einfachen Fall einer zusammenhängenden Siedlungsfläche kannst Du
dir vorstellen, dass die Siedlungsflächengrenze durch die Vereinigung
aller Flächen erhältst, die nach obigem Verfahren übrig sind.
Willst Du die _reine_ Siedlungsfläche erhalten, musst Du noch die
Verkehrsfläche abziehen - die haben wir (noch) nicht flächendeckend, das
ist richtig. Aber das ist im kommen. Bis dahin könnte man sich eine
Norm zur Straßenbebauung raussuchen und die üblichen Straßenbreiten
gepaart mit der Angabe von lanes=* verwenden, um eine gute Näherung der
_reinen_ Siedlungsfläche zu erhalten.
Für das Rendering von Flächennutzungsplänen spielt das erstmal keine
entscheidende Rolle. Dazu rendert man die Flächennutzungskarte anhand
der landuse=* Flächen und rendert die Straßen darüber, sofern man sie
überhaupt will. Natürlich ist die Verkehrsfläche dann nicht exakt
repräsentiert, aber genauer sind die Daten in OSM eben noch nicht.
Wir haben bis auf den Schienen- und Luftverkehr noch
nicht mal Einverständnis zum Taggen von Verkehrsflächen.
Wir brauchen auf landuse=traffic erstmal wenig Rücksicht nehmen.
Diesbzgl. stellt sich nur die Frage, ob landuse=traffic über anderen
landuse=* schweben darf, oder ob keine zwei landuse=* übereinanderliegen
dürfen. Das lässt sich aber separat diskutieren.
Wer dafür ist, landuse möglichst großflächig zu erfassen, wird sich für
sie Schwebevariante entscheiden, wer gerne parzelliert für die andere.
/Falls/ landuse /Gebiete/ erfasst, wäre es unsinnig zu parzellieren,
denn es geht dann um die "vorwiegende Nutzung". Ein Ackerland als
Gebiet wäre dann an der Straße die durchführt nicht zu teilen.
/Falls/ landuse /Flächen/ erfasst, müsste parzelliert werden, denn die
Acker/fläche/ ist dort zu Ende, wo die Verkehrsfläche beginnt.
Allerdings
ist die Fläche im Place-polygon das was dort oben als Siedlungsfläche
bezeichnet wird plus die dazugehörigen Verkehrsflächen.
Ja, noch so ein Grund, place als polygon abzuschaffen - es ist so unklar
definiert, dass mit jedem Versuch es zu fassen, festzustellen ist, dass
dieser Aspekt bereits durch andere Mittel des Datenmodells abgedeckt
ist. Aber ich wiederhole mich..
Die Ausdehnung
der Stadt (falls es eine Stadt ist). Ggf. würde ich sogar die
Betriebsflächen dazunehmen, wenn man sie als innerhalb der Stadt
gelegen bezeichnen würde.
Ich meine, wir sollten uns an die allg. Definition halten, wenn es eine
gibt. Und die steht, u. a., im Wiki-Artikel zum Flächenverbrauch.
Darauf kann man dann verweisen, anstatt wiederholt seine Sichtweise
gegen die allgemeine zu verteidigen - es gibt sicherlich Situationen in
denen das Sinn macht, aber doch nicht hier. Was wäre denn gewonnen,
wenn die Community deiner Sichtweise folgt und Betriebsflächen
dazuzählt, entgegen der allg. Definition? Nichts, imho.
Wieso sollten wir erst alles andere drum rum taggen müssen, nur damit
man dann durch komplexe Operationen auf die Ausdehnung der Siedlung
schließen kann?
Du musst gar nichts, aber es ist das, was seit jeher gemacht wird.
landuses=* werden so lala, mal nach Gebiets-, mal nach Flächendefinition
erfasst. landuse=* gibt es in OSM schon ewig. Und wir taggen damit
nach der Def. von 'Siedlungsfläche' die Siedlungsflächengrenze
automatisch mit.
Ja, Du kannst sie zusätzlich extra erfassen. Dann müsste man aber
wieder aufpassen, dass sie mit der Definition konsistent ist. Sprich,
sie würde genau an den Außengrenzen der Flächennutzungsgrenzen
entlanglaufen. Jedes mal, wenn man die Flächennutzungsgrenzen pflegt,
müsste man darauf achten auch die Siedlungsflächengrenze entsprechend zu
pflegen und vice versa.. Alles unnötig, denn Du kannst Dich, in diesem
Fall, auf einen Automatismus verlassen. Gerade deswegen finde ich
landuse=residential
place=village
name=Zdorf
so falsch. In diesem Fall wird das Wohngebiet (hier landuse als Gebiet)
mit der Siedlungsfläche gleichgesetzt (angenommen place-polygon ist
Siedlungsfläche). Das ist aber nach Definition nur genau dann richtig,
wenn alles andere innerhalb der Verwaltungsgrenze von Zdorf Betriebs-
oder Abbaufläche ist - ansonsten ist die Siedlungsfläche größer als das
Wohngebiet. All diese Fehlerquellen kann man vermeiden, wenn man sich
die Siedlungsfläche nach Definition einfach ausrechnet - und die
Rechnung ist, im Vergleich zu anderen GIS-Operationen nicht sehr
komplex. Wenn man das häufig braucht, kann man sich die
Siedlungsflächen ja auch cachen.
Wer sich die 'Siedlungsfläche' über Einschluss, statt Ausschluss,
definiert, hat es noch einfacher - der holt sich die entsprechenden
Flächen vom Server, vereinigt sie und ist fertig. Wenn er nur an der
Fläche und nicht an der Grenze interessiert ist, braucht er nicht einmal
den Vereinigungsschritt..
Gruß
Christian
_______________________________________________
Talk-de mailing list
Talk-de@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-de
