In the past you would get many "zero length arc" errors.
SEVERE (RoadNetwork): 63240020.osm.gz: Road (...) contains zero length arc ...
These were not caused by bad map data, or something that you could do anything about. The solution was to give the --remove-short-arcs option. If you did not give that option, then you could get routing errors in addition to those error messages. This meant that the option was effectively required.
This has now been fixed and in the latest versions of mkgmap the option is no longer required and at some point in the future it will be removed altogether.
Both splitter and mkgmap now support the o5m format. You can read these files just by putting them on the command line as with any other file. For splitter the default output format remains pbf, so if you want it to produce o5m files on output then you will need to give the --output=o5m option.
Files in the o5m format are larger than those in the pbf format, but are faster to read, particularly for splitter when it has to re-read the input file several times.
There is not such a large speed advantage for mkgmap.
The o5m support was added by Gerd Petermann.
Congratulations on a much improved version of splitter that was released today by Gerd Petermann.
The first improvement is that it fixes the annoying failures on large multipolygons such as lakes and forests and also on long ways such as ferry routes or country borders.
The previous method used by splitter could not guarantee that all features that should affect a tile but were wholly or partially outside of the tile would be correctly included. The new version tracks down all these cases and makes sure that they are complete.
Currently you have to supply the
--keep-complete=true option to get the new
behaviour, but as the results are so much better this will surely become the
It does take a little extra time and more memory with this option, but as the resulting file sizes
are smaller, it takes less time to run mkgmap on them so there is not so much
difference in the overall time taken.
The split is also improved to make the tiles sizes more even. This means both a more consistent number of points within the same tile and the tiles are more square with an maximum aspect ratio of 1:4 if possible with the given input file. More care is taken with tiles that approach the poles or the 180 degree of longitude line.
The o5m format is now supported for both read and write. The o5m format is somewhat quicker when used as a splitter input file.
There are also loads of bug fixes too! This is all available in release r263 which can be obtained as always from the splitter download page There are many more changes than are mentioned here, so for full details read the full description 
General information on how to use splitter can be found at the tile splitter page.
Another recent feature added is the ability to compile TYP file from the .txt format.
There is no special option needed, just place the .txt file on the command line wherever you would normally put a .typ file and it will be compiled to a .typ file with the same name and processed as though you had put that file on the command line.
A TYP file has a family id, and this must match the map it is used with. To make this easy, the family id is set automatically by mkgmap to the family-id that is being used to compile the map set. This will override any family id that is set within the TYP txt file itself. If no family-id option is given then the one in the txt file will be used.
The compiler supports some of the newer features in the TYP file:
- images with single colour transparency (gif-style)
- images with partially transparent colours (alpha channel)
- true colour images (16 million colours)
- true colour images with transparency
- Icons containing the same image in different resolutions, that can be displayed at a high resolution on newer devices.
There is a wiki page that describes the language that is accepted at mkgmap typ compile if you want to write software to create such files or even create them by hand! The compiler also attempts to read files produced by all the major know editors in addition to the recommended syntax described on that page.
The latest versions of mkgmap can now build a street address index when creating a gmapsupp.img file for a GPS device. This means you do not have to use MapSource to perform this step any more. This will be particularly beneficial to those using Linux to build their maps.
There is no special option to enable this new feature, if you have both the --index and --gmapsupp options, then the street index will be built inside the gmapsupp.img that is created.
The main thing to watch out for is that if you also have the --tdbfile flag set you will get both indexes and this will use more memory. Best thing is just to omit the --tdbfile option if you are not wanting to install the map on Windows. Otherwise you can build the gmapsupp in a separate step. You can combine the .img files without having to compile them from the OSM files and so this step is very quick.
At the moment the index will not fully work if you are combining more than one family id into the output file.
For general details of building a map with mkgmap from OSM data see the page on How to create a map