Wahrscheinlich sind die erwähnten Multipolygon-Relations zu komplex. Die ersten beiden (Relation: 14242231 | OpenStreetMap und https://www.openstreetmap.org/relation/9350128) sehen auf jeden Fall sehr komplex aus. Der OSM Inspector zeigt keine Fehler bei den Relationen an, also sind die wohl okay und die Software kommt einfach nicht damit zu recht, wie groß und komplex die sind.
Ich weiss nicht, wie Du die Daten erzeugt hast, vielleicht sind die Daten auch abgeschnitten worden und ein halbes Multipolygon kann man halt nicht zusammensetzen.
Die Fehlermeldungen von mkgmap, die mit “Internal error” anfangen sind immer ein Problem in mkgmap selbst. Passiert, wenn irgendwo nicht das rauskommt, was rauskommen sollte. Das Garmin Format kennt keine Multipolygone, mkgmap muss die tatsächlichen Flächen berechnen und dann auch noch diverse Größenlimits des IMG Formats in den einzelnen Zoom-Stufen beachten. Die Flächen werden also x-mal an irgendwelchen Stellen zerlegt und in manchen Fällen passiert es dann, das die zerlegten Flächen nicht mehr passen. Lässt sich leider meist nur mit genau den verwendeten Parametern und Eingabe-Daten reproduzieren.
Die Meldungen zu drive-on-x beziehen sich auf das Problem, dass Garmin in einer *.img Kachel nur ein Flag hat, um zu bestimmen, ob Rechts- oder Linksverkehr zu verwenden ist. Garmin selbst hat dann an der jeweiligen Grenze unregelmässige Kachel produziert, mkgmap kann das aber nicht. Auffallen tut das dort, wo Kreisverkehre sind.
Weiss nicht, ob das hilft. Ticker Berkin hat eine Datei, mit der er das Problem reproduzieren kann, aber er weiss nicht, wie er es lösen soll. Meine Birne ist leider nicht mehr fit genug, um mich in derlei komplexe Dinge reinzudenken.
Siehe auch diesen Faden: [mkgmap-dev] Internal Error Failed to render Multipolygon
@toc-rox
Verwendest Du die Option --improve-overview ?
Verschwindet die Meldung ohne diese Option?
Ich werde mal schauen, ob man bei der Meldung noch weitere Infos hinzufügen kann. zoomlevel und Position des Problems wären sicher hilfreich, um nachvollziehen zu können, ob man den Fehler überhaupt in der Karte sieht.
Nein, man sieht den Fehler nicht. Entweder sind die MPs irrelevant (Adriatisches Meer (9350128), Golf von Biskaya (7156290)), oder sie werden korrekt gerendert (el Segre (5373874), Relation: 9529527).
I opened relation 9529527 in Josm and the outer ways of the polygon are not ordered correctly. Strangely enough, the Josm validator doesn’t complain, but this might be the cause of the problem. I sorted the outers and they form a single closed area. Couldn’t save because the osm server is down.
Also the relation is not a valid polygon in the GIS definition of a polygon. In at least 2 places there are inner polygons that touch each other with a shared line. To make it a valid polygon, these touching inners should be combined in to one polygon.
The order of members is a nice to have but not required.
The order of the ways doesn’t matter at all for mkgmap. Also the touching inner rings should be no problem.
As I wrote before: The error is not in the data, it is in the way how mkgmap processes a complex (many points) multipolygon which also has many inner rings.
OK, sorry, I’ve made an error.
The program mkgmap may report such an internal error if e.g. a complex multipolygon is invald because a ring that has role inner is outside. I try to find out why this only happens under certain conditions.
Wegen “Failed to render …”:
Die Probleme ergaben sich durch einen ungeschickt gewählten Parameter beim Vorwerarbeiten von komplexen Multipolygonen. Sollte mit Version 4923 behoben sein oder zumindest in der Anzahl deutlich reduziert. Details siehe WebSVN - mkgmap - Rev 4923 - /
Ich habe die Karten für “BIH+” und “HUN+” mit der Version mkgmap 4923 neu erzeugt. Dabei sind keine Fehler “internal error” aufgetreten. Die Daten waren dieselben mit denen unter mkgmap 4922 die Fehler noch aufgetreten sind. Fazit: Die Version mkgmap 4923 behebt den Defekt.