Dan zouden we die tegels bij de gmapsupp generatie dus eigenlijk moeten hernummeren.
Gmaptool heeft daar een optie voor dacht ik, maar heb dat nooit uitgetest.
Simpelweg hernoemen van de img files gaat helaas niet omdat het nr ook in de tegel is “meegebakken”.
Vooralsnog is de oplossing dus of een custom mapset laten genereren, of met osm combiner aan de slag.
Als het mogelijk is om onder linux eenvoudig een tegel intern te hernoemen, dan wil ik best een poging doen om dit in in de scripts te bakken.
Met gmaptool zou je een tile kunnen hernummeren, http://www.gmaptool.eu/en/content/change-mapid
Ik weet echter niet of twee verschillende tiles met identieke inhoud de routering verstoren, moet dat eerst nog eens uittesten.
Zo doe ik het inderdaad nu, een custom mapset laten genereren en op de GPS zetten.
Echter omdat ik weet dat dit probleem speelt met een aantal Garmin toestellen.
Ik weet niet of dit de weg is om te gaan.
Als ik b.v. Frankrijk en Nederland tegelijk binnen haal en op de GPS zet, dan gaat het goed op de “Gent” tegel na.
Als je enige tijd later Frankrijk laat voor wat het is en je haalt alleen een verse Nederland binnen, dat is kansloos.
De tegelnummers rouleren blijkbaar.
Dit geeft een bak ellende met een heleboel dubbele tegels.
(Ik haal dus altijd FR en NL tegelijk binnen, vanwege de roulerende tegel nummers.)
Als je een enkele tegel gaat hernoemen, haal je volgens mij deze ellende alleen maar meer op de hals.
De beste methode is toch de landsgrenzen scherper krijgen, of accepteren zoals het nu is.
Als de tegels hernoemd worden dan zouden deze beginnen met de kaart type en landcode en dus altijd uniek zolang je niet meer dan 1 versie van hetzelfde land op je GPS hebt staan. Dan zou het toch goed gaan, of niet?
Dus i.p.v. 63xxxxxx.img krijg je dan bijv. 22108xxx: generic (22), belgie (108).
Je zou het aan popej kunnen vragen, de maker van gmaptool.
Ik weet niet of en hoe je met de command line versie gmt.exe die tegels kan hernummeren en of dat onder Linux ook draait?
Dat zou goed moeten gaan.
Als dat nummer in andere landen niet gebruikt wordt zie ik geen probleem.
Ik heb een testje gedaan door de Map ID’s mbv gmaptool te verminderen door de FID+000 (=24056000 is ook de overview mapname) eraf te halen.
B 63241878-24056000=39185878
NL 63241878-24528000=38713878
gmt.exe -w -e -24056000 6324*.img
Gmaptool houdt de tegelnummers hetzelfde alleen de interne hex code past die aan. Javawa device manager geeft ook geen foutmelding meer. Ik krijg alleen geen route als ik beide kaarten geselecteerd heb (maar dat is sowieso niet aan te raden).
Schakel ik er eentje uit dan lijkt het goed te routeren. Kortom ik denk dat dit een goede aanpassing is.
Nice!
Het is inderdaad een andere benadering van het probleem, maar ik denk een prima oplossing!
Zoals het lijkt kijkt de Garmin dus naar de interne hex codes.
Als je Nederland en Frankrijk binnen haalt, 1 map uitzet, en je kan routeren in Gent, dan moet het goed zijn. 
Wat ik begrijp schakelen alleen de wat oudere Garmin toestellen de dubbele tegel(s) uit in alle mappen. (Routeren.)
Dus niet iedereen zal er tegenaan lopen.
Van de Garmin Dakota 20 weet ik dat dit probleem speelt.
Bv in NL en Belgie zie ik sets met nummers in de range van 632418xx - 632419xx. Als er dan toevallig ook een tegel met 632420xx langskomt zijn dus de laatste 4 cijfers variabel en dat past niet. De Family ID’s hebben immers alleen de laatste 3 cijfers “vrij” want de eerste 5 cijfers zijn vast (2 maptype+ 3 landcode)
Dus dan ik denk dat tegelnummer - mapnummer het beste is, de kans dat een van die cijfers overlapt met een kaartenset van een andere mapleverancier is aanwezig maar erg klein.
@Kr@bs, het probleem doet zich ook voor op de nieuwere Garmins, bv op de Oregon 600.
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? 