– Mehr als ein Outer? Ja dann zum Teufel teil das Multipolygon doch einfach in mehrere auf. Und zwar nicht in der Datenbank, sondern in einem Schritt im Renderprozess. Das ist nun wirklich trivial.
– Löcher? Ja. So ist die Realität. Die Welt ist schlecht™: da gibts Löcher. Wenn ein Renderer nicht mit Löchern umgehen kann, ist er defekt und sollte gefixt werden. Selbst das dämliche SVG kann Löcher. Und wenn die Renderengine auf dem letztendlichen Client nicht mit Löchern zurechtkommt und auch nicht gefixt werden kann oder soll (warum auch immer), so ist es ein leichtes, ein Polygon mit Löchern in mehrere Polygone ohne Löcher zu zerschneiden. Nur muss man dann den Rand getrennt zeichnen, weil beim Aufteilen (natürlich) künstliche Ränder eingeführt werden.
Unsmarte Smartfones und defekte Renderer sind kein Grund, in der Datenbank rumzusauen.
So weit ich verstanden habe, besteht das Problem nicht daran, dass es sich um mehrere, separate Gebiete handelt, die von jeweils einem geschlossenen Way umgeben sind. Stattdessen handelt es sich um ein zusammenhängendes Gebiet, das nicht von einem geschlossenen Way umgeben ist, sondern dessen äußere Begrenzung aus mehreren offenen Wegen besteht, die alle als Outer im Multipolygon stecken. Das ist weniger trivial zu lösen als durch ein “Aufteilen in mehrere Polygone”.
Vielleicht wäre es einfacher, bei der Kartengenerierung für Navit die Multipolygone in Polygone umzurechnen und ein forest dran zu pappen. Dann müsste navit nicht aufwendig umprogrammiert werden.
Ob sich bei dem Programm Navit selbst so schnell was ändert? Scheint nicht so einfach zu sein, da was umzustricken. Ist ja schon sehr umfangreich.
Naja, wenn man “bei Navit” etwas an diesem Problem ändert, dann tun man das auf jeden Fall nicht am Programm navit selbst, sondern an maptool. Das ist das (zu Navit gehörige und mit Navit zusammen entwickelte) Programm, dass OSM-Daten in das Navit-interne binfile-Format umwandelt. Da muss man auch für die Multipolygone ansetzen.
Ich werde die Entwickler mal darauf ansprechen, ob man da was machen kann.
@efred: Wie erstellst du denn deine Navit-Maps? Mit einem gepatchten maptool? Falls ja, könntest du den Patch zur Verfügung stellen, damit er vielleicht in die aktuelle maptool-Version übernommen wird und künftig auch andere Navit-Karten das Multipolygon-Problem los sind?
Also darf ich mich mal als Auslöser diesen Forum-Threads outen.
Zunächst möchte ich mich entschuldigen, dass ich hier entsprechende Aufwände verursacht habe. Meine Motive waren rein produktiver Natur.
Wie schon oben besprochen habe ich in Navit entsprechende Darstellungslücken von Wäldern festgestellt, die auch in der Potlach-Anzeige feststellbar waren.
Die “Grenzlinien” der Wälder waren komplett ohne “tag” (unter Ansicht Advanced kontrolliert), damit hatte es für mich den Anschein das die Linien, nicht genutzt wurden und entsprechend noch zu “taggen” sind
→ Diese Linen verband ich zu Polygonen mit Grenzen zu Autobahnen, Landstraßen u.s.w. Damit hatte ich unter Potlach auch entsprechende Erfolge zu verzeichnen. (Wälder wurden sichtbar)
Was kann man tun, das ein “über-” motivierter OSM-Nutzer (wie ich) sein fehlerhaftes Treiben beendet?
Die Anmeldung des OSM-Nutzers sperren für Uploads von geänderter Daten mit (wichtig!) entsprechender aussagekräftiger Meldung (z.B. “Ihr Konto wurde wegen fehlerhafter Daten für OSM uploads gesperrt, bitte sehen Sie in Ihrem Postfach nach”) Ein Notfallsperrbutton könnte jedem Nutzer zur Verfügung stehen, um die Änderung eines Anderen zu verhindern, bis die Sachlage geklärt ist. Der “Admin” darf wieder freigeben.
Generelle Sperrung von “großflächige” Änderungen. Erst bei entsprechender Qualifikation des OSM-Nutzers sind diese erlaubt.
…und… Freigabe großflächiger Änderungen erst nach einem Review.
Wie schon gesagt, möchte ich mich nochmals entschuldigen. …Und! … gelernt habe ich auch was dabei.
Danke an alle Beteiligten, die meine Fehleingaben korrigierten.
Nachtrag:
Also solche Waldkonstrukte wie in Nürnberg sind schwierig zu editieren. Wenn man sich die Relationen anschaut, und die teilweise über 20km Ausbreitung haben, so wird das doch etwas unübersichtlich.
Ja, ich erstelle die Maps mit einem gepatchten maptool. Wenn ich die nodes >2^31 auch drin habe, kann ich dann gerne den Patch zur Verfügung stellen. Aber bis jetzt nutze ich noch eine relativ alte Version von Maptool, da ich zu faul war meinen Patch ständig auf eine neue maptool-version anzupassen… Ich weiss jetzt nur noch nicht, ob ich nur meinen patch für maptool zusätzlich auf nodes >2^31 ergänzen will, oder ob ich gleich eine neue maptool-version nehmen will und den MP-patch entsprechend anpassen will (was natürlich einiges mehr Arbeit macht). Mal schauen. Ich hoffe, ich komme dieses Wochenende dazu (ich habe zwar noch 2 Termine dieses Wochende und F1 fängt auch endlich wieder an, aber ich denke, ich sollte dennoch Zeit finden).
erst einmal herzlich willkommen im Forum - gilt auch für sog. “Problemfälle”
Zum Sperren problematischer User haben wir schon Mechanismen, allerdings ist die nur Admins möglich. Daher der Ruf nach der DWG - Data Working Group.
Die können einen User quasi zwingen, sein Postfach zu lesen und danach wird er automatisch wieder zugelassen. Nächste Stufe ist Sperrung für 24H und als letztes Totalsperre.
Allerdings gib es zumindest einen User, der sich einfach neu registriert und dann lustig weitermacht. Bei uns als “Schleswiger” bekannt, da er sich da rumtreibt.
Ich hatte das Problem / den Threadtitel so verstanden, dass Than noch immer fleißig dabei war, unabsichtlich Datenprobleme zu verursachen und die Frage darin bestand, ihn aufzuhalten, bevor dabei noch mehr kaputt geht, das man reverten oder in aufwändiger Kleinarbeit reparieren muss. In so einem Fall ist ein schnelles Handeln / Bremsen / Aufhalten des Neulings natürlich durchaus sinnvoll. Das bedeutet ja nicht, dass man ihm böse Absichten unterstellen würde, sondern nur, dass man schlimmeres verhindert.
Als ich die Änderungen durchführte, habe ich schon gemerkt, das meine Änderungen während der Arbeiten verloren waren.
Aber das bezog ich auf vermeintliche Fehler durch mich… (Toll… alle Wälder waren in Potlach jetzt sichtbar … upps wieso sind die wieder weg !!!) und wollte den Zustand nicht so zurücklassen…also alles nochmal . Damit habe ich natürlich unabsichtlich die Korrekturen torpediert .
Wenn ein “Stop-Schild” oder Ähnliches angezeigt worden wäre (Zugangssperre mit Mitteilung…) hätte ich mittags meine OSM-Tätigkeiten beendet und wäre raus an die frische Luft gegangen. Insofern wäre ein “Stop-Button” durchaus im Sinne eines “OSM-Vandalen”
Das sehe ich auch so. Ich habe mir als Beispiel das MP 1467782 angesehen: da werden zwei Waldflächen zu einem Objekt zusammengefasst, ohne dass das irgendeinen Zweck erfüllen würde.
Ich vertrete nicht die Ansicht, dass man große MPs aufspalten sollte – aber man sollte nicht grundlos Dinge zusammenfassen.
Teilweise sind ja schon zu zu Landsat-Zeiten großräumig Wälder abgemalt worden, und damals haben 40 Nodes für 10x15 km ausgereicht. Mit den immer besseren Bing-Bildern werden diese Wälder jetzt unhandlich. Das Teilen solcher Monster ist dann hohe Kunst.
Kann man nicht einfach die max. Punktezahl pro Linienzug aufheben oder auf 100.000 setzen? Ein MP, nur damit man über 2000 Punkte kommt, ist doch reichlich umständlich und sollte nicht der Grund für ein MP sein.
Einfach geht das sicher nicht, da sich zu viele Programme gerade im Kernbereich von OSM auf diese Randbedingung eingestellt haben. Aber selbst wenn, würde es das eigentliche Problem, dass riesige Objekte beim Editieren äußerst unhandlich sind, wirklich lösen? Ich denke nicht. Multipolygone mit mehreren Outer-ways machen die Sache vielleicht noch ein wenig schlechter zu durchschauen, aber die Unhandlichkeit sehr großer Objekte bleibt wie auch immer bestehen.
Das Teilen der Wälder hatte ich schon einmal vorgeschlagen: entlang von Straßen, Wasserläufen, Eisenbahnlinien. Es gibt ja auch Forstreviere, Grenzen, … an denen eine Teilungslinie entlang führen kann.
Und was spricht dagegen: (Experten können) diese einzelnen forest zu einer MP-Relation “Osterzgebirge” zusammen zu fassen und diese in eine Super-Relation “Erzgebirge” zu integrieren (ähnlich Wanderwege).
Vorteil: Ein (Nichtexperte-) Mapper zerstört nicht eine Relation, wenn er ein landuse aufteilt / trennt.
Mit Potlatch ist bei so großen Multipolygonen in der Tat kein Blumentopf zu gewinnen. Wenn du keine Angst vor anspruchsvolleren Tools hast, solltest du mal JOSM probieren. Mithilfe des Plugins “mirrored Download” kannst du sogar nur ausgewählte Daten (wie z.B. natural=*) herunterladen und bearbeiten.
Netter Nebeneffekt: auch Wälder, die “nur” am Multipolygon getaggt sind, werden in JOSM als Wald dargestellt.
@ geri-oc: Ich dachte, dass das immer “Keep It Simple, Stupid!” heißt
Heißt der Wald bzw. wirklich nur der Wald “Osterzgebirge”? Ich halte das eher für eine Region zu der auch Orte, Felder etc. gehören. Sprich: ein MP mit allen Wälder und dem Namen macht aus meiner Sicht keinen Sinn.
Es sollte als Beispiel dienen - das mehrere kleinere Landflächen entsprechend dem “ursprünglichen Riesen-MP aus einzelnen ways” ebenso zusammengefasst werden können.
Gemeint war wohl ich, nicht Geri. Etwas irritiert habe ich es nachgegugelt: Es gibt beides. Und es bedeutet das gleiche. “Keep It Simple, Stupid!” erzeugt aber das zugegebernmaßen hübschere Akronym “KISS”.
. Damit habe ich natürlich unabsichtlich die Korrekturen torpediert 
.
