The mkgmap blog

The mkgmap program converts map data from Open Street Map into the Garmin img map format that can be loaded onto Garmin GPS devices.

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.

The .txt files are best created with a graphical editor such as TYPWiz or the ati land web based editor.

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

As it is summer for many of the mkgmap developers there is the usual lull in activity at this time of year. So I thought I would just post a few numbers about the project.

For the first time number of downloads per month went over 5,000 in May and and has stayed over 5,000 since then. We have now just passed 100,000 total downloads.

No doubt many downloads are repeats and a fair few are robots trying to download everything and so on so it is very difficult to know how many people are really using it. For contrast there are about 170 people subscribed to the mailing list.

In each of the first 7 months of the project the monthly downloads were below 100, so things have come a long way since then. The first time that the number of monthly downloads went over a thousand was back in May 2008. It seems there is always a surge in May.

Over a year ago I announced that mkgmap would require Java 1.6 "soon". Well that time is now finally here and further releases will no longer work on Java 1.5

Version 1.6 has been out for nearly three years now and so most people will have it already. Indeed Sun is no longer supporting 1.5 after the end of October.

The only problem with obtaining Java 1.6 might be with older 32bit Macs. I believe that Snow Leopard includes Java 1.6, so upgrading is one solution. Another source is the soylatte project where you can download the openjdk release for 32 bit Macs.

Increasingly, as OSM gets bigger and bigger, people are having to face the problem that a map has to be split into tiles. There are various approaches that can be used, notably osmcut, and they work well enough at producing a map set that works. However to produce the best map additional features are desirable.

I not really interested in getting into the realm of splitting up xml files, but given its increasing importance I wrote a utility to split a large OSM file up into tiles in a way that is suitable for creating Garmin maps. I'm really hoping that others will look at this and do something better.

First of all, lets look at the features that I think are essential when splitting into tiles.

• Adapts the size of each area based on the amount of detail present. There is a maximum size that each .img file can be. If you divide into equal sized pieces then you have to choose that size based on the most densely populated part of the map, leading to many small tiles. By having variable sized tiles, you can cover a whole country with a small number of tiles without hitting the dreaded 'Map too big' message.
• Breaks maps on exact low zoom boundaries. Latitude and longitude values have to be rounded to particular integral amounts. At high zoom levels the resolution is a matter of centimeters on the ground. At low zooms however the possible divisions are a considerable distance apart. The tile boundaries are recorded at a low zoom in the overview map and so unless the positions are exact at the zoom level on the map, they will be either overlap or have gaps when the boundary is rounded to the nearest unit.
• Features are cut exactly on the boundary. The resulting tiles do not overlap, nor do they have gaps between them. A road that crosses from one tile to another will be cut exactly on the boundary, and one part will be in the first tile and the other part in the second. Polygons are are also cut into two (or more) polygons, each sharing an edge at the tile boundary.
• A line that crosses a tile corner, but does not actually have a point within the tile will still be included.

Although not essential, this splitter also has the following features:

• The calculated areas can be saved and re-used in another run. This is so you can produce an updated map that has the same tile boundaries.
• A template arguments file is produced that can be given to mkgmap with the -c argument to prepare the maps. It can be edited to describe the areas more accurately (for example the town or area the individual map tile covers).
• Can set the maximum number of nodes that are contained in each tile.

To achieve some of these points, the splitter and mkgmap work together. The splitter calculates the exact file boundaries and places a <bounds> element in the .osm file with these exact coordinates. The splitter however extracts a somewhat larger, oversized, area into each .osm file and leaves mkgmap to cut the features exactly on the boundary. This overlap must be large enough so that there are nodes outside the boundary for every feature that crosses more than one tile. The default oversize amount works fine in towns, it may need to be increased in areas with widely spaced nodes.

Other desirable features that you might want in a tile splitter, that are not catered for with this one.

• Ability to adjust the areas to match geographical areas or counties better. With the automatic way of splitting areas up, they may be hard to describe as they can cut across cities or countries in ways that are inconvenient to describe.
• Even an automatic way of determining the areas might be better by detecting highly feature rich parts of the map and using them as the centers of areas about which the tiles are grown around. Or alternatively explicitly using regional capitals to base the tiles around.
• Speed. This splitter is quite slow. It takes me 30 minutes to split the whole of Europe as defined by the Cloudmade extract, whereas it only takes 10 minutes to compile the generated files with mkgmap.
• A more even split. With this splitter tiles often have many fewer than the maximum number of nodes in a tile.

For details of the splitter see the tile splitter page.