Version mkgmap-r3686 will be last to run on java 7 31 Jul 2016 3:00 PM (8 years ago)

All future versions of mkgmap and splitter that are downloaded from the website will require java 8 to run.

The public updates of java 7 ended over a year ago in Apr 2015 and java 8 was released in Mar 2014, so you are likely to be running java 8 already, except for some long term supported linux distributions where java 7 may still be the default and you will have to install java 8 in addition or instead of java 7.

Maintenance Sun 6th March 28 Feb 2016 3:00 PM (9 years ago)

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.

House number improvements 7 Jun 2015 3:00 PM (9 years ago)

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=* {set mkgmap: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.

Drive on left or right 10 Dec 2014 3:00 PM (10 years ago)

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.

Converting units 23 Nov 2014 3:00 PM (10 years ago)

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=* {
	set height='${height|conv:"m=>ft"}';
    }

highway=* & maxspeed=* {
	set limit='${maxspeed|conv:"kmh=>mph"}';
    }

The possible units are:

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

Crash on compiling recent south american OSM maps. 20 Nov 2014 3:00 PM (10 years ago)

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.

Unicode searching. Now you can. 17 Jun 2014 3:00 PM (10 years ago)

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.

Quoting variable filter arguments 3 Jun 2014 3:00 PM (10 years ago)

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

A simple contrived example:

# Fix short form and mis-spelling
highway=residential { set name '${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.

Improved splitter 24 May 2014 3:00 PM (10 years ago)

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.

Splitter version r385 22 May 2014 3:00 PM (10 years ago)

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.

Improvements in turn restrictions 13 Apr 2014 3:00 PM (11 years ago)

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.

Announcement: version r3116 is a major upgrade for routing 18 Mar 2014 4:00 PM (11 years ago)

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 ]

More flexibility in style files - style changes required! 21 Dec 2013 3:00 PM (11 years ago)

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.

House numbers 5 Oct 2013 3:00 PM (11 years ago)

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.

Now mkgmap has a real overview map 30 May 2013 3:00 PM (11 years ago)

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.

Moving to Java version 7 26 Feb 2013 3:00 PM (12 years ago)

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!

Weekend in Essen 7 Feb 2013 3:00 PM (12 years ago)

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!

Exit hints 24 Jan 2013 3:00 PM (12 years ago)

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]

Style functions 19 Jan 2013 3:00 PM (12 years ago)

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.

Creating pre-processed boundaries 9 Jan 2013 3:00 PM (12 years ago)

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.

The --remove-short-arcs option is no longer needed 26 Dec 2012 3:00 PM (12 years ago)

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.

The o5m format is now supported 20 Dec 2012 3:00 PM (12 years ago)

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.

Improved splitter released 16 Dec 2012 3:00 PM (12 years ago)

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 default soon. 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 [1]

General information on how to use splitter can be found at the tile splitter page.

TYP file compiler 16 Feb 2012 3:00 PM (13 years ago)

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.

Address index for GPS devices 27 Jan 2012 3:00 PM (13 years ago)

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