Re: [Talk-de] landuse=road War:[viel Text zu landuse-handling..]
Am 19.09.2011 20:16, schrieb Martin Koppenhoefer: Am 19. September 2011 19:34 schrieb Christian Müllercmu...@gmx.de: Am 16.09.2011 11:16, schrieb Martin Koppenhoefer: Du täuschst Dich hier. Siedlungsstellen lassen sich nicht automatisch errechnen, weil die Informationen dazu fehlen. Bei den landuses - so man sie alle erfasst hat - sind die benötigten Informationen hingegen vorhanden. Daher geht es da. -1 Das ist, sorry, absoluter Unfug. /Erstens/ sind die benötigten Informationen für die Siedlungsstellen existent, wenn landuses komplett erfasst sind. Du willst es nicht verstehen. Es ist nicht klar, zu _welcher_ menschlichen Siedlung sie gehören. Das ist das Problem, nicht, ob sie besiedelt sind. Natürlich ist das klar - anhand der Gemeinde, bzw. Gemarkungsgrenze, innerhalb derer die landuses liegen. Im allgemeinen umfassen politische Grenzen einer Gemeinde einen größeren Bereich, mindestens aber den Bereich der Siedlung. Selbst wenn eine politische Grenze aktuell nicht mehr zu finden ist, wird es eine historische geben, die für die Ermittlung benutzt werden kann. Die Information einer Siedlungsflächengrenze ist damit klar redundant [[denn es gibt Regeln, mittels derer sie sich ausrechnen lässt]]. Ich vertrete aber die Auffassung, dass diese Regeln nicht außerhalb der DB stehen sollten. Schließlich ist sie über eine Relation innerhalb OSM effizient pro Fall abbildbar. In gewisser Weise steckt Redundanz dann nur dadurch in der DB, dass die Regel mehrmals angewandt wird. Das hat aber eben auch den Vorteil, dass Ausnahmen ohne weiteres abbildbar sind. Bisher standen dazu in unserer Debatte zwei Realisierungen zur Auswahl: a) Erfassung über (wiederbenutzte) Flächengrenzen b) Erfassung über Sammelrelation aller Teilflächen der Siedlungsfläche. b) hat klare Nachteile gegenüber a), siehe Datenhaltungsmail. Das ist alles nur Wiederholung, siehe frühere mails.. /Zweitens/, kannst Du aus einem Netz MICROgemappter Flächen _nicht_ oder nur mit sehr hohem Aufwand (sprich komplexe, regelbasierte Algorithmen) sinnvoll auf ein Netz grobgranularer Flächen schließen. So kompliziert ist das nicht. Du lehnst Dich hier viel zu weit aus dem Fenster. /Wie/ kompliziert das werden kann, überblickst Du gar nicht. Ich überblicke das auch nicht, behaupte aber auch nicht, dass ich das könnte. Der immense Vorteil ist aber dabei, dass alle Informationen vorliegen und ich selbst entscheide, was für mich unwesentlich ist, und was nicht. Ich lese nur /ich/ in deinen Sätzen. So funktioniert OSM nicht. Um /als Datennutzer/ entscheiden zu können, was für mich wesentlich ist, muss ich aus einem Angebot /wählen/ können. /Du/ bist hier gerade derjenige der einem dieses Angebot vorschreiben will, weil /Du/ der Meinung bist, dass ein Salat aus MICROgemappten Flächen ausreiche, um sich alle erdenklichen gröberen Fälle auszurechnen. Umgekehrt muss ich /als Mapper/ /wählen/ können, auf welcher Ebene ich Informationen zum Projekt hinzufüge. Nicht jeder hat die Muse, deinen Vorstellungen von Größen, die nicht weiter teilbar sind, nachzukommen. Solche Leute dürfen dann keine Flächennutzung mehr erfassen, oder wie? Und der nächste MICROmapper, der kommt, und das Gebiet der Forstwirtschaft dann parzelliert zerstört die Arbeit des MACROmappers - weil eben das Gebiet der Forstwirtschaft _nicht_ notwendigerweise, wie Du schreibst, aus Mini-Parzellen zusammensetzbar ist. Ich bin der Meinung, dass Du immer noch nicht durchdacht hast, welche wirklichen Konsequenzen deine Streichung von überwiegend aus der Definition zur Flächennutzung hat. Nochmal, wenn Du die reine statt überwiegende Flächennutzung erfasst, heißt das für Dich und alle, die Du damit begeistern willst: a) Erfassung aller erdenklichen Flächennutzungen einer Fläche b) Unterteilung der vorhandenen Fläche in kleinste Einheiten, die eine __eindeutige__ Erfassung der Flächennutzung ermöglichen Ich bitte Dich nochmals, mitzudenken: Eine Fläche beliebiger Größe kann _immer_ nochmal geteilt werden, um die Flächennutzung genauer zu erfassen: Selbst für einen Acker funktioniert das: linienschmale Flächen werden z.B. als Furche des Ackers genutzt. Bist Du allen Ernstes der Aufassung, dass aus diesen kleinsten, MICROgemappten landuses, sich _jeder_ diese gröberen Gebiete aus einem komplexen Regelset zusammenbauen will? Die Regel für den Acker wäre dann: Gruppiere alle Furchen, um das Gebiet des Ackers zu erhalten. (Total einfach! Da braucht man doch die überweigende Nutzung der Gesamtfläche als Acker gar nicht erfassen..) Ganze Softwareprojekte würden sich dann damit beschäftigen, Regelwerke zu pflegen, weil /Du/ der Auffassung warst, dass die Gruppierung feingranularer Strukturen in gröbere ja ein Kinderspiel sei (es aber schon für die Berechnung der Siedlungsflächengrenze verneinst!). Es geht nämlich nicht nur um die Flächengröße sondern auch um die Art der Nutzung. Eine kleine
Re: [Talk-de] landuse=road War:[viel Text zu landuse-handling..]
Hi, Am 16.09.2011 08:51, schrieb Georg Feddern: .. dann mappen wir zwar nicht für Renderer, aber der Renderer wird zur eigenen DB mit Regeln, die eine eigene (weniger komplexe) Realität aus der abbilden, die in OSM ist. tolles Ding.. ein sehr schönes Beispiel! Das zeigt nämlich genau das (Dein) Verständnisproblem. Du vermischst immer noch Gebiete (Örtlichkeiten) mit der reinen Angabe der Nutzung der Fläche. Es gibt __keine reine Angabe__ für die Nutzung der Fläche. Lies bitte die mails der vergangen Tage, dann steigst Du dahinter.. Zusammenfassung für Dich: - es gibt nicht DIE Granularität bei der Flächenerfassung - Mapper erfassen Flächennutzungen in unterschiedlichen Größenordnungen - was für den Mapper flächennutzungstechnisch interessant ist, ist für den anderen völlig irrelevant - dennoch gibt es einen Bezug zwischen allen Größenordnungen: die Flächengrenzen An der Definition von überwiegend führt kein Weg vorbei, ansonsten lässt sich die Bodennutzung einer Fläche durch den Menschen gar nicht angeben, da eine Fläche i.d.R. von _vielen_ Menschen für _viele_ unterschiedliche Zwecke benutzt wird. Nur ist es eben oft so, dass eine oder wenige Nutzungen davon gegenüber den anderen überwiegen. Wir erfassen nur die überwiegende Nutzung und nicht _alle_ Nutzungen. __Alle__ Nutzungen wären gar nicht erfassbar, da die gar nicht ermittelbar sind - was weißt Du denn, wie ein bestimmter Mensch XYZ die Fläche nutzt? Weiter haben wir festgestellt, dass es keine Größenordnung gibt, die einem Mapper bei der Erfassung der überwiegenden, realen Bodennutzung vorgeschrieben werden kann. Wir können nicht sagen, die überwiegende Bodennutzung wird für Flächen der Größen 2-20ha erfasst. Das ist Unsinn. Wir haben daher festgehalten, dass jeder Mapper die überwiegende Bodennutzung auf der Größe erfasst, die /ihm/ sinnvoll erscheint. Das können 20qm oder auch 2000ha sein. Weiterhin haben wir festgehalten, dass manche Datennutzer sich für Größenordnungen von 20qm, andere für 2000ha, wieder andere für 1qkm, etc. pp. interessieren. vgl.: - wenn ich mich für die Elbe-Radroute interessiere, möchte ich die Wege aus der Gesamtmenge _aller_ Wege erhalten, die zur Elbe-Radroute gehören - wenn ich mich für die überwiegende Bodennutzung eines Forstgebietes interessiere, möchte ich die Flächen aus der Gesamtmenge _aller_ Flächen erhalten, die zum Forstgebiet gehören - interessieren mich nur die Flächen des Forstgebiets, die größer 1qkm sind, möchte ich alle Flächen, die kleiner gleich 1qkm sind, zusätzlich aus dieser Ergebnismenge entfernen - das muss aber nicht zwangsläufig heißen, dass sich die Gesamtfläche des Ergebnisses verkleinert!! Bodennutzungsflächen können, je nachdem welchen Maßstab ein Betrachter anlegt, überlappen. Wenn mich nur die überwiegende Bodennutzung eines Waldgebietes interessiert, dann gibt es für die Behandlung von Bodennutzungsflächen, die wesentlich kleiner sind und innerhalb der Waldgebietsfläche liegen, exakt zwei Möglichkeiten: 1) sie werden vollständig vernachlässigt (ich tue so, als ob sie überhaupt nicht erfasst wurden) - Konsequenzen: Es existiert ein Waldgebiet. Das Waldgebiet wird _überwiegend_ für die Forstwirtschaft benutzt. Innenliegende Häuser und Wege ändern die Flächengröße des Waldgebietes nicht, sie sind ein Teil des Waldes. Daher ändert sich die Flächengröße auch dann nicht, wenn ich von einer überwiegenden Bodennutzung des Waldes durch die Forstwirtschaft spreche. Die Bodennutzung der kleineren Flächen der Häuser interessiert deshalb nicht, weil der Maßstab, der für die Erfassung der Bodennutzung angelegt wurde, diese nicht berücksichtigt. Wenn ich von der Forstwirtschaft in Wald X spreche, ist jedem Holzfäller klar, dass er Bäume in Wald X fällen soll und nicht die Häuser, die evtl. auch Teil des Waldes sind, _ohne_ dass ich explizit erkläre: Forstwirtschaft in Wald X, aber nicht Hauswirtschaft auf Lichtung Y. 2) sie werden insofern vernachlässigt, dass ihre Fläche von der Ergebnisfläche abgezogen wird (ich verringere die Waldgebietsfläche um alle Nutzungsflächen, die nicht der überwiegenden Nutzung der Gesamtfläche entsprechen) - Konsequenzen: Es existiert ein Waldgebiet. Das Waldgebiet wird _rein_ für die Forstwirtschaft benutzt. Es gibt _keine_ innenliegenden Häuser und Wege innerhalb eines __rein__ für die Forstwirtschaft genutzten Waldgebietes, weil (Wohn)Häuser und Wege innerhalb des Waldgebietes _nicht rein forstwirtschaftlich_ genutzt werden und damit _nicht_ Teil des Waldgebietes, das für Forstwirtschaft genutzt wird, sind. Die Bodennutzung der kleineren Flächen interessiert auf _jedem_ Maßstab, insofern, als dass ihre Fläche von der gröberen abegzogen wird. Setzt sich 2) für OSM durch, bedeutet das seehr viel Streit, denn /wer/ befindet über die Reinheit der Bodennutzung. Es fängt doch
Re: [Talk-de] landuse=road War:[viel Text zu landuse-handling..]
Am 16.09.2011 11:16, schrieb Martin Koppenhoefer: Am 16. September 2011 08:51 schrieb Georg Fedderno...@bavarianmallet.de: Christian Müller schrieb: Erinnere Dich an deine Argumente dazu, dass sich gröbere Gebiet der Siedlungsstelle nicht aus den Einzelflächen 'automatisch' errechnen zu lassen - vielleicht hilft Dir das dabei, zu verstehen, dass die überwiegende Zahl von Gruppierungen, die gröbere Gebiete bilden, nicht automatisch errechenbar sind. Du täuschst Dich hier. Siedlungsstellen lassen sich nicht automatisch errechnen, weil die Informationen dazu fehlen. Bei den landuses - so man sie alle erfasst hat - sind die benötigten Informationen hingegen vorhanden. Daher geht es da. -1 Das ist, sorry, absoluter Unfug. /Erstens/ sind die benötigten Informationen für die Siedlungsstellen existent, wenn landuses komplett erfasst sind. Letzteres unterstellst Du für: /Zweitens/, kannst Du aus einem Netz MICROgemappter Flächen _nicht_ oder nur mit sehr hohem Aufwand (sprich komplexe, regelbasierte Algorithmen) sinnvoll auf ein Netz grobgranularer Flächen schließen. Zwischen /erstens/ und /zweitens/ gibt es einen direkten Bezug. Solange Du den nicht siehst, brauchst Du mit mir eigentlich nicht weiter zu diskutieren, denn unsere Debatte ist lang genug, dass Du ihn sehen müsstest. Außerdem wären, selbst wenn ein komplexes Regelset in Renderregeln gröbere Gebiete aus MICROgemappten automatisch bildet, die Datenbeziehungen nicht in OSM (wo sie hingehören, da auch die Datenbeziehungen Teil der Realität sind), in einer Geodatenbank wie der unseren sind die Beziehungen immanent. -1 Das ist eine pauschale Aussage, mit der man nichts falsch machen kann, weil sie so allgemeingültig ist, wie irgendeine Tautologie. Uns geht es aber darum, dass möglichst _nur_ gerade _die_ Beziehungen in der DB sind, welche die Realität abbilden. Außerdem sollten möglichst _wenige_ Bezüge zwischen Daten der DB außerhalb der DB existieren und gepflegt werden. Besonders dann nicht, wenn /diese/ Bezüge nur Bezüge zwischen Objekten der Realität abbilden. Natürlich kann ich nur politische Gemeindegrenzen innerhalb der DB pflegen und dann extern die Bundesgrenze ausrechnen. Das machen wir aber eben nicht, weil die Vorteile einer expliziten Erfassung innerhalb der DB (mit Bezügen der Grenzen untereinander) klar überwiegen! Betrachte bitte die Relationen in OSM. Beziehungen zwischen den Daten sind nicht immanent und einfach so da! Sie werden definiert. Der Bezug zwischen Elbe-Radroute und ihren Teilwegen ist erst dann der DB immanent, wenn eine Relation innerhalb der DB (händisch!) erfasst wurde, welche die Beziehung definiert! So verhält es sich auch mit Flächen. Bezüge, die nicht definiert werden, sind nicht immanent! .. dann mappen wir zwar nicht für Renderer, aber der Renderer wird zur eigenen DB mit Regeln, die eine eigene (weniger komplexe) Realität aus der abbilden, die in OSM ist. tolles Ding.. Ob diese Realität dann weniger komplex ist oder nicht, lasse ich mal dahingestellt. Aber dass der Renderer eine DB mit eigenen Regeln ist, das ist bereits so. Zumindest bei mapnik. Du verstehst micht auch echt überall falsch, wo man mich falsch verstehen kann ;-) Natürlich wird der Renderer eine DB mit //Render//-Regeln bleiben. Was aber nicht passieren darf (!), ist, dass sich unter den Render-Regeln, Regeln befinden, wie Daten der Realität gruppiert werden, die schon in der Realität gruppiert werden. Am Beispiel Elbe-Radroute passiert dann nämlich folgendes: - ein Renderer gruppiert sich die Elbe-Radroute aus den Wegen der DB auf die eine Art - der nächste auf eine leicht andere Art richtig im Sinne der Frage, ob die entstehende Gruppierung eine Abbildung der Realität ist, kann aber nur die Gruppierung des Renderers sein, mittels derer auch in der Realität die Route aus ihren Teilwegen gebildet wird. ein sehr schönes Beispiel! Das zeigt nämlich genau das (Dein) Verständnisproblem. Du vermischst immer noch Gebiete (Örtlichkeiten) mit der reinen Angabe der Nutzung der Fläche. +1 zu Georg. Those who don't understand UNIX are condemned to reinvent it.. Viel Spaß beim Wiederentdecken der Gedanken, die andere und ich bereits hatten und haben.. Ich habe von Anfang getrennt - zwischen Flächen und Gebieten, zwischen politischer und wirtschaftlicher Nutzung von Flächen und Gebieten, zwischen reiner und überwiegender Nutzung, zwischen Nutzung von Micro- und Makroflächen. Und zuletzt zwischen Fläche und Flächengrenze. Ich habe _strikt_ getrennt, um dann _sinnvoll_ zu strukturieren, sprich in Beziehung setzen zu können. Zu behaupten, ich würde das vermischen, was ihr noch nicht auseinandergehalten habt, zeigt mir, dass ich trotz aller Bemühungen nicht verstanden wurde. Gruß ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] landuse=road War:[viel Text zu landuse-handling..]
Am 19. September 2011 19:34 schrieb Christian Müller cmu...@gmx.de: Am 16.09.2011 11:16, schrieb Martin Koppenhoefer: Du täuschst Dich hier. Siedlungsstellen lassen sich nicht automatisch errechnen, weil die Informationen dazu fehlen. Bei den landuses - so man sie alle erfasst hat - sind die benötigten Informationen hingegen vorhanden. Daher geht es da. -1 Das ist, sorry, absoluter Unfug. /Erstens/ sind die benötigten Informationen für die Siedlungsstellen existent, wenn landuses komplett erfasst sind. Du willst es nicht verstehen. Es ist nicht klar, zu _welcher_ menschlichen Siedlung sie gehören. Das ist das Problem, nicht, ob sie besiedelt sind. /Zweitens/, kannst Du aus einem Netz MICROgemappter Flächen _nicht_ oder nur mit sehr hohem Aufwand (sprich komplexe, regelbasierte Algorithmen) sinnvoll auf ein Netz grobgranularer Flächen schließen. So kompliziert ist das nicht. Der immense Vorteil ist aber dabei, dass alle Informationen vorliegen und ich selbst entscheide, was für mich unwesentlich ist, und was nicht. Es geht nämlich nicht nur um die Flächengröße sondern auch um die Art der Nutzung. Eine kleine aber extreme Nutzung ist für bestimmte Fragestellungen interessant. Wenn man alles vermanscht, fehlen die Infos nachher. in einer Geodatenbank wie der unseren sind die Beziehungen immanent. -1 Das ist eine pauschale Aussage, mit der man nichts falsch machen kann, weil sie so allgemeingültig ist, wie irgendeine Tautologie. Uns geht es aber darum, dass möglichst _nur_ gerade _die_ Beziehungen in der DB sind, welche die Realität abbilden. gerade dann ist die Lage doch ideal, realer geht es nicht. Natürlich kann ich nur politische Gemeindegrenzen innerhalb der DB pflegen und dann extern die Bundesgrenze ausrechnen. Das machen wir aber eben nicht, weil die Vorteile einer expliziten Erfassung innerhalb der DB (mit Bezügen der Grenzen untereinander) klar überwiegen! +1 daher sind Siedlungen auch besser nicht die Summe verschiedener Landuses sondern ein extra Polygon. Betrachte bitte die Relationen in OSM. Beziehungen zwischen den Daten sind nicht immanent und einfach so da! doch, die Lage ist einfach so da, genauso wie die Größe einer Fläche, oder was innerhalb und ausserhalb einer Fläche liegt, bzw. welche Flächen sich schneiden. Da musst Du z.B. nicht noch die Flächengröße dazuschreiben, auch wenn manche das trotzdem machen. Du verstehst micht auch echt überall falsch, wo man mich falsch verstehen kann ;-) Natürlich wird der Renderer eine DB mit //Render//-Regeln bleiben. Was aber nicht passieren darf (!), ist, dass sich unter den Render-Regeln, Regeln befinden, wie Daten der Realität gruppiert werden, die schon in der Realität gruppiert werden. Die Renderregeln leisten das: Daten selektieren und ggf. gruppieren. Am Beispiel Elbe-Radroute passiert dann nämlich folgendes: - ein Renderer gruppiert sich die Elbe-Radroute aus den Wegen der DB auf die eine Art - der nächste auf eine leicht andere Art sorry, aber irgendwo haben Vergleiche auch ein Ende, und ein linearer Radweg ist schlecht mit dem Problem hier vergleichbar. richtig im Sinne der Frage, ob die entstehende Gruppierung eine Abbildung der Realität ist, kann aber nur die Gruppierung des Renderers sein, mittels derer auch in der Realität die Route aus ihren Teilwegen gebildet wird. wie Frederik schon treffend sagte: um richtig und falsch geht es nicht, in jedem Fall machen wir hier ein Modell der Welt, das man nicht mit der Welt verwechseln sollte. M.E. geht es in der Diskussion hier darum, herauszufinden, wie unser Modell am besten abbilden sollte, dass: - es Verwaltungseinheiten und dazugehörige Verwaltungsgrenzen gibt, - es davon unabhängig Siedlungen und Teile davon gibt, - dass jedes Stück Land irgendwie genutzt wird, oder eben nicht weiterhin wären noch jede Menge andere Betrachtungsweisen denkbar (aber nicht alle sinnvoll in OSM aufgehoben), z.B. die Bodenbedeckung, die Vegetation, der Feuchtigkeitsgehalt des Bodens, das Klima, der geologische Untergrund, die Bebauungstypologie, die Einwohnerdichte ... Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] landuse=road War:[viel Text zu landuse-handling..]
Christian Müller schrieb: Am 15.09.2011 03:43, schrieb Martin Koppenhoefer: .. Daten das hergeben - auch als Renderer herausfinden, dass ein bestimmtes Gebiet eine bestimmte Nutzungsmischung hat, und das grafisch in die Karte einarbeiten. Z.B. könnte man größere, gröbere Gebiete automatisch aus feiner und differenzierter aufgelösten Gebieten berechnen und sich dabei je nach Karte, die man erstellt, entscheiden, welche Nutzungen man nicht differenzieren will, und welche einem, wenn sie auch klein sein mögen, dennoch wichtig genug sind, sie einzeln zu zeichnen. Erinnere Dich an deine Argumente dazu, dass sich gröbere Gebiet der Siedlungsstelle nicht aus den Einzelflächen 'automatisch' errechnen zu lassen - vielleicht hilft Dir das dabei, zu verstehen, dass die überwiegende Zahl von Gruppierungen, die gröbere Gebiete bilden, nicht automatisch errechenbar sind. Außerdem wären, selbst wenn ein komplexes Regelset in Renderregeln gröbere Gebiete aus MICROgemappten automatisch bildet, die Datenbeziehungen nicht in OSM (wo sie hingehören, da auch die Datenbeziehungen Teil der Realität sind), sondern -off-site- in den Algorithmen des Renderers. Das wäre in etwa so, die Route-Relationen von Radnetzwerken nicht in OSM aufzunehmen, weil der Renderer weiß, welche Wege er gruppieren muss, um z.B. die Elbe-Radroute zu rendern. .. dann mappen wir zwar nicht für Renderer, aber der Renderer wird zur eigenen DB mit Regeln, die eine eigene (weniger komplexe) Realität aus der abbilden, die in OSM ist. tolles Ding.. ein sehr schönes Beispiel! Das zeigt nämlich genau das (Dein) Verständnisproblem. Du vermischst immer noch Gebiete (Örtlichkeiten) mit der reinen Angabe der Nutzung der Fläche. Die einzelnen Wege entsprechen den landuse-Flächen, die Route entspricht dem Gebiet. Man erfasst auch nicht _nur_ die Elbe-Radroute an einem Stück in den Daten, weil die einzelnen Wege sonst zum Rauschen werden! Sondern man erfasst die einzelnen Wege nach ihren Eigenschaften. Und dann erfasst man das Gebiet / die Route _getrennt_! Alle Flächen gleicher Nutzung lassen sich aber problemlos automatisch zu einer Fläche /Multipolygon gleicher Nutzung zusammenfassen, wenn man es braucht, weil man sie entsprechend grafisch darstellen will. Ebenso lassen sich Flächen unterschiedlicher Nutzung programmtechnisch zusammenfassen und einheitlich darstellen (= kein Rauschen). Nur darum ging es in dem Argumenten. Die spezielle Gebietsinformation (Dies ist das Wohngebiet mit dem Namen Soundso) natürlich nicht - die muss getrennt erfasst werden, wie eine Route! Gruß Georg ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] landuse=road War:[viel Text zu landuse-handling..]
Am 16. September 2011 08:51 schrieb Georg Feddern o...@bavarianmallet.de: Christian Müller schrieb: Erinnere Dich an deine Argumente dazu, dass sich gröbere Gebiet der Siedlungsstelle nicht aus den Einzelflächen 'automatisch' errechnen zu lassen - vielleicht hilft Dir das dabei, zu verstehen, dass die überwiegende Zahl von Gruppierungen, die gröbere Gebiete bilden, nicht automatisch errechenbar sind. Du täuschst Dich hier. Siedlungsstellen lassen sich nicht automatisch errechnen, weil die Informationen dazu fehlen. Bei den landuses - so man sie alle erfasst hat - sind die benötigten Informationen hingegen vorhanden. Daher geht es da. Außerdem wären, selbst wenn ein komplexes Regelset in Renderregeln gröbere Gebiete aus MICROgemappten automatisch bildet, die Datenbeziehungen nicht in OSM (wo sie hingehören, da auch die Datenbeziehungen Teil der Realität sind), in einer Geodatenbank wie der unseren sind die Beziehungen immanent. .. dann mappen wir zwar nicht für Renderer, aber der Renderer wird zur eigenen DB mit Regeln, die eine eigene (weniger komplexe) Realität aus der abbilden, die in OSM ist. tolles Ding.. Ob diese Realität dann weniger komplex ist oder nicht, lasse ich mal dahingestellt. Aber dass der Renderer eine DB mit eigenen Regeln ist, das ist bereits so. Zumindest bei mapnik. ein sehr schönes Beispiel! Das zeigt nämlich genau das (Dein) Verständnisproblem. Du vermischst immer noch Gebiete (Örtlichkeiten) mit der reinen Angabe der Nutzung der Fläche. +1 zu Georg. Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] landuse=road War:[viel Text zu landuse-handling..]
Georg Feddern schrieb: Alle Flächen gleicher Nutzung lassen sich aber problemlos automatisch zu einer Fläche /Multipolygon gleicher Nutzung zusammenfassen, wenn man es braucht, weil man sie entsprechend grafisch darstellen will. Ebenso lassen sich Flächen unterschiedlicher Nutzung programmtechnisch zusammenfassen und einheitlich darstellen (= kein Rauschen). Nur darum ging es in dem Argumenten. Die spezielle Gebietsinformation (Dies ist das Wohngebiet mit dem Namen Soundso) natürlich nicht - die muss getrennt erfasst werden, wie eine Route! PS zur Sicherheit: Unter Umständen kann(!) ein Gebiet (z. B. Wohngebiet) als eine(!) landuse-Fläche erfasst werden, dann kann(!) die Information auch am gleichen Objekt erfasst werden. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] landuse=road War:[viel Text zu landuse-handling..]
Am 15.09.2011 03:43, schrieb Martin Koppenhoefer: .. Daten das hergeben - auch als Renderer herausfinden, dass ein bestimmtes Gebiet eine bestimmte Nutzungsmischung hat, und das grafisch in die Karte einarbeiten. Z.B. könnte man größere, gröbere Gebiete automatisch aus feiner und differenzierter aufgelösten Gebieten berechnen und sich dabei je nach Karte, die man erstellt, entscheiden, welche Nutzungen man nicht differenzieren will, und welche einem, wenn sie auch klein sein mögen, dennoch wichtig genug sind, sie einzeln zu zeichnen. Ich habe mich dazu zur genüge ausgelassen.. Erinnere Dich an deine Argumente dazu, dass sich gröbere Gebiet der Siedlungsstelle nicht aus den Einzelflächen 'automatisch' errechnen zu lassen - vielleicht hilft Dir das dabei, zu verstehen, dass die überwiegende Zahl von Gruppierungen, die gröbere Gebiete bilden, nicht automatisch errechenbar sind. Außerdem wären, selbst wenn ein komplexes Regelset in Renderregeln gröbere Gebiete aus MICROgemappten automatisch bildet, die Datenbeziehungen nicht in OSM (wo sie hingehören, da auch die Datenbeziehungen Teil der Realität sind), sondern -off-site- in den Algorithmen des Renderers. Das wäre in etwa so, die Route-Relationen von Radnetzwerken nicht in OSM aufzunehmen, weil der Renderer weiß, welche Wege er gruppieren muss, um z.B. die Elbe-Radroute zu rendern. .. dann mappen wir zwar nicht für Renderer, aber der Renderer wird zur eigenen DB mit Regeln, die eine eigene (weniger komplexe) Realität aus der abbilden, die in OSM ist. tolles Ding.. Gruß ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] landuse=road War:[viel Text zu landuse-handling..]
Am 15.09.2011 03:34, schrieb Martin Koppenhoefer: Am 15. September 2011 01:34 schrieb Christian Müllercmu...@gmx.de: Am 14.09.2011 15:17, schrieb Garry: Wenn Dir die Häuser im Wald wichtig sind, kannst Du auch /nur/ diese mit in die Karte aufnehmen. Bessere Lösungen für deinen Anwendungsfall (Datenreduktion ohne Detailverlust im Wald) sind: wieso sollte das kein Detailverlust sein? !? wie meinen? Du meinst, wieso die Lösungen, die ich vorgeschlagen habe, die hier aber nicht zitiert sind, keinen Detailverlust darstellen? Das Anliegen von Garry war, sekludierte Häuser im Wald nicht zu verlieren, wenn er /alle/ Häuser aus den Daten entfernt, bevor er eine Karte für sein Garmin erstellt. Bisher verliert er die, deshalb zeichnet er für die zwei Häuser, unabhängig von unserer Diskussion über die Relevanz, einen landuse=* ein. Das braucht er aber /z.B./ nicht, wenn er alle buildings=* wegfiltert, die innerhalb landuse=residential oder landuse=commercial liegen, weil dann die buildings (und damit das Detail) innerhalb landuse=forestry in seinen Daten erhalten bleiben. /Deshalb/ ist /für sein Problem/, die Frage, ob für die Häuser im Wald ein landuse=* erfasst werden sollte, nicht relevant. Ihm ging es nicht um den landuse=*, sondern darum das Detail der Häuser nicht zu verlieren. Das ist die gleiche Diskussion, die wir schon mit dem Bäcker hatten. Nein, ist es nicht. Zwei Wohnhäuser im Wald entsprechen nicht einem Bäcker im Wohngebiet. Aber zwei Bäckern im Wohngebiet. Das wird kindisch.. Gruß ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] landuse=road War:[viel Text zu landuse-handling..]
Am 15. September 2011 18:28 schrieb Christian Müller cmu...@gmx.de: Das ist die gleiche Diskussion, die wir schon mit dem Bäcker hatten. Nein, ist es nicht. Zwei Wohnhäuser im Wald entsprechen nicht einem Bäcker im Wohngebiet. Aber zwei Bäckern im Wohngebiet. Das wird kindisch.. Das hatte ich nicht gemeint. Vergleichbar würde es vielleicht eher, wenn dort der Förster wohnt oder der Holzfäller. Aber selbst dann würde die Info, dass dort jemand wohnt, wichtig finden. M.E. ist nicht ein landuse so wichtig wie der andere, sondern man muss als mapper abwägen. Ein Bäcker ist z.B. auch nach deutschem Recht im Wohngebiet möglich, eine Wohnnutzung im Wald normalerweise nicht. Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] landuse=road War:[viel Text zu landuse-handling..]
Am 15.09.2011 19:18, schrieb Martin Koppenhoefer: Am 15. September 2011 18:28 schrieb Christian Müllercmu...@gmx.de: Das ist die gleiche Diskussion, die wir schon mit dem Bäcker hatten. Nein, ist es nicht. Zwei Wohnhäuser im Wald entsprechen nicht einem Bäcker im Wohngebiet. Aber zwei Bäckern im Wohngebiet. Das wird kindisch.. Das hatte ich nicht gemeint. Vergleichbar würde es vielleicht eher, wenn dort der Förster wohnt oder der Holzfäller. Aber selbst dann würde die Info, dass dort jemand wohnt, wichtig finden. M.E. ist nicht ein landuse so wichtig wie der andere, sondern man muss als mapper abwägen. Eben, sag ich ja. Zwei Bäcker im Wohngebiet oder Zwei Häuser im Wald interessieren /mich/ überhaupt nicht, wenn ich wissen will, wofür ein Gebiet genutzt wird. /Dich/ hingegen schon. == Flächennetzwerk Das ist eine Lösung in der das koexistieren können. Denn zusammenfinden lässt sich da nichts: /Mich/ interessieren Granularitäten von zwei/drei Häusern nunmal nicht. Mit einem Flächennetzwerk könntest Du dein Ding machen, während andere ihr Ding machen, ohne dass es hier ständig zu m.E. und ich sehe das so, etc. pp. kommen muss. Evtl. unterhält man sich dann endlich mal über progessivere Sachen.. Gruß ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] landuse=road War:[viel Text zu landuse-handling..]
Moin, Christian Müller schrieb: Am 13.09.2011 17:14, schrieb Martin Koppenhoefer: ich würde das Gebiet zweier dauerhaft bewohnter Häuser im Wald als landuse=residential kennzeichnen. In Deutschland kommt so was aufgrund des Verbots, im Aussenbereich zu bauen, allerdings extrem selten vor. welchen Sinn soll das haben? so kommen wir nicht weiter.. Seit wann muss ein Hobby einen Sinn haben? ;-) Die Granularität von landuse=* ist in OSM einfach nicht die von building=* und wenn sie das wäre, wäre landuse=* für die meisten Datennutzer useless=* Ich glaube kaum, dass Martin ein landuse-Polygon in den Grenzen des buildings 'malt'. Und auf dem Wohn-Grundstück finden sich evtl. Bäume - aber da haben die Forstarbeiter bestimmt keinen Zugriff drauf! Das Liegenschaftsamt sieht das anders: die mappen sogar Teilflächen wenn sie unterschiedliche Nutzungen haben auch getrennt. Ich würde das weder fordern noch pauschal ausschließen wollen. Ja, können sie ja machen - haben wir die Ressourcen? Macht das in OSM Sinn? Ich denke nicht, wir sollten bei dem 'vorrangig' in der Definition zur Bodennutzung bleiben. Schon wieder diese Sinn-Frage ... 'Wir' haben auch kaum übergreifend im ländlichen Raum die Resourcen, überhaupt landuses zu erfassen - sollen 'wir' das deshalb von vornherein lassen? Äußerst vorrangig besteht die Erdoberfläche aus Wasser - das spart unheimlich Resourcen! Noch(!) besteht Deutschland 'vorrangig' aus Landwirtschaftsfläche ... In meinem Dorf überwiegt eindeutig die residential-Nutzung - muss ich deshalb die trotzdem das Gesamterscheinungsbild prägenden Vollerwerbsbauernhöfe unterschlagen? Auf dem Grundstück im Wald steht definitiv kein 'forrest' - aber ich darf diese Besonderheit der Einzel-Streu-Besiedelung einer Gegend nicht erfassen, weil es jemandem nicht genehm ist? Ich bin hier die Resource vor Ort - und da nehme ich mir das Recht heraus, zu entscheiden, wofür ich diese Resource verschwende! ;-) Und ja, es macht Sinn für mich, wenn ich auf meiner kleinen großformatigen Karte das private Grundstück vom öffentlich zugänglichen Wald unterscheiden möchte. Ich denke nicht, dass diese Granularitätsebene, auf der die Ämter mappen für eine OSM-Definition von landuse=* geeignet ist. Natürlich gibt's kein Verbot, diese Granularität in OSM zu benutzen, aber uns geht es hier um eine brauchbare Wiki-Definition, die würde ich nicht strikt gestalten. 'vorrangige', reale Flächennutzung Das ist durchaus eine sinnvolle, nicht-strikte Definition. Aber warum erwartest Du dann, das man sich _strikt_ an eine nicht näher angegebene Größenordnung hält? Wo muss man diese Größenordnung ziehen? Du musst auch mal überlegen, welche Konsquenzen das hätte: landuse=* würde evtl. nur noch auf dem letzten Zoomlevel renderbar sein, auf allen anderen gibt's ein verrauschtes noise bitmap. Nein, dass wären 'falsche' Renderregeln. Die Granularität bestimmt die Breite der definierten landuses. (Leider wird/wurde bei OSM oft zu schnell in die Breite gegangen, statt zu staffeln. :-( ) Erstens endet die landuse-Granularität z. Z. spätestens an der Grundstücksgrenze - den so sinnlosen landuse=grass mal außen vorgelassen - und gleiche Nutzungen nebeneinander ergeben eine gemeinsame Fläche, im Zweifelsfall den von Martin angesprochenen Block (zwischen Verkehrswegen) - den man ja nicht auf Krampf unterteilen muss. Aber setzt sich der landuse=road durch, ist dort dann sowieso Schluss, falls sich der Schwebe-Ansatz nicht durchsetzt. Und zweitens werden ab einem gewissen Zoomlevel landuses rendermäßig zusammengefasst (landwirtschaftlich, bebaut/besiedelt) sowie kleine Flächen weggelassen. Und wenn dort kein Pixel für den Verkehrsweg mehr bleibt (= weggelassen) ergibt sich auch dort grafisch eine durchgehende Fläche. Wenn die Flächennutzung auf der Granularitätsebene von Baufenstern (oder nahe diesen) arbeitet, hätten wir zum Schluss 25*Anzahl der building Polygone an Daten in der Stadt (für jedes Gebäude finde ich unter Garantie 25 verschiedene Bodennutzungsarten ringsum). Hier hätte ich gerne Belege für (diese Übertreibung) ... Das ist für landuse=*, useless=*.. Allerdings - aber in meinen Augen eben auch nicht zwangsläufig zu befürchten. Insbesondere nicht, wenn man sinnvoll staffeln würde, statt weiter nur (oft unüberlegt) in die Breite zu gehen. Wenn landuse=* auf Dauer nicht über Flächengrenzen mittels multipolygon gemappt wird, womit sich 'genaue' und 'vorranige' Flächennutzungsgebiete vereinen ließen, sollte man ein anderes Tag aufmachen, um landuse micromapping zu betreiben.. Denn landuse micromapping erhöht Eintrittsbarrieren, anstatt sie zu senken. Sehe ich - mittlerweile - anders. Multipolygone oder riesige Flächen schrecken da eher ab, nach meiner bisherigen Erfahrung. diese Einheiten macht (bis zu Flächen, die keine Straßen mehr beinhalten, einzelne Blumenbeete meine ich damit nicht), um so einfacher wird es für die folgenden
Re: [Talk-de] landuse=road War:[viel Text zu landuse-handling..]
Am 14.09.2011 03:14, schrieb Christian Müller: Am 13.09.2011 17:14, schrieb Martin Koppenhoefer: ich würde das Gebiet zweier dauerhaft bewohnter Häuser im Wald als landuse=residential kennzeichnen. In Deutschland kommt so was aufgrund des Verbots, im Aussenbereich zu bauen, allerdings extrem selten vor. welchen Sinn soll das haben? so kommen wir nicht weiter.. Es ist ein Alleinstellungsmerkmal und erhöht die Auffindbarkeit solcher Besonderheiten. Wenn Du z.B, eine OSM-Garminkarte verwendest in der aus Platzgründen keine Häuser dargestellt werden siehst Du an der Stelle des Hauses nur Wald, ohne eigenem landuse ist so ein Haus dann auf der Karte unauffindbar. Und nein, ich sehe dass nicht als Mappen für den Renderer an sondern ein Mappen der Realität zur besseren Nutzubarkeit der Daten. Die Granularität von landuse=* ist in OSM einfach nicht die von building=* und wenn sie das wäre, wäre landuse=* für die meisten Datennutzer useless=* Ich versteh Martin mit das Gebiet zweier dauerhaft bewohnter Häuserso dass er die Summe der beiden Grundstücke als eine landuse=residential Fläche mappen und nicht die Gebäude selbst als einzelne landuse-Flächen mappen will. Das Liegenschaftsamt sieht das anders: die mappen sogar Teilflächen wenn sie unterschiedliche Nutzungen haben auch getrennt. Ich würde das weder fordern noch pauschal ausschließen wollen. Ja, können sie ja machen - haben wir die Ressourcen? Macht das in OSM Sinn? In Bezug auf Einzelhäuser im Wald ist das nicht wirklich ein Argument Ich denke nicht, wir sollten bei dem 'vorrangig' in der Definition zur Bodennutzung bleiben. Bei so einer gravierende Nutzungsänderung wie hier die kleine bewohnte Fläche in einem riesigen unbesiedelten Gebiet sollte man schon differenzieren... Beim Taggen von landuse=* über seine Grenzen, macht aber auch ein amtlicher Datenimport keine Probleme. Man legt das einfach über das, was in OSM da ist, taggt die ways des Imports als border=administrative source=official und erstellt Multipolygone mit type=multipolygon landuse=xyz official_key1=* official_key2=* official_key3=* source=official Ich denke nicht, dass diese Granularitätsebene, auf der die Ämter mappen für eine OSM-Definition von landuse=* geeignet ist. Natürlich gibt's kein Verbot, diese Granularität in OSM zu benutzen, aber uns geht es hier um eine brauchbare Wiki-Definition, die würde ich nicht strikt gestalten. 'vorrangige', reale Flächennutzung Du musst auch mal überlegen, welche Konsquenzen das hätte: landuse=* würde evtl. nur noch auf dem letzten Zoomlevel renderbar sein, auf allen anderen gibt's ein verrauschtes noise bitmap. Weiterhin hatte sich jemand über die Fülle der Daten in Frankreich durch den Import aufgeregt. Wenn die Flächennutzung auf der Granularitätsebene von Baufenstern (oder nahe diesen) arbeitet, hätten wir zum Schluss 25*Anzahl der building Polygone an Daten in der Stadt (für jedes Gebäude finde ich unter Garantie 25 verschiedene Bodennutzungsarten ringsum). Das ist für landuse=*, useless=*.. Wenn landuse=* auf Dauer nicht über Flächengrenzen mittels multipolygon gemappt wird, womit sich 'genaue' und 'vorranige' Flächennutzungsgebiete vereinen ließen, sollte man ein anderes Tag aufmachen, um landuse micromapping zu betreiben.. Denn landuse micromapping erhöht Eintrittsbarrieren, anstatt sie zu senken.. Je kleiner man diese Einheiten macht (bis zu Flächen, die keine Straßen mehr beinhalten, einzelne Blumenbeete meine ich damit nicht), um so einfacher wird es für die folgenden Mapper, dort weiterzuarbeiten. Irrglaube, denn Du hast dann statt Struktur, rohe Komplexität abgebildet. brute-force, statt elegance. Es gibt keinen Bezug deiner Mini-Flächen untereinander. Man sieht sprichwörtlich den Wald vor lauter Bäumen nicht mehr. Wenn deine Mini-Einheit was bringen soll, dann nur über die Multipolygon-Methode, mittels derer diese Mini-Flächen wieder zu groben, fassbaren Flächen gruppiert werden können, bis zu dem Punkt, wo man wieder von 'vorrangiger', realer Flächennutzung sprechen kann, was landuse=* jetzt ist. woher kommt eigentlich dieser Wunsch, die Realität in diesem Punkt nicht (in unserem Rahmen) möglichst genau abzubilden, sondern grobe unfragmentierte Gebiete haben zu wollen? Kann man das nicht durch Datenverarbeitung hinterher machen, wenn man gerne vereinfachte Geometrien haben will? Nein, aus dem gleichen Grund, aus dem Du die Erfassung der Siedlungsfläche (nach deiner Definition) explizit wünschst. Um es mal auf dein Beispiel mit der dt. Staatsgrenze zu übertragen: Die ist auch explizit erfasst, obwohl man sie aus der Summe aller nächsttieferen Grenzen berechnen kann. Und die nächsttieferen Grenzen wiederum aus den nächsttieferen.. ad absurdum Der Grund weshalb man das nicht berechnet, ist, neben dem Rechenaufwand, dass wir in OSM selbst die Information der Realität haben wollen,
Re: [Talk-de] landuse=road War:[viel Text zu landuse-handling..]
Am 14.09.2011 15:17, schrieb Garry: Es ist ein Alleinstellungsmerkmal und erhöht die Auffindbarkeit solcher Besonderheiten. Wenn Du z.B, eine OSM-Garminkarte verwendest in der aus Platzgründen keine Häuser dargestellt werden siehst Du an der Stelle des Hauses nur Wald, ohne eigenem landuse ist so ein Haus dann auf der Karte unauffindbar. Und nein, ich sehe dass nicht als Mappen für den Renderer an sondern ein Mappen der Realität zur besseren Nutzubarkeit der Daten. Ich verstehe dein Anliegen vollkommen, solche Problem habe ich in der Datenweiterverarbeitung auch, aber das ist die Datennutzbarkeit /eines/ Anwendungsfalls. Der nächste wird es genau anders brauchen.. Auch /deinem/ Anwendungsfall ist damit nicht geholfen, wenn dies das Ziel sein soll: - jedes Haus hat irgendein Alleinstellungsmerkmal - wenn auf dieser Grundlage landuse=* erfasst und fragmentiert wird, bringt die Filterung von building=* bald nichts mehr.. Wenn Dir die Häuser im Wald wichtig sind, kannst Du auch /nur/ diese mit in die Karte aufnehmen. Bessere Lösungen für deinen Anwendungsfall (Datenreduktion ohne Detailverlust im Wald) sind: - filtere nur building=* aus den Daten, die innerhalb landuse=residential liegen - tagge die building=* im Wald mit einem Alleinstellungs-tag (z.B. secluded=yes), dann danach filtern - place-node nutzen (wenn die Häuser im Wald durch ein Toponymeinen Namen? häufig schon..) Es gibt keinen echten Grund /dafür/ (für dieses Problem) feingranulare landuse=* zu erfassen. Da bieten andere Problemstellungen bessere Gründe, siehe unten.. Ich versteh Martin mit das Gebiet zweier dauerhaft bewohnter Häuserso dass er die Summe der beiden Grundstücke als eine landuse=residential Fläche mappen und nicht die Gebäude selbst als einzelne landuse-Flächen mappen will. Das ist die gleiche Diskussion, die wir schon mit dem Bäcker hatten. Rechtfertigen - ein/zwei einzelne Bäcker innerhalb einer Fläche, die überwiegend zum Wohnen genutzt wird - ein/zwei Häuser innerhalb einer Fläche, die überwiegend durch die Forstwirtschaft genutzt wird eine Extrafläche, oder nicht? === Ich denke wir sind uns alle einig, wenn wir sagen landuse=* erfasst die reale Flächennutzung vor Ort Worüber wir hier also noch diskutieren ist, ob vorrangig, überwiegend oder bedeutsam mit in diese Definition aufgenommen werden sollte oder nicht. Diese Attribute bestimmen aber _nicht_ die Granularität der Flächenausdehnung (Maßstab). Die 'fuzzyness', um es mit Frederiks Worten zu sagen, brauchen wir auf _jedem_ Maßstab. Egal wie klein der Flächeninhalt einer Fläche wird, ihr wird _nie_ eine 'eindeutige' Nutzung zuschreibbar sein. Es gibt immer mehrere Nutzungen, von denen aber eine oder mehrere überwiegen. Eine Gebietsgröße, im Sinne einer Definition für die Flächenausdehnung eines landuse=* kann nicht gegeben werden, auch nicht als ///Empfehlung///. Wir werden keine quantitativen Zahlen angeben können, die definieren, dass eine Bodennutzungsfläche mindestens 1ha groß sein muss. Weiterhin nicht, wieviele Leute es braucht, die das Gebiet auf eine bestimmte Weise nutzen, bevor ein extra landuse=* gerechtfertigt erscheint: Es lässt sich weder sagen, dass, wenn das Flächenverhältnis von kleinerer zu größerer Fläche 1/10 ist, wird die kleinere Fläche nicht erfasst, noch sagen, dass 10 Menschen, die im Forst wohnen, die Bodennutzung eines Forstes zugunsten des Wohnens ändern. noch sagen, landuse=* hat immer eine größere räumliche Ausdehnung als Gebäude Einesorts kann es durchaus Gebäude geben, die ausdehnungsmäßig viel größer sind, als die Ausdehnung eines landuse anderenorts. Wer es mathematisch exakt braucht, ermittle die durchschnittliche Größe aller Gebäudeflächen (GF) zum einen, und die aller Bodennutzungsflächen (BF) zum anderen. Wenn die Werte in etwa gleich sind, oder BF GF, hat das nichts mit dem bisherigen Verständnis von landuse=* zu tun, aber falsch im Sinne der angestrebten Bodennutzungsdefinition wäre es nicht. === Würden diese Fälle eintreten hätten wir ein MICROmapping von landuse=*, das dann aber bitte auf ISIC-Level 4.. Das als Ziel anzustreben, verprellt alle Nutzer, die an dieser Granularität nicht interessiert sind, also sollten wir explizit ///keine Empfehlung/// zur Granularität geben. Das zeigt unsere Diskussion an sich - die Tatsache, das wir darüber diskutieren. Für den einen ist die Fläche des Bäckers oder das Waldhaus im Wald nach dem Kriterium der Bodennutzung vernachlässigbar, für den anderen nicht. Hier werden wir also nicht zusammenfinden. Stattdessen können wir die Beziehung verschieden großer Flächen der Bodennutzungen untereinander erkennen und diese Struktur gemeinsam managen. In
Re: [Talk-de] landuse=road War:[viel Text zu landuse-handling..]
Hi, Am 14.09.2011 11:23, schrieb Georg Feddern: 'vorrangige', reale Flächennutzung Das ist durchaus eine sinnvolle, nicht-strikte Definition. Aber warum erwartest Du dann, das man sich _strikt_ an eine nicht näher angegebene Größenordnung hält? Wo muss man diese Größenordnung ziehen? Erwarte ich nicht - siehe letzte mail + die mail zur Datenhaltung 'vorrangig' bezieht sich sowieso nicht auf die Größenordnung, denn 'vorrangig' oder 'überwiegend' ist auf bel. Größe/geograph. Ausdehnung ermittelbar.. Das Problem ist, dass die momentane Datenhaltung von landuses=* mittels closed ways uns nicht erlaubt, die Micromapper mit den Makromappern zusammenzubringen. Deshalb kommt Quark dabei heraus, wenn sowohl ein Micromapper, als auch ein Makromapper landuse=* verwendet. Der Micromapper zerlegt das Gebiet des Makromappers, obwohl die größere Fassung (Du schreibst, Deutschland besteht 'vorrangig' aus Agrarfläche), doch wohl auch Sinn macht! Und -vice versa- killt der Makromapper mini-landuses von der OSM-Bildfläche, weil er der Meinung ist, ein landuse=* sei kein building=* Nur aufgrund dieses Mißstands bestand von Anfang an der Wunsch landuse=* größenordnungsmäßig zu begrenzen. Weil wegen der technischen Art der Erfassung Micromapper und Makromapper nicht oder nur schlecht (overlapping ways..) koexistieren können. .. verrauschtes noise bitmap. Nein, dass wären 'falsche' Renderregeln. Angenommen ich würde jedes Grundstück mit einem einzelnen landuse=* taggen. Stell Dir Mischgebiet vor. Nun wird gerendert. Ich zoome heraus, und voila: Noise. Der nächste Schritt ist, dass die Renderregeln angepasst werden, und erst auf einer tieferen Ebene landuse=* gerendert wird Die Granularität bestimmt die Breite der definierten landuses. (Leider wird/wurde bei OSM oft zu schnell in die Breite gegangen, statt zu staffeln. :-( ) +1 bessere Staffelung ist eine Lösung des Problems.. zuviele Werte in einem key sind schlecht.. schlecht strukturierbar, schlecht für Einsteiger Erstens endet die landuse-Granularität z. Z. spätestens an der Grundstücksgrenze - den so sinnlosen landuse=grass mal außen vorgelassen - und gleiche Nutzungen nebeneinander ergeben eine gemeinsame Fläche, im Zweifelsfall den von Martin angesprochenen Block (zwischen Verkehrswegen) - den man ja nicht auf Krampf unterteilen muss. Aber setzt sich der landuse=road durch, ist dort dann sowieso Schluss, falls sich der Schwebe-Ansatz nicht durchsetzt. Mit multipolygons besteht das Problem nicht.. Da schwebt alles Makro dann über Micro, ohne sich zu stören. Die Frage ist nur, ob man die Editoren soweit bringen kann, dass Mapper damit keine Probleme haben.. Und zweitens werden ab einem gewissen Zoomlevel landuses rendermäßig zusammengefasst (landwirtschaftlich, bebaut/besiedelt) sowie kleine Flächen weggelassen. Das ist interessant. Machen Renderer tatsächlich den Aufwand Flächengrößen zu berechnen, bevor gerendert wird? .. (für jedes Gebäude finde ich unter Garantie 25 verschiedene Bodennutzungsarten ringsum). Hier hätte ich gerne Belege für (diese Übertreibung) ... ;-) Das ist für landuse=*, useless=*.. Allerdings - aber in meinen Augen eben auch nicht zwangsläufig zu befürchten. Insbesondere nicht, wenn man sinnvoll staffeln würde, statt weiter nur (oft unüberlegt) in die Breite zu gehen. The thing is.. Staffelst Du sinnvoll, erhälst Du kleinere Flächen, weil die Staffelung dann ja (hoffentlich) auch für die Ausdifferenzierung der verfügbaren Fläche genutzt wird. Damit gehen aber (ohne overlapping ways und ohne multipolygons) die Flächen verloren, welche die gröbere Einteilung, die gröbere Staffelung beinhalten. Dein wie auch mein Argument dazu würde sein, dass man sich die gröberen Flächen ausrechnen kann - das zieht hier aber nicht: - zum einen sind die Gebiete nicht immer ausrechenbar sind (z.B. dann nicht, wenn das gröbere Gebiet einen Namen hat - den müsstest Du dann auf jedem feingranularen Gebiet auch angeben, und das feingranularere Gebiet könnte dann keinen eigenen Namen mit name=* mehr erhalten) - zum anderen sehr viele Leute die gröberen Gebiete verwenden (es damit Verschwendung wäre, wenn jeder für sich rechnet) Wird ein grobes Gebiet unter Nutzung der Grenzen der feineren Gebiete mittels multipolygon erfasst, kann man auch nicht direkt davon sprechen, dass redundante Information in der DB wäre, denn es ist nur die Information enthalten, wie aus den feineren Gebieten, dass größere konstruiert wird). Die Regel an sich ist redundant in der DB (wie konstruiere ich die Siedlungsfläche aus den micro-landuses), aber keine Daten. Wenn landuse=* auf Dauer nicht über Flächengrenzen mittels multipolygon gemappt wird, womit sich 'genaue' und 'vorranige' Flächennutzungsgebiete vereinen ließen, sollte man ein anderes Tag aufmachen, um landuse micromapping zu betreiben.. Denn landuse micromapping erhöht
Re: [Talk-de] landuse=road War:[viel Text zu landuse-handling..]
Am 15. September 2011 01:34 schrieb Christian Müller cmu...@gmx.de: Am 14.09.2011 15:17, schrieb Garry: Wenn Dir die Häuser im Wald wichtig sind, kannst Du auch /nur/ diese mit in die Karte aufnehmen. Bessere Lösungen für deinen Anwendungsfall (Datenreduktion ohne Detailverlust im Wald) sind: wieso sollte das kein Detailverlust sein? Das ist die gleiche Diskussion, die wir schon mit dem Bäcker hatten. Nein, ist es nicht. Zwei Wohnhäuser im Wald entsprechen nicht einem Bäcker im Wohngebiet. Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] landuse=road War:[viel Text zu landuse-handling..]
Am 15. September 2011 02:22 schrieb Christian Müller cmu...@gmx.de: .. verrauschtes noise bitmap. Nein, dass wären 'falsche' Renderregeln. Angenommen ich würde jedes Grundstück mit einem einzelnen landuse=* taggen. Stell Dir Mischgebiet vor. Nun wird gerendert. Ich zoome heraus, und voila: Noise. Der nächste Schritt ist, dass die Renderregeln angepasst werden, und erst auf einer tieferen Ebene landuse=* gerendert wird Die Renderregeln können ja auch komplexer sein, als nur Flächen eines bestimmten Landuses in einer bestimmten Farbe einzufärben. Wenn sich im Laufe der Zeit dadurch, dass sich die Differenzierung der Welt auch in OSM wiederfindet, in einem bestimmten zoomlevel die landuses zu noise werden, wie Du befürchtest, dann könnte man z.B. - sofern die Daten das hergeben - auch als Renderer herausfinden, dass ein bestimmtes Gebiet eine bestimmte Nutzungsmischung hat, und das grafisch in die Karte einarbeiten. Z.B. könnte man größere, gröbere Gebiete automatisch aus feiner und differenzierter aufgelösten Gebieten berechnen und sich dabei je nach Karte, die man erstellt, entscheiden, welche Nutzungen man nicht differenzieren will, und welche einem, wenn sie auch klein sein mögen, dennoch wichtig genug sind, sie einzeln zu zeichnen. Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] landuse=road War:[viel Text zu landuse-handling..]
Am 10.09.2011 19:35, schrieb Christian Müller: 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. landuse=traffic ist hier irreführend, es sollte landuse=road heissen (unter der Voraussetzung/Annahme das roadgleichwertig mit Strasse aus der deutschen Wikipedia zu verstehen ist). traffic hört sich nach reiner Verkehrsfläche an, zu einer Strasse gehört aber noch etwas mehr Fläche drumherum dazu (Abschnittsweise durchaus auch mal mehr als die eigentliche Verkehrsfläche) die eine anderwertige Nutzung im Sinne von landuse quasi ausschliesst. Die eigentliche Verkehrsfläche sehe ich dann nicht als landuse sondern als sowas wie landcover=highway. So kann man dann die Verkehrsfläche nach belieben aufteilen (Fahrspuren, Schutzflächen,...) ohne mit landuse ins Gehege zu kommen. Ich vertrete nach wie vor den Standpunkt dass landuse-Flächen nicht an die highway-ways geklebt werden dürfen sondern nur an andere landuse-Flächen insofern sicher ist dass sich nicht noch eine andere landuse-Fläche dazwischen befindet. Zwischenstufen (im Sinne von mapping nicht abgeschlossen, z.B. weil noch keine genauen Daten verfügbar sind) bei denen sich landuse-Flächen überscheiden (hier insbesondere im Zusammenhang mit landuse=road) sehe ich nicht als problematisch an Gruss Garry ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] landuse=road War:[viel Text zu landuse-handling..]
Hi, Am 13.09.2011 13:51, schrieb Garry: landuse=traffic ist hier irreführend, es sollte landuse=road heissen (unter der Voraussetzung/Annahme das roadgleichwertig mit Strasse aus der deutschen Wikipedia zu verstehen ist). traffic hört sich nach reiner Verkehrsfläche an, zu einer Strasse gehört aber noch etwas mehr Fläche drumherum dazu (Abschnittsweise durchaus auch mal mehr als die eigentliche Verkehrsfläche) die eine anderwertige Nutzung im Sinne von landuse quasi ausschliesst. Die eigentliche Verkehrsfläche sehe ich dann nicht als landuse sondern als sowas wie landcover=highway. So kann man dann die Verkehrsfläche nach belieben aufteilen (Fahrspuren, Schutzflächen,...) ohne mit landuse ins Gehege zu kommen. +1 in allen Punkten. Deine Auffassung zur Verkehrsfläche deckt sich auch mit der in http://de.wikipedia.org/wiki/Straßenquerschnitt 'Verkehrsanlage' ist im dt. schon an Ampeln, Wegweiser, etc. vergeben, siehe http://de.wikipedia.org/wiki/Verkehrsanlage Vielleicht sollte man daher im dt. von 'Straßenraum' sprechen: http://de.wikipedia.org/wiki/Straßenraumgestaltung Die 'Straßenraumgestaltung' findet zwar (laut Wikipedia) nur innerörtlich statt, aber einen Straßenraum dürfte es überall geben. Hier ist noch eine eher gesellschafliche Definition zum Straßenraum, weniger eine geografische: http://bit.ly/nCx2OW Straßenraum - landuse=road Ich vertrete nach wie vor den Standpunkt dass landuse-Flächen nicht an die highway-ways geklebt werden dürfen sondern nur an andere landuse-Flächen Verbote (dürfen) bringen uns nicht weiter. Gute Gründe schon. Weshalb landuses an highways geklebt werden, wissen wir schon. Weil landuse=road bis jetzt selten eingetragen, wenig bekannt und daher die highway-Linie das einzige ist, was die landuse=road Grenze repräsentiert. Deshalb die Feststellung, dass das übergangsweise Sinn machen kann. Wir sollten landuse=road nicht einfordern, weil dann guess_work in den Gebieten entsteht, in denen keine hochaufgelösten Luftbilder vorhanden sind. Was nützen uns zig landuse=road Polygone, die guess_work sind. In Gebieten, in denen ich landuse=road nicht erfassen kann, weil die Quelldatenlage einfach zu schlecht ist, sollte das Kleben übergangsweise erwünscht sein. In diesem Fall kann nämlich auch die Grenze eines landuses neben dem Straßenraum schlecht bis gar nicht erfasst werden. 'Erwünscht' deshalb, weil der nicht vorhandene oder nicht ermittelbare landuse=road an dieser Stelle eben durch die highway-Linie repräsentiert wird. Du kannst übergangsweise natürlich auch eine schlechte, sprich sehr ungenaue zweite Grenze zeichnen, die wahrt aber eben in diesem Übergangsstadium (sprich Jahre) nicht die Topologie. Wenn Du übergangsweise klebst, hast Du auch mit ungenauen Quelldaten bereits die topologische Information in der DB, die Du erhälst, wenn zum Schluss geografisch genaue landuse Informationen vorliegen - ohne Distanzberechnungen anstellen zu müssen. insofern sicher ist dass sich nicht noch eine andere landuse-Fläche dazwischen befindet. Da landuse 'vorrangige' Flächennutzungen mappt, gehen vernachlässigbare, kleinere Änderungen in der 'vorrangigen' Flächennutzung eines größeren Gebietes unter. Zwei Häuser im Wald ändern die 'vorrangige' Flächennutzung des ungleich größeren Waldgebietes drumherum _nicht_, weil die Fläche eben 'vorrangig' für den Forst benutzt wird. Macht man das nicht so, wird landuse /beliebig/ fein granular, bis sich zum Schluss landuse=* einem building=* annähert. Das kann nicht der Sinn von landuse=* sein. Daran anknüpfend: Wie sieht deine Meinung bzgl. eines Sonderstatus von landuse=road aus? Macht es Sinn landuse=road über anderen landuses schweben zu lassen, damit landuses gerade in städtischen Gebieten nicht übermäßig fragmentieren? Meiner Meinung nach schon, ich kann aber auch Leute nachvollziehen, die das unschön finden. Evtl. finden wir eine Lösung im Multipolygon, also - große zusammenhängende Fläche als outer - Flächen der Straßenräume als inner Ideal wäre _ein_ way in der Rolle outer, weil sich dann die basisgeometrischen Daten auch ohne Betrachtung des Multipolygons nutzen lassen. Das Multipolygon würde sozusagen unseren Wunsch, landuse nicht übermäßig zu fragmentieren, mit der Realität verbinden, die fragmentiert ist. Zwischenstufen (im Sinne von mapping nicht abgeschlossen, z.B. weil noch keine genauen Daten verfügbar sind) bei denen sich landuse-Flächen überscheiden (hier insbesondere im Zusammenhang mit landuse=road) sehe ich nicht als problematisch an siehe oben, /Du/ nicht - ein Datennutzer, der sich für den topologischen Aspekt interessiert evtl. schon Gruß ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] landuse=road War:[viel Text zu landuse-handling..]
Am 13. September 2011 15:57 schrieb Christian Müller cmu...@gmx.de: Am 13.09.2011 13:51, schrieb Garry: traffic hört sich nach reiner Verkehrsfläche an, zu einer Strasse gehört aber noch etwas mehr Fläche drumherum dazu (Abschnittsweise durchaus auch mal mehr als die eigentliche Verkehrsfläche) die eine anderwertige Nutzung im Sinne von landuse quasi ausschliesst. stimmt nicht ganz. So gibt es z.B. Sicherheitsabstände, (von denen in Ausnahmen abgewichen werden kann), und die nicht unbedingt als Straßennutzung anzusehen sind, obwohl sich aus dem Vorhandensein der Straße rechtliche Auswirkungen ergeben. Mit der Idee, Straßen in Straßennutzung inkl. Nebenflächen und Verkehrsfläche zu teilen bin ich einverstanden - so man denn überhaupt ausserorts Straßenflächen erfassen will. Haltebuchten und so was wären Verkehrsraum in OSM, oder? 'Verkehrsanlage' ist im dt. schon an Ampeln, Wegweiser, etc. vergeben, siehe http://de.wikipedia.org/wiki/Verkehrsanlage gem. BGH_Urteil hins. HOAI: Zu den Verkehrsanlagen gehören „alle Gegenstände, die dem Gebrauch der Anlage zum Zweck des Straßenverkehrs dienen, insbesondere diejenigen, die aus konstruktiven oder rechtlichen Gründen für ihre Nutzung erforderlich sind“. Straßenraum - landuse=road road klingt mehr nach Straße als highway m.E.. Wir sollten landuse=road nicht einfordern, weil dann guess_work in den Gebieten entsteht, in denen keine hochaufgelösten Luftbilder vorhanden sind. Was nützen uns zig landuse=road Polygone, die guess_work sind. lieber vom Mapper mit der Kenntnis vor Ort geschätzt und bei Gelegenheit verfeinert als wenn man es ohne Kenntnis beim Auswerten schätzen muss. Da landuse 'vorrangige' Flächennutzungen mappt, gehen vernachlässigbare, kleinere Änderungen in der 'vorrangigen' Flächennutzung eines größeren Gebietes unter. Zwei Häuser im Wald ändern die 'vorrangige' Flächennutzung des ungleich größeren Waldgebietes drumherum _nicht_, weil die Fläche eben 'vorrangig' für den Forst benutzt wird. ich würde das Gebiet zweier dauerhaft bewohnter Häuser im Wald als landuse=residential kennzeichnen. In Deutschland kommt so was aufgrund des Verbots, im Aussenbereich zu bauen, allerdings extrem selten vor. Macht man das nicht so, wird landuse /beliebig/ fein granular, bis sich zum Schluss landuse=* einem building=* annähert. Das kann nicht der Sinn von landuse=* sein. Das Liegenschaftsamt sieht das anders: die mappen sogar Teilflächen wenn sie unterschiedliche Nutzungen haben auch getrennt. Ich würde das weder fordern noch pauschal ausschließen wollen. Daran anknüpfend: Wie sieht deine Meinung bzgl. eines Sonderstatus von landuse=road aus? Macht es Sinn landuse=road über anderen landuses schweben zu lassen, damit landuses gerade in städtischen Gebieten nicht übermäßig fragmentieren? ich halte mich an die Realität. Und an den Aufwand, den ich konkret investieren will. Klar mappe ich auch mal ein paar Straßen mit in den Landuse rein (mit Straßen verbinde ich die landuses allerdings trotzdem nicht), aber ich sehe das als vorläufig an. Je kleiner man diese Einheiten macht (bis zu Flächen, die keine Straßen mehr beinhalten, einzelne Blumenbeete meine ich damit nicht), um so einfacher wird es für die folgenden Mapper, dort weiterzuarbeiten. Meiner Meinung nach schon, ich kann aber auch Leute nachvollziehen, die das unschön finden. Evtl. finden wir eine Lösung im Multipolygon, also - große zusammenhängende Fläche als outer - Flächen der Straßenräume als inner das macht die Sache unnötig kompliziert. Ich sehe schon Unmengen von ungültigen Multipolygonen entstehen, wo inner ways an der Aussengrenze liegen. Wo sie nicht nötig sind, würde ich solche Konstrukte vermeiden wollen. Ideal wäre _ein_ way in der Rolle outer, weil sich dann die basisgeometrischen Daten auch ohne Betrachtung des Multipolygons nutzen lassen. Das Multipolygon würde sozusagen unseren Wunsch, landuse nicht übermäßig zu fragmentieren, mit der Realität verbinden, die fragmentiert ist. woher kommt eigentlich dieser Wunsch, die Realität in diesem Punkt nicht (in unserem Rahmen) möglichst genau abzubilden, sondern grobe unfragmentierte Gebiete haben zu wollen? Kann man das nicht durch Datenverarbeitung hinterher machen, wenn man gerne vereinfachte Geometrien haben will? Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] landuse=road War:[viel Text zu landuse-handling..]
Am 13.09.2011 17:14, schrieb Martin Koppenhoefer: ich würde das Gebiet zweier dauerhaft bewohnter Häuser im Wald als landuse=residential kennzeichnen. In Deutschland kommt so was aufgrund des Verbots, im Aussenbereich zu bauen, allerdings extrem selten vor. welchen Sinn soll das haben? so kommen wir nicht weiter.. Die Granularität von landuse=* ist in OSM einfach nicht die von building=* und wenn sie das wäre, wäre landuse=* für die meisten Datennutzer useless=* Das Liegenschaftsamt sieht das anders: die mappen sogar Teilflächen wenn sie unterschiedliche Nutzungen haben auch getrennt. Ich würde das weder fordern noch pauschal ausschließen wollen. Ja, können sie ja machen - haben wir die Ressourcen? Macht das in OSM Sinn? Ich denke nicht, wir sollten bei dem 'vorrangig' in der Definition zur Bodennutzung bleiben. Beim Taggen von landuse=* über seine Grenzen, macht aber auch ein amtlicher Datenimport keine Probleme. Man legt das einfach über das, was in OSM da ist, taggt die ways des Imports als border=administrative source=official und erstellt Multipolygone mit type=multipolygon landuse=xyz official_key1=* official_key2=* official_key3=* source=official Ich denke nicht, dass diese Granularitätsebene, auf der die Ämter mappen für eine OSM-Definition von landuse=* geeignet ist. Natürlich gibt's kein Verbot, diese Granularität in OSM zu benutzen, aber uns geht es hier um eine brauchbare Wiki-Definition, die würde ich nicht strikt gestalten. 'vorrangige', reale Flächennutzung Du musst auch mal überlegen, welche Konsquenzen das hätte: landuse=* würde evtl. nur noch auf dem letzten Zoomlevel renderbar sein, auf allen anderen gibt's ein verrauschtes noise bitmap. Weiterhin hatte sich jemand über die Fülle der Daten in Frankreich durch den Import aufgeregt. Wenn die Flächennutzung auf der Granularitätsebene von Baufenstern (oder nahe diesen) arbeitet, hätten wir zum Schluss 25*Anzahl der building Polygone an Daten in der Stadt (für jedes Gebäude finde ich unter Garantie 25 verschiedene Bodennutzungsarten ringsum). Das ist für landuse=*, useless=*.. Wenn landuse=* auf Dauer nicht über Flächengrenzen mittels multipolygon gemappt wird, womit sich 'genaue' und 'vorranige' Flächennutzungsgebiete vereinen ließen, sollte man ein anderes Tag aufmachen, um landuse micromapping zu betreiben.. Denn landuse micromapping erhöht Eintrittsbarrieren, anstatt sie zu senken.. Je kleiner man diese Einheiten macht (bis zu Flächen, die keine Straßen mehr beinhalten, einzelne Blumenbeete meine ich damit nicht), um so einfacher wird es für die folgenden Mapper, dort weiterzuarbeiten. Irrglaube, denn Du hast dann statt Struktur, rohe Komplexität abgebildet. brute-force, statt elegance. Es gibt keinen Bezug deiner Mini-Flächen untereinander. Man sieht sprichwörtlich den Wald vor lauter Bäumen nicht mehr. Wenn deine Mini-Einheit was bringen soll, dann nur über die Multipolygon-Methode, mittels derer diese Mini-Flächen wieder zu groben, fassbaren Flächen gruppiert werden können, bis zu dem Punkt, wo man wieder von 'vorrangiger', realer Flächennutzung sprechen kann, was landuse=* jetzt ist. woher kommt eigentlich dieser Wunsch, die Realität in diesem Punkt nicht (in unserem Rahmen) möglichst genau abzubilden, sondern grobe unfragmentierte Gebiete haben zu wollen? Kann man das nicht durch Datenverarbeitung hinterher machen, wenn man gerne vereinfachte Geometrien haben will? Nein, aus dem gleichen Grund, aus dem Du die Erfassung der Siedlungsfläche (nach deiner Definition) explizit wünschst. Um es mal auf dein Beispiel mit der dt. Staatsgrenze zu übertragen: Die ist auch explizit erfasst, obwohl man sie aus der Summe aller nächsttieferen Grenzen berechnen kann. Und die nächsttieferen Grenzen wiederum aus den nächsttieferen.. ad absurdum Der Grund weshalb man das nicht berechnet, ist, neben dem Rechenaufwand, dass wir in OSM selbst die Information der Realität haben wollen, in der DB. Würden wir rechnen, hätten wir das Wissen um die Struktur der Daten (die Definitionen /was/ ist eine Staatsgrenze, usw.), nicht /in den Daten/, sondern -off-site- /in den Algorithmen/. (Außerdem müßte dann eben jeder rechnen, selbst wenn die gleiche Information benötigt wird. Auf die Weise lassen sich abh. Strukturdaten in OSM vll als gecachte, vorberechnete Daten verstehen.) Gruß Christian ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
