Hello all While compiling a map from 6 tiles obtained with splitter (manually adjusted areas.list) I get the following error: GRAVE (BlockManager): overflowed directory with max block 65534, current=65535 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 guess I must split some of the tiles but, how to know which one? Does it depend on the size (in MB) of the resulting maps? Regards Carlos
2009/8/21 Carlos Dávila <cdavilam@jemila.jazztel.es>:
Hello all While compiling a map from 6 tiles obtained with splitter (manually adjusted areas.list) I get the following error: GRAVE (BlockManager): overflowed directory with max block 65534, current=65535 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 guess I must split some of the tiles but, how to know which one? Does it depend on the size (in MB) of the resulting maps?
My understanding is that this is not directly related to the size in MB of the map, but of the complexity of the individual tiles (number of nodes, etc.). Normally, if you use splitter to automatically generate the tiles, you can lower the --max-nodes values until the map correctly compiles. However in your case, since you are using a manually adjusted areas.list file, you cannot do this so easily. But since mkgmap normally generates the tiles more or less sequentially, can you not see on which .img file mkgmap died? Hope this helps.
Clinton Gladstone escribió:
2009/8/21 Carlos Dávila <cdavilam@jemila.jazztel.es>:
Hello all While compiling a map from 6 tiles obtained with splitter (manually adjusted areas.list) I get the following error: GRAVE (BlockManager): overflowed directory with max block 65534, current=65535 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 guess I must split some of the tiles but, how to know which one? Does it depend on the size (in MB) of the resulting maps?
My understanding is that this is not directly related to the size in MB of the map, but of the complexity of the individual tiles (number of nodes, etc.). Normally, if you use splitter to automatically generate the tiles, you can lower the --max-nodes values until the map correctly compiles.
However in your case, since you are using a manually adjusted areas.list file, you cannot do this so easily. But since mkgmap normally generates the tiles more or less sequentially, can you not see on which .img file mkgmap died?
In a first sight all maps seemed to be correct, at least in MapSource, but some route calculation is not working. I'll reduce the bbox of some tiles and see what happens.
Hope this helps. _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
-- Por favor, no me envíe documentos con extensiones .doc, .docx, .xls, .xlsx, .ppt, .pptx, .mdb, mdbx Instale OpenOffice desde http://es.openoffice.org/programa/index.html OpenOffice es libre: se puede copiar, modificar y redistribuir libremente. Gratis y totalmente legal. OpenOffice funciona mejor que otros paquetes de oficina. OpenOffice está en continuo desarrollo y no tendrá que pagar por las nuevas versiones.
Quoting Carlos Dávila <cdavilam@jemila.jazztel.es>:
Hello all While compiling a map from 6 tiles obtained with splitter (manually adjusted areas.list) I get the following error: GRAVE (BlockManager): overflowed directory with max block 65534, current=65535 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 guess I must split some of the tiles but, how to know which one? Does it depend on the size (in MB) of the resulting maps? Regards Carlos I also create manual areas.list files. My experience is that even if I set max-nodes smaller in splitter, it can still create tiles that are too big for mkgmap. My rule of thumb is that no tile created by splitter should be bigger than ~20MB (compressed, obviously). This makes it easy to spot tiles that are too big and I've not (yet) had mgkmap fail when applying this rule.
charlie@cferrero.net escribió:
Quoting Carlos Dávila <cdavilam@jemila.jazztel.es>:
Hello all While compiling a map from 6 tiles obtained with splitter (manually adjusted areas.list) I get the following error: GRAVE (BlockManager): overflowed directory with max block 65534, current=65535 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 guess I must split some of the tiles but, how to know which one? Does it depend on the size (in MB) of the resulting maps? Regards Carlos
I also create manual areas.list files. My experience is that even if I set max-nodes smaller in splitter, it can still create tiles that are too big for mkgmap. My rule of thumb is that no tile created by splitter should be bigger than ~20MB (compressed, obviously). This makes it easy to spot tiles that are too big and I've not (yet) had mgkmap fail when applying this rule. Thanks for the figure. I'm currently splitting the same input osm with a new areas.list. I'll take your size into account before processing tiles with mkgmap (previously I had one of 28 MB, thus the overflow).
Carlos Dávila escribió:
charlie@cferrero.net escribió:
Quoting Carlos Dávila <cdavilam@jemila.jazztel.es>:
Hello all While compiling a map from 6 tiles obtained with splitter (manually adjusted areas.list) I get the following error: GRAVE (BlockManager): overflowed directory with max block 65534, current=65535 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 guess I must split some of the tiles but, how to know which one? Does it depend on the size (in MB) of the resulting maps? Regards Carlos
I also create manual areas.list files. My experience is that even if I set max-nodes smaller in splitter, it can still create tiles that are too big for mkgmap. My rule of thumb is that no tile created by splitter should be bigger than ~20MB (compressed, obviously). This makes it easy to spot tiles that are too big and I've not (yet) had mgkmap fail when applying this rule.
Thanks for the figure. I'm currently splitting the same input osm with a new areas.list. I'll take your size into account before processing tiles with mkgmap (previously I had one of 28 MB, thus the overflow). Just for information, with a compressed input file of 25 MB I had no problem.
participants (3)
-
Carlos Dávila -
charlie＠cferrero.net -
Clinton Gladstone