Download numbers

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.

Moving to java 1.6 (really this time)

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.

A tile splitter

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.

Another year.

Today is the two year anniversary of the public announcement of mkgmap.

It is interesting to look back and recall that the project started less than a month before that announcement. The map was basic and only included roads and only at one zoom level, but it was still useful for mapping. I never imagined at that time, that two years later improvements would still be being made and there would be a separate web site and everything.

The big news of the year is that routing support has now been added. This came about by the efforts of Robert Vollmert and Alexander Atanasov. Alex had working code to read files that is used in Navit. Although the first work was done right at the beginning of the year, there was a lengthy break during the summer when little was done. It then really took off when Robert returned to the project in December and rapidly coded up all of the remaining pieces. In a mere couple of weeks it took shape and bugs were removed, resulting in something that looks very good indeed.

The other major improvement is with the style system to convert between OSM tags and the features on the map. This can now use conditions based on several tags. It should be possible to create special purpose maps, such as the cycle map directly from a mkgmap style. At the current time there is a noname style, that highlights residential streets that do not have a name so that they can be investigated by mappers.

What next?

These are my thoughts, but who knows development could take off on a completely different direction when the time comes...

1. Currently routing is only available when things are first converted to the Polish format. It will be a priority to make that work directly with OSM files.
2. Next up there is the overview map situation. Currently the overview map does not contain anything but the required definition areas. We need to get back to having it contain major roads and coastline etc. as it used to before it was dropped when the ability to stitch together previously generated .img files was added.
3. I hope there will be a variety of new styles added for different purposes.
4. It would be nice to have proper ocean areas, rather than just coastline as at present.
5. Perhaps 2009 will be the year that mkgmap gets a built in GUI, you never know.

There is also the issue of splitting up large OSM files into tiles that are suitable for generating the maps. I shall be releasing a program to do this in a way that is designed for the purpose and requirements of mkgmap, including variable sized areas depending on map density and exact cutting and matching of tiles.

Updated experimental routing

There has been a good response to the request to try out routing and lots of good feedback on the problems encountered.

Robert has made a large number of fixes over the last few days and so I have put up an updated ready-built distribution on the web-site.

Update: Removed outdated links, now supported in main line releases

I think this version is noticeably better than the previous one in many ways - give it a go!