Beim besten Willen kann ich mich nicht erinnern wo ich denn etwas geleugnet habe und das noch ständig. Und schon gar nicht habe ich gesagt, dass das kein Problem ist. Das gilt für mich. Für Andere ohne Auftrag zu sprechen ist nicht mein Stil. Selbstverständlich ist die Darstellung von komplexen Dingen schwierig. Und je mehr Einzelheiten und Zusammenhänge wir in unsere Daten aufnehmen umso komplexer wird es. Dennoch würde ich hier nicht von Problemen sondern von Herausforderungen reden. Und viele fleißige Freiwillige sorgen dankenswerter dafür dass sowohl die Datenbank als auch die Hauptanwendungen diese Herausforderungen meistern.
Selbstverständlich kann das nicht jede Person und vor allem nicht wenn sie neu einsteigt. So etwas zu fordern ist zwar ehrenwert jedoch weltfremd. Meines Erachtens wird dies immer so sein, auch wenn sich das Ganze mit besseren Algorithmen, Programmen und Rechnern verschieben wird. So kann man heutzutage ein Smartphone in der Hosentasche haben, das so leistungsfähig ist wie ein ganzes Rechenzentrum vor wenigen Jahrzehnten war und zu dessen Betrieb mehrere Spezialisten und Hilfskräfte erforderlich waren. Aber auch heute gibt es Nutzer die mehr als andere auf ihren Smartphones machen wollen und können.
Ich hab auch mal mit Punkten angefangen, dann sind Linien dazugekommen und später habe ich mich in Relationen eingearbeitet. Und selbst heute verstehe ich auch nur die Relationen, die ich selbst einsetze. Die anderen aktzeptiere ich einfach und äussere mich nicht dazu.
Nur die hier behaupteten Probleme sehe ich (noch) nicht. Vielmehr habe ich eher den Eindruck, dass hier Gespenster an die Wand gemalt werden, um seiner eigenen Meinung Nachdruck zu verleihen oder sie gar durchzudrücken. Eine uralte, gut bekannte Taktik. Ebenso andere Personen, vielleicht sogar die sogenannte “schweigende Mehrheit”, für sich zu vereinnahmen und ohne Auftrag für sie zu sprechen.
Der konsequente Verzicht auf Multipolygone führt allerdings auch nicht automatisch zu besseren Ergebnissen.
Das eigentliche Problem sind die Leute die jeden Quadratmillimeter bunt anmalen müssen.
Anbei ein paar Beispiele, warum man Straßen nicht mit Flächen (landuse:*) vernähen sollte.
Ich glaub nicht dass es Leuten darum geht MP abzulehnen, sondern um den maßvollen Einsatz. Dein farmland beschreibt nichts, deshalb wäre hier ein MP nicht zwingend notwendig und man kann auch 2 farmlands machen (Ich hätte auch eins gemacht, aber seis drum). Das Beispiel ist sehr übersichtlich, trotzdem unnötigerweise wieder 2 outer-Linien, warum? Das Problem ist, dass diese 2 outer-Linien nun wieder outer-Linien beim angrenzenden Stück http://www.openstreetmap.org/browse/relation/1561838 hervorrufen
Wenn dann noch mehrere outer-Linien genommen werden oder mehr als 20 Mitglieder genommen werden, hört der Spaß schnell auf. Nop hat vollkommen Recht: Je komplizierter, desto weniger steigen durch und geben auf. Das als Herausforderung zu deklarieren grenzt an Verhönung aller Leute die an OSM bereits gescheitert sind. Mir machen Relationen auch keine Kopfschmerzen, aber erzählt bitte nicht dass es einfach ist. Ich wette, bei euren Monsterdingern steigen nicht mal 1000 Leute in Deutschland wirklich durch. Auch mir ist ein sehr aktiver Mapper vom Stammtisch bekannt, der Relationen eben nicht anfasst, weil er das bis dato nicht verstanden hat und da ist er nicht der Einzige. Diese Leute haben schon mit den normalen JOSM-Fehlermeldungen extreme Probleme, da wollen die nicht noch mit 100 Relationsmitgliedern anfangen.
Wieso nicht? Soll man zwei übereinanderliegende Wege machen für jede Relation? Das ist schrecklich zu bearbeiten und total unübersichtlich.
Die alle angrenzend sind und da nicht ettliche Linien aufeinander liegen ist es eigentlich offensichtlich welche Linie zu welchen Multipolygon gehört.
Also bist du ganz gegen Multipolygone? Meiner meinung nach versteht man entweder Multipolygone oder man versteht es nicht, da ändert die Anzahl der Elemente nämlich garnichts daran.
Es kommt immer wieder die Behauptung, dass Multipolygone bei weitem schwerer zu verstehen seien als normale Flächen. Ich weiß nicht was daran so kompliziert ist, dass Relationen Sammlungen von Wegen und Punkten mit vergebenen Rollen sind und Multipolygone Flächen die durch Wege mit outer und inner Rollen für Außengrenzen und Innengrenzen beschrieben werden. Ich halte dies nicht für dramatisch schwieriger als normale Flächen, die geschlossene Wege sind, außer sie haben besondere Tags (wie junction=roundabout) was aber dann doch wieder mit area=yes verändert werden kann, manchmal. Und früher war es noch komplizierter, weil Seen im Uhrzeigersinn gezeichnet werden mussten.
Ich nehme an, das ist die Antwort auf meine Frage nach einem ähnlich komplexen Beispiel ohne Multipolygone im Beitrag #84. Die Studios K und L sind nicht mit Multipolygonen sondern mit doppelten Linien gezeichnet sind. Mache ich auch, wenn 2, 3 Knoten gemeinsam sind und nicht aus anderen Gründen ein Multipolygon sinnvoll ist. Die meisten Gebäude, z.B. die benachbarten Studios A-F, sind mit Multipolygonen dargestellt. Zeigt eigentlich schön, dass je nach Eignung die eine oder andere Methode gewählt wird und beide Methoden problemlos koexistieren. Ist jedoch nicht das Beispiel, das ich im Auge hatte. Ich dachte eher an ein Gebiet, so groß und mit so vielen komplexen Gebäuden wie dieses ja schon im Beitrag #70 genannte Gebiet, jedoch ohne Multipolygone.
Zwar würde ich die Bezeichnung “krass” nicht verwenden, aber aus einer Straße wie der B251 würde ich auch keinen Weg mit 80 m und 4 Knoten herausschneiden, um ein 80 x 10 m “kleines” Buschland darzustellen. Das halte ich nicht für ausgewogen.
Das sind “gute Beispiele” misslungener Vermeidung von Multipolygonen und schlampiger Arbeit: Beim Erstellen einer doppelten Linie werden vorhandene Knoten nur teilweise verwendet und teilweise neue knapp neben denen der alten Linie erstellt. Zum Beispiel Kreisverkehr Eschelbacher Straße und landuse=commercial.
Meine Erfahrung von OSM-Stammtischen ist nicht, dass irgendjemand die Multipolygone nicht verstehen würde, sondern dass manche sich mit Relationen noch gar nicht befasst haben, weil diese Bezeichnung so kompliziert klingt. Würde man statt Relation Objekteverbund oder -menge sagen, dann wärs viel klarer.
Auf den Stammtischen, wo ich war, hat nach Multipolygonen noch gar niemand gefragt, sondern hauptsächlich nach Routenrelationen. Landuse interessiert die meisten nicht sonderlich.
Vor allem die “Riesen aus alter Zeit” (=forest) müssten verkleinert werden. Da komme ich und trenne den forest auf, weil dort jetzt ein Skilift mit Abfahrtswiese eingebaut wurde - und plötzlich gibt es keinen Wald mehr - nur Weiß.
Als Beispiel auch die Wanderwege (z.B. “gelber Punkt”, “grüner Strich”) als Relationen sollten z.B. von “Ort zu Ort” oder “Um die Talsperre” geteilt werden. Dann kann ja ein MP-Profi eine Superrelation zusammenstellen.
Warum nicht die Wälder, Felder und Wiesen als landuse (durch einen Anfänger oder MP-Nichtversteher) - und die zu einem Bauern oder Ort gehören werden als Relation (im weiteren von einen MP-Profi) zusammen gefasst. Und eine Wiese im Wald mit einem See ist möglich als landuse. Wenn dann noch landuse=grass im water funktioniert, sind auch Inseln möglich - ohne MP-Wissen.
IMHO:
MP mit Wiese als Loch im Wald + MP Wiese mit See als Loch und landuse=grass im Water nur mit place= islet/isle ebenfalls als MP Wasser + Insel als Loch, oder?
landuse=forest → darin landuse=gras, landuse =scrub, natural=water (alles ohne MP)
natural=water mit place=islet und landuse=grass geht z.Z nur als MP.
… und es dann dem renderer überlassen, wie er das auseinanderfieselt?
Mein Verständnis von landuse ist, dass es an jeder Stelle der Welt genau ein landuse gibt.
Dem Landuse können natürlich andere Kategorien überlagert sein, z.B. building in landuse=residential.
Hallo ihr beiden,
streitet ihr euch nicht gerade um die trivialsten Fälle von Landuse? Waldfläche mit See und eine Insel in dem See? Das ist ganz banal mit einfachen MP zu erledigen.
Etwa so wie ein Haus mit Atrium, natürlich als MP - darüber regt sich auch keiner auf.
Die Methode “Landuse verschachteln (ohne MP)” sieht zwar auf der bunten Mapnik-Karte ganz korrekt aus, ist es aber nicht.
Sobald man flächenhafte Analysen machen will, wird es eng: Wie gross ist die Waldfläche ohne See? Wie gross ist die Wasserfläche des Sees?
OSM ist keine Karte - OSM ist eine Datenbank und wenn da Quark drin steht, kommt Käse raus (garbage in - garbage out)
Ob trivial oder nicht, sollte dahin gestellt sein.
Tatsache ist, daß es nicht richtig ist. Wenn man die Mapping-Praxis betrachtet, ist da so einiges im Argen.
Von so ziemlich jeder DTP- oder Bildbearbeitungssoftware kennt man zwei grundlegende Konzepte:
Gruppierung von Objekten (beliebig oft iteriert)
Stapelung von Objekten (“Vordergrund”, “Hintergrund”)
Das ist intuitiv und jeder Mapper versteht das schnell. Gruppierung ist in OSM mit Relationen abbildbar (wird aber eher nur in Spezialfällen dafür propagiert). OK, Relationen können eigentlich mehr (“Rollen”). Fehlt uns ein einfaches Gruppierungskonzept?
Vordergrund / Hintergrund implementiert Mapnik offenbar, obwohl das Datenmodell es nicht vorsieht: Ein Zeichen, daß hier ein offensichtliches Konzept im Modell vergessen wurde?
Hier sehe ich die gleiche Qualität wie “Mappen für den Renderer”. Wir erstellen das DB-Modell nicht für den Renderer und auch nicht für den Analysator. Wir versuchen, auf möglichst wirklichkeitsgetreue (= intuitive) Weise, die Realität abzubilden. Und wenn da eine Insel im Meer mit einem See, der wiederum eine Insel mit einem Waldstück drauf hat, abzubilden ist, kann man das gut durch Stapelung von Objekten abbilden.
Eine Staatsgrenze ist typischerweise ein geschlossener Weg. Im Falle von Exklaven eine Gruppierung von geschlossenen Wegen. Wobei der einzelne Weg (weil sehr groß) eine Gruppierung von Wegstücken ist… Die Enklave eines anderen Staates im eigenen Staat ist wiederum durch die Stapelung (“Vordergrund”) leicht kenntlich zu machen.
Das sind für mich intuitive Beispiele, wie man mit Konzepten, die ein Großteil der Internetnutzer kennt, Geodaten abbilden kann. Ohne daß es dazu eines Multipolygons bedürfte.
Warum wird hier eigentlich krampfhaft zwischen Grenzen und Landuse unterschieden? Beides sind Klassen/Arten von Flächen, die vieles gemeinsam haben:
sie liegen immer “nebeneinander” und überschneiden sich nicht
sie haben geschlossene Linienzüge als Rand
sie können Enklaven (Löcher) und Exklaven enthalten
Enklaven und Exklaven sind ebenfalls geschlossene Ringe
Bei Grenzrelationen ist zusätzlich folgendes etabliert:
Ringe können aus mehreren Ways (*) bestehen
Zwischen den Ländern gibt es keine doppelten Ways
ein Way als Grenzstück wird von beiden betroffenen Grenzrelationen gemeinsam verwendet.
Wendet man nun diese Regeln für Grenzrelationen auch auf Landuse an, bedeutet das
Landuse kann aus mehreren Ways bestehen
Zwischen den Landflächen gibt es keine doppelten Ways
Ein Way als “Grenze” zweier Landuse wird von beiden betroffenen Landuse-Relationen gemeinsam verwendet
Zusammenfassend: Grenzrelationen und Landuse-Relationen sind in ihrer Struktur absolut identisch.
Ich kann nicht verstehen, dass bei zwei (für mich) identischen Fällen die eine Lösung etabliert und die andere äußerst umstritten ist.
Gruss
Walter
() Ways im OSM-Sinn, also nicht etwa Wege (Highway=)
Highways für Grenzen/Landuse jeglicher Art mitzuverwenden lehne ich (inzwischen) ab. Aber das ist ein anderes Thema.
Dein Editor ist aber kein Zeichenprogramm für die slippy map sondern ein Editierwerkzeug für die Openstreetmap geodatenbank. Wenn da kein Wald ist, dann ist da kein Wald.
Was willst du an Relationen ohne vergebene Rollen noch einfacher machen? Das Problem ist wohl eher das Relationen erst später eingeführt wurden und etwas stiefmütterlich behandelt werden.
Eben nicht. Stapelung von Objekten bildet Stapelung von Objekten in der Wirklichkeit ab (Brücken, Tunnel). Desweiteren wäre es ein Graus Linien zu haben die teilweise zu 10 Wegen, die mit verschiedenen Layer Tags versehen sind gehören. Rregeln für wann welches Objekt welches Objekt überschreibt wären auch sehr kompliziert.
