mkgmap Fehlermeldung

Walter Schlögl wrote:

Ich bekomme folgende Fehlermeldung:
SCHWERWIEGEND (LocationHook): Cannot find any mkgmap tag for [boundary=administrative; name=Region Bodensee-Oberschwaben; type=multipolygon; ...]

Falls ich die Meldung richtig interpretiere, hätte ich folgende Frage:
Um welchen TAG handelt es sich denn dabei, der für mkgmap hier an dieser Grenze fehlt?

Hallo Walter

Das ist jetzt nur geraten. Fehlt da eventuel ein Tagg admin_level=* ?
Oder ist "Region Bodensee-Oberschwaben" gar keine Verwaltungseinheit und das "boundary=administrative" damit per se falsch?

Wie gesagt ist nur geraten, aber es gibt nun einmal Probleme bei OSM unscharfe Begriffe wie Regionen (z.B. Dachsteingruppe oder Alpen oder Oberrheingraben oder Adria oder thyrenisches Merr oder ...) angemessen zu erfassen.
Dazu gab es schon mehrfach Diskussionen.

Meine Vermutung beruht auf dem Text aus dem Wikipedia-Artikel http://de.wikipedia.org/wiki/Bodenseekreis

Der Bodenseekreis ist ein Landkreis in Baden-Württemberg. Er bildet zusammen mit dem Landkreis Ravensburg und dem Landkreis Sigmaringen die Region Bodensee-Oberschwaben im Regierungsbezirk Tübingen.

Landkreise und Regierungsbezirke sind klar definierte Verwaltungseinheiten. Eine Region aus mehreren Landkreisen ist das nicht. So gilt für die bedien Landschaftsverbände Rheinland und Westfalen-Lippe in Nordrhein-Westfalen folgender Satz laut http://de.wikipedia.org/wiki/Landschaft … -Westfalen

Die Landschaftsverbände haben aber keine Gebietshoheit. Verfassungsrechtlich gelten die Landschaftsverbände heute als ein Teil der kommunalen Selbstverwaltung. Dieser Vorstellung nach sind sie ein Zusammenschluss der Gebietskörperschaften zur Erfüllung von Aufgaben, die über die Leistungsfähigkeit der einzelnen Kommunen hinausgehen.

Sprich die Landschaftsverbände sind keine Verwaltungseinheiten im Sinne von boundary=administrative, da ihnen die Gebietshoheit fehlt. Ich vermute, dass es bei der Region Bodensee-Oberschwaben ähnlich gelagert ist. So ist laut http://de.wikipedia.org/wiki/Region_Bod … erschwaben die Region Bodensee-Oberschwaben 'nur' für die Regionalplanung zuständig.

Edbert (EvanE)

Walter Schlögl wrote:

Ich bekomme folgende Fehlermeldung:

SCHWERWIEGEND (LocationHook): Cannot find any mkgmap tag for [boundary=administrative; name=Region Bodensee-Oberschwaben; type=multipolygon; ...]

Falls ich die Meldung richtig interpretiere, hätte ich folgende Frage:
Um welchen TAG handelt es sich denn dabei, der für mkgmap hier an dieser Grenze fehlt?

Walter

Es geht wohl um diese Relation:
http://www.openstreetmap.org/browse/relation/1608487
Die hat in der Tat kein admin_level. dann gibt es in deinen Regeln wohl keine Umsetzung für sowas.

Gruß,
ajoessen

Dies dürften die mkgmap-Verarbeitungsregeln sein, die vermutlich alle nicht "greifen":

1. Germany = DEU cities
   

mkgmap:country=DEU & mkgmap:city!=* & mkgmap:admin_level8=* { set mkgmap:city='${mkgmap:admin_level8}' }
mkgmap:country=DEU & mkgmap:city!=* & mkgmap:admin_level7=* { set mkgmap:city='${mkgmap:admin_level7}' }
mkgmap:country=DEU & mkgmap:city!=* & mkgmap:admin_level6=* { set mkgmap:city='${mkgmap:admin_level6}' }
mkgmap:country=DEU & mkgmap:city!=* & mkgmap:admin_level9=* { set mkgmap:city='${mkgmap:admin_level9}' }
mkgmap:country=DEU & mkgmap:city!=* & mkgmap:admin_level10=* { set mkgmap:city='${mkgmap:admin_level10}' }

Klaus

Die Ursache verstehe ich nun, aber wie sieht eine mögliche Lösung aus.

Ich denke, dass boundary=region statt boundary=administrative die beste Lösung wäre.
Das MP von Südbayern ist jedenfalls als Region erfasst.

Was mich dabei noch wundert, dass bisher niemand auf diesen Fehler gestoßen ist, bzw. ihn behoben hat.
Ich bin doch sicher nicht der erste, der mit mkgmap einen Garmin-Plan erstellt und sich die Fehlermeldungen ansieht.

Walter

Weil man die Meldungen egtl. getrost ignorieren kann 😉

Ich denke schon, dass das eine administrative Grenze ist, von daher halte ich das nicht für falsch. Ebenso, dass es kein admin_level gibt.

@Walter
Lade von hier
http://www.navmaps.eu/index.php/developers/bound

die fehlenden Boundaries herunter und entpacke sie in das Arbeitsverzeichnis in dem die erstellten *.img liegen.

Das brauchst Du nur einmal zu machen.

Bernd

aighes wrote:

Ich denke schon, dass das eine administrative Grenze ist, von daher halte ich das nicht für falsch. Ebenso, dass es kein admin_level gibt.

Nun ja, nur für Teilbereiche (hier Regionalplanung). Es gibt keine Gebietshoheit wie z.B. bei den Regierungsbezirken in NRW. Insoweit ist das Fehlen von admin_level nachvollziehbar.

Das ist hier das Problem. boundary=administrative zusammen mit admin_level=* bildet eine Verwaltungshierarchie ab. Alles was dazu quer liegt wie Regionen zur Regionalplanung ist etwas irritierend.
Es ist halt die Frage, ob bei nur teilweiser Weisungskompetenz der Wert administrative wirklich angemessen ist, oder ob man dafür einen besseren (dann leider neuen) Wert finden kann/sollte.

Anderes Beispiel ist die Region aus drei neuen Bundesländern. Da weis man auch nicht, wie man die einordnen soll. Eine ähnliche Frage, wäre die Europäische Union (der Wirtschaftsraum) oder noch schwieriger die Eurozone innerhalb der EU.

Edbert (EvanE)

Hallo Bernd, danke für den Link, diese Grenzen verwende ich bereits, trotzdem kommt die Fehlermeldung.

Die Angabe von boundary=region bei Südbayern war wohl ein Versuch, eine Lösung zu finden.
Nachdem region erst 2x weltweit vorkommt, kann man das nicht gerade als verbreitet ansehen.
Ich werde also mit der Fehlermeldung leben müssen.

Ich bekomme noch eine weitere seltsame Fehlermeldung.
In einem Gebiet, in dem absolut keine Daten liegen, meldet mkgmap den Fehler

SCHWERWIEGEND (MapSplitter): Area to small to split at http://www.openstreetmap.org/?mlat=46.9 … 94&zoom=17
(reduce the density of points, length of lines, etc.)

Ich frage mich, wie ich die Punktdichte reduzieren soll, wenn es gar keine Punkte gibt.
Der Splitter hat keine Fehlermeldung geliefert.

Walter

Walter Schlögl wrote:

Die Ursache verstehe ich nun, aber wie sieht eine mögliche Lösung aus.

Ich denke, dass boundary=region statt boundary=administrative die beste Lösung wäre.
Das MP von Südbayern ist jedenfalls als Region erfasst.

Was mich dabei noch wundert, dass bisher niemand auf diesen Fehler gestoßen ist, bzw. ihn behoben hat.
Ich bin doch sicher nicht der erste, der mit mkgmap einen Garmin-Plan erstellt und sich die Fehlermeldungen ansieht.

Walter

Kann man nicht in mkgmap eine Fallback-Regel erstellen für boundary ohne admin_level?
Soweit ich das verstanden habe, sucht mkgamp alle Regeln durch bis zur ersten passenden. Also müsste der fallback am Schluß eingefügt werden.

Gruß,
ajoessen

Der LocationHook ist fest implementiert. Man müsste die boundary-Daten besser Filtern. Das führt dann aber dazu, dass richtige Fehler (also wo wirklich ein admin_level fehlt) nicht mehr gemeldet werden.

Das eigentliche Problem ist doch, dass man für diese Region keinen admin_level angeben kann, weil es eigentlich gar keine administrative Grenze ist.

Falls es sich bei dieser Region nicht um eine boundary=administrative handelt, sollte sie auch nicht als solche erfasst werden.
Falls es eine zivile oder politische Grenze ist, gibt es ja boundary=civil und political, und mit boundary:type oder border_type kann das ja noch näher beschrieben werden.

Wofür wird das boundary=civil derzeit eigentlich verwendet, im Wiki ist darüber nichts zu finden.

Walter

Walter Schlögl wrote:

Hallo Bernd, danke für den Link, diese Grenzen verwende ich bereits, trotzdem kommt die Fehlermeldung.

Die Angabe von boundary=region bei Südbayern war wohl ein Versuch, eine Lösung zu finden.
Nachdem region erst 2x weltweit vorkommt, kann man das nicht gerade als verbreitet ansehen.
Ich werde also mit der Fehlermeldung leben müssen.

Ich nehme als kleinste Größe den jeweiligen Staat, also Germany usw., aber die Meldung tritt hier nicht (mehr) auf.

Walter Schlögl wrote:

Ich bekomme noch eine weitere seltsame Fehlermeldung.
In einem Gebiet, in dem absolut keine Daten liegen, meldet mkgmap den Fehler

SCHWERWIEGEND (MapSplitter): Area to small to split at http://www.openstreetmap.org/?mlat=46.9 … 94&zoom=17
(reduce the density of points, length of lines, etc.)

Ich frage mich, wie ich die Punktdichte reduzieren soll, wenn es gar keine Punkte gibt.
Der Splitter hat keine Fehlermeldung geliefert.

Walter

Dabei dürfte es sich um den Schwerpunkt einer Fläche handeln, hier war die Insel Rügen eine Ursache, möglicherweise weil die umlaufende Grenzrelation nicht komplett im OSM-File drin war.

Ich verzichte mittlerweile auf eine Vorgabe der point-density in der Befehlszeile und nehme die MKMAP-defaults.

Meine Konfiguration findest Du hier:
https://github.com/berndw1960/creategmap

Ich bin nicht ganz so der Profi beim Bau der Karte, deswegen kann ich nicht mehr dazu schreiben. das Script war nur so ein Versuch 😉

Bernd

Hallo Bernd,

ich gebe auch keine point-density beim Aufruf an.
Wenn die Meldung keine weitere Bedeutung hat, als dass sie sich einfach meldet, werde ich sie halt ignorieren.

Walter

Mit welcher mkgmap Version treten die Fehler auf?

Die Meldung
SCHWERWIEGEND (LocationHook): Cannot find any mkgmap tag for [boundary=administrative; name=Region Bodensee-Oberschwaben; type=multipolygon; ...]
sollte nur noch in sehr seltenen Fällen auftreten, wenn die precompiled bounds mit mkgmap >= r2051 erstellt wurden.

Die Meldung
SCHWERWIEGEND (MapSplitter): Area to small to split at http://www.openstreetmap.org/?mlat=46.9 … 94&zoom=17 (reduce the density of points, length of lines, etc.)
könnte verschwinden, wenn man mkgmap >= r2028 verwendet.

Have fun!
WanMil

Walter Schlögl wrote:

Wofür wird das boundary=civil derzeit eigentlich verwendet, im Wiki ist darüber nichts zu finden.

Hallo Walter

Für zivile Grenzen wie es der Wert sagt, also solche, die keine Verwaltungsgrenzen sind.
Das reicht im Prinzip von einem einzelnen Grundstück, über Flurstücke und Fluren.

Die einzige Anwendung von der ich weiß, sind Waldstücke (Schläge) im Reichswald. Das ist in dem Fall die kleinste Einheit für die dortige Waldnutzung. Ach ja, die sind auch entsprechend ausgeschildert, also vor Ort nachprüfbar.

Edbert (EvanE)

Die mkgmap Version ist 2038, vielleicht wird es bei einer späteren Version ja noch besser bezüglich der MapSplitter Meldung.
Derzeit kommt fast täglich eine neue Version heraus.

Die Region Südbayern scheint mir als boundary=region recht plausibel erfasst zu sein.
Was spricht dagegen, das gleiche mit der Region Bodensee-Oberschwaben zu machen.

Mir ist klar, dass boundary=region weder dokumentiert noch häufig verwendet ist.
Aber solange es nichts besseres gibt, wäre es vorerst mal eine mögliche Lösung zur besseren Erfassung.

Walter

mkgmap-Version: 2136
splitter-Version: 185
Boundaries vom 02.12.2011 (gestern aktualisiert)
Damit bekomme ich ebenfalls location hooks in der Umgebung von Brieskow-Finkenheerd
Relationen
http://www.openstreetmap.org/browse/relation/1384799
http://www.openstreetmap.org/browse/relation/1384804
http://www.openstreetmap.org/browse/relation/1384816

Benutze ich die Boundaries vom 18.07.2011 (habe ich bisher genommen) gibt es keine Meldungen

Ich verwende fast nur die jeweils aktuellsten Versionen

habe aber keine speziellen mkgmap-tags zu den Boundaries in den Stylefiles, mangels für mich leider nötiger deutscher Beschreibung

Bernd

Editiert wegen Fehlern

berndw wrote:

mkgmap-Version: 2136
splitter-Version: 185
Boundaries vom 02.12.2011 (gestern aktualisiert)
Damit bekomme ich ebenfalls location hooks in der Umgebung von Brieskow-Finkenheerd
Relationen
http://www.openstreetmap.org/browse/relation/1384799
http://www.openstreetmap.org/browse/relation/1384804
http://www.openstreetmap.org/browse/relation/1384816

Editiert wegen Fehlern

Das sind die Fehlermeldungen wenn ich die Boundaries aus world_20111202.zip verwende

velomap-layer␣build␣with␣aiostyles
SCHWERWIEGEND␣(LocationHook):␣/home/bernd/share/osm/map_build/tiles/63240076.osm.pbf:␣Referenced␣boundary␣not␣available:␣[postal_code=15295;␣note=15295␣Brieskow-Finkenheerd;␣mkgmap:lies_in=2:r51477;4:r62504;5:r23860;6:r62628;7:r1384836;␣postal_code_level=8;␣mkgmap:bzip=15295;␣boundary=postal_code;␣type=multipolygon;␣mkgmap:boundaryid=r1384804]␣refs␣r1384836
SCHWERWIEGEND␣(LocationHook):␣/home/bernd/share/osm/map_build/tiles/63240076.osm.pbf:␣Referenced␣boundary␣not␣available:␣[mkgmap:lies_in=2:r51477;4:r62504;5:r23860;6:r62628;7:r1384836;␣admin_level=8;␣mkgmap:bname=Brieskow-Finkenheerd;␣de:amtlicher_gemeindeschluessel=12067076;␣boundary=administrative;␣name=Brieskow-Finkenheerd;␣type=multipolygon;␣mkgmap:boundaryid=r1384835]␣refs␣r1384836
SCHWERWIEGEND␣(LocationHook):␣/home/bernd/share/osm/map_build/tiles/63240076.osm.pbf:␣Referenced␣boundary␣not␣available:␣[TMC:cid_58:tabcd_1:Class=Area;␣mkgmap:lies_in=2:r51477;4:r62504;5:r23860;6:r62628;7:r1384836;␣admin_level=8;␣mkgmap:bname=Vogelsang;␣de:amtlicher_gemeindeschluessel=12067508;␣boundary=administrative;␣name=Vogelsang;␣TMC:cid_58:tabcd_1:LCLversion=9.00;␣TMC:cid_58:tabcd_1:LocationCode=34369;␣type=multipolygon;␣mkgmap:boundaryid=r1384832]␣refs␣r1384836
SCHWERWIEGEND␣(LocationHook):␣/home/bernd/share/osm/map_build/tiles/63240076.osm.pbf:␣Referenced␣boundary␣not␣available:␣[TMC:cid_58:tabcd_1:Class=Area;␣mkgmap:lies_in=2:r51477;4:r62504;5:r23860;6:r62628;7:r1384836;␣admin_level=8;␣mkgmap:bname=Ziltendorf;␣de:amtlicher_gemeindeschluessel=12067552;␣boundary=administrative;␣name=Ziltendorf;␣TMC:cid_58:tabcd_1:LCLversion=9.00;␣TMC:cid_58:tabcd_1:LocationCode=4682;␣type=multipolygon;␣mkgmap:boundaryid=r1384815]␣refs␣r1384836
SCHWERWIEGEND␣(LocationHook):␣/home/bernd/share/osm/map_build/tiles/63240076.osm.pbf:␣Referenced␣boundary␣not␣available:␣[mkgmap:lies_in=2:r51477;4:r62504;5:r23860;6:r62628;7:r1384836;␣admin_level=8;␣mkgmap:bname=Wiesenau;␣de:amtlicher_gemeindeschluessel=12067528;␣boundary=administrative;␣name=Wiesenau;␣type=multipolygon;␣mkgmap:boundaryid=r1384805]␣refs␣r1384836
SCHWERWIEGEND␣(LocationHook):␣/home/bernd/share/osm/map_build/tiles/63240076.osm.pbf:␣Referenced␣boundary␣not␣available:␣[mkgmap:lies_in=2:r51477;4:r62504;5:r23860;6:r62628;7:r1384836;␣admin_level=8;␣mkgmap:bname=Groß␣Lindow;␣de:amtlicher_gemeindeschluessel=12067180;␣boundary=administrative;␣name=Groß␣Lindow;␣type=multipolygon;␣mkgmap:boundaryid=r1384799]␣refs␣r1384836
SCHWERWIEGEND␣(LocationHook):␣/home/bernd/share/osm/map_build/tiles/63240128.osm.pbf:␣Referenced␣boundary␣not␣available:␣[postal_code=15295;␣note=15295␣Brieskow-Finkenheerd;␣mkgmap:lies_in=2:r51477;4:r62504;5:r23860;6:r62628;7:r1384836;␣postal_code_level=8;␣mkgmap:bzip=15295;␣boundary=postal_code;␣type=multipolygon;␣mkgmap:boundaryid=r1384804]␣refs␣r1384836
SCHWERWIEGEND␣(LocationHook):␣/home/bernd/share/osm/map_build/tiles/63240128.osm.pbf:␣Referenced␣boundary␣not␣available:␣[mkgmap:lies_in=2:r51477;4:r62504;5:r23860;6:r62628;7:r1384836;␣admin_level=8;␣mkgmap:bname=Brieskow-Finkenheerd;␣de:amtlicher_gemeindeschluessel=12067076;␣boundary=administrative;␣name=Brieskow-Finkenheerd;␣type=multipolygon;␣mkgmap:boundaryid=r1384835]␣refs␣r1384836
SCHWERWIEGEND␣(LocationHook):␣/home/bernd/share/osm/map_build/tiles/63240128.osm.pbf:␣Referenced␣boundary␣not␣available:␣[TMC:cid_58:tabcd_1:Class=Area;␣mkgmap:lies_in=2:r51477;4:r62504;5:r23860;6:r62628;7:r1384836;␣admin_level=8;␣mkgmap:bname=Ziltendorf;␣de:amtlicher_gemeindeschluessel=12067552;␣boundary=administrative;␣name=Ziltendorf;␣TMC:cid_58:tabcd_1:LCLversion=9.00;␣TMC:cid_58:tabcd_1:LocationCode=4682;␣type=multipolygon;␣mkgmap:boundaryid=r1384815]␣refs␣r1384836
SCHWERWIEGEND␣(LocationHook):␣/home/bernd/share/osm/map_build/tiles/63240128.osm.pbf:␣Referenced␣boundary␣not␣available:␣[mkgmap:lies_in=2:r51477;4:r62504;5:r23860;6:r62628;7:r1384836;␣admin_level=8;␣mkgmap:bname=Wiesenau;␣de:amtlicher_gemeindeschluessel=12067528;␣boundary=administrative;␣name=Wiesenau;␣type=multipolygon;␣mkgmap:boundaryid=r1384805]␣refs␣r1384836
SCHWERWIEGEND␣(LocationHook):␣/home/bernd/share/osm/map_build/tiles/63240128.osm.pbf:␣Referenced␣boundary␣not␣available:␣[mkgmap:lies_in=2:r51477;4:r62504;5:r23860;6:r62628;7:r1384836;␣admin_level=8;␣mkgmap:bname=Groß␣Lindow;␣de:amtlicher_gemeindeschluessel=12067180;␣boundary=administrative;␣name=Groß␣Lindow;␣type=multipolygon;␣mkgmap:boundaryid=r1384799]␣refs␣r1384836

Mir fällt nur auf, dass zwei Kacheln betroffen sind

Bernd

Das sind die Fehlermeldungen wenn ich die Boundaries aus world_20111202.zip verwende

velomap-layer␣build␣with␣aiostyles
SCHWERWIEGEND␣(LocationHook):␣/home/bernd/share/osm/map_build/tiles/63240076.osm.pbf:␣Referenced␣boundary␣not␣available:␣[postal_code=15295;␣note=15295␣Brieskow-Finkenheerd;␣mkgmap:lies_in=2:r51477;4:r62504;5:r23860;6:r62628;7:r1384836;␣postal_code_level=8;␣mkgmap:bzip=15295;␣boundary=postal_code;␣type=multipolygon;␣mkgmap:boundaryid=r1384804]␣refs␣r1384836
SCHWERWIEGEND␣(LocationHook):␣/home/bernd/share/osm/map_build/tiles/63240076.osm.pbf:␣Referenced␣boundary␣not␣available:␣[mkgmap:lies_in=2:r51477;4:r62504;5:r23860;6:r62628;7:r1384836;␣admin_level=8;␣mkgmap:bname=Brieskow-Finkenheerd;␣de:amtlicher_gemeindeschluessel=12067076;␣boundary=administrative;␣name=Brieskow-Finkenheerd;␣type=multipolygon;␣mkgmap:boundaryid=r1384835]␣refs␣r1384836
SCHWERWIEGEND␣(LocationHook):␣/home/bernd/share/osm/map_build/tiles/63240076.osm.pbf:␣Referenced␣boundary␣not␣available:␣[TMC:cid_58:tabcd_1:Class=Area;␣mkgmap:lies_in=2:r51477;4:r62504;5:r23860;6:r62628;7:r1384836;␣admin_level=8;␣mkgmap:bname=Vogelsang;␣de:amtlicher_gemeindeschluessel=12067508;␣boundary=administrative;␣name=Vogelsang;␣TMC:cid_58:tabcd_1:LCLversion=9.00;␣TMC:cid_58:tabcd_1:LocationCode=34369;␣type=multipolygon;␣mkgmap:boundaryid=r1384832]␣refs␣r1384836
SCHWERWIEGEND␣(LocationHook):␣/home/bernd/share/osm/map_build/tiles/63240076.osm.pbf:␣Referenced␣boundary␣not␣available:␣[TMC:cid_58:tabcd_1:Class=Area;␣mkgmap:lies_in=2:r51477;4:r62504;5:r23860;6:r62628;7:r1384836;␣admin_level=8;␣mkgmap:bname=Ziltendorf;␣de:amtlicher_gemeindeschluessel=12067552;␣boundary=administrative;␣name=Ziltendorf;␣TMC:cid_58:tabcd_1:LCLversion=9.00;␣TMC:cid_58:tabcd_1:LocationCode=4682;␣type=multipolygon;␣mkgmap:boundaryid=r1384815]␣refs␣r1384836
SCHWERWIEGEND␣(LocationHook):␣/home/bernd/share/osm/map_build/tiles/63240076.osm.pbf:␣Referenced␣boundary␣not␣available:␣[mkgmap:lies_in=2:r51477;4:r62504;5:r23860;6:r62628;7:r1384836;␣admin_level=8;␣mkgmap:bname=Wiesenau;␣de:amtlicher_gemeindeschluessel=12067528;␣boundary=administrative;␣name=Wiesenau;␣type=multipolygon;␣mkgmap:boundaryid=r1384805]␣refs␣r1384836
SCHWERWIEGEND␣(LocationHook):␣/home/bernd/share/osm/map_build/tiles/63240076.osm.pbf:␣Referenced␣boundary␣not␣available:␣[mkgmap:lies_in=2:r51477;4:r62504;5:r23860;6:r62628;7:r1384836;␣admin_level=8;␣mkgmap:bname=Groß␣Lindow;␣de:amtlicher_gemeindeschluessel=12067180;␣boundary=administrative;␣name=Groß␣Lindow;␣type=multipolygon;␣mkgmap:boundaryid=r1384799]␣refs␣r1384836
SCHWERWIEGEND␣(LocationHook):␣/home/bernd/share/osm/map_build/tiles/63240128.osm.pbf:␣Referenced␣boundary␣not␣available:␣[postal_code=15295;␣note=15295␣Brieskow-Finkenheerd;␣mkgmap:lies_in=2:r51477;4:r62504;5:r23860;6:r62628;7:r1384836;␣postal_code_level=8;␣mkgmap:bzip=15295;␣boundary=postal_code;␣type=multipolygon;␣mkgmap:boundaryid=r1384804]␣refs␣r1384836
SCHWERWIEGEND␣(LocationHook):␣/home/bernd/share/osm/map_build/tiles/63240128.osm.pbf:␣Referenced␣boundary␣not␣available:␣[mkgmap:lies_in=2:r51477;4:r62504;5:r23860;6:r62628;7:r1384836;␣admin_level=8;␣mkgmap:bname=Brieskow-Finkenheerd;␣de:amtlicher_gemeindeschluessel=12067076;␣boundary=administrative;␣name=Brieskow-Finkenheerd;␣type=multipolygon;␣mkgmap:boundaryid=r1384835]␣refs␣r1384836
SCHWERWIEGEND␣(LocationHook):␣/home/bernd/share/osm/map_build/tiles/63240128.osm.pbf:␣Referenced␣boundary␣not␣available:␣[TMC:cid_58:tabcd_1:Class=Area;␣mkgmap:lies_in=2:r51477;4:r62504;5:r23860;6:r62628;7:r1384836;␣admin_level=8;␣mkgmap:bname=Ziltendorf;␣de:amtlicher_gemeindeschluessel=12067552;␣boundary=administrative;␣name=Ziltendorf;␣TMC:cid_58:tabcd_1:LCLversion=9.00;␣TMC:cid_58:tabcd_1:LocationCode=4682;␣type=multipolygon;␣mkgmap:boundaryid=r1384815]␣refs␣r1384836
SCHWERWIEGEND␣(LocationHook):␣/home/bernd/share/osm/map_build/tiles/63240128.osm.pbf:␣Referenced␣boundary␣not␣available:␣[mkgmap:lies_in=2:r51477;4:r62504;5:r23860;6:r62628;7:r1384836;␣admin_level=8;␣mkgmap:bname=Wiesenau;␣de:amtlicher_gemeindeschluessel=12067528;␣boundary=administrative;␣name=Wiesenau;␣type=multipolygon;␣mkgmap:boundaryid=r1384805]␣refs␣r1384836
SCHWERWIEGEND␣(LocationHook):␣/home/bernd/share/osm/map_build/tiles/63240128.osm.pbf:␣Referenced␣boundary␣not␣available:␣[mkgmap:lies_in=2:r51477;4:r62504;5:r23860;6:r62628;7:r1384836;␣admin_level=8;␣mkgmap:bname=Groß␣Lindow;␣de:amtlicher_gemeindeschluessel=12067180;␣boundary=administrative;␣name=Groß␣Lindow;␣type=multipolygon;␣mkgmap:boundaryid=r1384799]␣refs␣r1384836

Mir fällt nur auf, dass zwei Kacheln betroffen sind

Bernd

Das sind andere Fehlermeldungen. Die Meldungen könnten inzwischen vielleicht besser als WARNING ausgegeben werden.

Ursache ist folgende:
Alle boundaries bekommen die Info innerhalb welcher anderen Boundaries sie sich befinden (also z.B. Bei bei Stadt Nürtingen stehen die ids von Kreis Esslingen, Baden-Würtemberg, Deutschland drin).
In dem vorliegenden Fall gibt es Verweise auf die Relation 1384836 (r1384836).
Relation 1384836:
admin_level = 7
boundary = administrative
name:prefix = Amt
note = Brieskow-Finkenheerd
type = multipolygon

Diese Relation hat aber das Problem, dass sie gar nicht genutzt werden kann. Sie wird zwar in die precompiled bounds mit aufgenommen, da sie ein Tag besitzt, welches mit name anfängt (name:prefix). Dieses steht aber nicht in der mkgmap option name-tag-list und daher kann für diese boundary kein Name ermittelt werden. Sie wird also weggeschmissen und die Referenz von den anderen boundaries kann nicht genutzt werden. Weist auf einen Problem in der Relation 1384836 hin, ist aber effektiv für die Kartenerstellung in mkgmap kein Problem.

WanMil

WanMil wrote:

Das sind andere Fehlermeldungen. Die Meldungen könnten inzwischen vielleicht besser als WARNING ausgegeben werden.

Es war mir schon klar das es andere Meldungen sind, aber Threads zum Thema mkmap und Fehlermeldungen sind im deutschen Forum ziemlich rar. Ich wollte den Thread auch nicht kapern. Und für mich verständliche Dokumentation habe ich bisher auch nciht gefunden.

WanMil wrote:

Ursache ist folgende:
Alle boundaries bekommen die Info innerhalb welcher anderen Boundaries sie sich befinden (also z.B. Bei bei Stadt Nürtingen stehen die ids von Kreis Esslingen, Baden-Würtemberg, Deutschland drin).
In dem vorliegenden Fall gibt es Verweise auf die Relation 1384836 (r1384836).
Relation 1384836:
admin_level = 7
boundary = administrative
name:prefix = Amt
note = Brieskow-Finkenheerd
type = multipolygon

Diese Relation hat aber das Problem, dass sie gar nicht genutzt werden kann. Sie wird zwar in die precompiled bounds mit aufgenommen, da sie ein Tag besitzt, welches mit name anfängt (name:prefix). Dieses steht aber nicht in der mkgmap option name-tag-list und daher kann für diese boundary kein Name ermittelt werden. Sie wird also weggeschmissen und die Referenz von den anderen boundaries kann nicht genutzt werden. Weist auf einen Problem in der Relation 1384836 hin, ist aber effektiv für die Kartenerstellung in mkgmap kein Problem.

WanMil

In der Historie zu dieser Relation habe ich den entsprechenden Kommentar gelesen, aber eine so einfache Lösung hatte ich nicht 😉

Danke für den Hinweis

Bernd

berndw wrote:

In der Historie zu dieser Relation habe ich den entsprechenden Kommentar gelesen, aber eine so einfache Lösung hatte ich nicht 😉

Bernd

Welchen Sinn macht es, dem Verwaltungsbezirk den Namen zu entziehen?
Außer, um mkgmap ein Bein zu stellen?

Ist jetzt wieder drin.

Gruß,
ajoessen

ajoessen wrote:

berndw wrote:

In der Historie zu dieser Relation habe ich den entsprechenden Kommentar gelesen, aber eine so einfache Lösung hatte ich nicht 😉

Bernd

Welchen Sinn macht es, dem Verwaltungsbezirk den Namen zu entziehen?
Außer, um mkgmap ein Bein zu stellen?

Ist jetzt wieder drin.

Gruß,
ajoessen

Anscheinend sollte der Name nicht mehrfach gerendert werden 😉
Mich stört das auch ein wenig, aber das macht man besser mit Renderregeln

Bernd