I have an OSM file which is 836Mb in size. When I try to convert it to an IMG file I get: "There is not enough room in a single garmin map for all the input data The .osm file should be split into smaller pieces first." I understand how to solve this problem (osmosis, osmcut, etc.) but I'm wondering what the size limit is and whether it is imposed by the IMG file format or mkgmap. Does anyone know? thanks, Andy -- Andy PGP Key ID: 0xDC1B5864
No, I too don't know. The resulting .img can be around 11-16MB big maximum right now. It mainly depends on your style-files. I noticed however that options like --net do increase the .img size, without however inflicting upon whether that error incurs when generating or not (--net produces about 20% bigger tiles). Instead of using osmosis (I wouldn't use osmcut, as it's too buggy for me - maybe others are more succesfull), you can also split up your maptiles by using several style-files. So you create one layer with all motorways, one layer with all residential roads, one layer for all polygons, one layer for all POI, etc... Just give them the same PID and FID and it works nicely. Garmin doesn't do such a seperation, so I don't know wheter it can break something. I do use this a lot however. I can easily get OSM files of 3-4 GB parsed without osmosis/osmcut by following this procedure. In Mapsource or on the gps you don't see a difference. When selecting maps for exporting to your gps you can't click on the maptiles in Mapsource however, but you have to capture them by drawing a rectangle while holding the left mouse button on selection. On click only one layer will be chosen, and not all. This is the only limitation I have found. I noticed however that the Garmin Topo Adria 2.11 map has maptiles of up to 29MB in size. The tiles themselves do not support autorouting, but do have a built-in DEM (which is in seperate subfiles if you decompile the .img). So I don't know where the real limit is of how big tiles you could theoretically produce. I do think that the Topo Adria 2.11 tiles are in NT format too. I think mkgmap writes non NT format tiles so the limitations are different. Felix Andrew Ayre wrote: I have an OSM file which is 836Mb in size. When I try to convert it to an IMG file I get: "There is not enough room in a single garmin map for all the input data The .osm file should be split into smaller pieces first." I understand how to solve this problem (osmosis, osmcut, etc.) but I'm wondering what the size limit is and whether it is imposed by the IMG file format or mkgmap. Does anyone know? thanks, Andy -- Andy PGP Key ID: 0xDC1B5864 _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk> http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev ________________________________ Diese Nachricht erhalten Sie von einem Studierenden der IMC Fachhochschule Krems. Für Übermittlungsfehler oder sonstige Irrtümer bei Übermittlung besteht keine Haftung seitens der IMC Fachhochschule Krems. This message is being transmitted by an IMC student. The sender does not accept liability for any errors or omissions as a result of the transmission.
Felix, Thanks for the info. I'm trying to understand your process. So you take a large OSM file and using style files generate multiple IMG files (one contains roads, etc.). Then you use the --gmapsupp option to merge the IMG files together into a single IMG file? thanks, Andy f.hartmann wrote:
No, I too don't know. The resulting .img can be around 11-16MB big maximum right now. It mainly depends on your style-files. I noticed however that options like --net do increase the .img size, without however inflicting upon whether that error incurs when generating or not (--net produces about 20% bigger tiles). Instead of using osmosis (I wouldn't use osmcut, as it's too buggy for me - maybe others are more succesfull), you can also split up your maptiles by using several style-files. So you create one layer with all motorways, one layer with all residential roads, one layer for all polygons, one layer for all POI, etc... Just give them the same PID and FID and it works nicely. Garmin doesn't do such a seperation, so I don't know wheter it can break something. I do use this a lot however. I can easily get OSM files of 3-4 GB parsed without osmosis/osmcut by following this procedure. In Mapsource or on the gps you don't see a difference. When selecting maps for exporting to your gps you can't click on the maptiles in Mapsource however, but you have to capture them by drawing a rectangle while holding the left mouse button on selection. On click only one layer will be chosen, and not all. This is the only limitation I have found.
I noticed however that the Garmin Topo Adria 2.11 map has maptiles of up to 29MB in size. The tiles themselves do not support autorouting, but do have a built-in DEM (which is in seperate subfiles if you decompile the .img). So I don't know where the real limit is of how big tiles you could theoretically produce. I do think that the Topo Adria 2.11 tiles are in NT format too. I think mkgmap writes non NT format tiles so the limitations are different.
Felix Andrew Ayre wrote:
I have an OSM file which is 836Mb in size. When I try to convert it to an IMG file I get:
"There is not enough room in a single garmin map for all the input data The .osm file should be split into smaller pieces first."
I understand how to solve this problem (osmosis, osmcut, etc.) but I'm wondering what the size limit is and whether it is imposed by the IMG file format or mkgmap. Does anyone know?
thanks, Andy
-- Andy PGP Key ID: 0xDC1B5864
No currently I integrate them with mapsettoolkit (could also use gmaptool). Then I either use the new Qlandkarte GT or Mapsource (and then sometimes transfer to GPS - not on most trial runs however). --gmapsupp would work too. I attach the bat file I'm using for your convenience (watch out for the different levels, you allways have to have the highest level included in map, otherwise it will fail): cd d:\garmin\mkgmap_680\ del gmapsupp.img del 73240000.img java -jar -Xmx1256M mkgmap.jar --family-id=4012 --style-file=1 --product-id=1 --levels=0:24,1:23,2:22,3:21,4:18,5:15,6:10 --mapname=73240000 austria.osm del 73240001.img java -jar -Xmx1256M mkgmap.jar --family-id=4012 --style-file=2 --product-id=1 --levels=0:24,1:23,2:22,3:21,4:20 --mapname=73240001 austria.osm del 73240002.img java -jar -Xmx1256M mkgmap.jar --family-id=4012 --style-file=3 --product-id=1 --levels=0:24,1:23,2:22,3:21,4:20 --mapname=73240002 austria.osm del 73240003.img java -jar -Xmx1256M mkgmap.jar --family-id=4012 --style-file=4 --product-id=1 --levels=0:24,1:23,2:22,3:21,4:20 --mapname=73240003 austria.osm del 73240004.img java -jar -Xmx1256M mkgmap.jar --family-id=4012 --style-file=5 --product-id=1 --levels=0:24,1:23,2:22,3:21,4:20 --mapname=73240004 austria.osm Andrew Ayre wrote: Felix, Thanks for the info. I'm trying to understand your process. So you take a large OSM file and using style files generate multiple IMG files (one contains roads, etc.). Then you use the --gmapsupp option to merge the IMG files together into a single IMG file? thanks, Andy f.hartmann wrote:
No, I too don't know. The resulting .img can be around 11-16MB big maximum right now. It mainly depends on your style-files. I noticed however that options like --net do increase the .img size, without however inflicting upon whether that error incurs when generating or not (--net produces about 20% bigger tiles). Instead of using osmosis (I wouldn't use osmcut, as it's too buggy for me - maybe others are more succesfull), you can also split up your maptiles by using several style-files. So you create one layer with all motorways, one layer with all residential roads, one layer for all polygons, one layer for all POI, etc... Just give them the same PID and FID and it works nicely. Garmin doesn't do such a seperation, so I don't know wheter it can break something. I do use this a lot however. I can easily get OSM files of 3-4 GB parsed without osmosis/osmcut by following this procedure. In Mapsource or on the gps you don't see a difference. When selecting maps for exporting to your gps you can't click on the maptiles in Mapsource however, but you have to capture them by drawing a rectangle while holding the left mouse button on selection. On click only one layer will be chosen, and not all. This is the only limitation I have found.
I noticed however that the Garmin Topo Adria 2.11 map has maptiles of up to 29MB in size. The tiles themselves do not support autorouting, but do have a built-in DEM (which is in seperate subfiles if you decompile the .img). So I don't know where the real limit is of how big tiles you could theoretically produce. I do think that the Topo Adria 2.11 tiles are in NT format too. I think mkgmap writes non NT format tiles so the limitations are different.
Felix Andrew Ayre wrote:
I have an OSM file which is 836Mb in size. When I try to convert it to an IMG file I get:
"There is not enough room in a single garmin map for all the input data The .osm file should be split into smaller pieces first."
I understand how to solve this problem (osmosis, osmcut, etc.) but I'm wondering what the size limit is and whether it is imposed by the IMG file format or mkgmap. Does anyone know?
thanks, Andy
-- Andy PGP Key ID: 0xDC1B5864 .. ________________________________ Diese Nachricht erhalten Sie von einem Studierenden der IMC Fachhochschule Krems. Für Übermittlungsfehler oder sonstige Irrtümer bei Übermittlung besteht keine Haftung seitens der IMC Fachhochschule Krems. This message is being transmitted by an IMC student. The sender does not accept liability for any errors or omissions as a result of the transmission.
Hi
I understand how to solve this problem (osmosis, osmcut, etc.) but I'm wondering what the size limit is and whether it is imposed by the IMG file format or mkgmap. Does anyone know?
The limit is in the IMG format, or at least the version of the format that we know how to use. It is not the size of the file as a whole but of one section within it. Files containing routing information for example will be much bigger in total size. The default style is somewhat heavyweight as it contains all residential roads on two different zoom levels. You would get about twice the amount with a less heavy style. (You could try --levels='0:23,1:21,2:19' for a rough idea). All garmin maps commercial or otherwise are split into tiles. In the days before cheap SD cards it would have been a necessary feature that the map was split into small enough chunks that you could load a few sections you were interested in onto limited memory. ..Steve
Thanks Steve and Felix - you have sent me down the path to solving my problem. Andy Steve Ratcliffe wrote:
Hi
I understand how to solve this problem (osmosis, osmcut, etc.) but I'm wondering what the size limit is and whether it is imposed by the IMG file format or mkgmap. Does anyone know?
The limit is in the IMG format, or at least the version of the format that we know how to use. It is not the size of the file as a whole but of one section within it. Files containing routing information for example will be much bigger in total size.
The default style is somewhat heavyweight as it contains all residential roads on two different zoom levels. You would get about twice the amount with a less heavy style. (You could try --levels='0:23,1:21,2:19' for a rough idea).
All garmin maps commercial or otherwise are split into tiles. In the days before cheap SD cards it would have been a necessary feature that the map was split into small enough chunks that you could load a few sections you were interested in onto limited memory.
..Steve
-- Andy PGP Key ID: 0xDC1B5864
participants (3)
-
Andrew Ayre -
f.hartmann -
Steve Ratcliffe