Hi,
Am 10.09.2011 15:12, schrieb Frederik Ramm:
Ich stehe place-Polygonen auch kritisch gegenueber. Traditionell ist
place ein Node, und ja, wir haben oft eine Dopplung eines place mit
einer zugehoerigen Admin-Boundary. In manchen Laendern ist es sogar
ueblich, den Place dann in die Boundary-Relation mit aufzunehmen - so
nach dem Motto "das hier ist die Stadtgrenze, und dort etwa ist die
Stadtmitte"). Das ist eine etwas unschone Dopplung von Informationen
(mal nur place, mal nur boundary, mal beides), aber da hab ich gerade
auch keine Patentloesung fuer, die nicht die halbe Welt vor den Kopf
stossen wuerde.
Die Siedlungsfläche als Relation der relevanten landuses=* zu erfassen,
wäre doch keine schlechte Lösung, anstatt Basisgeometrie zu zeichnen.
Die boundary Relation besteht dann aus
border ways
place node in der Rolle admin_centre
landuse relation in der Rolle settlement_centre
Die Relation der Siedlungsfläche bildet ab, welche Einzelflächen der
Realität zur Siedlungsfläche gehören. Damit ist das Wissen explizit in
der DB vorhanden, anstatt implizit über die Definition des Begriffs.
Ich wuerde zumindest anstreben, place-Polygone zu vermeiden. Wenn ich
einen place zu einem Polygon aufblasen moechte, dann sollte ich eine
geeignete Admin-Boundary-Relation dafuer finden. Das wird nicht fuer
alle Places gehen (man denke an place=isolated_dwelling), aber
anstreben kann man es ja.
+1 für die Zielvorstellung.
.., dann muesste es fuer diese Area ja auch eine offizielle oder
wenigstens dokumentierte Begrenzung geben, und dann kann man die
vielleicht auch so taggen.
Ja, gleiche denke hier.
"Landuse" wuerde ich komplett unabhaengig von administrativen Dingen
sehen. Wenn da ein Gebiet mit vorrangig Wohnnutzung ist, dann ist das
landuse=residential, und es spielt ueberhaupt keine Rolle, ob die
Leute da wild wohnen oder ob das ein ausgewiesenes Wohngebiet ist, ob
das zu einer Gemeinde gehoert oder nicht und so weiter.
D.h. Du bist für eine vom rechtlichen Sprachgebrauch vollends
entkoppelte Definition von landuse=residential. Dafür bin ich im
wesentlichen auch.
Aber das bedeutet, dass wir uns von Begriffen wie Wohngebiet als direkte
Übersetzung für landuse=residential verabschieden müssen, denn dieser
Begriff ist ein Rechtsbegriff, ebenso wie das Verständnis der
"vorrangigen Wohnnutzung" an sich - das entspringt direkt dem Gesetzestext.
Die dt. Administration nutzt, wie wäre es anders zu erwarten, diese
Begriffe vollständig. Baufläche, Bauflächengrenze, Baugebiet,
Baugebietsname und Baugebietsgrenze sind in rechtlich belastbarer Form
im Liegenschaftskataster in konkreter geografischer Ausgestaltung
enthalten. Unsere eigene, auch OSMs bisherige, Definition
danebenzustellen, stiftet Verwirrung oder, schlimmstenfalls, Streit.
Die Administration ist ein Teil der Realität. Als solche können wir sie
in OSM abbilden. Aber nicht, indem wir bestehende Definitionen neu
vereinbaren. Das hieße, die Realität zu ändern, nicht abzubilden.
Die Implikationen einer rechtsfreien Definition von landuse=*, die ich
ausdrücklich aufgrund "internationaler Belange" (^.^) befürworte, hatte
ich schon erwähnt:
- landuse erfasst nur die "reale Flächennutzung"
- die Benennung (name=*) der landuses wäre unsinnig
(denn der Name suggerierte, dass es sich um ein admin. Gebiet
handelt, und damit, dass die Grenzen eines benannten landuse
administrative Grenzen wären, was wir ja per Def. nicht wollen)
- Flächengrenze dort, wo Flächennutzung wechselt
- Def. landuse=residential -> /im deutschen/ 'Wohnbaufläche'
/ohne/ Rechtsbezug
Damit ließe sich ein lückenloses "Mosaik der realen Flächennutzungen"
anstreben. Einen Disput über Flächengrenzen wäre ohne weiteres auflösbar.
Der administrative Teil der Realität sollte durch die Mechanismen in OSM
abgebildet werden, die bereits schon länger für das Abbilden der
Administration bestehen, d.h. "von der Gemeindegrenze nach unten hin"
geeignet fortsetzen:
'Wohnbaugebietsname' (*)-> als
place=(neighbourhood/residential/etc. oder area - siehe mail)
'Wohnbaugebiet' (*)-> als border=administrative
- Wohnbaugebiete sind Ansammlungen von Bauflächen mit vorrangig
Wohnbauflächen
'Wohnbaufläche' (*)-> als border=administrative
- Wohnbaufläche entsteht durch den Schnitt von Flurstücksgrenze
mit "realer Flächennutzung"
Da wir die amtliche Flächennutzung nicht erfassen, kann es bei letzterem
Fehler geben, z.B. wenn ein erschlossenes Gebiet nocht nicht wohnbebaut ist.
- OSM gibt dann die reale Nutzung von Flurstücken aus
- das Liegenschaftskataster die amtl. Nutzung (evtl. extra tag
für amtl. Nutzung)
(*) alle Begriffe in ihrer rechtlich-administrativen Bedeutung, siehe
mail von gestern, 15:45 Uhr
Ich sehe bei "Landuse" den beschreibenden Charakter im Vordergrund -
"das hier sieht aus wie ein Wohngebiet".
Ja und das ist eben Mist. "Sieht aus wie X" ist in der Realität eben
nicht unbedingt X. Für die "reale Flächennutzung" muss eine andere
Definition her, eine die möglichst nicht einen bereits klar definierten
Begriff umdeutet. Z.B.
"sieht aus als ob diese Fläche bewohnt ist -> landuse residential"
Im allg. Sprachgebrauch verbietet Dir natürlich niemand, Wohngebiet zu
verwenden wie Du lustig bist. Aber im Wiki, wo es kein unmittelbares
Feedback für den Lesenden gibt, sollten, wenn wir die Realität abbilden
wollen, die Begrifflichkeiten stimmen und, unabhängig welchen Background
der Lesende hat, zu gleichen Interpretationen führen. Das ist momentan
einfach nicht der Fall.
Der Informationsgehalt ist fuer mich dabei gleich, egal, ob ich 10
direkt aneinandergrenzende Flaechen habe oder eine grosse - das sehe
ich im Gegensatz zu einer administrativen Grenze, wo es einen
Unterschied macht, ob man in dem einen admin_level=8-Gebiet oder in
dem anderen admin_level=8-Gebiet wohnt und wo es wichtig ist, an
welcher Stelle sich die Grenze zwischen beiden befindet.
Prinzipiell ok, aber "wichtig" ist relativ. Was für den einen wichtig
ist, ist für den anderen egal. Daher würde ich strikt bei der Frage
bleiben, ob und wie die Realität abgebildet wird, sprich ob OSM als
Datenprovider sowohl die Wünsche des einen, als auch des anderen
erfüllt. Mit guter Ausdifferenzierung lassen sich viele Nutzer
glücklich machen. Sie, die Datennutzer, formulieren was wichtig ist,
der Rest wird weggefiltert. Auf der Seite des Datenproviders wäre
hingegen zu fragen, bilde ich alles ab? Das kann natürlich bei OSM nur
ein Ziel bleiben. Dennoch bin ich der Meinung, dass sich ein
Datenprovider nicht fragen sollte, ob es wichtig ist, denn das
entscheidet der Nutzer. Und der ist bei OSM vielgestaltig und letztlich
undefiniert, weil wir eigentlich niemanden von der Nutzung ausschließen,
damit also nur Zulauf bekommen können.
Klar kann man fragen, ob diese Ausstrukturierung an irgendeiner Stelle
ein Ende haben sollte. Aber solange das Liegenschaftskataster nichtmal
_theoretisch_ mit OSMs Datenmodell abgebildet werden kann, sehe ich dazu
noch keinen wirklichen Grund. Wir fragen ja nicht nach der korrekten
Abbildung von Pflastersteinen, sondern der der Flächennutzung zum einen,
und der innergemdeindlicher Grenzen zum anderen.
Damit wären wir wieder beisammen. Nur haben wir keine lückenlose
Erfassung der Verwaltungsgrenze abzgl. aller Betriebs-, Verkehrs- und
Abbauflächen.
Das waere auch zu kompliziert fuer OSM. Das sind Feinheiten, die dem
Durchschnittsmapper nicht vermittelbar sind. Dass einer Boundary
verwenden soll, wenn er eine amtliche Grenze kennt, und
landuse=residential, wenn er irgendwo steht und das wie ein Wohngebiet
aussieht, das kriegt man den Leuten noch ganz gut erklaert.
Das sehe ich anders. Deine Einschätzung des 'Durchschnittsmappers' in
allen Ehren, aber nicht jeden Mapper interessiert das gleiche - es ist
doch wie in Wikipedia, dort interessiert sich auch nicht jeder im Kern
für Geografie. Die Interessen sind einfach zu verschieden. Und
Ausdifferenzierungen in Gewerbe-, Industrie- und gewisse Arten von
Abbaugebieten (quarry z.B.) gibt es schon _ewig_.
Wir muessen da ein bisschen auf dem Boden bleiben. OSM ist kein
akademisches Projekt, war es nie, kann es nie sein. Wenn jemand mit
akademischer Praezision da was oben drauf setzen will, dann muss er
das selber machen, da kann ihm die breite Masse der Mapper nicht helfen.
Mir geht es nicht darum, von heute auf morgen eine supergenaue Karte zu
haben. Aber Ziele zu definieren, evtl. zu präzisieren, ist schonmal
viel Wert. Indem wir diskutieren und formulieren was später angestrebt
werden kann, vermeiden wir viel doppelte Arbeit. Sonst stochert jeder
so in seinem "könnte" und "sollte" rum, bis sich Mapper wieder, gerade
in dicht gemappten Gebieten angreifen, weil jeder ohne viel
Kommunikation nach seinem eigenen Verständnis mappt. Mich persönlich
stört das, aus folgenden Gründen:
- über den Disput beenden Mapper evtl. ihre Arbeit
Es ist nerven- und zeitraubend, wenn Mapper einfach nur durch
Unklarheiten des Wikis oder des Datenmodells nicht zu einer Lösung
finden /können/. Wenn Unklarheiten im Datenmodell bestehen bleiben,
weil man sich gerne die Interpretationsfreiheit erhält, hat das wenig
mit dem Abbilden der zwar dynamischen, aber strukturierten Realität zu
tun. Diese Unklarheiten und Ungereimtheiten sind ein Fingerzeig auf
fehlende Struktur im Datenmodell, das nicht anzupacken, würde das Wiki
wirklich zur /heiligen/ Schrift erklären.
Es hilft auch nicht, superkomplexe Taggingschemata aufzubauen in der
Hoffnung, man koenne damit tausende Mapper vor seinen Karren spannen
und die fuehren das dann so aus, wie man sich das ueberlegt hat.
no comment - Du hast Bücher geschrieben, die tausende Mapper vor einen
Karren gespannt haben dürften.. so etwas macht man eigentlich aus
Überzeugung für die Sache - darf ich die jetzt nicht haben? Martin,
andere, und meine Wenigkeit haben sich hier an einer Lösung für ein
Problem versucht, das auf dieser Liste offensichlich nicht das erste Mal
diskutiert wurde. Willst Du bis nächstes Jahr warten, um das dann
wieder auf diese Weise flachzuklopfen? Wo bitteschön hast Du
superkomplexe Taggingschemata entdeckt?
Martin und ich haben in erster Linie und im Dialog eruiert, /was/
überhaupt im Bereich Baufläche/Baugebiet abgebildet werden kann, /wo/
unser Verständnis der verwendeten Begriffe herkommt und /weshalb/ es
Gründe für Disput überhaupt gibt. Es fing mit der Frage an, ob landuses
an ways geklebt werden sollten, oder nicht. Die Frage ist beantwortbar,
insofern klar ist, /was/ wir mit landuses=* überhaupt genau mappen. Das
ist wesentlich klarer, als zu Beginn, aber in den Kernpunkten noch
puzzleartig auf einzelne mails verstreut.
Ein aufsummiertes Taggingschema als Schlussfolgerung hat bisher keiner
von uns abgegeben. Wir haben an einigen Stellen festgestellt, wie es
besser und widerspruchsfreier laufen /könnte/. Es geht zumindest mir
darum, Dinge der Realität in OSM auseinanderzuhalten, die bisher
widerspruchsbehaftet gemeinsam abgebildet wurden.
Bei diesem Projekt erstellt niemand Komplexität - die steckt in der
Realität. Durch gute Dokumentation kannst Du die Erfassung ihres
Abbilds vereinfachen, durch schlechte hingegen erschweren. Meine Meinung.
Gruß
_______________________________________________
Talk-de mailing list
Talk-de@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-de
