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
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
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/Landschaftsverb%C3%A4nde_in_Nordrhein-Westfalen
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_Bodensee-Oberschwaben die Region Bodensee-Oberschwaben ‘nur’ für die Regionalplanung zuständig.
Edbert (EvanE)
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”:
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
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.96074&mlon=12.14494&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
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
Ich nehme als kleinste Größe den jeweiligen Staat, also Germany usw., aber die Meldung tritt hier nicht (mehr) auf.
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
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
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