Re: [Talk-de] Übersicht zur Debatte um die Boden/Flächennutzung (landuse=) und Orte/Toponyme (place=)
Am 23.09.2011 08:41, schrieb Georg Feddern:
Wie gesagt, kann man machen, ist aber nicht intuitiv und sehr, sehr
aufwändig zu pflegen. Der Sinn eines Tags hängt in OSM am TAG und
nur daran, und _nicht_ an welche Geometrie es gepappt ist. Oder
anders: Egal an welche Geometrie ein TAG gepappt wird, es hat immer
den gleichen Sinn. /Das/ verletzt Du, wenn Du sagst:
a) place an nodes ist ein Ort (im geographischen Sinne:
beliebige Orte: Seen, Fluren, Landstriche, Kontinente, Siedlungen,
etc..)
b) place als area ist eine Siedlung
Zu a) ja.
Zu b) nein, nicht nur. Wieso sollte das nur so sein? Eine Siedlung ist
aber nunmal auch ein Ort.
Ich hatte die Gegendarstellung dazu bereits in meine mail aufgenommen,
und Du gehst auch auf diese weiter unten ein.. Mir ging es mit b) im
besonderen darum, aufzuzeigen, wie /place als area im Kontext von
Siedlungen/ verwendet wird. In diesem Kontext stellt es eine
speziellere Verwendung dar, als in allen anderen,
Nicht-Siedlungskontexten in denen /place als area/ noch Verwendung
finden kann.
Da dieser Sachverhalt eben sprachlich schwer darzustellen ist, aber
entscheidend ist, habe ich beide Darstellungen aufgenommen - das was Du
in Zu b) feststellst, war also bereits Teil der mail, siehe hier:
Bevor ich deine nächste mail erhalte, prophezeie ich, dass Du den
letzten Punkt umdeformierst zu
place als area ist auch ein Ort (im geographischen Sinne: für
Seen, Fluren, Siedlungen, etc. pp.)
Umdeformieren würde ich das nicht nennen. Für mich hatte es von Anfang
an diese Form.
Ja, Du sagst es von Anfang an. Aber eben nicht mehr - im Kontext
von Siedlungen hat es nicht die gleiche Form, sondern eine speziellere.
Das funktioniert aber eben gerade für Siedlungen nicht, /weil/ diese
mehrere Flächen haben, die gleichberechtigt nebeneinanderstehen und
als Ortsfläche gelten können: Die Gemeindefläche ist eine
Ortsfläche, die Siedlungsfläche ist eine Ortsfläche, etc. pp. pp. pp.
Jetzt muss ich mal ein paar Gegenfragen stellen:
Ist die Gemeinde Bendfeld ein Ort oder ist die Siedlung Bendfeld ein Ort?
Sind place={city, town, village, hamlet} Siedlungen oder nicht?
Der /Ort/ Bendfeld ist /sowohl/ Gemeinde /als auch/ Siedlung. Ein
Datenmodell kann also entweder
- beide Flächen, die Gemeindefläche UND die Siedlungsfläche
als /place/ abbilden
- oder keine, also beide Flächen als das taggen was sie sind
- Gemeindefläche - boundary=administrative
- Fläche der Siedlung - boundary=settlement
- aber nicht _eine_ von beiden nach Belieben
Wdh.: es kann noch mehr Flächen geben, die ein und demselben Ort
zuordenbar und mit demselben Ortsnamen benannt sind
(Man beachte also: Nicht alle geographischen Orte werden in OSM mit
place bezeichnet!)
+1 Das ist korrekt, aber place=locality lässt ein seehr breites
Spektrum zu. So kann ein geographischer Ort, der in OSM eigentlich
durch ein spezielleres Tag abbildbar ist, durchaus auch nur als place
getaggt sein, auch dann, wenn man nicht genau weiß, welchem
geographischen Feature der place-name vor Ort zuzuordnen ist.
Die Gemeinde Bendfeld ist für mich ein Verwaltungsbereich und wird
deshalb auch sinnvoll durch die Verwaltungsgrenze abgebildet - ich
würde sie aber nicht als Ort bezeichnen.
ich würde - das ist deine Meinung. Die steht an dieser Stelle
gegen eine Vielzahl (!) anderer Meinungen. Für die politische Grenze
eines Ortes ist der Terminus Ortsgrenze durchaus geläufig.
Wenn für Dich die Verwaltungsgrenze keine Ortsgrenze ist, obwohl
letztere nur eine Generalisierung ersterer darstellt und damit durchaus
synonym verwendet werden kann, dann müsstest Du logischerweise auch die
Auffassung vertreten, dass auch der
Siedlungsbereich [...] deshalb auch sinnvoll durch die
Siedlungsgrenze abgebildet [wird] - [Du sie] aber nicht als Ort
bezeichnen [würdest].
- das ist eine simple Adaption deiner Auffassung zur Verwaltungsgrenze..
Die Siedlung Bendfeld ist für mich ein Ort (siehe auch Ortschaft).
Ok, aber wir waren bereits nun schon soweit, dass Ort (place) !=
Siedlung (und damit auch place != Ortschaft).
Natürlich mischt die deutsche Sprache diese Dinge zusammen, es geht uns
ja aber gerade darum, sie in OSM auseinanderzuhalten, weil wir eine
größere Genauigkeit im geographischen Kontext brauchen, als in einem
Alltags-Kontext (in welchem ich keine Geo-Daten erfasse, sondern nur
über sie spreche).
Mit dem node place=village und dem zugehörigen name=Bendfeld verbinde
ich daher auch immer die Siedlung, nicht die Gemeinde.
-1 das wird totaler Mist. Jeder halbwegs vernünftige Mensch verbindet
mit dem Ort (place) Bendfeld sowohl die Siedlung als auch die Gemeinde.
Wobei die letzten beiden eben Spezialisierungen von /Ort/ sind, um
/genauer/ zu bezeichnen, wovon man spricht..
Momentan geht OSM genau den umgekehrten Weg, wir verwenden /place/ um das
Re: [Talk-de] Übersicht zur Debatte um die Boden/Flächennutzung (landuse=) und Orte/Toponyme (place=)
Am 23.09.2011 13:07, schrieb Martin Koppenhoefer: Natural sehe ich allerdings auch als Art von geographischen Features, zusammen mit place ergibt das den Kanon der geographischen Orte in OSM. +1 genau so ist das. Nur, wenn Settlements mitsingen, klingt der Kanon schief.. Gruß ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Übersicht zur Debatte um die Boden/Flächennutzung (landuse=) und Orte/Toponyme (place=)
Am 23.09.2011 13:07, schrieb Martin Koppenhoefer: Natural sehe ich allerdings auch als Art von geographischen Features, zusammen mit place ergibt das den Kanon der geographischen Orte in OSM. +1 genau so ist das. Nur, wenn Settlements (als area / Fläche) mitsingen, klingt der Kanon schief.. Gruß ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Übersicht zur Debatte um die Boden/Flächennutzung (landuse=) und Orte/Toponyme (place=)
Hi, Am 24.09.2011 22:06, schrieb Stefan Keller: Du scheinst dieses Konzept nun erweitern zu wollen, so dass Beziehungen zu umschliessenden Flächen (Inkludiertheit) erfasst werden. Zu dem rate ich dingend ab! Ich möchte keine Beziehungen zu umschliessenden Flächen /explizit/ aufnehmen. Falls das anklang, habe ich mich zu ungenau ausgedrückt. Mir ist jedoch aufgefallen, dass einige Flächenbeziehungen evtl. bereits dadurch ermittelbar sein könnten, dass eine Flächengrenze (ein way als Grenzsegment) an mehreren Multipolygonen teilnehmen darf. Ob zwei Flächen benachbart sind, oder z.B. eine Inklusion darstellen, ist evtl. unter Vernachlässigung der gemeinsamen Flächengrenzsegmente beider Multipolygone einfacher auszurechnen. Anstatt die gesamten Streckenzüge zu betrachten, wäre dann nur auf den Unterschieden zu rechnen. Zugegebenermaßen fehlt mit hier etwas math. Hintergrundwissen, inwieweit topologische Information (gleiche Flächengrenze) mit geometrisch errechneter Information (unterschiedliche Flächengrenzen), kombiniert werden dürfen/können um exakte Aussagen über Flächenbeziehungen treffen zu können. Dass die relationale Datenstruktur der Multipolygone darüber Aufschluss gibt, wieviele und welche Flächengrenzsegmente zwei Flächen gemeinsam sind, ist für eine Berechnung von Lagebeziehungen zweier als Multipolygon repräsentierter Flächen aber sicher nicht bedeutungslos. Meine Gedanken drehten sich ganz konkret darum, inwieweit die durch die DB gewährleistete, referentielle Integrität zw. Multipolygonen und beteiligter Flächengrenzsegmente für die Berechnung der Flächenbeziehungen nutzbar ist. Oder einfacher: wie weit bringt mich das Traversieren von Flächengrenzen (das eine rein topologische Angelegenheit ist), wenn es darum geht, Aussagen über den Flächenbezug zu treffen und wann muss ich wirklich geometrische Berechnungen anstellen? Explizit Flächenbeziehungen zu erfassen, war nicht in meinem Sinne. Momentan ist es so, dass es zwar gemeinsame Flächengrenzen gibt (overlapping ways), aber die Ermittlung teilnehmender Flächen viel komplizierter ist, als wenn es sich um einen an Multipolys teilnehmenden Weg handelt. Bis evtl. auf den Punkt, dass ich Multipolys gerne als inner sehen möchte, anstatt closed ways, stelle ich mir keine Änderung zur bisherigen Def. vor. - ein Multipolygon besteht aus 1 (!) geschlossenen Außenring (Summe der outer ways) - ein Multipolygon enthält 0-n Innenringe (entweder /way/ (momentan), oder relation (multipolygon)) Damit ist vermutlich alles gesagt. Das Flächennetzwerk bildet sich eigentlich automatisch, wenn man das zum Mappen nutzt. Die Aussagen, die es zu Flächenbezügen treffen kann, sind von Fall zu Fall mal aufwendiger (sprich geometrischer), mal weniger aufwendiger (sprich topologischer) zu lösen. Du hast mich evtl. was die Inkludierungsbeziehung betrifft, deshalb falsch verstanden, weil ich davon sprach, dass manche Flächengrenzen für mehrere Flächen wiederverwendet werden und ich daraufhin einen unkonkreten Ausblick/Mutmaßung dazu gegeben habe, inwieweit dies die Ermittlung von Flächenbeziehungen positiv beeinflusst. Gruß Christian ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Übersicht zur Debatte um die Boden/Flächennutzung (landuse=) und Orte/Toponyme (place=)
Hi, Am 24.09.2011 22:06, schrieb Stefan Keller: Das kann jeder ausprobieren z.B. auf dem PostGIS Terminal, z.B. so http://labs.geometa.info/postgisterminal/?xapi=polygon[tourism=zoo] Danke für den Tipp.. Warum sollte aber jemand diesen Aufwand betreiben, wenn er durch bessere Datenlage nicht bestünde? Mehr noch, warum sollte ihn _jeder_ _separat_ betreiben, der an Lagebeziehungen zwischen Flächen interessiert ist? Anders rum: Warum sollte jeder, Relationen ohne Ende erfassen, nur um mögliche künftige Abfragen zu erleichtern? Dies zumal es schon genug schwierig ist, Flächen (jeder Art) konsistent zu erfassen? Hier reden wir ein klein wenig aneinander vorbei, was evtl. auch dem Fakt geschuldet ist, dass Du meine mail als Wunsch nach einer Erweiterung von Multipolygonen aufgefasst hast. Also noch anders herum: Es sollte jeder Flächen als Multipolygone erfassen, /um/ Flächen konsistent zu erfassen. Wie gesagt, dass Multipolygone im Hintergrund durch Relationen realisiert werden, ist eigentlich etwas, dass der Nutzer eines OSM-Editors gar nicht merken sollte - allenfalls, wenn er es merken will. Gruß Christian ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Übersicht zur Debatte um die Boden/Flächennutzung (landuse=) und Orte/Toponyme (place=)
Hallo Christian, Am 26. September 2011 23:56 schrieb Christian Müller cmu...@gmx.de: Warum sollte aber jemand diesen Aufwand betreiben, wenn er durch bessere Datenlage nicht bestünde? Mehr noch, warum sollte ihn _jeder_ _separat_ betreiben, der an Lagebeziehungen zwischen Flächen interessiert ist? Anders rum: Warum sollte jeder, Relationen ohne Ende erfassen, nur um mögliche künftige Abfragen zu erleichtern? Dies zumal es schon genug schwierig ist, Flächen (jeder Art) konsistent zu erfassen? Hier reden wir ein klein wenig aneinander vorbei, was evtl. auch dem Fakt geschuldet ist, dass Du meine mail als Wunsch nach einer Erweiterung von Multipolygonen aufgefasst hast. Also noch anders herum: Es sollte jeder Flächen als Multipolygone erfassen, /um/ Flächen konsistent zu erfassen. Wie gesagt, dass Multipolygone im Hintergrund durch Relationen realisiert werden, ist eigentlich etwas, dass der Nutzer eines OSM-Editors gar nicht merken sollte - allenfalls, wenn er es merken will. Einverstanden. Stefan ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Übersicht zur Debatte um die Boden/Flächennutzung (landuse=) und Orte/Toponyme (place=)
Christian, Am 22. September 2011 16:58 schrieb Christian Müller cmu...@gmx.de: - Bedingung: Datenhaltung von Flächen als multipolygons wie es Sinn macht, bei kleinen landuse-Flächen aus meiner Sicht unnötig und schädlich, da es unnötig das Mappen verkompliziert. +/- 1. Jein. Das ist ja momentan nur deshalb komplizierter, weil die Tools dafür zu schlecht sind. Ich schrieb in einer meiner mails: multipolygons müssen so einfach werden, wie einen closed way zu zeichen. Das erachte ich als Vorraussetzung und letztlich /sind/ multipolygons DAS Flächentool in OSM schlechthin. Nur werden sie noch nicht so eingesetzt, stattdessen beschränkt man sich auf ihre Verwendung für Spezialfälle. Das mit den Flächen ist bei OSM so eine Sache. Es gibt in der Nicht-OSM-Welt eine einzige allgemein(!) akzeptierte Norm (von OGC) und die kennt den Geometrietyp Polygon und Multipolygon. OSM-Multipolygone sind vergleichbar mit OGC-Polygon *und* OGC-Multipolygon. Mir wäre noch so recht, würde OSM auf diese Definition umstellen. Was du nun mit OSM-Multipolygonen in der Folge erläuterst, ist sehr mit Vorsicht zu geniessen: Die Vergangenheit zeigt aber, dass öfter als weniger, einfache Fälle zu Spezialfällen mutieren. Clevere Leute mappen ihre Flächen dann mit multipolygons neu (obwohl das umständlich ist, Du schreibst es selbst), andere behelfen sich damit, overlapping ways zu bilden (was ich selbst lange Zeit gemacht habe, da ich noch nicht wußte, wie die eigentliche Lösung aussieht), oder damit, überhaupt keinen Flächenbezug herzustellen (geschachtelte closed ways) - was keine vernünftige Abbildung der Realität ist. Du verwendest hier das Wort Flächenbezug in verwirrender Weist (s.u.). Wenn es Flächen gibt, die innerhalb Flächen sind, dann ist das Ok, ob die innerste Fläche nun als closed way plus tags oder Multipolygon erfasst ist. In der Realität gibt es ohne Ende Bezüge zwischen den Flächen (das Wohngebiet liegt __innerhalb__ der Gemeindefläche, der Bäcker liegt __innerhalb__ des Wohngebiets, das Feld _grenzt_ an Weg- oder Wald- -fläche -- und das sind nur Beispiele für eine Lagebeziehung). Einverstanden. Bezüge (Relationen) ohne Ende. Natürlich kann ich mir die Lagebeziehungen auch erst ausrechnen, anstatt sie ordentlich mitzumodellieren, für viele Lagebeziehungen wird aber diese Rechnung sehr komplex - betrachte z.B. die Lagebziehung Gemeindefläche __innerhalb__ Bundesgebietsfläche: Ist komplex - aber in allen Geodatenbanken und Geoinformationssystemen gelöst. Wenn diese Beziehung nicht durch Datenstrukturen zu ermitteln ist (wie das jetzt der Fall ist), müsste ich für die gesamte bundesdeutsche Grenze (a lot of nodes) algorithmisch prüfen, ob die Gemeindefläche (less nodes but still a lot) komplett inkludiert ist. Wenn ich diese Lagebeziehung dann für _alle_ Gemeindeflächen brauche, wird meine CPU schwitzen. OSM sei Dank muss ich aber nur wissen, /wie/ ich die entsprechende Datenstruktur auslesen muss. Dieses Problem lässt sich für jedwede Lagebeziehung von Flächen aufzeigen. Das ist, weshalb ich schon die ganze Zeit nicht müde werde, zu erzählen, dass Beziehungen zwischen Flächen nicht _einfach so_ da sind. Es ist besser, wenn insbes. die Lagebeziehungen innerhalb OSMs Datenstrukturen vorhanden sind: Das ist ein wichtiger Punkt: Die meisten geometrische(!) Beziehungen zwischen Punkten, Linien, Flächen und zwischen Flächen und Flächen kann man mit geometrischen Werkzeugen jederzeit berechnen! Es ist nur das Nötigste zu erfassen! Wenn eine Fläche keine Enklave hat, genügt ein closed way plus tags (du nennst es glaube ich anders) ansonsten als Multipolygon. Das geht nicht mit closed ways, das geht auch nicht mit overlapping ways sondern nur mit zueinander in Beziehung stehenden Multipolygons (ich habe das als 'Flächennetzwerk' bezeichnet). Flächennetzwerk ist ein Begriff, der die Topologie (Konzept der Nachbarschaft auf einer Menge von Punkten ...). Konkret wird die gemeinsame Grenze zweier Flächen je einmal in der Multipolygon-Relation erfasst. Du scheinst dieses Konzept nun erweitern zu wollen, so dass Beziehungen zu umschliessenden Flächen (Inkludiertheit) erfasst werden. Zu dem rate ich dingend ab! Es ist so schon schwierig genug, sich auf eine einheitliche Handhabung von OSM-Multipolygonen zu einigen. Würde man diese Forderung umsetzen, dann müsste man die Bezüge (Relationen) ohne Ende (wie oben erwähnt) und Relationen ohne Ende umsetzen, also möglichst für jede mögliche Abfrage. Dein Anliegen zur schnellen Abfrage (= genannt Analyse) ist aber legitim. Die Lösung sieht so aus, dass man Erfassung und Verwaltung trennt von der Analyse (s.u.). Es nützt auch nichts zu argumentieren, dass manche Polygone ja viel kleiner seien und nicht so viele nodes hätten, wie andere und damit die Rechnung in der Tat einfacher sei.. Eine Lagebeziehung kann ich nur zwischen mindestens zwei Polygonen bilden, d.h. ich beschränke mich mit dieser
Re: [Talk-de] Übersicht zur Debatte um die Boden/Flächennutzung (landuse=) und Orte/Toponyme (place=)
Moin,
Christian Müller schrieb:
Du hast das (schon) wieder aus dem Kontext gerissen. Der Satz bezieht
sich darauf, dass place in OSM keinen /Siedlungs/bezug im Speziellen,
sondern einen /Orts/bezug im Allgemeinen hat. Ich weiß nicht, wie oft
ich Dir das noch erzählen soll, aber wenn Du Dir taginfo anschaust,
wirst auch Du das feststellen.
Siedlungsgrenzen sind nunmal nichts Allgemeines, sondern etwas
Spezielles. Warum willst Du also darauf beharren, an etwas
Spezielles, einen allgemeinen Tag zu vergeben? Das wäre nicht nur
kindisch, sondern kontraproduktiv.
Wir können nicht auf /nodes/ die allgemeine Deutung anwenden und auf
areas plötzlich eine /speziellere/.
Der Sinn des Tags wohnt dem Tag selbst inne, der Sinn des Tags
entsteht nicht erst, wenn ich das Tag an eine Geometrie vergebe.
Es ist in OSM egal an welche Art Geometrie Du ein Tag hängst, es
ändert seinen Sinn dadurch nicht (ein Geschäft /shop/ bleibt ein
Geschäft, egal ob ich /node/ oder /way/ oder /relation/ damit tagge).
/Du/ brichst diesen Konsens auf, indem Du eine Sinnwandlung des Tags
/place/, _in Abhängigkeit_ der Geometrie welche Du betaggst, befürwortest.
Bei Dir (und denen, die deiner Auffassung folgen) ist /place/ am
way vom Sinn her etwas anderes, als /place/ am node. Das ist keine
Kleinigkeit!!!
Äh, nein. Das sehe ich anders. Für mich ist place am node und am way von
jeher vom Sinn her das Gleiche. Aber weiter s. u.
Wie gesagt, kann man machen, ist aber nicht intuitiv und sehr, sehr
aufwändig zu pflegen. Der Sinn eines Tags hängt in OSM am TAG und nur
daran, und _nicht_ an welche Geometrie es gepappt ist. Oder anders:
Egal an welche Geometrie ein TAG gepappt wird, es hat immer den
gleichen Sinn. /Das/ verletzt Du, wenn Du sagst:
a) place an nodes ist ein Ort (im geographischen Sinne:
beliebige Orte: Seen, Fluren, Landstriche, Kontinente, Siedlungen, etc..)
b) place als area ist eine Siedlung
Zu a) ja.
Zu b) nein, nicht nur. Wieso sollte das nur so sein? Eine Siedlung ist
aber nunmal auch ein Ort.
Bevor ich deine nächste mail erhalte, prophezeie ich, dass Du den
letzten Punkt umdeformierst zu
place als area ist auch ein Ort (im geographischen Sinne: für
Seen, Fluren, Siedlungen, etc. pp.)
Umdeformieren würde ich das nicht nennen. Für mich hatte es von Anfang
an diese Form.
Das funktioniert aber eben gerade für Siedlungen nicht, /weil/ diese
mehrere Flächen haben, die gleichberechtigt nebeneinanderstehen und
als Ortsfläche gelten können: Die Gemeindefläche ist eine
Ortsfläche, die Siedlungsfläche ist eine Ortsfläche, etc. pp. pp. pp.
Jetzt muss ich mal ein paar Gegenfragen stellen:
Ist die Gemeinde Bendfeld ein Ort oder ist die Siedlung Bendfeld ein Ort?
Sind place={city, town, village, hamlet} Siedlungen oder nicht?
In diesem Sinne also durchaus ja, ein place (in OSM) ist ein Ort (im
geographischen Sinne: für Fluren, Siedlungen, etc. pp.) - ob als note
oder als area.
Seen, Berge u.ä. würde ich in diesem Fall mal außen vor lassen, da diese
in OSM grundsätzlich nicht mit place bezeichnet werden, auch wenn sie
geographisch einen Ort darstellen.
(Man beachte also: Nicht alle geographischen Orte werden in OSM mit
place bezeichnet!)
Die Gemeinde Bendfeld ist für mich ein Verwaltungsbereich und wird
deshalb auch sinnvoll durch die Verwaltungsgrenze abgebildet - ich würde
sie aber nicht als Ort bezeichnen.
Die Siedlung Bendfeld ist für mich ein Ort (siehe auch Ortschaft).
Mit dem node place=village und dem zugehörigen name=Bendfeld verbinde
ich daher auch immer die Siedlung, nicht die Gemeinde.
Von daher habe ich auch kein Problem damit, mit der area place=village
die Siedlungsfläche der Ortschaft zu verbinden.
Das eine ist mein praktisch-pragmatisches Verständnis - das andere mag
Dein theoretisch-wissenschaftliches Verständnis sein.
Letztendlich entscheidet aber das 'allgemeine' Verständnis in OSM über
die Tags und Verwendung - dem werden wir uns beide anpassen müssen, wie
auch immer.
Erfahren werden wir das hier aber nicht - dafür müsste man wohl einen
neuen Thread starten, um wieder die Aufmerksamkeit der Allgemeinheit zu
erlangen ...
Gruß
Georg
___
Talk-de mailing list
Talk-de@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Übersicht zur Debatte um die Boden/Flächennutzung (landuse=) und Orte/Toponyme (place=)
Am 23. September 2011 08:41 schrieb Georg Feddern o...@bavarianmallet.de: In diesem Sinne also durchaus ja, ein place (in OSM) ist ein Ort (im geographischen Sinne: für Fluren, Siedlungen, etc. pp.) - ob als node oder als area. Seen, Berge u.ä. würde ich in diesem Fall mal außen vor lassen, da diese in OSM grundsätzlich nicht mit place bezeichnet werden, auch wenn sie geographisch einen Ort darstellen. (Man beachte also: Nicht alle geographischen Orte werden in OSM mit place bezeichnet!) nun ja, Inseln werden mit place bezeichnet und Seen und Berge gibt es als solche bisher noch gar nicht in OSM (es gibt Gipfel und Wasser). Natural sehe ich allerdings auch als Art von geographischen Features, zusammen mit place ergibt das den Kanon der geographischen Orte in OSM. Auch sonst +1 zu Deiner kompletten Mail. Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Übersicht zur Debatte um die Boden/Flächennutzung (landuse=) und Orte/Toponyme (place=)
Am 22. September 2011 02:17 schrieb Christian Müller cmu...@gmx.de: Am 21.09.2011 21:58, schrieb Stefan Keller: Im Kern geht es um drei Baustellen: 1) die Erfassung von landuse (Bodennutzung) allgemein +1 - bessere Strukturierung der tag-values nach ISIC, etc. das war immer nur zusätzlich gedacht, zumindest hatte ich das so verstanden und unterstütze es auch nur parallel aber nicht als values für landuse - beliebige Flächen/größe/ zulassen (MICROmapping und normalos) das war schon immer so, es geht nur darum, was man empfiehlt. - Bedingung: Datenhaltung von Flächen als multipolygons wie es Sinn macht, bei kleinen landuse-Flächen aus meiner Sicht unnötig und schädlich, da es unnötig das Mappen verkompliziert. - Flächen/charakterisierung/, also Definition im Wiki überarbeiten - überwiegende, bzw. vorrangige Nutzung steht da bereits. Ist zwar unwidersprochen aber nicht klar, da unklar ist, wie groß eine area ist. - Nutzungserfassung vor Ort (oder äquivalent) +1. Äquivalent gibt es praktisch nicht, oder nur in Spezialfällen wie großen Fabriken. Kenntnis der Lage vor Ort ist erforderlich. 2) die Bedeutung von landuse=residential im Speziellen - darf da nun ein /Gebiets/name dran? da kann auch ein Gebietsname ran, aber der wird sich i.d.R. nicht auf die Bodennutzung sondern auf das Gebiet an sich beziehen, in dem eben u.a. auch die Nutzung einheitlich ist. Das Objekt, das den Namen trägt, ist m.E. ein Siedlungsteil, nicht eine Bodennutzung. - eigentlich erfasst landuse nur die Bodennutzung, und damit Bodennutzungsgrenzen es erfasst Bodennutzungsflächen (indem die Bodennutzungsgrenzen markiert wird). - Wohngebiete sind aber dadurch charakterisiert, dass sie einen Namen tragen und der Grenzverlauf amtlich dokumentiert ist -1. Da täuscht Du Dich, bzw. ist das keine generelle Regel sondern kann sein, muss aber nicht - in einem strengen Sinne sind Wohngebietsgrenzen boundary=administrative (Verwaltungsgrenzen) -1 3) place-tag Verwendung auf nodes zurückfahren -1, was meint zurückfahren? Löschen? Nur damit Du Deine Ansichten durchdrücken kannst? Und dann in 2 Jahren feststellst, dass es ein Irrtum war? - alle geografischen Orte haben eine unbestimmte Lage (node = ausdehnungslos) in erster Näherung ist das z.B. fürs Rendern schonmal viel besser als gar nichts. Nochmal besser sind Flächen. Flächen, die in einem bestimmten Kontext zu einem Ort stehen, haben i.d.R. kontextbezogene Namen, z.B. Gemeindefläche, Siedlungsfläche. Ob die Grenzen dieser Fläche, oder die Gesamtfläche rudimentär als closed way erfasst wird, spielt keine Rolle bei der Feststellung, dass ein kontextbezogener Tag vergeben werden sollte. Gemeindefläche - boundary=administrative, Siedlungsfläche - ??? (boundary=settlement oder landuse=settlement oder settlement=*, etc. möglich - Hauptsache, da taucht kein place auf) Hauptsache, da taucht kein place auf. Sorry, aber jetzt wirds m.E. kindisch. Du willst geographische Orte also auch erfassen, aber nicht den dafür etablierten Tag verwenden sondern einen neuen, aus Prinzip, damit die Diskussion hier nicht sinnlos war? Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Übersicht zur Debatte um die Boden/Flächennutzung (landuse=) und Orte/Toponyme (place=)
Hi, Am 22.09.2011 10:16, schrieb Martin Koppenhoefer: - bessere Strukturierung der tag-values nach ISIC, etc. das war immer nur zusätzlich gedacht, zumindest hatte ich das so verstanden und unterstütze es auch nur parallel aber nicht als values für landuse da hat ein z.B. gefehlt .. Frederik ging es ja um die Senkung von Eintrittsbarrieren, um das mappen für Einsteiger verständlicher zu machen, daher der Wunsch ein paar values aus landuse zu entfernen und diese stattdessen in subtags oder sub-sub-tags zu modellieren.. dazu gab es auch von anderen Leuten Zustimmung, die fanden, dass die values liste für key:landuse bereits zu lang ist.. ISIC war nur eine Anregung, wie man das sinnvoll machen kann, wenn man bestehende Arbeit (der UNO) in diesem Fall wiederverwendet.. Für eine Ausdifferenzierung der obersten Ebene von landuse ist die oberste Ebene von ISIC vermutlich nicht zu gebrauchen. So wie ich es verstanden habe, bildete sich für die oberste Ebene von key:landuse residential, commercial, industrial, ((mixed)) heraus, wobei ich den mixed-Typ für überflüssig hielt. Für alle anderen values von key:landuse müsste man schauen, ob die wirklich berechtigt _neben_ diesen Werten stehen, oder eher _unter_, also eine Spezialisierung eines dieser Werte sind (also in einen subtag gehören..) - Bedingung: Datenhaltung von Flächen als multipolygons wie es Sinn macht, bei kleinen landuse-Flächen aus meiner Sicht unnötig und schädlich, da es unnötig das Mappen verkompliziert. +/- 1. Jein. Das ist ja momentan nur deshalb komplizierter, weil die Tools dafür zu schlecht sind. Ich schrieb in einer meiner mails: multipolygons müssen so einfach werden, wie einen closed way zu zeichen. Das erachte ich als Vorraussetzung und letztlich /sind/ multipolygons DAS Flächentool in OSM schlechthin. Nur werden sie noch nicht so eingesetzt, stattdessen beschränkt man sich auf ihre Verwendung für Spezialfälle. Die Vergangenheit zeigt aber, dass öfter als weniger, einfache Fälle zu Spezialfällen mutieren. Clevere Leute mappen ihre Flächen dann mit multipolygons neu (obwohl das umständlich ist, Du schreibst es selbst), andere behelfen sich damit, overlapping ways zu bilden (was ich selbst lange Zeit gemacht habe, da ich noch nicht wußte, wie die eigentliche Lösung aussieht), oder damit, überhaupt keinen Flächenbezug herzustellen (geschachtelte closed ways) - was keine vernünftige Abbildung der Realität ist. In der Realität gibt es ohne Ende Bezüge zwischen den Flächen (das Wohngebiet liegt __innerhalb__ der Gemeindefläche, der Bäcker liegt __innerhalb__ des Wohngebiets, das Feld _grenzt_ an Weg- oder Wald- -fläche -- und das sind nur Beispiele für eine Lagebeziehung). Natürlich kann ich mir die Lagebeziehungen auch erst ausrechnen, anstatt sie ordentlich mitzumodellieren, für viele Lagebeziehungen wird aber diese Rechnung sehr komplex - betrachte z.B. die Lagebziehung Gemeindefläche __innerhalb__ Bundesgebietsfläche: Wenn diese Beziehung nicht durch Datenstrukturen zu ermitteln ist (wie das jetzt der Fall ist), müsste ich für die gesamte bundesdeutsche Grenze (a lot of nodes) algorithmisch prüfen, ob die Gemeindefläche (less nodes but still a lot) komplett inkludiert ist. Wenn ich diese Lagebeziehung dann für _alle_ Gemeindeflächen brauche, wird meine CPU schwitzen. OSM sei Dank muss ich aber nur wissen, /wie/ ich die entsprechende Datenstruktur auslesen muss. Dieses Problem lässt sich für jedwede Lagebeziehung von Flächen aufzeigen. Das ist, weshalb ich schon die ganze Zeit nicht müde werde, zu erzählen, dass Beziehungen zwischen Flächen nicht _einfach so_ da sind. Es ist besser, wenn insbes. die Lagebeziehungen innerhalb OSMs Datenstrukturen vorhanden sind: Das geht nicht mit closed ways, das geht auch nicht mit overlapping ways sondern nur mit zueinander in Beziehung stehenden Multipolygons (ich habe das als 'Flächennetzwerk' bezeichnet). Es nützt auch nichts zu argumentieren, dass manche Polygone ja viel kleiner seien und nicht so viele nodes hätten, wie andere und damit die Rechnung in der Tat einfacher sei.. Eine Lagebeziehung kann ich nur zwischen mindestens zwei Polygonen bilden, d.h. ich beschränke mich mit dieser Argumentation dann schon auf Lagebeziehungen zwischen zwei _viel kleineren_ Polygonen. Natürlich sind Algorithmen denkbar, die den Rechenaufwand für viele solcher Berechnungen wieder reduzieren, indem z.B. entsprechend bounding boxes gebildet werden und dann erstmal nur gegen diese gerechnet wird, anstatt gegen den kompletten Streckenzug. Warum sollte aber jemand diesen Aufwand betreiben, wenn er durch bessere Datenlage nicht bestünde? Mehr noch, warum sollte ihn _jeder_ _separat_ betreiben, der an Lagebeziehungen zwischen Flächen interessiert ist? Mit ein bisschen Javascript, und dem entsprechenden Flächennetzwerk, kann ich auf jedem Client echt komplexe Lagebeziehungen aufzeigen,
