Ich habe mir vor einiger Zeit mit dem Composer eine Karte mit der Region Harz zusammengestellt und dabei festgestellt, dass da Teile des Waldes verloren gegangen sind. Am Anfang habe ich das ignoriert. Gestern Abend habe ich diese Region aktualisiert und festgestellt, dass auf dem Kartenausschnitt das Waldstück immer noch fehlt.
Mir geht´s insbesondere um das Stück zwischen den Orten Altenau im Norden, Braunlage im Osten und Herzberg am Harz im Südwesten. Eigentlich ist dort Wald. Und eigentlich ist dort auch der Nationalpark Harz. Aber was sieht man? Nichts dergleichen. Was mich stutzig macht, sind die merkwürdigen, über länger Strecken schnurgeraden Waldgrenzen. Dass der Nationalpark nicht schraffiert wird (so wie das NSG Wurmberg nördlich von Braunlage) ist ja noch i. O. und das habe ich im MapComposer schon öfter erlebt wenn ein äußerer Ring nicht geschlossen ist. Dass da aber kein Wald ist …
Nun habe ich mal versucht, die entsprechenden Linien zu finden. Das Multipolygon für den Nationalpark (90584) ist ja noch relativ einfach zu finden. Aber die Darstellung des Waldes erfolgt durch viele einzelne Stücke ohne Eigenschaften (z. B. region harz 253058, mp harz 93882).
Würde sich bitte mal jemand das Gebiet ansehen und evtl. reparieren? Ich kann es nicht und möchte da auch nichts kaputt machen.
Da sind aber laut JOSM MP Editor alle Outer und Inner schön geschlossen.
Das einzige was mir bei einer Schnellsichtung auffällt ist, das im outer 1 Weg eine andere Richtung hat (so interpretiere ich zumindest den JOSM MP Editor,
der bei http://www.openstreetmap.org/browse/way/99319315
eine andere Richtung als die anderen darstellt.
Hab aber noch nie gehört, das das ein Problem sein kann.
mich nicht - es ist halt so, dass manche Kollegen einfach eine fiktive Waldgrenze durch ein grosses Waldstück ziehen, weil ihnen sonst die Gegend zu unübersichtlich wird. Dann liegt “Wald an Wald”. Ich nene das “Taggen für den Mapper”.
Torsten, ich hab mal in meiner Karte geguckt, da ist der Wald und der Nationalpark vorhanden. Datenstand ist gestern 7:00. Daraus folgere ich, dass mkgmap als solches damit kein Problem hat, sondern dass das Problem weiter vorne angesiedelt sein muss. Es sei denn jemand hat zwischen deiner Aktualisierung und meiner etwas an den Daten geändert.
Hast du schonmal in der Garmin-Karte von Nop geschaut?
Evtl. könnte es auch eine sehr veraltete mkgmap-version sein.
Ich habe dieses fehlende Waldstück das erste Mal Anfang Juni 2011 festgestellt, mich aber nicht weiter damit beschäftigt. Aus diesem Grund denke ich nicht, dass zwischen gestern 07.00 und meiner Aktualisierung um 20.00 jemand etwas an den Daten geändert hat.
Aber scheinbar haben unterschiedliche Renderer auch unterschiedliche oder keine Probleme mit diesem Wald.
In der RWK ist der Wald vorhanden, der Nationalpark aber nur als Linie. Ich dachte, dass Nop die RWK mit dem Composer erstellt hat. In die GARMIN-Karte habe ich nicht geschaut, die hat einen Stand vom 23.06.2011.
Ich nutze den MC 0.86 und entsprechenden Teile.
Ich weiß! Am Anfang habe ich das auch schon gemacht. Aber irgendwann wieder geändert. Diese schnurgeraden Flächenbegrenzungen entstehen aber auch, wenn ein Randpolygon (z. B. für ein Naturschutzgebiet) nicht geschlossen ist. Da verbindet der Composer einfach die beiden äußeren Punkte durch eine Gerade. Wenn diese beiden Punkte dicht beeinander liegen fällt das gar nicht auf.
Deshalb schau ich mir ja immer die Rohdaten an (bei mir mit Josm und im Extremfall meine SQL-DB) damit ich nicht auf die manchmal eigenwillige Interpretation der Renderer angewiesen bin.
Eine gute QA-Software hilft auch ein wenig.
die andere Richtung sollte schon Pille-Palle sein - aber die Tags an den ways könnten ihn evtl. stören.
Der boundary=administrative darf ihn dabei eigentlich nicht stören, da er sich gar nicht mit den Tags des Wald-Polygons beißt.
Ich würde mein Augenmerk eher auf den key name richten - der Eintrag ist nämlich in way und Relation enthalten, aber mit unterschiedlichen Werten.
Das ist auch für andere Auswerter ja nicht unbedingt in Einklang zu bringen.
Und falls der Composer hier etwas zu generisch prüft (Gleicher key mit unterschiedlichen Werten => ignorieren, siehe MP-Regelung im Wiki) geht das schief.
Die Tags an den ways 31731473, 99319329, 99319327 sind aufgrund der Zwitterhaftigkeit einer Grenze (einerseits Linie, andererseits Gebiet) nicht falsch, aber können eben auch zu Problemen führen.
Warum aber der Waldbereich westlich von Hohegeiß fehlt, obwohl die anderen Bereiche desselben Multipolygons (Bad Lauterberg, Bad Sachsa, Ellrich) dargestellt werden, ist mir nicht so recht ergründlich.
Ich habe in der Relation allerdings mal die outer-Elemente sortiert und komplett an den Anfang gestellt - mal sehen ob das was ändert, muss dann aber auch nicht unbedingt was heißen …
Aber der dargestellte Zipfel beim “L 601” war irgendwie der Anfangsbereich …
Wird aber mit den aktuellen Daten von meinem Mapnik korrekt dargestellt:
Und wir taggen ja bekanntlich nicht für (kaputte) Renderer
Es ist wohl so, dass der Map Composer den Grenz-Way an der Nordwestflanke bei den Multipolygonen nicht berücksichtigt. Dann ist 93882 nicht geschlossen und bekommt keine Farbe, und das Waldstück daneben hat ne gerade Kante.
Ich hab mir nämlich grad mal mkgmap (stable 1867) runtergeladen, und eine garmin-Datei erzeugt. Und siehe da, es kommt das gleiche raus wie bei Mapnik. Also liegt der Fehler in den verwendeten Stylefiles bei mkgmap.
Die Lösung des Rätsels ist noch viel einfacher. Composer erkennt Multipolygone mit Mehrfach-outer einfach nicht, weil mir noch kein vernünftiger Weg eingefallen ist, sowas zu verarbeiten ohne aus den ganzen Outer-Fragmenten wieder ein echtes Polygon zu zusammenzusetzen.
Ich bin von der ganzen Angelegnehit auch absolut nicht überzeugt. Diese Art von Multipolygonen ist ein komplizierter Riesenwust und sorgt dafür, daß die Verwendung von OSM Daten nicht mehr wie früher vergleichsweise einfach möglich ist. Wie man an dem ganzen Rätselraten und den Konjunktiven in diesem Thread erkennen kann, ist sich auch keiner so recht sicher, wie das Zeug eigentlich gehört. Auf jedenfall muß es in jeder Applikation nachprogrammiert werden - und wenn man nicht nur einen kleinen Datenbereich anschaut (wie JOSM oder mkgmap) oder eine PostGIS Datenbank zur Verfügung hat (wie oms2pgsql/Mapnik) oder 24GB Speicher, dann ist das eine ebenso schwierige wie schweinelangsame Angelegenheit. Es sind auch nur die Mainstream-Applikationen, die das unterstützen -(wobei ich vermute daß niemand weiß ob sie es genau gleich tun - und auch da nicht alle.
Das prominenteste Beispiel ist Potlatch, wo dort kein Wald zu sehen ist, sondern nur eine dünne Linie ohne Tags. Diese komplexen MPs werden dort weder angezeigt noch lassen sie sich vernünftig bearbeiten. Auf der anderen Seite gibt es aber auch noch eine große Menge an anderen Anwendungen [1]. Ich möchte nicht wissen, bei wievielen davon statt der komplizierten MPs nur Löcher klaffen. Sicher bin ich mir bei Navit. Oder Kosmos. Weiß einer z.B. wie der Harz bei Skobbler aussieht? Wie sieht es mit Maperitive aus? Andere Navis? Dieser Bruch, daß eine Fläche ein Way sein kann, oder eine Relation mit einem outer way, oder eine Relation mit mehreren Outer ways ist unverständlich, schwer auszuwerten und legt die Einstiegshürde verdammt hoch. Was OSM da bräuchte wäre mal ein vernünftiges Flächenobjekt - ein paar Diskussionen in die Richtung gab es ja schon.
Was Composer angeht sind momentan ein paar fehlende Wälder das kleinere Übel im Vergleich zu einer Verdopplung der Verarbeitungszeit für einen extra MP-Zusammenbastel-Durchlauf. Und der Gefahr, daß dann wieder was anderes schiefgeht. Und ich habe die Hoffnung auf eine vernünftige Area-Lösung statt des Relations-Workarounds noch nicht ganz aufgegeben. Für den Moment wäre es wohl die einfachste Lösung, das Schneiden der Kacheln ganz aufzugeben und das mkgmap zu überlassen. Dafür müßte ich bloß noch wissen, wie man mkgmap dazu überredet das dann auch zu tun. Wenn man die Daten einfach so reinfüttert, erzeugt mkgmap einen “Flatterrand” und läßt alle überstehenden Daten einfach stehen.
Mkgmap hat übrigens auch schon längere Zeit Probleme mit diesen großen Multipolygonen. In ungünstigen Kombinationen verschluckt es sich dran, bringt die Fehlermeldung “area too small to split” und läßt das große Polygon und eine zufällige Menge an Daten in dessen Nähe einfach weg. [2]
MPs sind eine komplizierte Materie und wie Nop schon erwähnte ist die Unterstützung und die Definition von MPs sehr unterschiedlich.
Grundsätzlich (aus meiner Sicht und damit auch aus mkgmap Sicht) ist es gut:
Die Tags eines MPs nur im MP setzen und nicht auf den outer-Wegen selber (also keine Verdoppelung). mkgmap stört sich nicht daran und löscht Tag/Value Kombinationen des MPs bei den Wegen. Habe bislang auch mit den Standard-Renderern hiermit die besten Erfahrungen gemacht (das waren allerdings sehr wenige…).
mkgmaps Unterstützung von MPs ist nicht perfekt. Dies liegt daran, dass mkgmap immer nur einen Ausschnitt (Tile) der Karte bearbeitet. Manchmal sind die Wege eines MP in den Daten eines Tiles nicht vollständig enthalten, da z.B. das MP an der Grenze eines Tiles liegt. In diesem Fall muss mkgmap raten, wie das MP geschlossen werden kann. In der letzten Zeit wurden hierzu aber nur noch vergleichsweise wenige Probleme auf der Mailingliste diskutiert. Von daher gehe ich davon aus, dass dieser “Rate”-Algorithmus in dem allermeisten Fällen ganz gut funktioniert.
Kannst Du etwas genauer beschreiben, was Du mit “reinfüttern” meinst?
Für das Schneiden ist der Tile-Splitter zuständig, nicht mkgmap. Wenn Du die Daten selber schneiden möchtest, musst Du jedem OSM Tile ein nicht überlappendes bounds Tag verpassen (http://forum.openstreetmap.org/viewtopic.php?id=12934 - Mein Post vom 8.7.2011). Dann schneidet mkgmap die Daten auf den durch das bounds Tag beschriebenen Bereich und es gibt keine überstehenden Daten.
Die Fehlermeldung hat primär erst mal nichts mit Multipolygonen an sich zu tun. Dies ist ein Problem mit Objekten, die an sich zu groß sind, um in eine Garmin-Einheit (subdivision) gepackt zu werden. Bislang tritt dieser Fehler aber vergleichsweise selten auf. Mit dem Default-Style von mkgmap tritt dieser Fehler in ganz Europa nur eine Handvoll mal auf, wobei hier nach meinen Recherchen nur etwas Background-Area verloren geht, aber keine wirklich produktiven Daten.
Seit längerer Zeit gibt es auch einen ersten Bugfix hierfür. Der wartet aber noch auf eine Bestätigung durch Dich, Nop?!?
Der von Dir erfreulicherweise bereitgestellte Testcase lief bei mir einwandfrei, bei Dir aber nicht. Da gibt es Klärungsbedarf und ich warte immer noch auf eine Antwort von Dir. Solange ich nichts von Dir höre, sehe ich den Fehler mal als nicht so wichtig an.
Meiner Meinung liegt es am auschneiden.
Wo sich die Daten verhaspeln ob beim Auschneiden oder ob die Renderer nicht damit klarkommen ?
Wenn das MP mit allen seinen Teilen im Auschnitt ist geht es , wählt man einen kleineren Auschnitt wird der Wald weggelassen.
Bereich wo der fehlende Wald gut reinpasst = Wald wird nicht angezeigt (NSG liegt nur zum Teil darin, wird auch nicht angezeigt[wenn ich mich noch recht erinnere]!).
Bereich sehr großzügig bemessen (0,8*0,8 Grad) = Wald wird ordentlich gezeigt (NSG liegt komplett darin, wird angezeigt!)
Ausprobiert mit pbftoosm und Maperative.
Hab ähnliche Effekt auch Südlich von Wiesbaden gefunden.
Im gewünschten Bereich fehlt in der Nord/Westlichen Ecke etwas Wald (Deffinitiv mit Linien-Punkten im Bereich) - den Bereich um 0,05 Grad nach Norden erweitert und schon ist der Wald vorhanden.
Das wird es sein. Ich habe in obigem Beispiel das MP mit josm vollständig geladen, als .osm gespeichert und mit mapnik und mkgmap rendern lassen. Beidesmal erfolgreich.
Dann muss eben beim Ausschneiden nicht nach bounding-box geschnitten werden, sondern mit completetWays und completeRelations. Natürlich dauert die Verarbeitung dann länger.
Wie ist das zu verstehen?
Sollen dann die ansonsten an den Kachelgrenzen geschnittenen Polygone als Überhang erhalten bleiben?
Das würde sich bei der Erstellung einer “gekachelten” Karte negativ auswirken.
Beobachteter Effekt beim Kombinieren von Karten aus Kartenteilen mit unsauber geschnittenen Kanten = Polygonüberhängen etc. :
Die über die Schnittgrenze aus der Kachel heraus ragenden Flächen überdecken die in der Nachbarkachel angezeigten Wege.
Naja, Composer unterstützt diese MPs überhaupt nicht - und es hat Monate gedauert bis es jetzt hier diskutiert wurde. Von daher wär ich mir da nicht so sicher.
Aber wenn Composer dafür sorgt, daß alle Daten für das Tile enthalten sind, sollte mkgamp den Rest hinbekommen?
Das sollte nicht allzu schwer sein. Die Aufteilung macht Composer jetzt schon und ein Bounds-Tag reinzusetzen dürfte kein Problem sein.
Das problematische Objekt war halt genau so ein riesiges MP mit mehrfach-outer, nur in dem Fall ein See und kein Wald.
Ich hab’ Dir doch auf der Liste geantwortet daß der Patch keinen Effekt hatte. Die Daten nochmal nachzustellen und komplett zu schicken bin ich noch nicht dazu gekommen. Kommt aber noch, vielleicht sogar mit einem Patch für einen intelligenteren MapArea split.
Diese schnurgeraden Flächenbegrenzungen entstehen aber auch, wenn ein Randpolygon (z. B. für ein Naturschutzgebiet) nicht geschlossen ist. Da verbindet der Composer einfach die beiden äußeren Punkte durch eine Gerade. Wenn diese beiden Punkte dicht beeinander liegen fällt das gar nicht auf.
- und auch da nicht alle.
