Moving to java 1.6

Just a quick note to say that in the not too distant future, mkgmap will require version 1.6 of java to run.

Really the only reason why this is not the case at the moment is so that it can run with gcj. However it just doesn't really work with gcj anyway as it either runs very slowly or goes into a never ending loop. If that were the only Free Software java then I would try to make it work, but Sun's version of Java is now available under the GPL licence and it works so much better for this application. So openJDK (also known as Iced Tea) is the only reliable way of running mkgmap and as this is 1.6 there is really nothing left preventing a switch to version 1.6.

Having said all that, nothing will change until there is something added that actually requires 1.6, this is just advanced notice.

Tile clipping

A new feature has been added to mkgmap to clip all features exactly to a bounding box. This allows you to create tiles that meet exactly without overlapping. The general idea is that you start with an area that is slightly larger and then chop it down with in mkgmap. It will work even if a line crosses the area without any nodes being inside. The example uses osmosis, but any software that adds the bound element to the osm file will work and I will probably add an option to specify the bounding box manually later as well.

This is quick example that I made to try it out. Normally you would probably have larger tiles. First I ran osmosis on a uk osm file to create two small tiles. Two bounding boxes were created that shared a vertical side at -0.24 degrees longitude.

osmosis --rx uk-080623.osm.gz enableDateParsing=no \
    --tee 2 outPipe.0=a outPipe.1=b \
    --bb inPipe.0=a completeWays=yes top=51.65 bottom=51.55 left=-0.34 right=-0.24 \
    --bb inPipe.0=b completeWays=yes top=51.65 bottom=51.55 left=-0.24 right=-0.14 \
    --wx uk-test-1.osm.gz \
    --wx uk-test-2.osm.gz 

The completeWays argument makes osmosis include the whole way when any part of it is inside the bounding box. This is essential otherwise there will be gaps between the tiles. Thats all there is to it really. You can now run mkgmap on those tiles normally.

A picture probably says it better than words. Here you can see the clipping in action in QLandkarte displaying one of the tiles produced. This screenshot was taken before points were excluded from the bounding box, which is why you can see a few stray ones outside the box.

Here is what the same data file would look like before clipping.

NET file added

It is exciting to announce that version 617 of mkgmap now has support for the NET section. This support was entirely written by Elrond.

So what does this give you?

First I've got to say that I've not been able to verify the following things, but then I've not got them to work with other maps either. So keep that in mind and let me know what you find and I'll update this article if things become clearer.

• It allows you to use the lock to road option. If you enable that option, then after a while the location pointer will lock onto the nearest road. Even if you then leave a road, the location pointer will stay on the last place you were on a road, until you get back to a road at which time it will jump onto that road.

  I've not really tried this option before, because of course when out mapping it is essential to turn off this lock to road option, otherwise you will not be recording your actual track of where you went.

• The second thing is that the status bar at the top shows the road that you are on and sometimes sometimes roads that are ahead that you can turn into. The exact facilities available may depend on the particular GPS device that you are using it on.

• Finally it is a stepping stone towards routable map support.

To include it you have to give the option --net. Some day it may become the default, but as it takes longer and produces a larger file we are leaving it optional.

Download from the mkgmap download page. Get version 617 or later, don't forget to enable the NET support with the --net flag.

Extended TRE header completed

This is going to be a somewhat technical post that won't be of much interest I fear, so its a good job that only about three people read these notes.

After the previous entry I've spent some time getting the 188 length version of the TRE header version to work. The good news is that it now appears to work and I have created a small map that loads and displays.

So what advantage does it have? The answer is none at all by itself, but it is part of the puzzle that must be solved to get routing to work. Now that it is done, it may be possible to get a very simple routable map to work, or it may be that we just find the next problem.

So what about routing?

Many people are interested in creating routable maps and this must be the most asked-for feature for mkgmap.

I've was never really concerned about routable maps in the beginning, both because there wasn't really enough OSM data to do routing except in localised places and because the format was only partially known in openly available information. The situation is a lot different now and I think it should be within reach with a bit of luck.

What needs to be done

If you want to help out, then here is a list of things that need to be done. The truth is though, that it is all blocked on figuring out the extended TRE header. However it should be possible to produce a file that would work in an open source navigation program such as navit that ignores that part of the TRE header.

Extract information from OSM files

Extract and calculate routing information from the OSM data. All projects that do routing with OSM data need to do this to some extent so there is plenty of inspiration. Some people are converting OSM data for use with cGPSMapper, for example the perl script [1] by Liosha.

Implement the NET subfile

This subfile links together the road network. Watch out for a separate post with news on this soon. Or look around in svn...

Implement the NOD subfile.

This contains routing information. There is now quite a lot known about this subfile., I'd think at least enough to implement some routes and see what happens. See for example the libgarmin [2] project although that reads the format rather than writing it. There is also a write up [3] by Robert Vollmert based his own work and information from Alex on the libgarmin project.

There is also code to display the NET and NOD files in the display svn. It doesn't yet fully work with every map, but to produce a map we don't need to understand every aspect of the format.

TRE header versionl with size of 184

The headers in Garmin maps have different versions identified by the size. It appears that you need this version of the header to have routing as without it the map does not even display when there is a NOD section.

This is in fact the sticking point at the moment and it isn't possible to know how long it will take to solve. I've made a little progress towards working out what the values are and that can again be seen in the display svn.

Unknown things

It might be that there are more things that need to be discovered, but we won't know until we try...