Am 25. Mai 2011 00:41 schrieb Stephan Wolff <[email protected]>: > Am 24.05.2011 18:52, schrieb Flaimo: > Die Außengrenzen eines Wohn-, Industrie- oder Waldgebiets sind nicht > ungenauer als die Grenzen der Einzelgrundstücke, sondern stellen eine > andere, zweifellos notwendige Informationsebene dar.
dem widerspreche ich für die Datenbank entschieden. Klar, auf einer Karte wird man die Information vielleicht so darstellen wollen, aber in der Datenbank braucht man Informationen, und nicht grobe Einschätzungen einzelner Mapper zu Tendenzen oder "überwiegenden" Sachverhalten (die kann man nämlich präzise automatisch nach klaren Regeln ermitteln, wenn die Informationen dazu vorliegen). > "landuse" wird > aktuell weit überwiegend als Gebiet verwendet und ist so auch im Wiki > definiert. ja, nur das nicht klar ist, was "das Gebiet" ist, und wie groß es ist. Wenn man sich mal Gedanken dazu macht, wie es sinnvoll ist, dann kommt man m.E. zu dem Schluss, dass man landuse möglichst kleinteilig erfassen will. Richtig klar und eindeutig "Nutzung" ist landuse allerdings sowieso nicht, es gibt auch noch leisure und natural mit ebenfalls unklarer Abgrenzung und Featuremischung. Im Wiki findest Du auch einen landcover Vorschlag von mir, der dieses Problem erläutert. > Die Einführung eines neuen Tag für die Mikrostruktur wäre problemlos > möglich. Eine Umdefinition von "landuse" würde dagegen eine Änderungen > fast aller bestehender "landuse"-Daten und Auswertungen erfordern. Das kannst Du sicherlich mit Statistiken gut belegen? Hast Du mal ein Beispiel, wo es störend ist, den landuse kleinteiliger zu erfassen, und wo es daher sinnvoll ist, Teilflächen "falsch" zu klassifizieren, damit die Daten besser sein sollen? > - erklären, wie er die die bisherige Information (z.B. Gebietsnamen) > erhalten will verstehe ich nicht, wo da ein Problem sein soll. Multipolygone kennst Du? Ein Problem erkenne ich eher anders rum: wenn man nur große zusammengefasste Gebiete hat, dann kann man die kleinen Einzelteile nicht benamsen und muss dafür entweder zusätzliche, überlappende Flächen erstellen, oder ungenaue nodes setzen. > - eine Mehrheit(!) für die Umdefinition finden. ich mappe einfach, in meinem Umfeld muss ich nicht diskuttieren über dieses Thema, weil man sich einig ist. Ich habe den Hinweis hier nur mal angebracht, weil ich Dir einen Gefallen tun wollte, aber ich kann auch damit leben wenn es in Deutschland noch ein bisschen dauert, bis die Detaillierung von Feld und Flur zunimmt. >> dabei sollte man dann vielleicht auch mal definieren was >> "überwiegend" bedeutet > Das Problem tritt ebenso bei jeder anderen Flächendefinition auf. > Schon innerhalb eines Gebäudes kann es über- und nebeneinander > verschiedene Nutzungen geben. Ich kann einen Sinn darin erkennen, eine bestimmte Nutzung für ein Grundstück festzulegen (wobei auch da in seltenen Fällen eine Zusatzinfo wünschenswert ist), aber nicht darin, abweichende Nutzungsarten und Flächen in einem Gebiet zu unterschlagen. Zusätzlich zu überwiegend sollte man - wenn man trotz aller Überlegungen zu der Auffassung kommt, dass eine Zusammenfassung besser ist als Einzelinformationen - welche Nutzungsmischungen noch kompatibel sind, und welche nicht mehr (z.B. könnte man sagen, dass eine Tankstelle oder Kneipe in einem Wohngebiet noch verträglich ist, eine Industrienutzung aber grundsätzlich getrennt gemappt werden muss). Diese Definitionen gibt es bisher nicht, und daher macht das jeder nach Gutdünken. > In meinem Editor kann man Wege auf einer großen Fläche leichter > verschieben als drei fast parallele Linien. Auch beim Einzeichnen > von Gebäuden und POIs sind weniger Einzellinien vorteilhaft. in meinem Editor muss man Wege nur höchst selten verschieben, weil sie dort sind, wo ich sie auch zeichnen würde. Topologisch ist Präzision auch hier besser als Generalisierung, die Einzellinien sind ja nicht willkürlich sondern beschreiben die Realität (Straßenmitte vs. Grundstücksgrenze). Aber klar: eine leere Karte ist am Leichtesten zu editieren und am Einfachsten beim Betrachten. Gruß Martin _______________________________________________ Talk-de mailing list [email protected] http://lists.openstreetmap.org/listinfo/talk-de
