Maar als ik de tegels gewoon hernoem van 1 tot aan het aantal tegels in de kaart (dus maximaal 999 tegels in een kaart, waarbij 000 gebruikt wordt voor de overview tegel), zowel intern als de bestandsnaam, dan komt het toch ook wel goed? Of zie ik iets over het hoofd?
Ah, zo bedoel je. Dus stel je hebt de NL set bestaande uit
63241878.img
63241879.img
63241881.img
63241882.img
enz
Dan hernummer je die om naar
001.img
002.img
003.img
enz
En daar zet je dan 24528 voor.
24528001.img
24528002.img
24528003.img
Dan is de vraag nog, hoe je die 24528001 weer in de interne hex code zet in de img zelf, want dat moet ook nog, want Garmin kijkt alleen naar dat interne getal, niet de bestandsnaam. Dat zou dan met gmt moeten. Ik zie bij gmaptool die opties, absolute, substract en add.
Zou dat dan met absolute kunnen? Zal het even aan popej vragen.
BTW ben je van plan de tegelnummering voor alle sets om te nummeren, of uitsluitend voor de gmapsupp.img generatie?
Als alle sets worden hernummerd is nl osm combiner niet meer mogelijk omdat dubbele identieke tegels dan andere nummers hebben.
De vraag is of osm combiner nog wel nodig is omdat je op de site die service ook al aanbied in de vorm van de custom mapgeneratie.
Op dit moment wordt mkgmap slechts eenmaal aangeroepen, voor zowel, NSIS, gmapsupp en TDB generatie. In dat geval is het makkelijk om alle kaartversies dezelfde originele tegels te geven. Het is natuurlijk mogelijk om dit op te splitsen en dan originele tegels danwel omgenummerde tegels te gebruiken. Mijn voorkeur gaat uit naar de eerste, maar als osmcombiner veel gebruikt wordt en nog steeds nuttig is om meerdere grote kaartsets te combineren dan kan de tweede ook.
Ik ben ook van voornemens om een nieuwe functie te maken waarmee je een polygoon aan de website kunt geven waarmee de tegels geselecteerd worden. Dit heeft als voordelen:
- dat je een linkbestand kunt opbouwen van veelgebruikte gebieden (bijv. Alpen, Oost-Amerika, Noord-Europa enz.)
- dat je minder gebonden bent aan een rechthoek zoals dat nu het geval is met de custom tegel selectie.
- dat je geen kaarten meer hoeft te combineren zolang je gewenste gebied niet echt enorm groot is.
Met respect voor ieders inspanningen, maar wat is werkelijk het bezwaar tegen Manual tile selection, anders dan meer server-belasting? Je vraagt 's avonds een kaart aan en download deze de volgende ochtend.
Wel kun je overwegen om meer voorgedefineerde regio’s aan te bieden [vgl OFM]. Denk aan Benelux, Alpen, West-Europa, verzin het maar.
Die OSM combiner werkt alleen goed in de eerste methode, en juist niet meer met omgenummerde tegels.
Alleen de gmapsupp.img heeft last van dubbele tegels bij het gebruik van twee landensets, zoals Kr@bs al aangaf.
Dan zou je voor de gmapsupp dus een aparte stap moeten toevoegen, door de omgenummerde tegels te gebruiken.
Volgens mij is die OSM combiner echter niet meer nodig als je voldoende mogelijkhden aanbied zoals de manual tile selectie plus polygonen van veelgebruikte gebieden als Benelux, Alpen, DACH (Duitstalige regio) etc
Ben bang dat de huidige twee servers niet genoeg zijn om iedere aanvraag als ‘manual tile selection’ te gaan afhandelen. Een groot deel van de downloads zijn landen en die hoeven maar één keer gerenderd te worden, een custom kaart is toch bijna altijd uniek. Bovendien kun je nu eenvoudig meerdere kaarten tegelijkertijd geinstalleerd hebben itt tot de custom kaarten waar je met externe tools nog aan moet sleutelen om dit voorelkaar te krijgen.
Dat is dus wat ik bedoelde met de tweede alinea in mijn vorige post en is uiteindelijk gelijk aan de landen selectie behalve dat de definitie van een ‘land’ niet meer vast ligt.
Het is niet moeilijk om Mkgmap tweemaal aan te roepen. Het kost ook niet echt veel meer cpu tijd schat ik zo in, het meerendeel zit toch al in de bewerkingen om de gmapsupp te maken en de verschillende kaartversies te zippen. Dan heb je misschien het beste van beide werelden.
Meer regio’s aanbieden die naadloos op elkaar aansluiten lijkt me ook een goede manier om het probleem van dubbele tegels te voorkomen. Voorbeeld mijn EU set maar dan wellicht iets meer regio’s: http://www.openfietsmap.nl/downloads/europe
Volgens “popej” moet het kunnen om die interne img id aan te passen op de volgende wijze:
gmt -we 24528001 001.img
rename 001.img 24528001.img
Weet niet of je dat met Linux in een script om kan zetten, moet vast wel lukken? 
Gaat vast lukken 
Net even de nieuwe kaarten binnen gehaald.
In de Frankrijk map is de “Gent” tegel weg, top!
In het geheel liggen de grenzen ook scherper.
Echter het sleutelen aan de polygonen is iets uitgeschoten aan de zuidoost kant.
Daar zitten nu iets teveel tegels.
Een plaatje ter verduidelijking:
Die grote tegel in de Middellandse Zee heeft te maken met hoe mkgmap de tegels splitst.
Aangezien er geen of nauwelijks data in zee ligt worden ze heel groot.
Ik heb even gekeken wat er gebeurt als je Nederland en Belgie op de GPS zet. Routering werkt gewoon bij die dubbele tegels en er overheen.
Een route van N-Frankrijk tot NO Groningen is ook geen probleem >400km. Kortom die hernummering van die tegels is m.i. niet zo noodzakelijk.
Is dat wel zo van teveel polygonen? In het gebied van de cirkel ligt Corsica en dat hoort bij Frankrijk. De enige tegel die op het plaatje niet lijkt thuis te horen is die grote rechthoek die tot Algiers rijkt.
Zie net dat Ligfietser al een antwoord heeft gepost.
De tegel naar Algiers zat er de vorige keer niet in.
Ach die landsgrenzen hebben tegenwoordig weinig waarde meer.
De Duitsers zijn ook al bezig om NO Groningen te annexeren en misschien is Frankrijk met een offensief bezig om oude koloniale gebieden weer in te pikken
Over Frankrijk gesproken, bij de installatie in het Frans krijgt men een melding:
OSM generic routable new(Netherlands) est d�j� install�. Appuyez sur `OK` pour retirer la version pr�c�dente et continuer avec l'installation ou sur `Annuler` pour annuler cette mise � jour.
Er is iets mis met de diacritische tekens in de nsi file, die worden niet goed geconverteerd tijdens het proces. Idem voor Spaans.
http://osm.pleiades.uni-wuppertal.de/garmin/generic_new/23-04-2014/3949b0c98390de1c6dc1b48c4c1a79ba/metadata/24528000.nsi
Het matchen van de tegels met de landpolygonen duurt ruim 3x zo lang voor de nieuwe polygonen van Frankrijk en Belgie. Ik ga dus niet alle (Europese) landen van een nauwkeurigere polygoon voorzien want dan duurt het proces 2 uur langer. Ik vind het ook niet belangrijk dat die grote tegel in de Midellandsezee bij Frankrijk zit en ga er dus verder niks meer aan doen. Daar is m’n tijd te beperkt voor.
Helder.
Je kan je tijd maar 1x besteden.
In ieder geval bedankt zover. 