Ich glaube ajoessen verwechselt das mit dem Ausschneiden mit osmosis - das sind Parameter von osmosis. Das wird aber hier gar nicht benutzt.
bye
Nop
Ja, meinte ich. Dann müsst ihr eurem Ausschneideprogramm das eben auch beibringen.
Gruß,
ajoessen
1+
walter
Sinnvoll wäre sowas. Allerdings nicht zum Rendern an sich, sondern um das Raten zu umgehen, welches WanMil angesprochen hat. Wenn das Objekt vollständig enthalten ist, dann muss man nicht mehr raten, wie es an der Kachelgrenze aussieht, sondern kann vereinfacht gesagt an der Kachelgrenze Einen schnitt machen.
Nuja…auf mkgmap-dev war das vor nicht allzu langer Zeit auch Thema und es gibt auch keine Klagen über schlechtes raten.
Was ich nicht so ganz verstehe: Warum muss der Composer sich überhaupt um MP’s kümmern. Der müsste doch maximal schneiden und Tags ersetzen. Da macht es doch aber keinen Unterschied, ob es nun eine Relation oder ein geschlossener Weg ist.
Das ist nicht das Problem, die Daten sind vollständig vorhanden. Wie weiter oben schon beschrieben ist es das Problem, die Einzelteile von einem MP zusammenzusammeln ohne daß es saulangsam wird oder endlos Speicher braucht.
bye
Nop
Und wieviele Leute schreiben auf der Dev-Liste?
Ich weiß ja nicht wieviel Zeit andere damit verbringen über ihre eigene Karte zu scrollen, aber ich hab schon lange festgestellt, daß es völlig unmöglich ist, Fehler wie einen fehlenden Wald oder eine verhunzte Straße selbst zu finden - da ist man auf Benutzer angewiesen, die zufällig drüber stolpern und nachfragen. Und die diskutieren nicht auf einer Dev-Liste.
Tags zu ersetzen ist nicht so leicht wenn die am Way hängen oder an einer Relation oder beides oder an der Relation und am Way ganz andere Tags weil es eine eigenständige Straße ist. Das macht bei der Verarbeitung einen Riesenunterschied.
Zufällig ´drauf gestoßen:
Westlich von Ilmenau ist eigentlich Wald. 
Das MP 1558626 unterhalb der A71 erscheint mir in diesem Fall aber in Ordnung zu sein. Und es ist auch nicht so kompliziert wie das im Eröffnungsbeitrag. Dafür wird der Weg 20911103 ohne MP nicht dargestellt. 
Und dann würde der in Torstens Screenshot sichtbare Effekt ausbleiben?
Solche Fehler fallen mir im Gegensatz zu früher immer wieder an Kachelgrenzen auf.
Gruß
tippeltappel
Genau auf diese Weise ist mir heute die Hainleite aufgefallen (Relation 17489). Da sind Tags an der Relation selber (name). Da gibt es Tags am einzigen outer-Way und da sind inner-Ways genauso markiert wie der outer-Way => Es sind also alle moeglichen MP-Varianten lustig miteinander gemischt (inklusive der inzwischen als veraltet akzeptierten, identischen inner- und outer-Tags). Kein Wunder, dass da mkgmap nicht weiter weiss.
Ich weiss uebrigens auch nicht, was da nun wirklich gemeint ist. Kann da mal jemand aufrauemen, der sich da ein bisschen auskennt?
Gruss
Torsten
Ich hab die Hainleite mal in Ordnung gebracht.
Im Harz tut sich einiges … 
Die MP-Relationen werden immer größer und damit fehleranfälliger: http://tools.geofabrik.de/osmi/?view=multipolygon&lon=10.75233&lat=51.72140&zoom=10&opacity=0.77&overlays=invalid_geometry_hull,duplicate_ways,intersections,intersection_lines,ring_not_closed_hull,ring_not_closed,unconnected_end_nodes,touching_inner_rings_hull,touching_inner_rings,role_mismatch_hull,role_mismatch,duplicate_tags_hull,duplicate_tags,multipolygons_type_is_boundary,type_is_boundary,ways,role_markers,way_end_nodes,way_nodes
Als Ergebnis werden die Wälder immer kleiner und die Bäume weniger:
Screenshot: Nop´s Garmin-RWK
Mittlerweile fehlt auch noch ein Stück Wald südwestlich von Wernigerode.
Frei nach dem Motto: “Siehst du den Wald nicht, fälle die Bäume um zu sehen, dass da gar kein Wald ist.”
Oder so ähnlich in einer Signatur hier im Forum gelesen.
Das kann doch nicht das Ziel sein …
Edit: falscher Permalink!
Hallo Torsten, gerade eben ist meine neue Karte fertig geworden. Alle Bäume sind noch da, wo OSM sie gerne hätte.
Das Problem liegt also weder in den Daten, noch im eigentlichen Konverter (mkgmap, aktuelle Version). Ebenso in Mapnik, Osmarender und der OpenCycleMap sind die Bäume da, wo sie sein sollen.
Sommer 2009 wurden die Multipolygone im Harz einheitlich gestaltet. Die Renderer, Tools und Mapper kamen seitdem klar. Die Nationalparkgrenze und anderes ließen sich flexibel und unabhängig von den Waldflächen erweitern. Einziges Manko war, dass man die hier genannten störenden optische Linien an Polygongrenzen in Kauf nehmen oder die Grenzen an Straßen entlangführen musste (heute wäre das Mapper für die Renderer, damals ging es technisch nicht anders).
Und dann wurde das ganze ab Anfang 2011 zum Teil umgestellt. Sonstige Kurvenzüge, wie Nationalpark- oder Kreisgrenzen dienen nun in Teilbereichen als Waldpolygongrenzen (auch mitten im Wald). Außenrandkonturen bestehen aus oft mehreren unterschiedlichsten Kurven (mal mehr, mal weniger sinnvoll):
- Weder alle Renderer, Tools noch viele Mapper kommen damit klar, wie wir hier im Thread sehen.
- Die Mapper, die damit klarkommen, haben nicht unbedingt die Zeit, solche Bugs zu fixen.
- Außerdem Landes- und Nationalparkgrenzen als Waldpolygongrenzen? Wenn links und rechts von einer Grenze der “gleiche” Wald ist, warum sollte man den dann dort unterteilen? Wäre das nicht auch Mappen für die Renderer? Man sieht die Grenzen zwischen den Waldpolygonen nur deshalb nicht, weil dort sonstige Grenze drauf “gemalt” wird. Aber was, wenn ein Renderer/Tool letztgenannte gar nicht darstellt/nutzt…
Ich sehe da irgendwie “wenig” Vorteile.
Daher bin ich etwas unschlüssig, wenn ich nun im gesamten Harz mal wieder etwas Ordnung reinbringen will. Nehme ich das “alte” Prinzip, das “neue” oder etwas gaaaaaanz anderes? Vorschläge?
Wichtigstes Prinzip: Keep it Simple!
Damit scheidet das “neue” Prinzip schon mal aus, sonst gaebe es die Diskussion hier jetzt ja gar nicht.
Der alte Zustand muss nateurlich nicht genau wieder hergestellt werden, aber die einzelnen Flaechen sollten am Ende weder zu kompliziert noch zu gross werden, beides erhoeht nur unnoetig den Bearbeitungsaufwand und damit die Fehleranfaelligkeit.
Gruss
Torsten
Es mag schon sein, dass die Daten »in Ordnung« sind, fehlerfrei sind sie aber trotzdem nicht. Das zeigt der OSM-I mit den Daten vom 2011-09-17 20:00 ja eindeutig: http://tools.geofabrik.de/osmi/?view=multipolygon&lon=10.75233&lat=51.72140&zoom=10&opacity=0.77&overlays=invalid_geometry_hull,duplicate_ways,intersections,intersection_lines,ring_not_closed_hull,ring_not_closed,unconnected_end_nodes,touching_inner_rings_hull,touching_inner_rings,role_mismatch_hull,role_mismatch,duplicate_tags_hull,duplicate_tags,multipolygons_type_is_boundary,type_is_boundary,ways,role_markers,way_end_nodes,way_nodes
Offensichtlich können einige Renderer damit leben und erzeugen eine inhaltlich richtige Karte. Andere können es leider nicht. Im Screenshot aus Beitrag #32 ist das gut erkennbar. In der Deutschlandkarte von computerteddy fehlen übrigens die gleichen Wälder.
Was ist daran verkehrt? Und wieso ist das »Mappen für den Renderer«?
Ein Wald hat an einer Straße, einer Schneise für Elektro-Freileitungen, einer Eisenbahntrasse, einem Kanal o. dgl. ein körperlich greifbares Ende, auch wenn es vielleicht nicht natürlich entstanden ist. Aber es ist da und man kann es „anfassen". Wir tragen also nur das in die Datenbank ein, was auch vorhanden ist. Aber diese Daten müssen so eingetragen werden, dass jeder damit arbeiten kann. Egal welchen Renderer er nutzt.
Dem kann ich nur zustimmen.
Wie wird das in anderen Waldgebieten gehandhabt? Da sind mir bisher noch nicht so viele fehlende Wälder/Waldpolygone aufgefallen.
Nur so eine Vermutung 
Kann es sein, dass die Probleme im Harz mit diesem MP zusammenhängen?
http://www.openstreetmap.org/browse/relation/253058
type=region und die ways haben alle keine role
Basis für das tagging scheint dieses Proposal zu sein:
http://wiki.openstreetmap.org/wiki/Relations/Proposed/Region
Meine Vermutung hängt auch mit den MP’s zusammen.
Die Daten sind komplett für den entsprechenden Bereich in meinem Ausschnitt (Alle Nodes Wayes und Relationen).
Wenn aber das MP Objekte enthält die komplett ausserhalb des Bereiches sind (Wahrscheinlich nur bei Superrelationen nee Relation…) wird die komplette Relation nicht verwendet obwohl die Daten ja da sind
Ähnlich Effekte hatte ich im Taunus und auch im Odenwald meist in den Randbereichen meines Bereiches - wenn der Bereich dort vergößert wurde auf einmal wieder alles gerendert!
Natürlich, dass soll/muss dann auch so sein. Ich meinte eher Methoden wie (als Extrembeispiel): die Grenze von zwei Waldpolygonen wird auf einen 1 m breiten Trampelpfad im Wald gelegt, damit der Renderer dann die Polygongrenze mit dem Pfad überdeckt. Das wäre Mappen für den/die Renderer.
Soweit das nicht in diesem Jahr massiv geändert wurde, sind die meisten Wälder einfach durch mehrere nebeneinanderliegende Polygone/Fläche umgesetzt. Die Polygone werden zumeist durch Straßen voneinander abgegrenzt, was ja zumeist auch der Realität entspricht (s.o.). Das nur rendertechnische Problem (von Mapnik), dass man an Grenzen zweier Waldpolygone kleine weiße Linien sieht, tritt daher nicht auf.
Letztendlich ist es nämlich nur dies, was einige am Harz in OSM stört. Dort sind Unterteilungen mitten im Wald aber kaum zu vermeiden, denn die zusammenhängenden Waldflächen waren zumindest früher für die Tools/Renderer zu groß, um jene nur an Straßen/Schneisen zu zerteilen. Und Forstwege/-straßen, die keine klare Schneise bilden, finde ich zur Unterteilung nicht so geeignet (siehe oben, Mappe für die Renderer).
Na ja, mal schauen, wie sich die Unterteilung jetzt optimieren lässt.
Gute Idee.
Aber an diesem MP liegt es vermutlich nicht, das gab es schon recht lange und es hat nie Probleme verursacht (gänzlich auszuschließen ist es aber nicht, denn das MP ist zur Zeit nicht i. O. Eine Reparatur lohnt sich aber erst, nachdem die Einzelbestandteile wieder ok sind.)