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.

In the past you have used the createboundsfile option to create preprocessed bounds used by mkgmap to assign correct address information. This option is now removed and replaced by a separate tool delivered with the common mkgmap download.

The following command chain is an example how to create preprocessed bounds for europe. Additionally to mkgmap you need the two tools osmconvert and osmfilter.

1. Download the OSM europe extract
2. Run osmconvert and osmfilter to extract all boundary information:

      osmconvert europe.osm.pbf --out-o5m >europe.o5m
      # The following should all be one line
      osmfilter europe.o5m --keep-nodes=
        --keep-ways-relations="boundary=administrative =postal_code postal_code="
        --out-o5m > europe-boundaries.o5m
   

3. Start the new mkgmap bounds preprocessor:

      # The following should be all one line
      java -cp mkgmap.jar
        uk.me.parabola.mkgmap.reader.osm.boundary.BoundaryPreprocessor
        europe-boundaries.o5m
        europe_bounds
   

   This will create a directory called europe_bounds containing the preprocessed bounds which can be used with the bounds option on the mkgmap command line.

In a mkgmap style, you can now do more than just test the values of tags.

length()

Gives the length of a way in meters. This can be used to omit short driveways and the like.

    highway=residential & access=private
       & length() > 50 ...

is_complete()

True if all the nodes of a way were present in the input file.

is_closed()

True if the first point is the same as the last. This can be useful to determine if something might be a polygon when it could otherwise be ambiguous.

This useful feature was added by WanMil.

There is a new feature to help creating rules in the style file that help with writing style rules that give a bit more help about motorway exits.

The default style is not affected, this is for style authors to use in their styles. It may not work the same on all devices, so you should experiment with the results.

Usually Garmin devices do not display the name of the exit on motorways while routing with mkgmap created maps. The new feature allows you to create a style rule that names part of the exit link road with the junction number, so that when the device tells you to turn onto that road it will include the junction number.

To make this work you have to specify the --process-exits option. This works by splitting each motorway_link into three parts. All parts are tagged with the original tags of the motorway_link. Additionally the middle part is tagged with the following tags:

 mkgmap:exit_hint=true
 mkgmap:exit_hint_ref=ref # tag value of the motorway exit
 mkgmap:exit_hint_name=name # tag value of the motorway exit
 mkgmap:exit_hint_exit_to=exit_to # tag value of the motorway exit

Adding a rule checking that mkgmap:exit_hint=true makes it possible to use Garmin type 0x01 (motorway) for the middle part so that the Garmin device displays the name of this middle part as a hint where to leave the motorway.

An example of such a rule is given below.

highway=motorway_link & mkgmap:exit_hint=true
   { delete display_name;
     name 'Exit ${mkgmap:exit_hint_ref} ${mkgmap:exit_hint_name}' |
          'Exit ${mkgmap:exit_hint_ref} ${mkgmap:exit_hint_exit_to}' |
          'Exit ${mkgmap:exit_hint_exit_to}' |
          'Exit ${mkgmap:exit_hint_name}' |
          'Exit ${mkgmap:exit_hint_ref}' }
    [0x1 road_class=3 road_speed=2 level 1]

Over the last weekend I attended the Garmin Project weekend in Essen, Germany. It was great to meet and exchange views with all the other participants.

I am looking forward to seeing the result of the main discussion of the weekend which was to design a web site to help people without any pre-existing knowledge of OSM find maps for their Garmin devices in a simple and straightforward way. In addition there were many other useful discussions, and the chance to meet others face-to-face is very valuable in a project such as ours where the only ongoing contact is via email.

So I would like to thank those that made it all possible, to FOSSGIS who sponsored the event; the Linux Hotel who support open source by providing facilities to events such as this one and to Marc Gehling who in addition to organising the whole event, even cooked lunch for us!

This is just a notice that Java 7 will soon be required to run mkgmap. Version 7 was released in 2011 so I expect that most people already have it. If not, now is a good time to update in preparation.

Although it was over a year between the announcement that mkgmap would require Java 6 and it actually happening, this time there will not be such a gap!

Earlier today, mkgmap developer Gerd Petermann merged his changes to create a proper overview map into trunk. Update now or go and get version r2636 or later from the download page.

This is an important feature that has been missing from mkgmap for a long time. The overview map exists to display a low resolution map of the whole area of a set of map tiles.

Although there has always been an overview map, as it is essential to displaying in MapSource or BaseCamp, it has been empty apart from the polygons that show the area covered by each tile in the map.

There was another problem: to compensate for the lack of an overview map most map styles, including the default one, contained extra map levels so that the map was still visible when zoomed out to the scale of regions and countries. This extra data made the map slower when scrolling on GPS devices.

So the change has a double benefit; the map is still visible when zoomed out far enough to show whole countries and continents and can also be faster to scroll on GPS

The new enhanced overview map will be automatically generated when creating a map without having to make any changes. There are however a couple of new options to control what happens.

--overview-levels

like levels, specifies additional levels that are to be written to the overview map. Counting of the levels should continue. Up to 8 additional levels may be specified, but the lowest usable resolution with MapSource seems to be 11.

--remove-ovm-work-files

If overview-levels is used, mkgmap creates one additional file with the prefix ovm_ for each map (*.img) file. These files are used to create the overview map. With option --remove-ovm-work-files=true the files are removed after the overview map was created. The default is to keep the files.

Further improvements

In addition to the overview map, there is also a slew of improvements and bug fixes that have been added.

Fixes

There are fixes for maps that cover a large portion of the globe or extend to 180 degrees longitude.

• fix wrong interpretation of 0x800000 as -180.0 degrees for maxLon
• fix treatment of very long lines that cross the planet

Optimizations

• The polygon filter allows larger polygons.
• SeaGenerator generates fewer "sea-only" and "land-only" polygons when precomp-sea is used.

Both reduce the img size, esp. for maps containing large sea only areas.

An option to better control the minimum size of a polygon that can now be configured per level.

--polygon-size-limits=limits-code

Allows you to specify a different min-size-polygon value for each resolution. For example:

  --polygon-size-limits="24:12, 18:10, 16:8, 14:4, 12:2, 11:0"

If a resolution is not given, mkgmap uses the value for the next higher one. For the given sample, resolutions 19 to 24 will use value 12, resolution 17 and 18 will use 10, and so on. Value 0 means to skip the size filter. Note that in resolution 24 the filter is not used.

Changes regarding styles

• The support for the obsolete map-features.csv file was removed.
• Level ranges can now use min-max or max-min
• There is now an option --check-styles which will flag issues in the style that are known to cause problems.

Other changes

• A few checks are performed regarding the plausibility of the given options and input files to help beginners.

There are now a number of places where house numbers are well mapped and it would be nice to be able to see them on your GPS. In fact this has been a much desired feature for a long time now.

This is now possible, and has been for some time - I suck at getting the news out promptly.

It works with both polish format input files and also with regular OpenStreetMap format files.

For files in Polish format, the house numbers support is complete and any differences from what you were expecting should be reported as a bug.

For OSM files things are a bit more tricky because there are various systems of recording housenumbers used in different parts of the world, and not all of them will be recognised.

For OSM files, you need to add the --housenumbers option to get house numbers in the map.

Of course if there are no numbers in the OSM data in your region then you will need to get out and map some to take advantage of this. You will need to add addr:street and addr:housenumber to nodes or polygons representing the house.

Since r2906 there are some important changes in the style processing which gives the style developer more control about converting OSM elements into the Garmin map elements. As a benefit the routing network is up to 25% smaller which results in faster route calculation and slightly smaller img files.

Changes in the style system:

• Styles can now have a <finalize> block. This block is executed for each element if an element style definition matches. The finalize block must contain actions only. This is sometimes useful for general rules and to assign the numerous mkgmap:* tags.
• The four labels to pois/lines/roads/polygons are no longer assigned automatically. They must be assigned using the name and addlabel function. This also means that ref tags are no longer used as labels automatically.
• Access restrictions of roads are now defined by setting special mkgmap:* access tags (mkgmap:car, mkgmap:foot, mkgmap:bicycle, mkgmap:truck, mkgmap:bus, mkgmap:taxi, mkgmap:emergency, mkgmap:delivery). Roads are blocked for a specific vehicle type if the mkgmap:<type> is set to the value no. The new addaccess and setaccess actions help to assign all values at once.

   Example:
   highway=motorway { set mkgmap:foot=no }
   This rule blocks access of pedestrians to motorways.
  

• mkgmap:carpool does no longer automatically set all access restrictions. In the trunk mkgmap:carpool=yes lead to set all access restrictions to no except emergency, bus and carpool. It is not fully clear if the bit toggled by mkgmap really controls if a road has a carpool lane or not. So use it with caution.
• The road speed is no longer automatically calculated using the maxspeed tag. New style functions maxspeedkmh() and maxspeedmph() allow to perform the same by setting the mkgmap:road-speed-class tag. Due to this change the --ignore-maxspeeds option is superfluous and has been removed.

The changes listed above require a change of all style files. But there are three new include files (inc/compat_points, inc/compat_lines, inc/compat_polygons) which ensure compatibility to pre-r2906 releases. They need to be added to the new finalize section.

Example lines file:

 ...
 boundary=political [0x1c resolution 19]
 
 include 'inc/water_lines';
 include 'inc/contour_lines';
 
 # add the following lines to your lines file
 <finalize>
 include 'inc/compat_lines'; 

Please refer also to the style manual.

There have been almost no changes to how mkgmap deals with routing for several years now. So I am very happy to announce that the latest version of mkgmap now saves much improved routing information to the map. This allows better routes to be calculated and over longer distances in many cases.

Although there are no deliberate backward incompatibilities, if you have a heavily customised style, you should carefully examine any workarounds to force particular routing behaviour as it may no longer be necessary or may work differently now.

Also the new version improves the fidelity of features on the map, such as roundabouts and parallel lines. It happens that positions can only be represented to within 1-2 meters in a Garmin map, whereas positions are recorded much more accurately than that within OSM. So some approximation is necessary, however this was made worse since mkgmap would reduce the precision right at the beginning, allowing errors to build up as the data was manipulated. Now the extra accuracy is kept throughout all processing until the map data is written and care is taken to preserve angles so that lines that are meant to be parallel are more likely to stay that way and are less likely to cross or appear to cross.

Both these improvements were added by Gerd.

[ Updated: modified to say that roundabouts and parallel lines are a better example of improvement than buildings. Buildings will be improved in a subsequent update ]

The latest version of mkgmap now has much better support for restriction relations.

Here are the main things that are newly implemented:

• Restrictions that prohibit going between two node via a particular way.
• restrictions no_entry or no_exit
• specific vehicle type, e.g. type=restriction:motorcar or restriction:motorcar=no_u_turn
• fixes possible error if different roads connect the same nodes (old code possibly saved the restriction for the wrong road)
• detects obsolete restrictions, e.g. when a oneway doesn't allow to enter the road or when the restiction applies to motor_vehicles only and the road is a cycleway.
• if the style creates multiple routable ways for one OSM way, the restriction is added for all needed combinations

There are a lot of bug fixes too, so it should all work a lot more smoothly. Use version r3189 or higher for all the fixes.

Version r385 of splitter is a large update.

All the dependent libraries have been upgraded to later versions, so make sure that you install the complete package. This might affect you if you don't download the complete distribution or install in some unusual way.

A summary of the visible changes follows:

• Improved error handling: most I/O errors like corrupted or missing files will now stop the program instead of just printing error messages, and producing a useless result
• Working with pbf files is faster because of the updated libraries.
• Splitting large files is faster because of some improvements in the branch
• Lots of internal changes in the code.

Splitter now has a new split algorithm that usually results in fewer, more evenly sized tiles.

The test generator is > 10 times faster. This allows a deeper search for good splits. A few errors where fixed which sometimes prohibited to find a good split, but also sometimes helped to find one.

A new option --search-limit can be used to increase/decrease the amount of time the splitter tries to find a good split. The larger the input file the higher this value should be. For planet, --search-limit=1000000 is okay, --search-limit=10000000 is better.

You can now quote the argument to a variable filter in a style file.

A simple contrived example:

# Fix short form and mis-spellinghighway=residential{setname'${name|subst:"(Raod|Rd)~>Road"}';}

For backward compatibility you do not have to do this and all existing styles should work as they are. However I would recommend that you start to quote all arguments that are more complex than a simple word. Before this change it was impossible to use a pipe symbol within a regular expression since it would be seen as the start of the next filter.

For quite some time it has been possible to build a map using unicode to display characters in various languages.

Now searching should also work in versions r3294 and later.

All of Western, Central and Eastern European characters should be available as well as Arabic, Greek and various others. It is unlikely to work with Chinese characters and that will require further investigation.

Ensure that you are using the options --code-page=65001 --index --route as well any others that you need.

A recent change to data in Columbia, South America in Open Street Map may cause a problem when creating a map of that area.

There is a long standing bug in mkgmap that results in a crash when compiling the object http://www.openstreetmap.org/way/313259878 which is in Columbia. The addr:housenumber is ":702" which triggers the bug. Probably that is just a typo and it should be just "702", however this should not cause a crash in mkgmap.

The problem is now fixed in r3354, so you should upgrade if affected by this problem. I think you will only see it if using the --add-pois-to-areas option.

Due to the nature of the fix, the resulting .img files may be a little smaller than before.

There has always been a way to convert a tag value from meters to feet, this was originally for contour heights which need to be in feet, but the default for OSM is for them to be in meters.

With the release of version r3353 these conversions are much more useful and can be applied to speeds as well as lengths. They also take into account any unit that is already specified.

So for example if you specify a conversion of meters to feet, then "100" will be converted to "328", "100m" will be converted to "328" but "100ft" will be left as "100". Furthermore "100km" would result in "328000". If any of the units are not recognised then the value remains completely unchanged.

Here are some examples.

natural=hill&height=*{setheight='${height|conv:"m=>ft"}';}highway=*&maxspeed=*{setlimit='${maxspeed|conv:"kmh=>mph"}';}

The possible units are:

• Length: m, km, ft (feet), mi (miles).
• Speed: mph; km/h (or kmh, kmph), knots

From r3366 there are some improvements to the support for driving on the left or right. Each tile has a flag to say if roads are drive on the left or right. It is known to make a difference with roundabouts and may be used in other ways.

The options --drive-on-left and --drive-on-right were replaced by --drive-on=left and --drive-on=right. You can also add detect which will use the country information to select the correct side. The default is equivalent to --drive-on=detect,right which means that if detection fails, it will use drive on the right. The old flags --drive-on-left and --drive-on-right still work.

The detection uses the precompiled bounds (or country-abbr/country-name) to determine the country in which the roads are located, and the resource file LocatorConfig.xml contains a new attribute driveOnLeft="true" for all known drive-on-left countries

If a tile covers two countries where you drive on different sides of the road, then it cannot work for the whole tile and you get a warning. In the future we will be able to cut tiles on country boundaries so that the problem will then not arise.

House numbers have been part of mkgmap for a couple of years now, but as more and more housenumbers are added to OSM, Gerd undertook a project to update the code to deal with many more cases of real world OSM tagging.

The main changes are:

• mkgmap tries to identify unnamed roads which lead to houses and can be named (assuming they are service roads)
• mkgmap tries to find a plausible road when no street is given.
• addr:interpolation ways are used to find the most plausible road and the interpolated addresses are found
• improved evaluation of addr:* tags, esp. the support for addr:place and the support for addr:housenumber without addr:street, img data is optimized to make sure that address search finds a place close (< 40m) to the address.
• special cases regarding addresses in different cities or zip codes along the same road are handled. This is important when a road starts in city A and has some numbers 1..20 there and later crosses city B with numbers 1..5 and finally ends in city C with numbers 1..50.
• the found addresses are typically closer to the house

Using in your own style

If you want to test with your own style: Please note the new special tags mkgmap:numbers=false and mkgmap:execute_finalize_rules=true

• a road with mkgmap:numbers=false is ignored in house number processing. The default style uses this for ferries and motorways and for bicycle-only roads.
• The mkgmap:execute_finalize_rules=true tag will cause the finalize rules to be run, even if no object is created in the map for that element. So to set the city, region and country values for all elements with house numbers, use

  addr:housenumber=*{setmkgmap:execute_finalize_rules=true}

  as a first rule in points, lines and polygons and add

  include 'inc/address';

  to the finalize sections.

Use version r3612 or above to get these upgrades.

The server and website will be down from around 4pm GMT on Sunday 6th March so they can be upgraded. This should take less than two hours, probably much less.

There will be an announcement on the mailing list just before the downtime and then just afterwards.

During the upgrade, mailing list, svn and downloads will not be available.