MP-Fehler?

Von der Lage und von dem was Dir fehlt, könnte es das MP
http://www.openstreetmap.org/browse/relation/93882
sein.

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.

moin,

ich vermute auch irgendein Problem mit MP http://www.openstreetmap.org/browse/relation/1422308 mit dem way http://www.openstreetmap.org/browse/way/31731473. Der way hat eine andere Richtung und ist gleichzeitig als boundary getaggt. Vielleicht hat Composer dort Probleme?

Gruß
OPerivar

Edit: way 31731473 wird von beiden genannten MP genutzt

moin moin, Torsten

_torsten_ wrote:

Was mich stutzig macht, sind die merkwürdigen, über länger Strecken schnurgeraden Waldgrenzen.

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".

http://wnordmann.homeunix.com/images/st … /harz1.png

aber zum eigentlichen Problem: da ist im Harz halt noch einiges defekt.

http://tools.geofabrik.de/osmi/debug.ht … ,way_nodes

Die verschiedenen Renderer machen daraus unterschiedlich gute Karten. In Mapnik ist der Wald z.b. drin und bei dir fehlt er eben - Pech gehabt.

Würde sich bitte mal jemand das Gebiet ansehen und evtl. reparieren? Ich kann es nicht und möchte da auch nichts kaputt machen.

Der Bitte schliesse ich mich hiermit aus Zeitgründen an.

Gruss
Walter

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.

aighes wrote:

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?

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.

aighes wrote:

Evtl. könnte es auch eine sehr veraltete mkgmap-version sein.

Ich nutze den MC 0.86 und entsprechenden Teile.

wambacher wrote:

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 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.

_torsten_ wrote:

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.

Gruss
Walter

_torsten_ wrote:

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.

Ne, Nop erstellt AFAIK mit seinem Composer nur die Stylefiles für die Onlinekarte.

Moin,

OPerivar wrote:

ich vermute auch irgendein Problem mit MP http://www.openstreetmap.org/browse/relation/1422308 mit dem way http://www.openstreetmap.org/browse/way/31731473. Der way hat eine andere Richtung und ist gleichzeitig als boundary getaggt. Vielleicht hat Composer dort Probleme?

Edit: way 31731473 wird von beiden genannten MP genutzt

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 ...

Gruß
Georg

TheFive wrote:

Von der Lage und von dem was Dir fehlt, könnte es das MP
http://www.openstreetmap.org/browse/relation/93882
sein.

Da sind aber laut JOSM MP Editor alle Outer und Inner schön geschlossen.

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.

Gruß,
ajoessen

OPerivar wrote:

moin,

ich vermute auch irgendein Problem mit MP http://www.openstreetmap.org/browse/relation/1422308 mit dem way http://www.openstreetmap.org/browse/way/31731473. Der way hat eine andere Richtung und ist gleichzeitig als boundary getaggt. Vielleicht hat Composer dort Probleme?

Gruß
OPerivar

Edit: way 31731473 wird von beiden genannten MP genutzt

Ich vermute mal eher, das boundary=national_park an dem Weg und an der Relation stört ihn.
Wenn alle outer das hätten, wärs vermutlich wieder egal.

Gruß,
ajoessen

ajoessen wrote:

Ich vermute mal eher, das boundary=national_park an dem Weg und an der Relation stört ihn.
Wenn alle outer das hätten, wärs vermutlich wieder egal.

dann mach es doch aus dem way raus - ist eh unsinnig.

wambacher wrote:

ajoessen wrote:

Ich vermute mal eher, das boundary=national_park an dem Weg und an der Relation stört ihn.
Wenn alle outer das hätten, wärs vermutlich wieder egal.

dann mach es doch aus dem way raus - ist eh unsinnig.

Nö, mach ich nicht.

Ommmmmm.... [tm]

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.

Gruß,
ajoessen

aighes wrote:

Hast du schonmal in der Garmin-Karte von Nop geschaut?

_torsten_ wrote:

In die GARMIN-Karte habe ich nicht geschaut, die hat einen Stand vom 23.06.2011.

Das hab ich jetzt gemacht. In der soeben herunter geladenen Version fehlt das Waldstück auch.

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]

bye
Nop

[1] http://wiki.openstreetmap.org/wiki/List … d_Services
[2] http://gis.638310.n2.nabble.com/Mkgmap- … 90533.html

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.

Nop wrote:

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.

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.

Nop wrote:

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.

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.

WanMil

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.

quasilotte wrote:

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.

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.

Gruß,
ajoessen

ajoessen wrote:

quasilotte wrote:

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.

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.

Gruß,
ajoessen

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.

Gruß
tippeltappel

WanMil wrote:

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.

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?

WanMil wrote:

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.

Das sollte nicht allzu schwer sein. Die Aufteilung macht Composer jetzt schon und ein Bounds-Tag reinzusetzen dürfte kein Problem sein.

WanMil wrote:

Nop wrote:

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.

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.

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.

bye
Nop

tippeltappel wrote:

ajoessen wrote:

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?

Ich glaube ajoessen verwechselt das mit dem Ausschneiden mit osmosis - das sind Parameter von osmosis. Das wird aber hier gar nicht benutzt.

bye
Nop

Nop wrote:

tippeltappel wrote:

ajoessen wrote:

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?

Ich glaube ajoessen verwechselt das mit dem Ausschneiden mit osmosis - das sind Parameter von osmosis. Das wird aber hier gar nicht benutzt.

Ja, meinte ich. Dann müsst ihr eurem Ausschneideprogramm das eben auch beibringen.

Gruß,
ajoessen

ajoessen wrote:

Ja, meinte ich. Dann müsst ihr eurem Ausschneideprogramm das eben auch beibringen.

1+
walter

tippeltappel wrote:

ajoessen wrote:

quasilotte wrote:

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.

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.

Gruß,
ajoessen

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.

Gruß
tippeltappel

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.

Nop wrote:

WanMil wrote:

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.

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. :-)

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.

ajoessen wrote:

Ja, meinte ich. Dann müsst ihr eurem Ausschneideprogramm das eben auch beibringen.

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

aighes wrote:

Nuja...auf mkgmap-dev war das vor nicht allzu langer Zeit auch Thema und es gibt auch keine Klagen über schlechtes raten.

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.

aighes wrote:

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.

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.

Nop wrote:

da ist man auf Benutzer angewiesen, die zufällig drüber stolpern und nachfragen.

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. 🙁

aighes wrote:

tippeltappel wrote:

ajoessen wrote:

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.

Gruß,
ajoessen

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.

Gruß
tippeltappel

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.

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

Nop wrote:

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.

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=mu … ,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?

Ebbe73 wrote:

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

aighes wrote:

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.

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=mu … ,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.

Ebbe73 wrote:

…
die Grenzen an Straßen entlangführen musste (heute wäre das Mapper für die Renderer,
…

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.

de_muur wrote:

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.

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/Rela … sed/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!

_torsten_ wrote:

Ebbe73 wrote:

…
die Grenzen an Straßen entlangführen musste (heute wäre das Mapper für die Renderer,
…

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, ...

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.

_torsten_ wrote:

Wie wird das in anderen Waldgebieten gehandhabt? Da sind mir bisher noch nicht so viele fehlende Wälder/Waldpolygone aufgefallen.

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.

hurdygurdyman wrote:

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/Rela … sed/Region

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.)

Ebbe73 wrote:

Das nur rendertechnische Problem (von Mapnik), dass man an Grenzen zweier Waldpolygone kleine weiße Linien sieht, tritt daher nicht auf.

Das ist kein Mapnik-spezifisches Problem sondern fuer jeden Renderer eine harte Nummer (man sieht es .z.B. auch auf Garmin-Karten. Aneinander grenzende Flaechen in der Darstellung lueckenlos zu fuellen ist allgemein alles andere als trivial. Wenn die beiden Flaechen ansonsten gleich aus sehen (z.B. beide Wald), dann faellt das nur besonders auf.
Wenn man aber auf der Grenze zusaetzlich eine Linie zu zeichnen hat, so ueberdeckt diese freundlicher Weise die Probleme.

Gruss
Torsten

Hallo an alle,

ich bin neu hier und habe von den meisten Dingen, die diskutiert werden nicht viel Ahnung. Ich bin in diesem Forum gelandet, weil hier über fehlenden Wald diskutiert wird.
Mir ist aufgefallen dass bei den Garmin Karten auch Wald fehlt.
Beispiel in Aalen:
südlich von Aalen auf der Ostalb und östlich von Aalen auf der Ostalb zwischen Aalen und Lauchheim fehlt der ganze Wald.

Ich benutze Mapsource und Basecamp zum Darstellen der Karte aber in beiden Programmen sehe ich den Wald nicht- er fehlt mir sehr :-)

Ich habe die Wanderkarte 11/11 und die Deutschlandkarte 11/11 heruntergeladen und bei beiden fehlt er.

Nun meine Fragen:
1. Liegt das an den Einstellungen in meinen Programmen?
2. Wie kann das Problem behoben werden?

Hinweis: In der Online-Version, die man über das Internet anschauen kann, sind alle Wälder vorhanden?

Über Eure Hilfe bin ich erst mal sehr dankbar.

Grüße aus Aalen vom Friederle :-)

Hallo Friederle,

willkommen im Forum. Kannst Du online bitte mal an den Wald ranzoomen, rechts unten auf Permalink klicken und den Link hier posten? Dann wissen wir genauer um welchen Wald es geht und können nachschauen

Das ging ja schnell :-)

Ich hoffe es ist der Link, den Du meinst:

http://www.wanderreitkarte.de/index.php … 64&zoom=13

man sieht Aalen, östlich von Aalen bis Lauchheim fehlt Wald und
südlich von Aalen, das Dreieck Aalen , Oberkochen und westlich davon Essingen.

Vielen Dank mal :-)

Hab gerade gesehen, da fehlt noch viel mehr Wald in dieser Gegend......

Bauer-Frieder wrote:

Das ging ja schnell :-)

Ich hoffe es ist der Link, den Du meinst:

http://www.wanderreitkarte.de/index.php … 64&zoom=13

man sieht Aalen, östlich von Aalen bis Lauchheim fehlt Wald und
südlich von Aalen, das Dreieck Aalen , Oberkochen und westlich davon Essingen.

Vielen Dank mal :-)

Es tut mir leid, aber ich kann beim besten Willen nicht erkennen wo dort Wald fehlt. Falls du die Fläche um Ebnat und Waldhausen meinst, so ist dies nach dem Bingbildern deutlich als Feld oder Wiese zu erkennen. Aber auf keinen Fall Wald.

http://tools.geofabrik.de/mc/?mt0=mapni … 72&zoom=12

Ich glaube wir haben ein Missverständnis.

In der Onlineversion sind alle Wälder vorhanden. Nur in den Downloadversionen, die ich in Mapsource verwende habe (Wanderkarte_11_11 und Deutschland_11_11), fehlen diese Wälder.
Die Fläche zwischen Ebnat und Waldhausen sind Felder oder Wiese, das ist richtig.

Ich würde Dir einen Screenshot schicken, weiß aber nicht wie das geht.....

Grüße von Friederle

Bauer-Frieder wrote:

Ich glaube wir haben ein Missverständnis.

In der Onlineversion sind alle Wälder vorhanden. Nur in den Downloadversionen, die ich in Mapsource verwende habe (Wanderkarte_11_11 und Deutschland_11_11), fehlen diese Wälder.
Die Fläche zwischen Ebnat und Waldhausen sind Felder oder Wiese, das ist richtig.

Ich würde Dir einen Screenshot schicken, weiß aber nicht wie das geht.....

Grüße von Friederle

Du brauchst mir keinen Screenshot schicken. Wenn die Daten inzwischen berichtigt wurden, dann können wir nicht mehr tun. Sollte in der nächsten version bei Nop immer noch ein Problem mit dem Wald vorhanden sein, so müsstest du mit ihm mal darüber reden, ob er den Fehler bei der Kartenerstellung findet. Es ist schonmal schön, dass wenn es einen Datenfehler gab dieser nun behoben ist.

Bauer-Frieder wrote:

...
In der Onlineversion sind alle Wälder vorhanden. Nur in den Downloadversionen, die ich in Mapsource verwende habe (Wanderkarte_11_11 und Deutschland_11_11), fehlen diese Wälder.
...

Hallo Friederle,

da ich u. a. auch die Reit- und Wanderkarte von Nop und auch die Deutschlandkarte von Computerteddy im MapSource nutze, habe ich mal nachgesehen und kann deine Feststellung bestätigen: in beiden Karten fehlen diese Wälder südöstlich von Aalen. Die beiden Karten haben bei mir auch einen Datenstand von November 2011.

Ich habe mir mal den entsprechenden Bereich im OSM-Inspektor angesehen. Dort wurden keine MP-Fehler ausgewiesen.

Ich habe an anderen MP festgestellt, dass die Darstellung immer dann fehlerhaft wird bzw. die MP gar nicht dargestellt werden, wenn die MP die Kachelgrenzen schneiden. Das scheint dann auch hier das Fall zu sein. Da hilt m. M. nach nur, die MP zu verkleinern.

Edit: Beim MP 110979 ist offenbar im Bereich Ochsenberg ein innerer Ring nicht richtig geschlossen. Das könnte u. U. auch ein Problem darstellen. Allerdings ist im Editor dieser Fehler nicht zu erkennen.

Vielen Dank mal für Eure Bemühungen!
Wenn ich das richtig verstehe, ist der Fehler schon behoben, da die Wälder ja in der Onlineversion richtig dargestellt werden oder liege ich damit falsch?

Könnte ja auch ein Problem bei der Umwandlung zur Mapsourceverwendung entstanden sein.....

@_torsten_:
Leider habe ich absolut keine Ahnung wie das mit der Programmierung der Karten ist. Was meinst Du mit die MP zu verkleinern? Muss ich das machen oder der Ersteller?Also in diesem Fall warscheinlich Nop.
Was ist eigentlich eine MP? Ist das ein Kartenausschnitt?

Kann mir jemand sagen wann ungefähr die nächste Version der Wanderkarte heraus kommen soll?

Grüße vom Friederle

Also MP steht für Multipolygon. Das ist quasie eine Fläche, die von mehr als einem Weg begrenzt wird. Diese Flächen können sehr groß werden.

Außerdem werden Karten sowohl online als auch für Garmin nicht als ein großes Bild sondern als mehrer kleine Bilder erstellt. Das sind dann die Kacheln, welche von der Software wieder zusammengesetzt werden, damit sie wie ein Bild aussehen.

torsten meinte, das eventuell Probleme bei der Umwandlung dieser Flächen in Garminkarten auftreten können, wenn diese Flächen so groß sind, dass keine sie begrenzenden Wege in der Kachel liegen. Dadurch weiß das Programm gar nicht, das hier als Hintergrund eigentlich eine Fläche erstellt werden müsste.
Um dieses Problem zu löse war sein Vorschlag die Große Fläche durch zwei aneinanderstoßende Flächen zu ersetzen. Da dies aber tagging für den Garmin ist, würde ich davon abraten. Viel mehr sollte an der Ursache des Problems gearbeitet werden. Denn nicht überall besitzt man die nötige Orstkenntnis um diesen Fehler zu finden, so dass man im Zweifelsfall doch mit einer "flaschen" Karte unterwegs ist.

Vielen Dank mal.
Dann hoffe ich, dass mit der nächsten Version die Wälder da sind :-)
Ich habe Nop eine Email geschickt und auf diesen Fehler aufmerksam gemacht.

Grüße vom Friederle

viw wrote:

Da dies aber tagging für den Garmin ist, ...

Das habe ich ja noch gar nicht gehört. 😉 Klingt aber gut!

Bauer-Frieder wrote:

Wenn ich das richtig verstehe, ist der Fehler schon behoben, da die Wälder ja in der Onlineversion richtig dargestellt werden oder liege ich damit falsch?

Könnte ja auch ein Problem bei der Umwandlung zur Mapsourceverwendung entstanden sein.....

Ich habe mir die Historie der Daten nicht angesehen, aber wahrscheinlich lag und liegt hier bei dieser (Wald)Fläche kein Fehler in den OSM-Daten vor. Die Ursache vermute ich an der Größe der (Wald)Fläche. Irgendein Rand schneidet wahrscheinlich eine Grenze des Kartenausschnittes für die MapSource-Karte. Damit gehen u. U. die Informationen verloren, dass es sich hier um eine Fläche handelt und der Wald wird nicht dargestellt. Da die Online-Karten und die GARMIN-Karten nicht unbedingt die gleichen Kartenausschnitte haben, kommt es zu unterschiedlichen Darstellungen.

Bauer-Frieder wrote:

Was meinst Du mit die MP zu verkleinern? Muss ich das machen oder der Ersteller?Also in diesem Fall warscheinlich Nop.

In Grund kann und darf das jeder. Das ist OSM.
Aber wie viw schon sagte, es ist nicht immer sinnvoll, vorhandene Daten ohne die entsprechende Ortskenntnis zu verändern.

Bauer-Frieder wrote:

Kann mir jemand sagen wann ungefähr die nächste Version der Wanderkarte heraus kommen soll?

Ja, Nop.

Die anderen Fragen hat ja viw schon beantwortet.

_torsten_ wrote:

Die Ursache vermute ich an der Größe der (Wald)Fläche. Irgendein Rand schneidet wahrscheinlich eine Grenze des Kartenausschnittes für die MapSource-Karte. Damit gehen u. U. die Informationen verloren, dass es sich hier um eine Fläche handelt und der Wald wird nicht dargestellt.

Ich kann mir kaum vorstellen, dass dieser Fall nicht entsprechend behandelt wird.

Werden denn die fraglichen Wälder von einer Kachelgrenze geschnitten?

Gruß,
Mondschein

der Weg hier http://www.openstreetmap.org/browse/way/145274477 wurde am 12.01.2012 angefasst (hinzugefügt...was vorher war, bi ich jetzt zu faul zum Nachschauen). Das ist genau das fehlende Stück im Relation Analyzer
http://ra.osmsurround.org/analyzeMap?relationId=110979

Wenn die Karten einen Stand vom letzten November haben, würde ich erstmal eine Aktualisierung abwarten...sonst verschlimmbessert man es noch

Mondschein wrote:

_torsten_ wrote:

Die Ursache vermute ich an der Größe der (Wald)Fläche. Irgendein Rand schneidet wahrscheinlich eine Grenze des Kartenausschnittes für die MapSource-Karte. Damit gehen u. U. die Informationen verloren, dass es sich hier um eine Fläche handelt und der Wald wird nicht dargestellt.

Ich kann mir kaum vorstellen, dass dieser Fall nicht entsprechend behandelt wird.

Ich erstelle meine Karten mit dem composer. Dabei ist mir genau dieses Problem schon aufgefallen. Deswegen lege ich meine Kartengrenzen entsprechend so fest, dass die gewünschten Regionen den ganzen MP / die ganze Fläche enthalten.

Mondschein wrote:

Werden denn die fraglichen Wälder von einer Kachelgrenze geschnitten?

Ich kann im Moment nur auf einer Reit- und Wanderkarte mit Kartenstand von Juli 2011 nachsehen. Da liegen die entsprechenden Wälder in einer Kachel. Allerdings sind da die entsprechenden Wälder auch dargestellt.

SunColbalt wrote:

Wenn die Karten einen Stand vom letzten November haben, würde ich erstmal eine Aktualisierung abwarten...sonst verschlimmbessert man es noch

Da stimme ich dir vollkommen zu.

SunCobalt wrote:

der Weg hier http://www.openstreetmap.org/browse/way/145274477 wurde am 12.01.2012 angefasst (hinzugefügt...was vorher war, bi ich jetzt zu faul zum Nachschauen). Das ist genau das fehlende Stück im Relation Analyzer
http://ra.osmsurround.org/analyzeMap?relationId=110979

Und die Relation http://www.openstreetmap.org/browse/relation/110979 liegt auch vollständig in einer Garmin-Kachel der aktuellen Reit- und Wanderkarte (Datenbestand vom 23.11.11).

Also auf die nächste Aktualisierung warten.

Gruß,
Mondschein

Allerdings fällt mir gerade auf, dass Lichtungen in Wäldern (inner eines Multipoligons) unabhängig vom Schneiden von Kachelgrenzen bei der Reit- und Wanderkarte für Garmin nicht dargestellt werden!
Ist das bei anderen Garmin-Karten ebenfalls so? AIO?
Kann das bitte jemand überprüfen?

Gruß,
Mondschein

Mondschein wrote:

Allerdings fällt mir gerade auf, dass Lichtungen in Wäldern (inner eines Multipoligons) unabhängig vom Schneiden von Kachelgrenzen bei der Reit- und Wanderkarte für Garmin nicht dargestellt werden!
Ist das bei anderen Garmin-Karten ebenfalls so? AIO?

Wenn das jemand überprüfen soll, dann braucht man schon Beispiele. Bei meiner Garmin Karte ist das im allgemeinen nicht so.
Aber eine Zeitlang wurden Lichtungen (inner eines Mulitpoligons) gerne mit landuse=forest getaggt, was natürlich quatsch ist ...
In meiner Gegend habe ich schon sehr viele dieser Fehler korrigiert.

Thorsten

kukuk wrote:

Mondschein wrote:

Allerdings fällt mir gerade auf, dass Lichtungen in Wäldern (inner eines Multipoligons) unabhängig vom Schneiden von Kachelgrenzen bei der Reit- und Wanderkarte für Garmin nicht dargestellt werden!
Ist das bei anderen Garmin-Karten ebenfalls so? AIO?

Wenn das jemand überprüfen soll, dann braucht man schon Beispiele. Bei meiner Garmin Karte ist das im allgemeinen nicht so.
Aber eine Zeitlang wurden Lichtungen (inner eines Mulitpoligons) gerne mit landuse=forest getaggt, was natürlich quatsch ist ...
In meiner Gegend habe ich schon sehr viele dieser Fehler korrigiert.

Thorsten

Hier ist ein Beispiel: Die Kaiserwiese wird aus der RWK nicht ausgeschnitten. Wie das in der AIO weiß ich nicht.

http://www.openstreetmap.org/?lat=50.90 … 7&layers=M

kukuk wrote:

Wenn das jemand überprüfen soll, dann braucht man schon Beispiele.

Noch ein Beispiel:
http://www.openstreetmap.org/browse/relation/77637

Gruß,
Mondschein

_torsten_ wrote:

Hier ist ein Beispiel: Die Kaiserwiese wird aus der RWK nicht ausgeschnitten.

Diese wird bei mir in der Reit- und Wanderkarte zwar nicht als Wiese dargestellt, sondern als Wald, aber es befinden sich an dieser Stelle grüne Streifen über dem Wald (vermutlich wegen nature_reserve oder protected_area).
Aber diese beiden Lichtungen im selben Wald, werden ebenfalls in der aktuellen Reit- und Wanderkarte nicht dargestellt:
http://www.openstreetmap.org/browse/way/54383145
http://www.openstreetmap.org/browse/way/54512965

edit: Der komplette Wald liegt übrigens mitten in einer Garmin-Kachel der Reit- und Wanderkarte.

Gruß,
Mondschein

Mondschein wrote:

Allerdings fällt mir gerade auf, dass Lichtungen in Wäldern (inner eines Multipoligons) unabhängig vom Schneiden von Kachelgrenzen bei der Reit- und Wanderkarte für Garmin nicht dargestellt werden!

Irgendwie erinnere ich mich, dass Nop in der RuW Lichtungen generell nicht ausschneidet und irgendwo auch den Grund genannt. 🤔

hurdygurdyman wrote:

Irgendwie erinnere ich mich, dass Nop in der RuW Lichtungen generell nicht ausschneidet und irgendwo auch den Grund genannt. 🤔

Kann ich fast nicht glauben. Diese hier
http://www.openstreetmap.org/browse/way/109235883
http://www.openstreetmap.org/browse/way/103971133
http://www.openstreetmap.org/browse/way/103971147
werden ausgeschnitten. Zumindest mit dem Stand Juli 2011.

Edit: link korrigiert: http://www.openstreetmap.org/?lat=50.74 … 4&layers=M

Ich habe mir mal von den MP aus #62 und #64 den Inhalt angesehen.
Der Unterschied besteht darin, dass es bei #62 nur einen outer-way und bei #64 sechs outer-ways gibt.
Ob das eine Rolle spielt?

_torsten_ wrote:

Ich habe mir mal von den MP aus #62 und #64 den Inhalt angesehen.
Der Unterschied besteht darin, dass es bei #62 nur einen outer-way und bei #64 sechs outer-ways gibt.

Schwer zu überprüfen, denn in der aktuellen Reit- und Wanderkarte werden weder der hier genannten Wald noch die Wiesen dargestellt:

_torsten_ wrote:

Diese hier
http://www.openstreetmap.org/browse/way/109235883
http://www.openstreetmap.org/browse/way/103971133
http://www.openstreetmap.org/browse/way/103971147
werden ausgeschnitten. Zumindest mit dem Stand Juli 2011.

Vermutlich waren die Date im November fehlerhaft.

Gruß,
Mondschein

Mondschein wrote:

Schwer zu überprüfen, denn in der aktuellen Reit- und Wanderkarte werden weder der hier genannten Wald noch die Wiesen dargestellt: ...

Stimmt!
In diesem Falle läuft die rechte/ästliche vertikale Kachelgrenze senkrecht von Gotha nach Suhl und schneidet genau diesen Wald. Weder der Wald noch die Lichtungen werden dargestellt.
Kartenstand: November 2011

Die von mir für den Composer gewählte Region schneidet dieses Waldstück nicht. Es wird im ganzen dargestellt und es werden auch die Lichtungen ausgeschnitten.
Kartenstand: Januar 2012

Muss ich bei diesen beiden Screenshots eigentlich die Quellen angeben?

_torsten_ wrote:

Mondschein wrote:

Schwer zu überprüfen, denn in der aktuellen Reit- und Wanderkarte werden weder der hier genannten Wald noch die Wiesen dargestellt: ...

Stimmt!
In diesem Falle läuft die rechte/ästliche vertikale Kachelgrenze senkrecht von Gotha nach Suhl und schneidet genau diesen Wald. Weder der Wald noch die Lichtungen werden dargestellt.
Kartenstand: November 2011 http://fotos.mtb-news.de/img/photos/3/6 … rte001.jpg

Die von mir für den Composer gewählte Region schneidet dieses Waldstück nicht. Es wird im ganzen dargestellt und es werden auch die Lichtungen ausgeschnitten.
Kartenstand: Januar 2012 http://fotos.mtb-news.de/img/photos/3/6 … rte002.jpg

Muss ich bei diesen beiden Screenshots eigentlich die Quellen angeben?

Na ja, es ergibt sich im Grunde genommen aus dem Zusammenhang.
Dennoch wäre eine Angabe
"Kartendaten: OSM&Contributer" +
"Kartendarstellung: Reit+Wanderkarte ..."
nicht verkehrt.

Edbert (EvanE)

EvanE wrote:

Na ja, es ergibt sich im Grunde genommen aus dem Zusammenhang.
Dennoch wäre eine Angabe
"Kartendaten: OSM&Contributer" +
"Kartendarstellung: Reit+Wanderkarte ..."
nicht verkehrt.

Edbert (EvanE)

Werd ich mir merken.
Da das aber nun schon durch dich erfolgt ist, werde ich´s dann in diesem Falle lassen.

_torsten_ wrote:

In diesem Falle läuft die rechte/ästliche vertikale Kachelgrenze senkrecht von Gotha nach Suhl und schneidet genau diesen Wald. Weder der Wald noch die Lichtungen werden dargestellt.

Das kann ich nicht bestätigen, hier das Wald-Multipolygon, in welchem sich die Lichtungen befinden:
http://www.openstreetmap.org/?relation=1706134
Dieses Wald-Multipolygon befindet sich vollständig in einer Garmin-Kachel (Reit- und Wanderkarte vom November).

_torsten_ wrote:

Kartenstand: November 2011

Die von mir für den Composer gewählte Region schneidet dieses Waldstück nicht.

Bei der Reit- und Wanderkarte vom November wird das oben genannte Waldstück ebenfalls nicht geschnitten!
Die Kachelgrenze geht durch Gräfenhain und das Waldstück ist westlich davon.

Die Kachelgrenze ist richtig eingezeichnet.

Gruß,
Mondschein

@_torsten_
Übrigens solltest du die heute von dir in das genannte Wald-Multipolygon hinzugefügte Lichtung auch als "inner" eintragen:
http://www.openstreetmap.org/browse/way/147062408

Gruß,
Mondschein

_torsten_ wrote:

hurdygurdyman wrote:

Irgendwie erinnere ich mich, dass Nop in der RuW Lichtungen generell nicht ausschneidet und irgendwo auch den Grund genannt. 🤔

Kann ich fast nicht glauben. ...

🤔
Habe mir die Ecke, um die es damals ging, nochmal angeschaut. RuW schneidet alle richtig erfassten Lichtungen aus. Das war vor geschätzt einem Jahr mal nicht so.

hurdygurdyman wrote:

...
RuW schneidet alle richtig erfassten Lichtungen aus. Das war vor geschätzt einem Jahr mal nicht so.

Mondschein wrote:

...
Aber diese beiden Lichtungen im selben Wald, werden ebenfalls in der aktuellen Reit- und Wanderkarte nicht dargestellt:
http://www.openstreetmap.org/browse/way/54383145
http://www.openstreetmap.org/browse/way/54512965

edit: Der komplette Wald liegt übrigens mitten in einer Garmin-Kachel der Reit- und Wanderkarte.

Gruß,
Mondschein

Was ist hier an dieser Relation falsch?
http://www.openstreetmap.org/?relation=1660327

Mondschein wrote:

@_torsten_
Übrigens solltest du die heute von dir in das genannte Wald-Multipolygon hinzugefügte Lichtung auch als "inner" eintragen:
http://www.openstreetmap.org/browse/way/147062408

Gruß,
Mondschein

Danke für den Hinweis!

_torsten_ wrote:

Was ist hier an dieser Relation falsch?
http://www.openstreetmap.org/?relation=1660327

Das landuse=forest sollte in die Relation nicht an den outer Way

SunCobalt wrote:

_torsten_ wrote:

Was ist hier an dieser Relation falsch?
http://www.openstreetmap.org/?relation=1660327

Das landuse=forest sollte in die Relation nicht an den outer Way

Sollte oder muss? Dazu gibt´s ja auch unterschiedliche Meinungen hier im Forum.
Ist das auch nootwendig, wenn der äußere Umring nur aus einem Weg besteht?

_torsten_ wrote:

SunCobalt wrote:

_torsten_ wrote:

Was ist hier an dieser Relation falsch?
http://www.openstreetmap.org/?relation=1660327

Das landuse=forest sollte in die Relation nicht an den outer Way

Sollte oder muss? Dazu gibt´s ja auch unterschiedliche Meinungen hier im Forum.
Ist das auch nootwendig, wenn der äußere Umring nur aus einem Weg besteht?

Es ist auf jeden Fall besser, wenn es an der Relation klebt. Dann muß sich der Renderer nicht erst durch die Liste der Members wühlen, und entscheiden, ob ein rollenloses Mtglied oder ein outer mit abweichendem tag nun das letzte Wort hat.
Das gilt insbesondere für landuse=forest und natural=wood, die sich eigentlich ausschliessen sollten, aber trotzdem gemeinsam gesetzt sein können.

Gruß,
ajoessen

ajoessen wrote:

Es ist auf jeden Fall besser, wenn es an der Relation klebt. Dann muß sich der Renderer nicht erst durch die Liste der Members wühlen, und entscheiden, ob ein rollenloses Mtglied oder ein outer mit abweichendem tag nun das letzte Wort hat.
Das gilt insbesondere für landuse=forest und natural=wood, die sich eigentlich ausschliessen sollten, aber trotzdem gemeinsam gesetzt sein können.

Gruß,
ajoessen

O. k., dann werde ich das mal ändern und die nächste Aktualisierung abwarten. 😉

In der AIO vom 22. Januar wird der Wald richtig dargestellt, die Lichtungen auch.

Gruß,
Mondschein

Sorry, aber ich muss hier mal nachfragen.

Ich habe jetzt die RWK bei mir im MapSource aktualisiert. Dazu habe ich die GARMIN-Deutschland vom 16.01.2012 von Nops Webseite herunter geladen und installiert.
Dabei habe ich festgestellt, dass im Bereich zwischen Oberhof, Ohrdruf und Steinbach-Hallenberg der Thüringer Wald immer noch fehlt.

Kartendaten: OSM&Contributer
Kartendarstellung: WanderReitKarte
Kartendaten: Januar 2012

Als Gegenüberstellung hier noch einmal der gleiche Ausschnitt

Kartendaten: OSM&Contributer
Kartendarstellung: WanderReitKarte
Kartendaten: November 2011

Aber eigentlich ist da Wald vorhanden: http://www.openstreetmap.org/?lat=50.75 … 2&layers=M

Wos ist der Fehler im MP 1706134 falsch?

_torsten_ wrote:

Wos ist der Fehler im MP 1706134 falsch?

Der Fehler liegt nicht im MP, sondern im splitter, der die OSM-Daten garminverträglich zuschneidet. Du siehst in der Lücke die Kachelgrenzen. Mit manchen MPs kommt der splitter nicht klar.

EDIT: Wenn man nur das MP in mapnik rendert, ist es auch vollständig mit allen Löchern.

Gruß,
ajoessen

ajoessen wrote:

_torsten_ wrote:

Wos ist der Fehler im MP 1706134 falsch?

Der Fehler liegt nicht im MP, sondern im splitter, der die OSM-Daten garminverträglich zuschneidet. Du siehst in der Lücke die Kachelgrenzen. Mit manchen MPs kommt der splitter nicht klar.

Gruß,
ajoessen

Aha! *unverständlichguck*
Und welche Lösung gibt´s da jetzt? Und warum ist bei meinem Kartenlayout der Wald da?

Kartendaten: OSM&Contributer
Kartendarstellung: eigenes Layout
Kartendaten: November 2011

Edit: Ergänzung

ajoessen wrote:

EDIT: Wenn man nur das MP in mapnik rendert, ist es auch vollständig mit allen Löchern.

Hm, wenn ich nur einen kleinen Ausschnitt vom Thüringer Wald mit dem composer rendern lasse, ist der Wald auch vollständig. (siehe screenshot)

_torsten_ wrote:

Edit: Ergänzung

ajoessen wrote:

EDIT: Wenn man nur das MP in mapnik rendert, ist es auch vollständig mit allen Löchern.

Hm, wenn ich nur einen kleinen Ausschnitt vom Thüringer Wald mit dem composer rendern lasse, ist der Wald auch vollständig. (siehe screenshot)

ebend. Bei kleinen Ausschnitten braucht der splitter nicht aktiv zu werden. Was genau ihm nicht gefällt, weiß ich nicht. MPs mit nur einem outer-way dürften unproblematisch sein, aber dafür ist dein Wald zu groß. Maximal 2000 Punkte pro Weg sind erlaubt. Natürlich kannst du den Wald auch weiter aufteilen.

EDIT: Ganz oben bei nop sind 3 Kacheln beteiligt, wie man an den hellen Linien sieht.

Gruß,
ajoessen

Immer das übliche bei den MP's!

Mehere Wege ergeben ein MP

Splitter teilt im MP.
Dabei wird ein Way nicht erfasst da komplett ausserhalb der Kachel (bzw. in allen 3 Kacheln).

= Dadurch MP nicht geschlossen = nicht gefüllt !

ajoessen wrote:

EDIT: Ganz oben bei nop sind 3 Kacheln beteiligt, wie man an den hellen Linien sieht.

Ist das wirklich so? *grübel*
Wenn ich mir in der RWK die Kachelgrenzen ansehe und übertrage, dann kommt das hier heraus:

Kartendaten: OSM&Contributer
Kartendarstellung: WanderReitKarte
Kartendaten: Januar 2012

Wie man sehen kann, stimmen die gelben Linien mit den weißen nicht überein.

Kartendaten: OSM&Contributer
Kartendarstellung: WanderReitKarte
Kartendaten: Januar 2012

Ich glaube, es hatte schon mal jemand geprüft und festgestellt, das MP 1706134 schneidet diese Kachengrenzen gar nicht.
http://www.openstreetmap.org/?lat=50.75 … on=1706134

quasilotte wrote:

Immer das übliche bei den MP's!

Mehere Wege ergeben ein MP

Splitter teilt im MP.
Dabei wird ein Way nicht erfasst da komplett ausserhalb der Kachel (bzw. in allen 3 Kacheln).

= Dadurch MP nicht geschlossen = nicht gefüllt !

Aber wie lösen wir dieses Problem? Nicht jeder bastelt seine eigenen Kartenausschnitte.

_torsten_ wrote:

Aber wie lösen wir dieses Problem? Nicht jeder bastelt seine eigenen Kartenausschnitte.

Wie hier schon oft gesagt wurde: Durch weniger Einsatz von Monsterpolygonen. 😉

Hallo,

also auf meiner Karte ist der Wald da, und dort wird er sogar auf 4 Kacheln verteilt. Bei einigen der obigen Karten sieht der Truppenübungsplatz Ohrdruf aber auch sehr abgeschnitten aus. Da er sehr gerade abgeschnitten ist, vermute ich auch mal das der Splitter eine sehr ungünstige Aufteilung der Kacheln vorgenommen hat.

Es wird halt Zeit das jemand den Splitter neu schreibt. Aber da fehlt es entweder am Wissen oder an der Zeit. Als Notlösung verwende ich inzwischen die Option "--overlap=10000" für den Splitter, bisher reicht das.
Aber vor allem in Canada habe ich damit trotzdem noch Kachel-Löcher...

Thorsten

chris66 wrote:

_torsten_ wrote:

Aber wie lösen wir dieses Problem? Nicht jeder bastelt seine eigenen Kartenausschnitte.

Wie hier schon oft gesagt wurde: Durch weniger Einsatz von Monsterpolygonen. 😉

Das findet meine volle Unterstützung. :daumen:

Dem gegenüber steht aber die Aussage: "Wir mappen nicht für ..." 😉

kukuk wrote:

Es wird halt Zeit das jemand den Splitter neu schreibt. Aber da fehlt es entweder am Wissen oder an der Zeit.

Könnte man das nicht in osmconvert/osmfilter integrieren? <Zaunpfahl-wink>

Gruß,
ajoessen

kukuk wrote:

...
Bei einigen der obigen Karten sieht der Truppenübungsplatz Ohrdruf aber auch sehr abgeschnitten aus. Da er sehr gerade abgeschnitten ist, vermute ich auch mal das der Splitter eine sehr ungünstige Aufteilung der Kacheln vorgenommen hat.
...

Die südliche Begrenzung war lange Zeit eine gerade Linie. Dazu gab´s / gibt´s auch einen bug in http://openstreetbugs.schokokeks.org/?z … ayers=B00T. Dieser bug ist kürzlich behoben worden. Auf den Kartenständen von November 2011 war da noch der alte Datenstand.

Edit: Das kann man der Kante des undeutlichen bing-Luftbildes noch erkennen.

Ich hab noch eine weitere Frage: Warum werden hier die "inner" nicht ausgeschnitten?

http://www.openstreetmap.org/browse/relation/1660339

Kartendaten: OSM&Contributer
Kartendarstellung: WanderReitKarte
Kartendaten: Januar 2012

Und ist das
http://www.openstreetmap.org/?relation=1660339
ein

chris66 wrote:

... Monsterpolygonen. 😉

ajoessen wrote:

kukuk wrote:

Es wird halt Zeit das jemand den Splitter neu schreibt. Aber da fehlt es entweder am Wissen oder an der Zeit.

Könnte man das nicht in osmconvert/osmfilter integrieren? <Zaunpfahl-wink>

Gruß,
ajoessen

osmconvert hat mit den Monster-MP's keine Probleme mehr dank --complex-ways.

Das Problem ist nur durch eine Komplexe logic im Splitter zu lösen.
Da gibts mittlerweile MP die gehen über 2° - da wird der Splitter immer zushclagen - Willste Dresden kriegste die ganze Sä. Schweiz dazu...

Analysiere das MP lege für alle Way's des MP's die komplett ausserhalb des Bereichs sind an der Kachelgrenze ein Way mit gleicher ID am ...

Ich weis dann nur nicht was passiert wenn mehrere Way's mit gleicher ID in einer IMG sind?
Wenn es damit Probleme gibt müsste das MP bzw. die Relation ganz neu aufggezogen werden (mit negativen ID bzw. ID+ 10^12 ... wie es für z.B bei Höhenliegen gemacht wird)

quasilotte wrote:

ajoessen wrote:

kukuk wrote:

Es wird halt Zeit das jemand den Splitter neu schreibt. Aber da fehlt es entweder am Wissen oder an der Zeit.

Könnte man das nicht in osmconvert/osmfilter integrieren? <Zaunpfahl-wink>

Gruß,
ajoessen

osmconvert hat mit den Monster-MP's keine Probleme mehr dank --complex-ways.

Ich wollte den Splitter unauffällig durch osmconvert/osmfilter ersetzen ;-)

Dazu fehlt eigentlich nur die Rechteck-Aufteilungsstrategie nach maxnodes.

Gruß,
ajoessen

Ich hab mit dem splitter von mkgmap sowie mkgmap schon länger keine Probleme mehr mit MP's. Auch mit riesiegen wie den finnischen und schwedischen Seen und auch wenn die Tile-Grenzen mitten durch gehen. _torsten_, hast du es denn schonmal ohne den Composer probiert?

Zu Monsterpolygonen vermeiden: Sicher ist das eine sinnvolle Sache, nur bin ich der Meinung, dass ein Objekt (See) auch als ein Polygon gemappt werden sollte.

quasilotte wrote:

osmconvert hat mit den Monster-MP's keine Probleme mehr dank --complex-ways.

Wenn man eine Kachel ausschneidet, die komplett innerhalb eines Polygons liegt, was passiert dann?

chris66 wrote:

quasilotte wrote:

osmconvert hat mit den Monster-MP's keine Probleme mehr dank --complex-ways.

Wenn man eine Kachel ausschneidet, die komplett innerhalb eines Polygons liegt, was passiert dann?

Ist mir noch nicht aufgefallen - da ich meist recht große Bereiche ausschneide.

Das See-Polygon allerdings wird dabei berücksichtigt.
Ein Ausschnitt im Innland wird wenn in der Aussgangsdatei das /ein Teil des Seepolygon enthält wird richtig berücksichtigt.

Schneide ich ohne --complex-ways einen Ausschnitt im Innland aus und aus diesem Ausschnitt nochmal einen Ausschnitt mit --complex-ways(Hinweis: Wegen 2GB Grenze bei osmconvert mit Windowssysthemen) dann Säuft das Festland beim Rendern ab.

aighes wrote:

_torsten_, hast du es denn schonmal ohne den Composer probiert?

Ich bastle ja mit dem composer eine sehr spartanische Karte zum Biken. Da man ja mit dem Mountainbike eigentlich überschaubare Streckenanschnitte (oftmals Rundstrecken) zurück legt, sind meine festgelegten Regionen immer kleiner als 1x1° (das größte bisher 0.6x0.5). Und wenn ich in andere Regione fahre, dann gibt´s eine neue Region.
Ich habe, so lange das MP (scheinbar) fehlerfrei ist, auch bisher keine Probleme mit fehlenden Wäldern oder fehlenden Innerrings gehabt.

Allerdings habe ich der Übersicht wegen ganz gerne größere Karten (also z. B. Deutschland) im MapSource liegen, u. a. die RWK.

Und da habe ich gesehen, dass die in RWK nicht immer alle Innerings ausgeschnitten werden, bei der velomap dagegen schon. Und da bei meinem (kleineren) Ausschnitt diese ebenfalls ausgeschnitten werden und Nop die Garmin-Karten auch mit dem composer bastelt, frage ich mich warum es da Unterschiede gibt. Und wie man diese eventuell lösen kann.

Edit: Tippfehler

_torsten_ wrote:

Ich hab noch eine weitere Frage: Warum werden hier die "inner" nicht ausgeschnitten?

http://www.openstreetmap.org/browse/relation/1660339

Keine Ahnung, die OSM-Daten sehen richtig aus.

Kartendaten: OSM&Contributer
Kartendarstellung: WanderReitKarte
Kartendaten: Januar 2012

Und ist das
http://www.openstreetmap.org/?relation=1660339
ein

chris66 wrote:

... Monsterpolygonen. 😉

Denke ich nicht.

_torsten_ wrote:

Ich glaube, es hatte schon mal jemand geprüft und festgestellt, das MP 1706134 schneidet diese Kachengrenzen gar nicht.
http://www.openstreetmap.org/?lat=50.75 … on=1706134

Ja, das war ich, siehe:
http://forum.openstreetmap.org/viewtopi … 93#p215893

_torsten_ wrote:

Der Fehler liegt nicht im MP, sondern im splitter, der die OSM-Daten garminverträglich zuschneidet.

Fraglich ist nur, wie und ob der Splitter hier beteiligt ist, da das genannte Wald-MP komplett in einer Kachel liegt.

_torsten_ wrote:

Und warum ist bei meinem Kartenlayout der Wald da?

Hm, die Kachelgrenzen sind bei dir die gleichen?

Welche Version von mkgmap/splitter und welche Optionen verwendest du?

Irgendwo muss es doch einen Unterschied geben.

Gruß,
Mondschein

Er verwendet den MapComposer. Dieser verwurstet zuerst die osm-Daten und teilt sie dann in Kacheln auf. Dieses Resultat übergibt der Composer dann an mkgmap. Was der Composer in den beiden Schritten macht, weiß aber nur Nop, da der Code nicht offen ist.

Daher war ja mein Vorschlag, das ganze mal mit dem normalen splitter zerteilen zulassen.

aighes wrote:

Dieser verwurstet zuerst die osm-Daten und teilt sie dann in Kacheln auf.

Das Aufteilen in Kacheln macht aber nicht der "Map Composer":
"das Schneiden von Kacheln nicht mehr direkt in Composer sondern mit mkgmap"
Quelle: http://composer.waldpfa.de

Gruß,
Mondschein

Könntest du das mal direkt verlinken. Ich hab mir soeben das Strathilfe-set geladen, in dem alle secundären Tools enthalten sind. Dort ist splitter.jar nicht enthalten.

aighes wrote:

Könntest du das mal direkt verlinken.

Steht direkt auf der verlinkten Seite unter "Aktuell" und wurde am 23.11.2011 hinzugefügt, siehe:
http://composer.waldpfa.de/index.php/MC … ction=diff

aighes wrote:

Ich hab mir soeben das Strathilfe-set geladen, in dem alle secundären Tools enthalten sind. Dort ist splitter.jar nicht enthalten.

Hm.

Gruß,
Mondschein

Neu in Version 0.87

• Kachelgrenzen werden nicht mehr von Composer zugeschnitten sondern von mkgmap

• weniger Artefakte an den Kanten
• langsamer, da Schnitte nicht mehr exakt sondern mit Überlappung für mkgmap erfolgen

Quelle: http://composer.waldpfa.de/index.php/MC/Download

Gruß,
Mondschein

Mondschein wrote:

Neu in Version 0.87

• Kachelgrenzen werden nicht mehr von Composer zugeschnitten sondern von mkgmap

• weniger Artefakte an den Kanten
• langsamer, da Schnitte nicht mehr exakt sondern mit Überlappung für mkgmap erfolgen

Quelle: http://composer.waldpfa.de/index.php/MC/Download

Gruß,
Mondschein

Ich habe gerade mal testhalber Map Composer 0.88 inklusive Starterset runtergeladen. Weder im Starterkit noch im MapComposer gibt es das splitter.jar. Auch in der GUI kann man unter Einstellungen nirgendwo den Pfad zum Splitter einstellen. Es sieht also nicht so aus, dass splitter hier zum Einsatz kommt.

Mir ist daher unklar, was Nop mit seinem Changelog Eintrag genau meint.

Benutzt man den splitter und benutzt mindestens die Default-Einstellungen für overlap, dann gibt es nur in sehr wenigen Fällen Problemen mit Multipolygonen.

WanMil

WanMil wrote:

Mir ist daher unklar, was Nop mit seinem Changelog Eintrag genau meint.

Dann werde ich bei Nop wahrscheinlich demnächst nachfragen.

Wäre gut, wenn der Fehler nur bei seinem Splitter auftritt und nicht bei dem Splitter "von" mkgmap.

Gruß,
Mondschein

Composer teilt die Daten immer in Kacheln auf.

Früher hat er auch gleich einen exakten Schnitt an den Kanten gemacht, was aber mit immer komplexeren Multipolygonkonstrukten immer aufwändiger wurde und immer schlechter funktioniert hat.

Jetzt läßt Composer einen Rand überstehen wie splitter auch und überläßt es mkgmap einen exakten Schnitt am Kartenrand durchzuführen.

bye
Nop