The mkgmap news and bloghttps://www.mkgmap.org.uk/news/2016-08-01T00:00:00+01:00News on mkgmap, the program to convert Open Street Map to the Garmin map format.Version mkgmap-r3686 will be last to run on java 72016-08-01T00:00:00+01:00https://www.mkgmap.org.uk/news/2016/08/01/version-mkgmap-r3686-will-be-last-to-run<p>All future versions of mkgmap and splitter that are downloaded from
the website will require java 8 to run.</p>
<p>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.</p>
Maintenance Sun 6th March2016-02-29T00:00:00+00:00https://www.mkgmap.org.uk/news/2016/02/29/maintenance-sun-6th-march<p>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.</p>
<p>There will be an announcement on the mailing list just before the downtime and then just afterwards.</p>
<p>During the upgrade, mailing list, svn and downloads will not be available.</p>
House number improvements2015-06-08T00:00:00+01:00https://www.mkgmap.org.uk/news/2015/06/08/house-number-improvements<p>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.</p>
<p>The main changes are:</p>
<ul>
<li>mkgmap tries to identify unnamed roads which lead to houses and can be named
(assuming they are service roads)</li>
<li>mkgmap tries to find a plausible road when
no street is given.</li>
<li><code>addr:interpolation</code> ways are used to find the most plausible road
and the interpolated addresses are found</li>
<li>improved evaluation of <code>addr:*</code> tags, esp. the support for <code>addr:place</code> and the
support for <code>addr:housenumber</code> without <code>addr:street</code>,
img data is optimized to make sure that address search finds a place close (< 40m) to the address. </li>
<li>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.</li>
<li>the found addresses are typically closer to the house</li>
</ul>
<h3>Using in your own style </h3>
<p>If you want to test with your own style: Please note the new special tags
<code>mkgmap:numbers=false</code>
and <code>mkgmap:execute_finalize_rules=true</code></p>
<ul>
<li>a road with <code>mkgmap:numbers=false</code> is ignored in house number processing.
The default style uses this for ferries and motorways and for bicycle-only roads.</li>
<li>The <code>mkgmap:execute_finalize_rules=true</code> 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<div class="source"><pre><span class="na">addr:housenumber</span><span class="p">=</span><span class="l">*</span> <span class="p">{</span><span class="k">set</span> <span class="n">mkgmap:execute_finalize_rules</span><span class="p">=</span><span class="s">true</span><span class="p">}</span>
</pre></div>
as a first rule in points, lines and polygons and add<div class="source"><pre><span class="k">include </span><span class="s1">'inc/address'</span><span class="p">;</span>
</pre></div>
to the finalize sections.</li>
</ul>
<p>Use version r3612 or above to get these upgrades.</p>
Drive on left or right2014-12-11T00:00:00+00:00https://www.mkgmap.org.uk/news/2014/12/11/drive-on-left-or-right<p>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.</p>
<p>The options <code>--drive-on-left</code> and <code>--drive-on-right</code> were
replaced by <code>--drive-on=left</code> and <code>--drive-on=right</code>.
You can also add <i>detect</i> which will use the country information to select
the correct side. The default is equivalent to
<code>--drive-on=detect,right</code> which means that if detection fails, it
will use drive on the right.
The old flags <code>--drive-on-left</code> and <code>--drive-on-right</code> still work.</p>
<p>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</p>
<p>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.</p>
Converting units2014-11-24T00:00:00+00:00https://www.mkgmap.org.uk/news/2014/11/24/converting-units<p>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.</p>
<p>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.</p>
<p>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.</p>
<table class="display">
<tr>
<th>Input </th><th> Result</th>
</tr>
<tr>
<td>100 </td><td> 328</td>
</tr>
<tr>
<td>100m </td><td> 328</td>
</tr>
<tr>
<td>100ft </td><td> 100</td>
</tr>
<tr>
<td>100km </td><td> 328000</td>
</tr>
<tr>
<td>100xyz </td><td> 100xyz</td>
</tr>
</table>
<p>Here are some examples.<div class="source"><pre><span class="na">natural</span><span class="p">=</span><span class="s">hill</span> <span class="p">&</span> <span class="na">height</span><span class="p">=</span><span class="l">*</span> <span class="p">{</span>
<span class="k">set</span> <span class="n">height</span><span class="p">=</span><span class="s1">'${height|conv:"m=>ft"}'</span><span class="p">;</span>
<span class="p">}</span>
<span class="na">highway</span><span class="p">=</span><span class="l">*</span> <span class="p">&</span> <span class="na">maxspeed</span><span class="p">=</span><span class="l">*</span> <span class="p">{</span>
<span class="k">set</span> <span class="n">limit</span><span class="p">=</span><span class="s1">'${maxspeed|conv:"kmh=>mph"}'</span><span class="p">;</span>
<span class="p">}</span>
</pre></div>
</p>
<p>The possible units are:</p>
<ul>
<li>Length: m, km, ft (feet), mi (miles).</li>
<li>Speed: mph; km/h (or kmh, kmph), knots</li>
</ul>
Crash on compiling recent south american OSM maps.2014-11-21T00:00:00+00:00https://www.mkgmap.org.uk/news/2014/11/21/crash-on-compiling-recent-south-american<p>A recent change to data in Columbia, South America in Open Street Map
may cause a problem when creating a map of that area.</p>
<p>There is a long standing bug in mkgmap that results in a crash when
compiling the object<a href="http://www.openstreetmap.org/way/313259878">
http://www.openstreetmap.org/way/313259878</a>
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.</p>
<p>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.</p>
<p>Due to the nature of the fix, the resulting .img files may be a little
smaller than before.</p>
Unicode searching. Now you can.2014-06-18T00:00:00+01:00https://www.mkgmap.org.uk/news/2014/06/18/unicode-searching-now-you-can<p>For quite some time it has been possible to build a map
using unicode to display characters in various languages.</p>
<p>Now searching should also work in versions r3294 and later.</p>
<p>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.</p>
<p>Ensure that you are using the options <code>--code-page=65001 --index --route</code>
as well any others that you need.</p>
Quoting variable filter arguments2014-06-04T00:00:00+01:00https://www.mkgmap.org.uk/news/2014/06/04/quoting-varible-filter-arguments<p>You can now quote the argument to a variable filter in a style file.</p>
<p>A simple contrived example:<div class="source"><pre><span class="c"># Fix short form and mis-spelling</span>
<span class="na">highway</span><span class="p">=</span><span class="s">residential</span> <span class="p">{</span> <span class="k">set</span> <span class="n">name</span> <span class="s">'</span><span class="si">${name|subst:"(Raod|Rd)~>Road"}</span><span class="s">'</span> <span class="p">;</span> <span class="p">}</span>
</pre></div>
</p>
<p>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.</p>
Improved splitter2014-05-25T00:00:00+01:00https://www.mkgmap.org.uk/news/2014/05/25/improved-splitter<p>Splitter now has a new split algorithm that usually results
in fewer, more evenly sized tiles.</p>
<p>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.</p>
<p>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.</p>
Splitter version r3852014-05-23T00:00:00+01:00https://www.mkgmap.org.uk/news/2014/05/23/splitter-version-r385<p>Version r385 of splitter is a large update.</p>
<p>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.</p>
<p>A summary of the visible changes follows:</p>
<ul>
<li>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</li>
<li>Working with pbf files is faster because of the updated libraries.</li>
<li>Splitting large files is faster because of some improvements in the branch</li>
<li>Lots of internal changes in the code.</li>
</ul>
Improvements in turn restrictions2014-04-14T00:00:00+01:00https://www.mkgmap.org.uk/news/2014/04/14/improvements-in-turn-restrictions<p>The latest version of mkgmap now has much better support for restriction relations.</p>
<p>Here are the main things that are newly implemented: </p>
<ul>
<li>Restrictions that prohibit going between two node via a particular way.</li>
<li>restrictions no_entry or no_exit</li>
<li>specific vehicle type, e.g. type=restriction:motorcar or
restriction:motorcar=no_u_turn</li>
<li>fixes possible error if different roads connect the same nodes
(old code possibly saved the restriction for the wrong road)</li>
<li>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.</li>
<li>if the style creates multiple routable ways for one OSM way,
the restriction is added for all needed combinations</li>
</ul>
<p>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.</p>
Announcement: version r3116 is a major upgrade for routing2014-03-19T00:00:00+00:00https://www.mkgmap.org.uk/news/2014/03/19/announcement-version-r3116-is-a-major-u<p>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.</p>
<p>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.</p>
<p>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.</p>
<p>Both these improvements were added by Gerd.</p>
<p>[ <b>Updated</b>: modified to say that roundabouts and parallel lines are a better example of improvement than buildings. Buildings
will be improved in a subsequent update ]</p>
More flexibility in style files - style changes required!2013-12-22T00:00:00+00:00https://www.mkgmap.org.uk/news/2013/12/22/more-flexibility-in-style-files-style<p>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.</p>
<p>Changes in the style system:</p>
<ul>
<li>Styles can now have a <tt><finalize></tt> 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 <tt>mkgmap:*</tt> tags.</li>
<li>The four labels to pois/lines/roads/polygons are no longer assigned automatically. They must be assigned using the <tt>name</tt> and <tt>addlabel</tt> function. This also means that <tt>ref</tt> tags are no longer used as labels automatically.</li>
<li>Access restrictions of roads are now defined by setting special <tt>mkgmap:*</tt> access tags (<tt>mkgmap:car, mkgmap:foot, mkgmap:bicycle, mkgmap:truck, mkgmap:bus, mkgmap:taxi, mkgmap:emergency, mkgmap:delivery</tt>). Roads are blocked for a specific vehicle type if the mkgmap:<type> is set to the value <tt>no</tt>. The new <tt>addaccess</tt> and <tt>setaccess</tt> actions help to assign all values at once.
<pre>
Example:
highway=motorway { set mkgmap:foot=no }
This rule blocks access of pedestrians to motorways.
</pre></li>
<li><tt>mkgmap:carpool</tt> does no longer automatically set all access restrictions. In the trunk <tt>mkgmap:carpool=yes</tt> lead to set all access restrictions to <tt>no</tt> 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.</li>
<li>The road speed is no longer automatically calculated using the <tt>maxspeed</tt> tag. New style functions <tt>maxspeedkmh()</tt> and <tt>maxspeedmph()</tt> allow to perform the same by setting the <tt>mkgmap:road-speed-class</tt> tag. Due to this change the <tt>--ignore-maxspeeds</tt> option is superfluous and has been removed.</li>
</ul>
<p>The changes listed above require a change of all style files. But there are three new include files (<tt>inc/compat_points, inc/compat_lines, inc/compat_polygons</tt>) which ensure compatibility to pre-r2906 releases. They need to be added to the new finalize section.</p>
<p>Example lines file:</p>
<pre>
...
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';
</pre>
<p>Please refer also to the <a href="http://www.mkgmap.org.uk/doc/index.html|">style manual</a>.</p>
House numbers2013-10-06T00:00:00+01:00https://www.mkgmap.org.uk/news/2013/10/06/house-numbers<p>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.</p>
<p>This is now possible, and has been for some time - I suck at getting the news out
promptly.</p>
<p>It works with both polish format input files and also with
regular OpenStreetMap format files.</p>
<p>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.</p>
<p>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.</p>
<p>For OSM files, you need to add the <code>--housenumbers</code> option to
get house numbers in the map.</p>
<p>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
<code>addr:street</code> and <code>addr:housenumber</code> to nodes or polygons
representing the house.</p>
Now mkgmap has a real overview map2013-05-31T00:00:00+01:00https://www.mkgmap.org.uk/news/2013/05/31/now-mkgmap-has-a-real-overview-map<p>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 <a href="/download/mkgmap.html">download page</a>.</p>
<p>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.</p>
<p>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.</p>
<p>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.</p>
<p>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</p>
<p>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.</p>
<dl><dt>--overview-levels</dt>
<dd>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. </dd>
<dt>--remove-ovm-work-files</dt>
<dd>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. </dd>
</dl>
<h1>Further improvements </h1>
<p>In addition to the overview map, there is also a slew of improvements and bug fixes
that have been added.</p>
<h3>Fixes</h3>
<p>There are fixes for maps that cover a large portion of the globe or extend to 180 degrees longitude.</p>
<ul>
<li>fix wrong interpretation of 0x800000 as -180.0 degrees for maxLon</li>
<li>fix treatment of very long lines that cross the planet</li>
</ul>
<h3>Optimizations</h3>
<ul>
<li>The polygon filter allows larger polygons. </li>
<li>SeaGenerator generates fewer "sea-only" and "land-only" polygons when
precomp-sea is used.</li>
</ul>
<p>Both reduce the img size, esp. for maps containing large <b>sea only</b> areas. </p>
<p>An option to better control the minimum size of a polygon that can now be configured per level.</p>
<dl><dt>--polygon-size-limits=limits-code</dt>
<dd>Allows you to specify a different min-size-polygon value for each resolution.
For example:
<pre>
--polygon-size-limits="24:12, 18:10, 16:8, 14:4, 12:2, 11:0"
</pre>
<p>
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. </dd>
</dl>
<h3>Changes regarding styles</h3>
<ul>
<li>The support for the obsolete map-features.csv file was removed.</li>
<li>Level ranges can now use min-max or max-min</li>
<li>There is now an option <code>--check-styles</code> which will flag issues in the style
that are known to cause problems.</li>
</ul>
<h3>Other changes</h3>
<ul>
<li>A few checks are performed regarding the plausibility of the given options and input files
to help beginners.</li>
</ul>
Moving to Java version 72013-02-27T00:00:00+00:00https://www.mkgmap.org.uk/news/2013/02/27/moving-to-java-version-7<p>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. </p>
<p>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!</p>
Weekend in Essen2013-02-08T00:00:00+00:00https://www.mkgmap.org.uk/news/2013/02/08/weekend-in-essen<p>Over the last weekend I attended the<a href="http://wiki.openstreetmap.org/wiki/Garmin_Project">
Garmin Project weekend</a>
in Essen, Germany.
It was great to meet and exchange views with
all the other participants.</p>
<p>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.</p>
<p>So I would like to thank those that made it all possible, to <a href="http://www.fossgis.de">FOSSGIS</a> who sponsored the event;
the <a href="http://www.linuxhotel.de">Linux Hotel</a> 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!</p>
Exit hints2013-01-25T00:00:00+00:00https://www.mkgmap.org.uk/news/2013/01/25/exit-hints<p>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.</p>
<p>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.</p>
<p>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.</p>
<p>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:</p>
<pre>
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
</pre>
<p>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. </p>
<p>An example of such a rule is given below.</p>
<pre class="wiki-pre">
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]
</pre>Style functions2013-01-20T00:00:00+00:00https://www.mkgmap.org.uk/news/2013/01/20/style-functions<p>In a mkgmap style, you can now do more than just test the values of tags.</p>
<dl><dt>length()</dt>
<dd>Gives the length of a way in meters. This can be used to omit short driveways and the like.
<pre>
highway=residential & access=private
& length() > 50 ...
</pre></dd>
<dt>is_complete()</dt>
<dd>True if all the nodes of a way were present in the input file.</dd>
<dt>is_closed()</dt>
<dd>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.</dd>
</dl>
<p>This useful feature was added by WanMil.</p>
Creating pre-processed boundaries2013-01-10T00:00:00+00:00https://www.mkgmap.org.uk/news/2013/01/10/creating-pre-processed-boundaries<p>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.</p>
<p>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.</p>
<ol>
<li>Download the OSM europe extract</li>
<li>Run osmconvert and osmfilter to extract all boundary information:
<pre>
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
</pre></li>
<li>Start the new mkgmap bounds preprocessor:
<pre>
# The following should be all one line
java -cp mkgmap.jar
uk.me.parabola.mkgmap.reader.osm.boundary.BoundaryPreprocessor
europe-boundaries.o5m
europe_bounds
</pre>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. </li>
</ol>
The --remove-short-arcs option is no longer needed2012-12-27T00:00:00+00:00https://www.mkgmap.org.uk/news/2012/12/27/the-remove-short-arcs-option-is-no-lon<p>In the past you would get many "zero length arc" errors.</p>
<pre>
SEVERE (RoadNetwork): 63240020.osm.gz: Road (...) contains zero length arc ...
</pre>
<p>These were not caused by bad map data, or something that you could do
anything about. The solution was to give the
<kbd>--remove-short-arcs</kbd> 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.</p>
<p>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.</p>
The o5m format is now supported2012-12-21T00:00:00+00:00https://www.mkgmap.org.uk/news/2012/12/21/the-o5m-format-is-now-supported<p>Both splitter and mkgmap now support the <a href="http://wiki.openstreetmap.org/wiki/O5m">o5m</a> 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 <tt>--output=o5m</tt> option.</p>
<p>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.</p>
<p>There is not such a large speed advantage for mkgmap.</p>
<p>The o5m support was added by Gerd Petermann.</p>
Improved splitter released2012-12-17T00:00:00+00:00https://www.mkgmap.org.uk/news/2012/12/17/improved-splitter-released<p>Congratulations on a much improved version of splitter that was released
today by Gerd Petermann.</p>
<p>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.</p>
<p>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.</p>
<p>Currently you have to supply the <code>--keep-complete=true</code> 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.</p>
<p>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.</p>
<p>The <a href="http://wiki.openstreetmap.org/wiki/O5m">o5m</a> format is now supported for both
read and write. The o5m format is somewhat quicker when used as a splitter input file.</p>
<p>There are also loads of bug fixes too!
This is all available in release r263 which
can be obtained as always from the <a href="/download/splitter.html">splitter download page</a>
There are many more changes than are mentioned here, so for full details
read the full description <a href="/pipermail/mkgmap-dev/2012q4/015806.html">[1]</a></p>
<p>General information on how to use splitter can be found at
the <a href="/tile-splitter">tile splitter</a> page.</p>
TYP file compiler2012-02-17T00:00:00+00:00https://www.mkgmap.org.uk/news/2012/02/17/typ-file-compiler<p>Another recent feature added is the ability to compile TYP file from the .txt
format.</p>
<p>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.</p>
<p>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.</p>
<p>The compiler supports some of the newer features in the TYP file:</p>
<ul>
<li>images with single colour transparency (gif-style)</li>
<li>images with partially transparent colours (alpha channel)</li>
<li>true colour images (16 million colours)</li>
<li>true colour images with transparency</li>
<li>Icons containing the same image in different resolutions, that can be displayed at a high resolution on newer devices.</li>
</ul>
<p>The .txt files are best created with a graphical editor such as <a href="http://pinns.co.uk/osm/ostyp.html">TYPWiz</a> or the <a href="http://ati.land.cz/gps/typdecomp/editor.cgi">
ati land</a> web based editor.</p>
<p>There is a wiki page that describes the language that is accepted
at <a href="http://wiki.openstreetmap.org/wiki/Mkgmap/help/typ_compile">mkgmap typ compile</a>
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.</p>
Address index for GPS devices2012-01-28T00:00:00+00:00https://www.mkgmap.org.uk/news/2012/01/28/address-index-for-gps-devices<p>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.</p>
<p>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.</p>
<p>The main thing to watch out for is that if you <b>also</b> have the --tdbfile flag set you will get
<b>both</b> 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.</p>
<p>At the moment the index will not fully work if you are combining more than one family id into the output file.</p>
<p>For general details of building a map with mkgmap from OSM data see the page on <a href="http://wiki.openstreetmap.org/wiki/Mkgmap/help/How_to_create_a_map">How to create a map</a></p>