Multipolygonwahnsinn - oder: Durchblick war gestern!

Die alternativen zu outerpolygonen sind doch auch nicht wirklich besser.

Normale Flächen, deren Kanten übereinander liegen finde ich noch viel schwieriger zu bearbeiten. Wenn ich ersteinmal bei den Kanten rumprobieren muss damit ich die Fläche ausgewählt bekomm, nur um ein Tag abzuändern, da hab ich schon deutlich schneller die Relation rausgesucht und das Tag schnell abgeändert.
Wenn man zwischen Flächen (und Wegen) Platz lässt, gibt das sehr häufig die Realität nicht gut wieder, und ist mit der Verschieberrei auch nicht umbedingt unproblematisch zu bearbeiten.

Das ganze ist ein Grundsätzliches Problem. In den Editoren lassen sich Flächen nicht wirklich gut bearbeiten (nur genauso wie Linien) und die zugrundeliegenden Datenstrukturen sind auch nicht ganz unproblematisch (geschlossener Weg, Multipolygon)

Die Diskussion hier erweckt bei mir eher den Eindruck eines Glaubenskrieges statt einer sachlichen Diskussion:

  • Die Meinung Andersdenkender wird nicht akzeptiert.

  • Persönliche statt sachliche Äusserungen:
    [list=*]

  • “Unterlass bitte solch unsinnige und absurde Behauptungen.”

  • “Vielleicht werden dort auch Multipolygone von dieser Person bewußt verwendet, um Änderungen von nicht versierten OSMlern`zu verhindern.”

[/*] [/list]

In dieser Situation halte ich es für dreist, unverschämt und einen Affront gegen Andere, das Wiki ohne vorherige Abstimmung zu ändern. Dies insbesonders wenn Änderungen

  • grammatikalisch inkorrekt sind: “don’t works”

  • inhaltlich schlechter oder falsch sind: “However, this model don’t works for very huge areas, and which have holes.”

  • persönliche Ansichten darstellen: “Please take the examples … with care!”

Ich habe mir deshalb erlaubt, die Änderungen zu revertieren.

Nee, Relation 2015472. Da kann man die Hausnummer ändern. Die Relation 2015473 ist nur der nordwestliche Trakt des Gebäudes.

Ich sehe da mehr das Problem “Detailmapping”. Beim Detailmapping kommt es immer zu Aufspaltungen. Straßen werden gesplittet, weil Geschwindigkeitbegrenzungen eingetragen werden und hier wurde ein Gebäude gesplittet, weil Geschosshöhen eingetragen wurden. Ich würde sowas nicht machen … aber mich interessieren Geschosshöhen ja auch nicht. Ich denke, damit muss man leben.

Weide

Hallo!
Ich bin einer dieser Mapper, die Landuse-Flächen grundsätzlich nur noch als Multipolygon erfassen, und bin ehrlich gesagt etwas erschreckt darüber, wie hier auf uns eingedroschen wird.
Ich muss vorweg sagen, dass ich in einer Gegend mappe, wo es auf 100 km² vielleicht 2-3 aktive Mapper gibt. Hin und wieder zieht mal einer durch, der ein paar POIs oder Wege hinterlässt, manchmal bleibt jemand auch mal ein paar Monate, aber ansonsten konzentriert sich eben alles auf einige wenige Mapper. Da versucht man natürlich, so effizient wie möglich zu arbeiten, denn es gibt so viel zu tun, dass jede Mannstunde sinnvoll investiert sein will, vor allem so lange die Grunddaten (Wegenetz, Landnutzung) nicht vollständig erfasst sind.
Ich empfand es immer als Krampf, wenn Wegenetz und Landnutzung mit getrennten Linien erfasst waren, und man dann den schlecht erfassten Wegverlauf (3 Knickpunkte pro km Weglänge oder so) detaillierter erfassen wollte. Statt einer Linie durfte man dann derer 3 bearbeiten. Bei gestapelten Linien war immerhin die Geometriekorrektur einfacher, aber da nervte es dann, dass es schwierig war im Editor die richtige Linie auszuwählen (was aber bei nebeneinanderliegenden Linien je nach Abstand und Zoomstufe genau das gleiche ist).
Ein Nachbarmapper fing vor einiger Zeit an, neue Flächen als Multipolygon zu mappen und dabei vorhandene Linien (Wege, Bäche etc.) als Begrenzung zu nutzen. Ich war begeistert, dass es nun in OSM möglich war auf eine derart elegante Weise Flächen zu erzeugen, und ich möchte diese Möglichkeit nicht mehr missen. Geometriekorrekturen, das nachträgliche Einfügen von Details, Vergrößern und Verkleinern von Landnutzungsflächen, all das geht in den Bereichen, die schon als MP gemappt sind, wesentlich schneller und einfacher von der Hand.
Ich versuche, zumindest für meine Heimatgemarkung, auch die Flurnamen flächenhaft zu erfassen. Zuerst hatte ich die Namen direkt an den Landuse-Flächen, was ich aber ziemlich schnell wieder aufgeben musste, da Landuse und Flurnamen selten deckungsgleich waren. Danach probierte ich es mit site-Relationen. Dabei störte mich aber immer die fehlende optische Kontrollmöglichkeit. Mittlerweile erfasse ich sie ebenfalls als Multipolygone und bin froh über die einfache Editiermöglichkeit, da ich doch oft etwas ändere, wenn ein Gespräch mit einem älteren Mitbürger mal wieder neue Erkenntnisse gebracht hat. Vorher hätte das nämlich bedeutet, dass ich zunächst die Landuse-Flächen hätte neu zuschneiden und dann noch die Mitglieder der site-Relation hätte ändern müssen - mühsam!
Gerade in den Waldgebieten ziehe ich oft die Luftbilder von Bing heran um die Grenzen zwischen Laub-, Nadel- und Mischwald zu kartieren, weil das vor Ort ja meistens eher schwierig ist. Leider sind die Luftbilder im hiesigen Bereich mindestens 8 Jahre alt und deshalb würde ich gern kennzeichnen, welche Daten aus Bing stammen und welche vor Ort aufgenommen wurden. Bisher habe ich das immer über ein source-Tag an den Flächen resp. Multipolygonen gemacht. Das empfinde ich mittlerweile aber als unbefriedigend, da es viele Flächen gibt, die ich teilweise per GPS und teilweise mit Bing erfasst habe. Ich möchte in Zukunft also die entsprechenden Begrenzungslinien der Fläche mit dem source-Tag kennzeichnen und spätestens an dem Punkt komme ich gar nicht mehr um Multipolygone herum.
Dass durch die Nutzung der Wege als Landuse-Geometrien diese Wege zerstückelt werden ist klar. Aber das passiert durch Brücken, Route-Relationen, Ver- und Gebotsstrecken, detailliertes Fahrspur- oder Feldweg-Beschaffenheits-Mapping usw. usf. genauso und je detaillierter der Datenbestand wird, desto häufiger werden auch die Wege aufgetrennt.
Meiner Meinung nach sollte es für Wege ebenfalls eine Möglichkeit geben, diese als Relationen zu erfassen. D. h. anstatt an jedes Teilstück alle Tags dranpappen zu müssen, erzeuge ich nur noch eine Linien-Relation für highway=primary, ref=B 1 und ordne dieser alle (zusammenhängenden) Linien zu, auf die diese Attribute zutreffen.
Ich möchte das ganze noch etwas ketzerischer formulieren: Ich fände eine komplette Trennung zwischen Karteninhalt und Kartengrafik gut. Als Vorbild denke ich da an HTML und CSS. Ich stelle mir das so vor: Auf der einen Seite wird eine Kartengrafik aus Punkten und Linien erzeugt. Auf der anderen Seite erzeuge ich den Karteninhalt, der aus Attributen besteht. Jedem dieser Attribute weise ich einen oder mehrere Punkte bzw. Linien zu. Will ich also die Nummer einer Bundesstraße ändern, kann ich das an einer Stelle machen und muss mir nicht erst 527 Linien zusammensuchen (und übersehe dann doch wieder 3). Hat sich nur bei einem Teil der Bundesstraße die Nummer geändert, verschiebe ich halt die betroffenen Elemente zu einem neuen Attribut. Es wären auch neue geometrische Zusammenhänge möglich. Setze ich z. B. ein Attribut natural=tree und weise ihm drei Punkte zu, habe ich eine Baumgruppe erzeugt, die später im Renderer auch so behandelt werden kann (z. B. für Generalisierung).
Anstatt einer Geometrie Attribute zuzuweisen, würde man also Attributen eine Geometrie zuweisen. Ist das nun komplizierter oder weniger intuitiv als andersherum? In meinen Augen nicht, ich empfinde es sogar als logischer. Und effizienter zu bearbeiten wäre es allemal. Die Multipolygone sind ein erster Schritt in diese Richtung und ich würde eine weitere Entwicklung dorthingehend durchaus begrüßen.
Ich hoffe, ich habe mich einigermaßen verständlich ausgedrückt.

Waldgraf

Moins,

Und du bist nicht alleine.

Ich hab die kompletten Allgäuer Alpen auf diese Wesie bearbeitet, von einer weißen Ödnis bis zur vollständigen Erfassung.

Ich kann es nicht besser ausdrücken. Danke.

Bei den Wasserläufen (zumindest in AT) entwickelt sich das gerade.

100% Zustimmung.

Die konsequente Trennung zwischen Geometrie und Semantik/Features ist bei unserer professionellen Konkurrenz seit mehr als einem Jahrzehnt Standard.

Oder aus einem Punktfeature “Gasthaus” wird ein Flächenfeature “Gasthaus” und dann ein Flächenfeature, das auch den Biergarten auf der anderen Straßenseite umfasst. Ohne dass ich Adresse und Namen des Objektes umhängen müsste auf ein andere Objekt. Das Feature behält seine id unabhängig von Änderungen andere Geometrie.

Andererseits kann man einem Geometrieobjekt auch mehrere Features zuordnen - damit sind mehrere Läden in einem Gebäude trivial darzustellen.

Ich schließe mich auch hier zu 100% an.

(Wenn ich mich auch als Memverbreiter in Sachen Google sehen würde, würde ich hier ein “+1” hinsetzen.)

Du hast. Danke nochmal. Wobei ich nicht glaube, dass es etwas nützen wird :frowning:

Gruß Wolf

In der Gegend: http://www.openstreetmap.org/?lat=52.4307&lon=13.5346&zoom=14

Weiß nicht, ob man das noch als Normal betrachten kann, eher irrsinnig, IMHO.

@Netzwolf und Waldgraf: Eure Ausführungen klingen natürlich sehr gut und sind vermutlich auch der einzige Weg aus dem zunehmenden Datenwust (es wird ja nicht weniger). Dem steht aber entgegen, dass die meisten Mapper (mich eingeschlossen) keine Profis sind. Die meisten haben wohl -wie auch ich- mit Potlach angefangen und sind dann, falls sie nicht schon vorher das Handtuch geschmissen haben, eventuell irgendwann zu JOSM gewechselt, weil sie gemerkt haben, dass da -nach einer gewissen Einarbeitungszeit- vieles einfacher zu bearbeiten ist. Mit anderen Worten, ich müßte mich mal intensiv mit der Bearbeitung von Multipolygonen mittels JOSM beschäftigen, so wie man es bei html mit CSS auch machen müßte, um damit etwas auf die Beine stellen zu können?!?! :expressionless: Das hättet Ihr aber auch gleich klarer sagen können! Ob das die meisten Hobby-Mapper auch tun werden, ich meine “intensiv mit der MP-Materie befassen” ?

Genauso bei mir: Angefangen mit Potlatch (YAPIS gab es ja noch nicht) und dann nicht “irgendwann”, sondern nach einer Woche gemerkt, daß es das nicht gewesen sein kann.

Du hast es gemerkt! Wenn du aber mental aus “Bearbeitung von Multipolygonen” “Bearbeitung von Relationen” machst, bist du auf dem richtigen Weg. Relationen sind für viele andere Sachen in OSM wichtig: Routen, ÖPNV, Buildings mit Löchern, Landuse, Sites, Wasserwege und was es sonst noch so gibt.

Ich hoffe es, muss aber genauso wie Netzwolf ein wenig zweifeln.

@waldgraf: 100% Zustimmung zu deinem Artikel. Nur strukturiere den bitte ein wenig durch einige Absätze; diesen monolitischen Textblock habe ich glatt übersprungen (tl;dr) Erst die Antwort von Netzwolf hat mir die Augen geöffnet.

Gruss
Walter

@Waldgraf:

Danke! Meine Gründe, Flächen nur noch als MPs zu mappen waren ähnlich.

Kurze Texte sind nicht meine Stärke, ich hatte das ganze schon auf die Hälfte gekürzt. Aber ich gelobe Besserung für das nächste Mal.

Es werden nicht Pfade und Wege als Begrenzungen der Polygone verwendet, sondern Geometrien. Da es bisher keine Möglichkeit gibt, einen Weg, Pfad, Bach etc. als Relation zu erfassen, muss ich die Tags umständlich an jedes einzelne Geometriestück hängen. Im Endeffekt ist seitdem aber sowohl das Bearbeiten der Wege als auch der Flächen einfacher geworden, weil ich mich nicht mehr mit Linienbündeln bzw. gestapelten Linien herumschlagen muss.

Ich finde es hingegen komplizierter zu bearbeiten, wenn die Linien nicht gestapelt sind, sondern nebeneinanderliegen. Vor allem wenn der Mapper, der das erzeugt hat, die Linien in 10 cm Abstand zueinander gezeichnet hat, ist es oft zum Verzweifeln.

Wie bereits gesagt, das mit dem Mit-Nutzen von “Wegen” kann man auch durchaus anders interpretieren. Und ich glaube, du unterschätzt die Mapper.

Potlatch war doch schon immer eher der Editor für das Grobe, oder? Kann man da mittlerweile weiter als Stufe 18 zoomen? Entschuldige die dummen Fragen, aber ich habe Potlatch seit 2008 nicht mehr benutzt, weil ich das Programm als viel zu eingeschränkt und träge empfand.

Das ist aber wohl ein generelles Problem an OSM. Wenn eine Gegend einigermaßen vollständig erfasst aussieht, hat doch kaum ein neuer Mapper mehr die Motivation, dort noch etwas beizutragen. Je umfangreicher die Datenbank wird, desto weniger wird es für Gelegenheitsmapper zu tun geben. Die einen werden dann gehen, die anderen sich umso mehr in die Materie einarbeiten.

Das ist hier in der Gegend aber wirklich nicht das Problem. Es gibt noch genug weiße Flecken, die neue Mapper anlocken könnten, einzig die Mapper bleiben aus. Und so lange hier nur ein paar Einzelkämpfer arbeiten, sollte es diesen doch auch erlaubt sein, so effektiv wie möglich zu arbeiten.

Einen Satz aus einem älteren Posting von Dir möchte ich aber noch aufgreifen:

“Unnötig kompliziertes Konstrukt” ist Deine Meinung, ok. Für mich ist es das genaue Gegenteil. Einen anderen Kartierstil als den eigenen als Problem zu bezeichnen schießt aber schon arg über das Ziel hinaus.

Gruß,
Waldgraf

Andere Meinungen nicht zu aktzeptieren oder gar abzuwerten, wie hier schon mehrfach geschehen, nenne ich schlichtweg intolerant. Wie sagte doch ein kluger Kopf so schön, natürlich nach meiner persönlichen Ansicht:

Es ist ein Traum, den ich auch mal hatte. In jeder Gemeinschaft, egal ob ehrenamtliche Organisation oder profitorientiertes Unternehmen habe ich immer höchst unterschiedliche Personen, mit verschiedenen Fähigkeiten und Erfahrungen, kennen gelernt. Das Motto “Jeder kann alles und macht alles auch wenn er ganz neu im Geschäft ist” habe ich nirgends realisiert gesehen. Es gab immer “alte Hasen” und “Spezialisten” für das eine oder andere, nach den Mottoes

  • Der Neue kriegt erst mal eine einfache Aufgabe.

  • Die richtige Person am richtigen Platz.

Es freut mich wieder mehr sachliche Beiträge zu sehen. ganz besonders und persönlich freut mich, dass die Beitragenden Multipolygone einsetzen und zwar nicht um ihrer selbst willen sondern ganz bewusst wenn sie diese für geeignet oder geeigneter halten. Natürlich fällt die Entscheidung nach ihrer ganz persönlichen Meinung, denn einen Konsens gibt es nicht und wird es meines Erachtens auch nie geben. Denn:

  • Die zu kartierenden Objekte sind höchst unterschiedlich.

  • Wenn zwei das Gleiche betrachten sehen sie oft erstaunlich verschiedene Dinge.

  • Jeder wählt selbst was er kartiert.

  • Fähigkeiten, Kenntnisse und Erfahrungen sind verschieden.
    Zum Beispiel sind Multipolygone für manche ein Buch mit sieben Siegeln, manche haben nur einen Teil davon verstanden, für andere sind sie eine Selbstverständlichkeit und sie haben schon hunderte erstellt.

In dieser Situation kommt man meines Erachtens nur mit Toleranz weiter und hierdurch ist OSM erst zu dem geworden was es ist. Z.B.:
  • Jeder aktzeptiert die Methoden der Anderen.

  • Wenn man etwas nicht versteht oder für falsch hält kommuniziert man zunächst direkt mit der Person, die es eingetragen hat.

  • In gut kartierten Bereichen ist zu überlegen, ob man nicht besser flexibel ist und sich an die dominierenden Methoden anpasst.

Nicht hilfreich ist zu versuchen, seine Meinung durchzudrücken und schon gar nicht trotz Widerstand eine Wiki-Seite zur Abschaffung einer der wesentlichen Eigenschaften von Multipolygonen zu "kapern".

Völlig unbeanstandet und von Vielen so verstanden und benutzt steht dort seit Jahren, dass ein Multipolygon aus mehreren Wegen bestehen kann. Ja, dass dies notwendig ist und deshalb Multipolygone geschaffen und so konzipiert wurden, dass Wege mit unterschiedlichen Eigenschaften eine Fläche begrenzen können. Dies kommt häufig vor. Zum Beispiel ein Einzelgrundstück, das teils von Mauer, teils von Zaun begrenzt ist. Vort Ort ist kein zusätzliches Objekt zu finden, das das ganze Grundstück umgibt. Oder zwei Grundstücke, die eine gemeinsame Mauer haben. Oder Grenzsteine, in der Wirklichkeit sind sie nur einfach vorhanden, nicht eins für jedes angrenzende Grundstück. In der OSM Datenbank sind nicht nur doppelte Grenzlinien sondern auch doppelte “Grenzpunkte” zu finden, die meist leicht verschoben sind, so dass sie nicht beanstandet werden. Ich erinnere mich, dass hier im Forum mal gefragt wurde, was ein sinnvoller Wert für solch einen künstlichen, in der Wirklichkeit nicht vorhandenen Abstand, ist.

Willi

Als Informatiker kann ich verstehen, daß ein solches abstrakteres Datenmodell durchaus seine Vorteile hat. Für Informatiker und Datenbankenorganisation.

Als Mapper, der auch schon eine ganze Menge von Leute zum Mappen verleitet hat, empfinde ich es aber als schädlich.

  • Die API und die Datenstruktur von OSM sehen keine solche Trennung vor, das Multipolygon ist nur ein Workaround, der Versuch es mit Mitteln für ganz andere Zwecke irgendwie abzubilden. Das macht es so unhandlich und unverständlich. Um Deinem Ansatz ernsthaft zu folgen bräuchte man ein entsprechende Struktur in der API und konsequente Unterstützung dafür.

  • leider besteht die Mehrheit der Mapper nicht aus Informatikern oder Technikfreunden, die viel Zeit investiert haben. Mit solchen komplexen Strukturen, wo auch einfache möglich sind, grenzt Du die Mehrheit der Mapper aus. Es haben sich schon genug Leute dementsprechend hier zu Wort gemeldet - aber denk dran: Die Mehrheit der Mapper ist nicht in Foren oder MLs vertreten, um sich zu Wort zu melden. Die stellt einfach frustriert fest, daß sie das komplexe Ding nicht verstehen und tragen halt nix ein. Oder gehen ganz.

Ich glaube da liegst Du völlig falsch. Ich fürchte Du bildest Deine eigenen, sehr hohen Anforderungen auf alle Mapper ab. Hast die Posts in diesem Thread gelesen und berücksichtigt, in denen genau solche Probleme klipp und klar aus erster Hand bestätigt werden? Du weil es für Dich einfach und verständlich ist muß es nicht für alle anderen einfach und verständlich sein.

Ansonsten würde ich Dich ernsthaft bitten: Geh zum nächstgelegenen OSM-Stammtisch. Such Dir ein paar Neulinge oder Gelegenheitsmapper ohne technischen Hintergrund, die noch nie freiwillig ein Programm geschrieben und ihren Rechner nicht selbst installiert haben. Dann unterhalte Dich mit ihnen wie sie mit dem Mappen zurechtkommen, was sie als einfach empfinden und was als kompliziert. Nur dann hast Du einen sinnvollen Eindruck von den Verhältnissen. Und dann erkläre ihnen, wie Deine Multipolygone aussehen, wie man eine Änderung dort einpflegen muß und versuche mal, dasmit Potlatch durchzuführen.

Potlatch ist der Standardeditor, der jedem Mapper sofort auf der OSM-Hauptseite angeboten wird und ohne Installation zur Verfügung steht. Außerdem ist er mit seinem Simple-Mode besonders Anfängerfreundlich. Damit dürfte er auch von der großen Mehrheit der Mapper genutzt werden - egal was für ausgebuffte Werkzeuge sich die Experten geschrieben haben.

Nimm Dir mal Potlatch, schau Dir Deine Multipolygone damit an und versuch mal damit was zu ändern. So sehen sie für die meisten Mapper aus - nur daß Du noch weißt was eigentlich gemeint wäre und Dir die Relationen von Hand zusammensuchen kannst. Die meisten Leute haben diesen Hintergrund nicht. Erwartest Du ernsthaft, daß sie damit klar kommen?

Vielleicht müssen wir erst noch die Grundsatzfrage klären: Soll OSM ein offenes Projekt sein, an dem möglichst viele Leute sich beteiligen sollen? (So wird es zumindest häufig verkauft)

Oder soll es eine hochkomplizierte Spielwiese für eine Handvoll Experten sein, von der nicht-Techniker durche eine enorme Lernkurve faktisch ausgegrenzt sind?

In meinen Augen widersprichst Du Dir selber. Auf der einen Seite beklagst Du daß neue Mapper ausbleiben - auf der anderen Seite schaffst Du mit Deinen “effizienten” Strukturen selbst schon die Voraussetzung dafür, daß neue Mapper sofort abgeschreckt werden und schnell wieder gehen.

Das würde nur dann gelten, wenn die beiden Kartierstile gleichberechtig nebeneinander stehen können. Leider ist es aber so, daß der komplexe Kartierstil alle Anderen ausgrenzt.

Wenn es zwei Stile gibt, dieselbe Sache auszudrücken: Sollte man dann sinnvollerweise den verwenden, der nur von vielleicht 50 Powermappern verstanden wird. Oder besser den, der von 50000 Mappern verstanden wird?

bye
Nop

Auch durch ständige Wiederholung werden Behauptungen nicht wahr. Wie wäre es mal mit Indizien, es müssen ja nicht unbedingt Beweise sein.

Ansonsten wundere ich mich immer wieder mit welchem Recht hier so manche für Andere sprechen und glauben Andere belehren zu können oder vielleicht gar zu müssen und warum es in diesen Beiträgen anscheinend vorwiegend die Personen sind, die Probleme mit Multipolygonen haben. Intolerantes, oberlehrerhaftes Verhalten kann auch Leute vertreiben. Aber vielleicht ist der “master” im gewählten Spitznamen entsprechend wie bei “schoolmaster” Programm.

Es ist durchaus auch in meinem Sinn, was Nop da schreibt.
Die IMHO übertriebene Anwendung von MP-Relationen (siehe Post #70), was zwar nicht falsch ist, schreckt viele ab. Da wird z.B. gesagt, man soll sich sich an anderem Mapping orientieren. Wenn man dann auf sowas stößt ‘Gute Nacht’.
Vorschlag: Macht aus OpenStreetMap ein ClosedStreetMap für die eingefleischten Spezialisten.

Intoleranter und oberlehrerhafter ist IMHO das vehemente Ablehnen von bindenden Regeln.
Da verweise ich nur auf das unterschiedliche Mappen von Flächen.

Und durch standhaftes Leugnen werden sie nicht unwahr. Vor allem nicht wenn sich hier im Topic schon einige Leute konkret geäußert haben, daß es sie abschreckt.

Wo sind Deine Indizien dafür, daß das alles kein Problem ist?

bye
Nop

Ich hab mir das Beispiel angesehen. Zwar kann ich nicht beurteilen ob es korrekt ist, da ich noch nie dort war. Aber ich habe den Eindruck, da wurde eine sehr komplexe Situation sauber und strukturiert mit Multipolygonen dargestellt. Maperitive zeichnet das Gebiet auf meinem Netbook in weniger als einer Minute. Wo liegt das Problem? Gibt es denn auch ein ähnlich komplexes Beispiel, das ohne Multipolygone dargestellt wurde? Wen schreckt das denn ab? Es werden immer wieder Andere genannt, die sich jedoch nicht melden.

Zu den vehementen Ablehnern von verbindlichen Regeln gehöre ich sicherlich nicht. Wenn jemand dies jedoch tut, warum ist er dann intolerant? Für mich ist jemand intolerant, der die Meinung Anderer nicht akzeptiert. Eine eigene Meinung darf er jedoch durchaus haben, ansonsten wäre das ja intolerant.

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.

Willi

Irgendwelche Hecken als Multipolygon zu erfassen und dafür die B251 zu atomisieren
finde ich schon recht krass.
http://www.openstreetmap.org/browse/way/110818834

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.

http://www.openstreetmap.org/browse/node/1462767392
http://www.openstreetmap.org/browse/way/59159280
http://www.openstreetmap.org/browse/node/977782807
http://www.openstreetmap.org/browse/way/30053578
http://www.openstreetmap.org/browse/way/29408608
http://www.openstreetmap.org/browse/way/30681545