|
|
|
Posted
20 days
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
... [More]
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. [Less]
|
|
Posted
4 months
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
... [More]
between the announcement that mkgmap would require Java 6 and it actually happening, this time there
will not be such a gap! [Less]
|
|
Posted
4 months
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
... [More]
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! [Less]
|
|
Posted
5 months
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
... [More]
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] [Less]
|
|
Posted
5 months
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
... [More]
& 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. [Less]
|
|
Posted
5 months
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
... [More]
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.
Download the OSM europe extract
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
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. [Less]
|
|
Posted
6 months
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
... [More]
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. [Less]
|
|
Posted
6 months
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
... [More]
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. [Less]
|
|
Posted
6 months
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
... [More]
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. [Less]
|
|
Posted
7 months
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
... [More]
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 [Less]
|
Copyright
©
2013
Black Duck Software, Inc.
and its contributors, Some Rights Reserved. Unless otherwise marked, this work is licensed under a
Creative Commons Attribution 3.0 Unported License
. Ohloh
®
and the Ohloh logo are trademarks of
Black Duck Software, Inc.
in the United States and/or other jurisdictions. All other trademarks are the property of their respective holders.