Hi Andrzej, looked at this again now. What I don't understand is why you want to use exactly the same formular as Garmin. I think my approach would be to make sure that we DON'T use their numbers to avoid conflicts.
Gerd popej wrote > Hi Gerd, > > yes, I got the formula after examining numerous Garmin's maps. I know, > that City Navigator is different, my guess is that next CN map gets next > free mapid. I'm not sure about marine maps and other new maps from Garmin. > > It looks like the formula is easy to support up to FID 45744. For bigger > values you could take different strategy. The rules I know are following: > > Mapid inside img data is 4-byte value, no problem here. > > File names are independent of mapid, could be any arbitrary 8-digit > number (number from file name could be even written in TRE header, at > offset 0xCF). > > Names of subfiles like 12345678.TRE can be written in HEX, in this case > you should use prefix 'I'. So 12345678.TRE is equivalent of > I0BC614E.TRE. Mapid 140.531.712 could correspond to I8605800.TRE. > > My first suggestion is to limit --fid to max 45744. For bigger FID > option --mapid should be used. > > Second proposition is to overlap mapid values for big FIDs, but with an > offset of 1024. So for FID > 45744 formula could be like this: > > mapid = (fid - 19792)*2048 + 6316032 + 1024 > > -- > Best regards, > Andrzej > _______________________________________________ > mkgmap-dev mailing list > [email protected] > http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev -- Sent from: http://gis.19327.n8.nabble.com/Mkgmap-Development-f5324443.html _______________________________________________ mkgmap-dev mailing list [email protected] http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
