Talk:Mkgmap

Note: You can post your mkgmap questions here, but you will get better response if you post your question to the mkgmap developer mailing list. --WanMil 18:08, 6 June 2011 (BST)

Could not open file: *.osm.gz after running Splitter

Hi, I have a drama trying to run MKgmap after the splitter.

Could not open file: *.osm.gz (note, where * is the file name)

Exception in thread "main" java.lang.NullPointerException

at uk.me.parabola.mkgmap.combiners.FileInfo.getFileInfo(FileInfo.java:136)

at uk.me.parabola.mkgmap.main.Main.endOptions(Main.java:366)

at uk.me.parabola.mkgmap.CommandArgsReader.readArgs(CommandArgsReader.java:124)

at uk.me.parabola.mkgmap.main.Main.main(Main.java:122)

I've tried saving the output files to various locations, thinking it's a file access problem. It doesn't matter what directory, nor where the files are (pointing to location)... have I missed something really silly? (note the o/p of the splitter is 8 .osm.gz files) I've not been able to find a result in the Wiki, Ubuntu forums or Google. Trenchtractor

Also posted Talk:Splitter

--

Can you post the full mkgmap command you're using. For instance, are you running mkgmap with -c template.args?csdf 16:13, 4 January 2010 (UTC)

--

Are you sure all files you specify to mkgmap exist? When I run "java -jar -Xmx512m ..\mkgmap\mkgmap.jar --tdbfile *.osm *.gz" in a folder containing only gz files I get the same message (checked with mkgmap versions 1436, 1523, 1536). Running mkgmap 1309 or omitting the "*.osm" generates a valid map. Individual tiles and the tdb file are created, but the overview map isn't. Rene_A 18:40, 29 January 2010 (UTC)

--

When splitter is called with --mapid=0000001 (or any other mapid which starts with zero(s)) there is a bug in splitter.

the files generated have eight character names (i.e. 00000001.osm.gz, 00000002.osm.gz, etc.) but the templates.args contains lines like:

mapname: 1
description: OSM-Map 1
input-file: 1.osm.gz

mapname: 2
description: OSM-Map 2
input-file: 2.osm.gz

Thus mkgmap cannot find the tile files when using this template file as "-c" input. I wrote a small patch to fix this:

Index: src/uk/me/parabola/splitter/AreaList.java
===================================================================
--- src/uk/me/parabola/splitter/AreaList.java   (revision 161)
+++ src/uk/me/parabola/splitter/AreaList.java   (working copy)
@@ -164,7 +164,7 @@
                Reader r = null;
                areas = new ArrayList<Area>();
 
-               Pattern pattern = Pattern.compile("([0-9]{8}):" +
+               Pattern pattern = Pattern.compile("([0-9]{1,8}):" +
                " ([\\p{XDigit}x-]+),([\\p{XDigit}x-]+)" +
                " to ([\\p{XDigit}x-]+),([\\p{XDigit}x-]+)");
 
Index: src/uk/me/parabola/splitter/Main.java
===================================================================
--- src/uk/me/parabola/splitter/Main.java       (revision 161)
+++ src/uk/me/parabola/splitter/Main.java       (working copy)
@@ -491,12 +491,12 @@
                w.println("# for each one.");
                for (Area a : areas) {
                       w.println();
-                       w.format("mapname: %d\n", a.getMapId());
+                       w.format("mapname: %08d\n", a.getMapId());
                       if (a.getName() == null)
-                               w.println("# description: OSM Map");
+                               w.format("description: OSM Map #08d\n", a.getMapId());
                       else
                               w.println("description: " + a.getName());
-                       w.format("input-file: %d.osm.gz\n", a.getMapId());
+                       w.format("input-file: %08d.osm.gz\n", a.getMapId());
               }

               w.println();

--

I do have the exact same problem. Issue occurs with the template. java -jar ../mkgmap.jar -c ../template.args

Oddly, when I am using java -jar ../mkgmap.jar --gmapsupp --route --net ../*.osm.gz , it generates 5 .img files (corresponding to my 5 .osm.gz), a gmapsupp.img (what I am actually looking for), a osmmap.img, osmmap.tdb but also an error file hs_err_pid4501.log In the terminal, I have this message:

#
# A fatal error has been detected by the Java Runtime Environment:
#
#  SIGSEGV (0xb) at pc=0x00007f3fe12138fd, pid=4501, tid=139912434505488
#
# JRE version: 6.0_18-b18
# Java VM: OpenJDK 64-Bit Server VM (14.0-b16 mixed mode linux-amd64 )
# Derivative: IcedTea6 1.8
# Distribution: Ubuntu lucid (development branch), package 6b18-1.8-0ubuntu1
# Problematic frame:
# j  uk.me.parabola.mkgmap.main.Main.endOptions(Luk/me/parabola/mkgmap/CommandArgs;)V+428
#
# An error report file with more information is saved as:
# /home/waluyo/Documents/rando/MapFinland/tentative compil finland/garmin-maps/hs_err_pid4501.log
#
# If you would like to submit a bug report, please include
# instructions how to reproduce the bug and visit:
#   https://bugs.launchpad.net/ubuntu/+source/openjdk-6/
#
Abandon

however, this one seems to work despite the error message, although the routing was totally absurd yesterday when I tried. Can you give me an explanation on that?

I am running on Ubuntu 10.04 (but I think it doesn't matter, does it?)and mkgmap is at its version 1652 (and splitter at 112)

Thanks! waluyo 10 January 2010

There have been some reports about problems with OpenJDK. Try the Sun JRE or JDK. This should work. --WanMil 18:00, 10 June 2010 (UTC)

thanks WanMil! it worked! :)) I simply switched the default version of Java using the command "sudo update-alternatives --config java". The previous error message doesn't appear anymore! However, the issue exposed by Trenchtractor remains. I still can't use templates for some reason. Any hints on that? waluyo 07:00 10 January 2010 (UTC)

Suggesting tags

I've just tried this out, and it works really well! Thanks! Is there anywhere I can put suggestions for improvements, like rendering railway=subway the same as normal railways, rendering highway=service, and rendering leisure=common the same as leisure=park? Gravitystorm 17:12, 6 January 2007 (UTC)

Good point, I've added my OSM email page. Adding suggestions here will work too! The next version will have many more renderings, based on the database in OSMGarminMap. I'll make sure your requests are included. Thanks. AcousticNewt 18:50, 6 January 2007 (UTC)

JOSM downloading memory problems

Works great for me! Thanks a lot. It's way more than I expected, as even the Find functions work with the OSM data. Two comments - I've uploaded a 160K file, so I haven't hit your predicted size limit (70-80K) yet. My limitation now is trying to get JOSM to download more data - it's sucking down a lot of memory ~ 460Mb or so and slowing up badly on my Powerbook. Secondly, I get more than one level of zoom - it displays at 0.3 miles, which I calculate is roughly 500m, and there's three or four useful levels of zoom below that. I'm using a Legend Cx, by the way. Phillip@comsomol.org 23:47, 11 February 2007 (UTC)

Sorry I didn't see your comment until just now. By now most of the arbitrary limits in mkgmap are gone anyway. For downloading, instead of using josm to download areas, you might want to try getting data directly. I wouldn't mind adding an option to mkgmap to download an area directly too. Thanks for the zoom info, I'll modify the main page as it seems to vary a lot between different models. AcousticNewt 13:43, 24 February 2007 (UTC)

Show segments which have no ways (out-of-date)

It is possible to show the segments which have no ways on garmin? This would it make easier for mapping with bike. Normally I add the ways first if I finished a region --waschbaer 18:40, 23 February 2007 (UTC)

Not possible with mkgmap currently, but I shall look to adding the option in the future. AcousticNewt 13:43, 24 February 2007 (UTC)

I found as solution, to add a second map with sendmap. For these second map I used OSM_Map_On_Garmin. So I can also select if I want to have the featured mkgmap-img or the complete map done by cgsmapper. --waschbaer 12:05, 24 March 2007 (UTC)

basemap bug

Discussion moved from the article page:

On my Vista Cx, if I switch off the basemap, the OSM map will display out to 1.2 miles/2 km. Bruce89 12:41, 20 January 2007 (UTC)

Interesting, although thats not the case on my Legend. AcousticNewt 13:21, 20 January 2007 (UTC)

Also true for the GPSMap60. When the basemap is not hidden the OSM data disappears above 500ft.

Attribution

I really like this, it's simple to use and produces great results. Is there any way that somehow the OSM attribution could be incorporated? In the future I'd like to make some img. files available for download, but wouldn't like to do that until I could comply with OSM licensing. Dmgroom 00:15, 19 April 2007 (BST)

It already includes an OSM attribution in the .img file in the place where copyright messages are placed. AcousticNewt 23:52, 22 April 2007 (BST)

OK, sorry, these obviously don't get displayed when I view the image file in PocketMV.Dmgroom 14:28, 23 April 2007 (BST)

forest and park green areas + consistent highway colours

I use the map from Computerteddy and it works great, thank you for the good job. I have some suggestions for showing the map.
From Mkgmap 198 to 200 you have changed the drawing of forest and park, it would be good if park, forest and wood are all green areas.
In the most Maps for Mapsource you have highways in blue, main streets in red and other streets in black and different thickness, it is very clearly in that way. The OSM Map is all in black except the highways, the same type of drawing like the most maps would be more consistently.
--Stefan 22:34, 30 August 2007 (BST)

Hi, I think the problem there is that I changed the feature definition file a bit and the Computerteddy generated maps, use a modified feature_map which didn't work. This lead to the differences in the areas I think. I certainly didn't intentionally change anything. I'm sure about the streets, they are just the colour that they are, it may be the same problem. ..Steve (AcousticNewt 20:41, 2 September 2007 (BST))

On a similar note, does the program handle Landuse: Basin. On a recent trip to the Avon, the basin at Stratford on Avon did not show up. --TTTPPP 12:20, 10 September 2007 (BST)

Not currently, should be fairly easy to add it ..Steve (AcousticNewt 22:43, 11 September 2007 (BST))

BUG: Lines are shifted

Long lines (often roads and coastlines) are shifted on the lowest (24-bit) layer in the resulting IMG. On all other layers they are on right place  :) Here is an example. Screenshots: buggy layer 0, right layer 1. --Liosha 10:19, 25 November 2007 (UTC)

There are some very long ways in there and that is the problem. It will probably be best from a practical point of view to split those ways into smaller pieces. But as far as mkgmap goes I can probably split the ways up, I already do this when there are too many nodes in a single way, so I imagine that its not a big problem to split them when they cover too much ground as well ..Steve AcousticNewt 20:04, 28 November 2007 (UTC)

I've just tried r417, problem still exists. Is t possible to split long ways automatically? --Liosha 17:31, 5 December 2007 (UTC)

This problem has not been addressed in r417. They can be split for size, but this has to be done earlier on in the process than is currently done to fix this particular problem. I'll post here when this is done. ..Steve AcousticNewt 20:14, 5 December 2007 (UTC)

Try r423, that might now work, it does for my test cases anyway AcousticNewt 23:42, 5 December 2007 (UTC).

Seems r423 works right, thanks. But probably there is the same problem with large polygons --Liosha 06:47, 6 December 2007 (UTC)

Found only one buggy example --Liosha 07:12, 6 December 2007 (UTC)

Oops, stupid bug. Fixed in SVN and will be in the next build AcousticNewt 21:24, 6 December 2007 (UTC)

So now polygons should also be split for size in the next build ..Steve 23:11, 6 December 2007 (UTC)

Still a bug with large polygon splitting, layer 0 again. Part of lake Baikal as example --Liosha 06:01, 7 December 2007 (UTC)

OK I found a bug that was not specifically to do with the splitting that causes the problem. Your example works now in SVN.

r433: there is no shift now, but some parts of polygon are missing on layer 0. Tested with the same example (reg04.osm) --Liosha 07:27, 9 December 2007 (UTC)

I added some code to investigate another bug, I've changed it now and all the polygons should appear again. ..Steve AcousticNewt 19:36, 9 December 2007 (UTC)

'Bad input file format' message

I got a problem by converting the actual planet.osm dated 09.05.2007 (also the version 02.05.2007) with mkgmap. By calling "java -Xmx1500M -jar mkgmap.jar planet.osm" i got the message "Bad input file format". What can I do? Kokstef 13:36, 12 May 2007 (BST)

I had the same message with a much smaler osm-file. May it is possible to get the line number of the osm-file there it happens? --waschbaer 15:48, 10 June 2007 (BST)

Firstly, a whole planet file is way too big to process so you need to use one of the extraction utilities to select an area from it. Still that is not the cause of 'Bad input file format' errors. These might be caused by attempting to to use the compressed file -- any file used must be uncompressed. It could just be a bad file of course too. I'd like to add some code to detect the various problems, not sure how easy it is to get actual line numbers, but could do better than it does. AcousticNewt 22:38, 11 June 2007 (BST)

May it is easier if I send you an example that wouldnt work? --waschbaer 11:56, 19 June 2007 (BST)

Yes you certainly can send me an example. I forgot to add that a common cause would be the file not being in utf-8, this was a problem with the planet.osm files (perhaps still is?) and you had to run UTF8Sanitise on them.

I was having this problem until I noticed the XML was missing the closing </osm>. Seems like a bug in osm-subset.pl. Firefishy 10:32, 18 July 2007 (BST)

Zoom levels

Any estimate in when different zoom levels will be ready in mkgmap? (apart from "when it is done"!) Great program by the way! It really has helped my mapping. --TimSC 11:22, 28 May 2007 (BST)

Pretty soon now... In fact if you build from svn see mkgmap/dev a basic multiple zoom map will be produced. AcousticNewt 22:38, 11 June 2007 (BST)

Doesn't seem to work for recent UK planets (Now fixed)

The latest UK planet files result in IMG files that don't work. For instance this one doesn't work made from the UK data. The GPS doesn't recognise the map, and QLandkarte crashes if it is loaded. Bruce89 14:26, 31 May 2007 (BST)

Having just tried it on data from 30th may, I can confirm that it produced an unrecognisable file as far as my GPSmap 60CSx is concerned. Fil 18:11, 31 May 2007 (BST) -- Ah, I see that Bruce89 was actually referring to my attempt -- I've since re-run it and it didn't work with that either. I was running this on an AMD64 system BTW, in case that makes a difference.

I have also tried on an AMD64 machine with both Java 1.6 and GCJ. No results. Bruce89 18:42, 31 May 2007 (BST)

I also produced a file that didn't work with data from an April planet, using an AMD XP+ processor- sorry for vagueness, but I thought it was just me being stupid. Now I see it's a more general problem. Phillip@comsomol.org 15:20, 7 June 2007 (BST)

This is now fixed in version r173. There was two problems. The first was that the UK is just a lot bigger than it was just a couple of months ago and an area of the file was overflowing. The second was that one of the subdivisions was too big. The top bit of the 'width' field is used as a flag to say that the list of subdivisions has ended. Everything after that would not appear in the file. AcousticNewt 12:20, 10 June 2007 (BST)

Doesn't seem to work for recent Germany file

the latest germany snapshot from http://openstreetmap.gryph.de/germany/germany-070823.osm.bz2 dont work for mkgmap-r188 and also not for mkgmap-r193 with the error message:

 Exception in thread "main" java.lang.ArrayIndexOutOfBoundsException: -6
       at uk.me.parabola.mkgmap.general.MapArea.pickArea(MapArea.java:330)
       at uk.me.parabola.mkgmap.general.MapArea.split(MapArea.java:140)
       at uk.me.parabola.mkgmap.general.MapSplitter.splitMaxSize(MapSplitter.java:152)
       at uk.me.parabola.mkgmap.general.MapSplitter.split(MapSplitter.java:85)
       at uk.me.parabola.mkgmap.main.MakeMap.makeMapAreas(MakeMap.java:182)
       at uk.me.parabola.mkgmap.main.MakeMap.makeMap(MakeMap.java:98)
       at uk.me.parabola.mkgmap.main.MakeMap.main(MakeMap.java:71)

java version is build 1.5.0_10-b03 --waschbaer 11:40, 25 August 2007 (BST)

Hi. Thanks for reporting this. I've also been emailed this bug and I'm working on the fix. I'll check the fix with your example osm file too. AcousticNewt 13:15, 25 August 2007 (BST)

Oh well the problem was actually a different one, but it is now fixed too. Look out for version 197 and above.

Find function on GPSr (Fixed)

The map works really well on a Garmin Legend Cx, but the find function behaves a bit oddly. Searches often bring up the same POI multiple times. This does not appear to be a problem in the OSM data.

Hmmm yes. I haven't looked at find for a while, it didn't used to do that. Thanks, I'll look into it. AcousticNewt 23:09, 29 August 2007 (BST)

I found the same problem with the find function bringing up multiple instances of the same points repeatedly--Petz 13:26, 1 October 2007 (BST)

Yes it is definitely a problem, but I don't know what causes it. It only happens when there is more than one zoom level in the map and when there are enough other features on the map. ..Steve

This should be fixed in version 313 ..Steve

Sea areas

A couple of side notes (I have no idea how easy/hard these are to do!) Would it be possible to make the sea an area as it is in the base map? I believe it's rendered as the coastline in Mkgmap. Would it be possible to select the area to create a map for by simply entering a lon/lat bounding box into Mkgmap?

Making the sea an area is the right way to do it certainly. I'm not entirely sure how to do it though. If anyone wants to help on that it would be great. AcousticNewt 23:09, 29 August 2007 (BST)

When I made a Garmin map of an island using GPSMapEdit and cgpsmapper, I had the same problem.

I created a coastline first. Then I tried to make a sea polygon in the shape of a rectangle connected on one side to a "hole" in the same shape as the coastline. The shape was somewhat like a ring with a cut in it, i.e. a line around the island with start and as separate nodes at the same position and a similar line around the outer rectangle, the start of the island line connected by a straight line with the end of the outer line and vice versa.

IIRC this did not work, maybe because the island coastline had too many points (around 8000). As my next and successful try I cut the sea polygon into two parts. I chose one point at the west coast of the island and one at the east cost and connected these to the outer rectangle. With these two sea polygons, my map is displayed correctly on a GPSMAP76CSx. The display has one problem, though. When I zoom out so that the outer rectangular border of my map can be seen on the GPS device, it fills the area outside my map with crossed lines to show that this area is not covered by the map. The Garmin City Navigator map is shown only if no part of my map is on the screen.

I think mkgmap could do the same to create some sea polygons that completely fill the area between coastline and tile border.

The algorithm to cut the coastline into pieces could use a point in the center of the land area, draw some lines (rays) from this center point to the border of the map tile, cut the coastline at the outmost intersection with this ray and connect it with the intersection of the ray with the tile border to create sea polygons.

-- Bomm 01:35, 19 June 2008 (CET DST)

Garmin eTrex Vista HCx

The Garmin eTrex Vista HCx is the newest model in the eTrex line and came out in Summer 2007. It's $100 cheaper and has better battery life than the 60CSx but with similar sensitivity.

You MUST use a MicroSD card to use Mass Storage Mode to upload maps. You can't use the internal memory.

Summary: mkgmap works!

I cheated a bit since I did not download OSM data, but instead generated it from TIGER. Interestingly, the at first the output from the tiger generator did not work. I had to open it up in JOSM (which accepted the file just fine) and then re-save it. Then mkgmap worked. Perhaps the XML is off a bit or the generator makes an old version.

Then I uploaded Manhattan NYC to my unit. If you zoom in, it works really well, full street detail. Zooming way out, for some reason all you see is the outline of the city and bridges (not major streets or highways), and if you are in the middle, you see nothing. I'll take a look at the data later and see how it's tagged, and upload screen shots.

--Nickg 16:34, 2 September 2007 (BST)

The HCx sounds cool... I'd be interested in finding out more about the problems you see, I've recently fixed a few problems that might affect things as you zoom out. ..Steve. -- AcousticNewt 22:43, 11 September 2007 (BST)

"mapsource" label

In the lower left corner of the screen (just below the scale) there is the "mapsource" label. Can that be changed to a meaningful "openstreetmap" (or "OSM") or is that label displayed as such by the GPS unit regardless of where the used map data comes from? --Stefanb 11:58, 28 September 2007 (BST)

Hi. That label is just what the GPS unit displays. There is no way to change it as far as I know. ..Steve --AcousticNewt 19:40, 28 September 2007 (BST)

I think this is because there is a ROM-based Garmin map on the unit (on my Vista CX at least), which you cannot delete (obviously :)). And an observation: when using high-level zoom, the text changes from "mapsource" to "overzoom" --Breki 14:54, 2 October 2007 (BST)

Rivers with new versions of mkgmap

Hi,

Rivers tagged as areas with waterway=riverbank and natural=water are now rendered only as a blue line ploygon and no more as a blue area. How should they be tagged to be better rendered ?

By the way, thanks for this wonderful work. FredB 23:26, 10 October 2007 (BST)

I've just made a change so that if something could be both a line and a shape, due to conflicting tags, then the polygon will be preferred. That may not be the only problem though, if not could you point me to an example. This should show up in tonights build. AcousticNewt 19:45, 13 January 2008 (UTC)

I have a Garmin Vista, and riverbanks (i.e. "shaped rivers") worked fine in past versions up to r506; now in r519, they are no longer filled. Oh, and forests are still rendered as parks, and vice versa. (Otherwise, a great program indeed - I wouldn't have joined OSM without the possibility of using the maps on my GPSr.) Dawidi 10:28, 12 January 2008 (UTC)

I understand the riverbank, see above, should be fixed. I don't get the park/forest swap though - parks near me show up as parks, do you have an example? ..Steve AcousticNewt 19:45, 13 January 2008 (UTC)

0x50 gives that patchy green, for solid green use 0x17. I exchanged the 0x50 with 0x17 for landuse:forest and natural:wood:

polygon|landuse|forest|0x17||18
polygon|natural|wood|0x17||18

I think it looks much better on my eTrex that way. R kleineisel 10:01, 25 July 2008 (UTC)

New Version doesn't work

Don't know, where to put bugs... Hope this is ok here.

I've downloaded version r291 and some data with josm (0.5-data; http://www.openstreetmap.org/index.html?mlat=48.0125646172838&mlon=7.779960847340263&zoom=9). mkgmap produces a file, but GPSmap 60CSx doesn't show the map (but it recognizes it). With the old version everything worked fine... Any ideas? --Kumakyoo 11:34, 12 October 2007 (BST)

Yes it just doesn't work... I'd stick to version 251 for now, the download section has been updated. ..Steve

tried latest as of r296, does not work. cz2.osm is produced with extract-polygon from planet-latest.osm. api0.5.

walley@ol-grezl:/mnt/hdb/poly$java -jar mkgmap.jar cz2.osm

   Exception in thread "main" java.lang.NullPointerException
       at uk.me.parabola.mkgmap.general.MapLine.addToBounds(MapLine.java:75)
       at uk.me.parabola.mkgmap.general.MapLine.setPoints(MapLine.java:45)
       at uk.me.parabola.mkgmap.reader.osm.FeatureListConverter.convertWay(FeatureListConverter.java:136)
       at uk.me.parabola.mkgmap.reader.osm.Osm5XmlHandler.endElement(Osm5XmlHandler.java:145)
       at com.sun.org.apache.xerces.internal.parsers.AbstractSAXParser.endElement(Unknown Source)
       at com.sun.org.apache.xerces.internal.impl.XMLDocumentFragmentScannerImpl.scanEndElement(Unknown Source)
       at com.sun.org.apache.xerces.internal.impl.XMLDocumentFragmentScannerImpl$FragmentContentDriver.next(Unknown Source)
       at com.sun.org.apache.xerces.internal.impl.XMLDocumentScannerImpl.next(Unknown Source)
       at com.sun.org.apache.xerces.internal.impl.XMLDocumentFragmentScannerImpl.scanDocument(Unknown Source)
       at com.sun.org.apache.xerces.internal.parsers.XML11Configuration.parse(Unknown Source)
       at com.sun.org.apache.xerces.internal.parsers.XML11Configuration.parse(Unknown Source)
       at com.sun.org.apache.xerces.internal.parsers.XMLParser.parse(Unknown Source)
       at com.sun.org.apache.xerces.internal.parsers.AbstractSAXParser.parse(Unknown Source)
       at com.sun.org.apache.xerces.internal.jaxp.SAXParserImpl$JAXPSAXParser.parse(Unknown Source)
       at javax.xml.parsers.SAXParser.parse(Unknown Source)
       at javax.xml.parsers.SAXParser.parse(Unknown Source)
       at uk.me.parabola.mkgmap.reader.osm.Osm5MapDataSource.load(Osm5MapDataSource.java:86)
       at uk.me.parabola.mkgmap.main.MakeMap.loadFromFile(MakeMap.java:136)
       at uk.me.parabola.mkgmap.main.MakeMap.processFilename(MakeMap.java:44)
       at uk.me.parabola.mkgmap.main.Main.processFilename(Main.java:84)
       at uk.me.parabola.mkgmap.main.CommandArgs$Filename.processArg(CommandArgs.java:285)
       at uk.me.parabola.mkgmap.main.CommandArgs.readArgs(CommandArgs.java:109)
       at uk.me.parabola.mkgmap.main.Main.main(Main.java:55)

--Walley 15:26, 12 October 2007 (BST)

Hi. If you could give me a link to the cz2.osm file that didn't work, I'll make sure that it does. ..Steve (AcousticNewt 21:25, 12 October 2007 (BST)). Updated: should be fixed in version 298.

I will be able to put it somwhere on teh web on monday if you still want it, but yes, version 298 works. THANK YOU! --Walley 09:14, 13 October 2007 (BST)

I've fixed it and have a good test case for the problem, so there is no need to post the osm file. Thanks ..Steve

298 Works. Thanks a lot for this fast "support". :-) --Kumakyoo 19:19, 14 October 2007 (BST)

Putting elevation contours into Garmin

Hello AcousticNewt. Please check out the Srtm2Osm tool I have just published. It could be used to generate relief data for Garmin maps. Since you have a lot of experience on Garmin features, you could suggest to me the best way to tag contours so that it would be easy for Mkgmap to translate them to Garmin contours.--Breki 18:43, 14 October 2007 (BST)

Hi. That looks really good. I got it to work on linux under wine and ran with the example area given on the srtm2osm page. I put a hack into mkgmap to put contours into the map along with the heights version 307 and it works well enough as a first attempt. I'll add more discussion at Contours. ..Steve (AcousticNewt 22:55, 14 October 2007 (BST))

Precedence of mapfeatures

I'm trying to prepare a cyclemap (with cycleways rendered red). I'd like to render roads with cyclelanes different from other roads, i.e:

• Road A: "highway=residential"
• Road B: "highway=residential, cycleway=lane"

My first try was:

polyline|cycleway|lane|0x0b||
polyline|highway|residential|0x06||

But this doesn't work. Both roads are rendered similar and the cycleway tag is ignored. I also tried to change the order of these two statements with the same result.

The same applies for "bicycle=yes" tags.

Therefore, I'd be happy to have mkgmap select the rules according to the order in the .csv-file. Is this difficult to add? --Kumakyoo 14:20, 18 October 2007 (BST)

Yes that sounds like a good idea. I should easily be possible to do something like that, I may have to think it over for a couple of days though. ..Steve (AcousticNewt 20:24, 18 October 2007 (BST))

Thats OK. I'll wait ;-) --Kumakyoo 21:03, 18 October 2007 (BST)

Routing

Is it possible to enable routing? I know that its possible with different conversion software, such as what I found here : http://www.malsingmaps.com/wiki/index.php/Making_A_Map_Routable . Thats really the only big thing thats still missing from OSM on Garmin. --Petz 12:31, 31 October 2007 (UTC)

Yes it would be great to do that, the trouble is that there is only a limited amount of information available about the extra information that is required to make the map routeable. ..Steve (AcousticNewt 18:36, 4 November 2007 (UTC))

libgarmin decodes the oneway flag on roads and the routing graph node positions. --Usm78 23:35, 24 March 2008 (UTC)

Is there any news about routing on Garmin? I know from the german mailing list, that lots of people (including myself) are extremely waiting for this. -- dieterdreist 13:41, 23 April 2008 (UTC)

There are many details of the routing sections that are now known. Alex of the libgarmin project and Robert Vollmert have made a lot of progress and their work is in the 'display' svn, where there is a utility to display the sections which works well on some maps.

There would probably be enough known to get some simple examples working. The main problem is, I believe, that routing needs an extended TRE header compared to what is used in mkgmap currently. The bytes at offset 0x9a need to be set correctly and I don't know how to derive them.. Although in the John Mechalas document they are speculated to be an encryption key, that can't be right (or complete) as they occur in un-encrypted maps (mkgmap doesn't and will not produce encrypted maps). ..Steve (AcousticNewt 15:07, 26 April 2008 (UTC))

I found routeable garmin maps on [1]. Was there made with mkgmap? --waschbaer 10:00, 13 July 2008 (UTC)

No, this is conversion to polish format (*.mp) and compilation with cgpsmapper.--Popej. 11:17, 13 July 2008 (UTC)

Hello, i have a Problem with newer mkgmap Versions. The Routing for Roads have a bug by me. It draw a routing Line directly from a point to another, and not along the Road. This appears not the whole Route, only partially. I have make sure i choose routing street, not airline on Garmin etrex Vista HCX. By older versions of spring 2009 i have Version 1163, there was no Problem at all. By the newer i have this problem. For Example, i route from Rödelsee in North Bavaria / Germany to Würzburg. There in Rödelsee the Problem begins to appear.

cgpsmapper failure

cgpsmapper can't convert the .img tiles generated by mkgmap into shapefiles. The error message is

cgpsmapper0081static: rgn_header.cpp:91: void RGN_element::Read(xor_fstream *, Coordinates, IMGfile *): Assertion `((rgnType >= 0x20 && rgnType <= 0x27 ) || rgnType == 0x2f || rgnType == 0x1d || rgnType == 0x2a || rgnType == 0x2c )' failed.

I'm afraid I cannot guess what it is that cgpsmapper is complaining about here. Is it every file or just a few? I am not using cgpsmapper while developing mkgmap and so I am not going to be able to look into it. I'll try out a fix if you have any idea what the issue is. ..Steve (AcousticNewt 18:36, 4 November 2007 (UTC))

Version 519 and POI in Garmin E-Trex

Hi, I use the files from User:Computerteddy which are created with mkgmap 519. I can not choose the menu entry: "Point of Intressts" from the search menu. It is disabled. So I can not search the nearest supermarket ....

The older versions (used by Computerteddy) works for me. Device: Garmin E-Trex Legend. Sven Anders 13:14, 13 January 2008 (UTC)

Is this a particular tile, or the whole Germany map? I'm probably going to need more information as my own maps don't seem to have this problem. AcousticNewt 20:31, 13 January 2008 (UTC)

Tile Number: 63255216 [2] The Whole Germany-File does not fit to 8MB Garmin devices. Sven Anders 11:56, 14 January 2008 (UTC)

Right. I see the same problem that you do with the downloaded one, but if I compile it myself, then it is OK. So I'm thinking that either it is a problem thats been fixed, or it is the way that the maps were generated.

I've just fixed a problem that caused similar symptoms, not sure if it was the same problem, but it definately was a problem. AcousticNewt 18:48, 19 January 2008 (UTC)

Map background

Hi, I have downloaded World maps for Mapsource from User:Computerteddy. This doesn't work correctly. I think maps generated by Mkgmap lack background polygon (type 0x4B). It's OK when there are other objects, but when map is totally empty Mapsource crashes.

I've now added background polygons, on the other hand empty maps are quite probably never going to work very well and we should try to avoid them altogether. ..Steve AcousticNewt 00:38, 20 January 2008 (UTC)

Is it possible to add custom-shape background? Or just to disable it? --Liosha 12:13, 29 January 2008 (UTC)

Its not possible at the moment. What are you trying to do? I guess there needs to be a way of making a transparent map.

Having a background object might allow us to make maps with a different background color than the standard yellow. It would be useful for making maps with e.g. a white background that look like topographic maps. R kleineisel 07:50, 7 August 2008 (UTC)

Converting multiple .img files to gmapsupp

I want to take the .img tiles from Computerteddy to create a gmapsupp of Europe. I wondered what the way is to specify that, because putting all of the .img file names into a options file and then calling that doesnt seem to work, and theres a limit to the length of the command line, so that doesnt work either? PS: I want to merge 926 img files. --Petz 17:41, 24 January 2008 (UTC)

You need to create a options file as below, with an input-file line for each file in the set along with the gmapsupp option. Pass the file to mkgmap with the -c option.

gmapsupp

input-file: 63243936.img
input-file: 63247525.img
input-file: 63253506.img
input-file: 63364845.img
input-file: 63364846.img

Cheers, that worked!! I generated a map of West and Central Europe, quite amazing that it only comes to 160mb. Is anyone interested in getting that file as well? I might put it up on my webserver.--Petz 20:42, 24 January 2008 (UTC)

POI not being found on GPS

I just checked out the img file I created on my GPSMAP 60Csx, and altough there are plenty of pubs in my neighbourhood, when i press find, and click on POI, the GPS doesnt return any of those nearby POI, but stuff 50km away as the closest. What's going on? My img come from Computerteddy's --Petz 20:56, 24 January 2008 (UTC)

There was a bug fixed in version mkgmap-r526 that would cause some kinds of POI to not show up. I think the latest computerteddy maps are from before this. I think however that there may be another problem with those maps as a lot of points appear to be just missing.

I am going to try and recreate the .img files from scratch using Computerteddy's OSM tiles, do you reckon that will yield a better result? Or is the POI problem also present in his .osm tiles? --Petz 09:52, 25 January 2008 (UTC)

Yes, I now got all POI in the .img. Will try to post it in this weekend. Cheers for mkgmap. --Petz 22:03, 25 January 2008 (UTC)

Well I was too late to reply :) But yes, recreating will work as the problem is not in the osm files. AcousticNewt 00:21, 26 January 2008 (UTC)

Updating an available gmapsupp.img

Ok, I concede this may be complete nonsense:

java -Xmx750M -jar mkgmap-r530/mkgmap.jar --description='Deutschland' --gmapsupp gmapsupp-copied.img new-data.osm

The idea was to update a huge map file with some new data freshly mapped.

What I get is this:

SEVERE (GmapsuppBuilder): could not create MPS file as it already existed (aledgedly) Could not create gmapsupp file

Is there anywhere some more information about the general .img-files with numbers as names, and why the numbers, and how they relate to gmapsupp.img, and whether this is a special name for Garmin?

BTW: I use a Garmin Legend HCx which works just fine otherwise with generated maps.

--HaraldK 10:28, 27 January 2008 (UTC)

Yes the gmapsupp.img is just a name that Garmin uses. The .img file format is an archive format, similar to a zip file for example, that can contain other files.

The individual maps that comprise the gmapsupp file are themselves .img files which contain serveral other files. These are all named with a number, again that's just the way it is done.

To do what you want to do, then you would need to extract all the files from the gmapsupp.img, remove the ones you want to update and combine the remainder altogether with the new ones. This is not possible with mkgmap, although the tools are there to create such a program fairly easily - look at CopyFile under the test directory for example.

If you just want to add files to the gmapsupp, rather than update, then it is now possible with mkgmap using the command you tried. I made a fix to ignore the MPS file that was causing your error. This version can be obtained from subversion and will be in the next nightly snapshot.

AcousticNewt 15:01, 27 January 2008 (UTC)

Various comments

Cool Tool

Thanks for the great tool. I used the maps of ComputerTeddy as well, but as I was more interested in Cycle Maps I started to play with it a bit. I'm watching the map right now and am very pleased to see all cycleble ways even in low zoom levels. --SlowRider 20:28, 4 February 2008 (UTC)

Thanks for the comments, I've done an initial reply to everything below. ..Steve AcousticNewt 21:54, 5 February 2008 (UTC)

Config file for cyclists

I tried to create a config which renders ways less convenient for cyclists as dashed lines, but renders ways convenient for cyclists as thin black lines even at lower zoom levels. Unfortunately the wiki does not allow uploading files other than image formats. Temporarily I placed it here. It also works very well to render tracks with tracktype set other than tracks without tracktype set. I just placed tracktype=grade1 before highway=track. I enjoy it :) .

Thanks, I've downloaded that. One day I'll make a way of having lots of different styles built in and and referenced by name.

Creating custom street types

I have a somewhat heretic question. Was it possible to create custom way types? I like the thin black lines for cycleways, but they now read as "Line" on the device. It would be cool to redefine it as something like "Cyclable Way". Plus was it possible to redefine its colour? It would be cool to paint tracks of grade 5-3 as gray lines, grade 2-1 as brown, and service+cycleways as black lines.

• It is possible to redefine the colour and the name of any of the line features using a custom type file (TYP file). It may not work on all units though. Its another undocumented format, but I believe I know enough to create simple coloured styles for lines, though I've not actually tried yet.
  • Not that important for me, but anyway: One user complained that the black lines do not provide a good contrast in night mode. He asked if it was possible to render them in brown colour. Unfortunately there are only thin dashed lines and fat lines predefined in brown, but not thin continuous lines. Maybe a further case where you might be attempted to tweak the line styles. --SlowRider 21:25, 6 February 2008 (UTC)
  • Polylines tagged 0x2b to 0x3f and 0x17 will not be shown in Mapsource (6.3.17). They will show on GPS unit however. 3 byte definitions are not yet supported. --Extremecarver 16:39, 1 October 2008 (UTC)

Tweaking zoom levels

I also tried getting better results by mapping resolutions to zoom levels. After some fiddling I asked someone who already tried it. After some short experience exchange, we decided that it was better to give up. That's not related to mkgmap directly, but maybe it's worth mentioning in its docs that it is very difficult to actually improve the map by tweaking those settings.

• Well I don't want to stop people trying ;) but Jochen and the other contibutors have done a good job and it works quite well. But again there is room for different styles, the current one works better on a larger screen (eg QLandkarte, and perhaps the larger Garmin devices) than on the smaller ones in my opinion and one style will never be the best for all situations.
  • I bet you are right. I guess you're talking about User:Joto. We did the first tweaking some months ago as we wanted to improve the default rendering.

Mapname option won't work

Neither --mapname=abcdefgh nor --mapname="abcdefgh" work for me. Not an issue as I have written a script anyway. But it's a feature that doesn't work as advertised :) .

• Perhaps the advertising is wrong then... as it has to be an eight digit number. OK, thats not entirely true and I will fix that stack trace at least, but you should stick with a number. If you want to give a readable name to the name then --description is the one to use.
  • No, the advertising is right. I simply ignored "Garmin maps are named by 8 digit numbers" and interpreted it with "Garmin maps are named by 8 characters". My fault :) .

Example:

java -mx2048m -jar ../mkgmap-r530/mkgmap.jar  --mapname="abcdefgh" --description=osm-map-ce --map-features=../mkgmap-config/GPSMap60csx-TrekkingBike-features.csv  --latin1 --gmapsupp MyAreaHuge.osm
Exception in thread "main" java.lang.NumberFormatException: For input string: "abcdefgh"
        at java.lang.NumberFormatException.forputString(NumberFormatException.java:48)
        at java.lang.Integer.parseInt(Integer.java:447)
        at java.lang.Integer.parseInt(Integer.java:497)
        at uk.me.parabola.imgfmt.app.map.Map.createMap(Map.java:92)
        at uk.me.parabola.mkgmap.main.MapMaker.makeMap(MapMaker.java:69)
        at uk.me.parabola.mkgmap.main.MapMaker.makeMap(MapMaker.java:45)
        at uk.me.parabola.mkgmap.main.Main.processFilename(Main.java:102)
        at uk.me.parabola.mkgmap.CommandArgs$Filename.processArg(CommandArgs.java:348)
        at uk.me.parabola.mkgmap.CommandArgs.readArgs(CommandArgs.java:118)
        at uk.me.parabola.mkgmap.main.Main.main(Main.java:78)

Without the mapname option it works.

Street name search

Currently we do not know how to make the map searchable for street names. Very annoying if a passenger asks you for a street and you cannot answer his question. But here's a question: Wasn't it possible to extract one node of any street and make it a POI in the map? It has some drawbacks, I know, but anyway it would be much better than no search at all. As the Garmins list POIs next to your location/pointer streets with the same name in different locations wouldn't be a problem, would they? Still you will see streets wich are splitted into various trunks as multiple streets with the same name, but again it's much better than no search at all.

• Yes thats a good idea, I've seen groups on the net doing that. Heh, I looked up OsmPoiCreator thinking it would be ideal but saw that you wrote it... so maybe thats not what you were looking for...
  • OsmPoiCreator creates custom POIs in gpx and gpi formats. My idea was to embed the streets as POIs in the map. Thus they could appear as a category of its own (like "Streets") in the find menu. If we place them in the gpi file you had to go to Find, Custom POIs, Press menu, select database, choose "Streets" and then search for the desired destination. Not as straightforward as having them directly in the find menu :) .

mkgmap-r530 support Chinese?

Hi,

Just found this cool tool, and I tried to use josm created a .osm file (POI in Chinese) and compileed with mkgmap-r530. And the final img file contain "???" for the POI name (in Chinese), I also tried to add --latin1, however still the same. Just wondering if mkgmap-r530 support Chinese or not? Or is there any way to do this?

Thanks

it is the same with russian language. Regards --Stefan 19:16, 26 February 2008 (UTC)

QLandkarte has support for 10bit encoding, so there is a free software reference code which can be implemented in mkgmap --Usm78 23:11, 24 March 2008 (UTC)

Buildings and TYP-Files

Computerteddy has included rendering buildings with building=yes tag in his World Map. This is very usefull for orientation. There are two problems with rendering.
1. The colour of the building, it is white. In Mapsource the background is yellow and the buildings are white, it is difficult to see a building on the map. It is possible to change this colour to a light red or so? The Garmin code for building is 0x13.
2. Using of multipolygon for building with a courtyard. Example is The Zwinger in Dresden. It is possible to render this in the same way like Osmarender do it?
Best Regards from Dresden --Stefan 19:29, 26 February 2008 (UTC)

0x13 is really "Man-Made Area" (shown as "Area" ("Fläche") on a nuvi). I guess, it's not supposed to be easily visible. Having a better code would be nicer. Another option is some "TYP"-file, which changes the colors for existing codes or so. But I have no idea, how they work. Elrond 12:25, 1 March 2008 (UTC)

Hello Elrond and Steve, I have used the last days to learn something about TYP-Files for Garmin. The Result you can find on my Page User:saftl, there are some Screenshots from Mapsource and my Nüvi. On the Etrex Vista HCX it is also working. I have created a TYP-File for Polylines and Polygones which are defined in Computerteddys Map Feature File. The Styles and Colors I have made in a similar way to Osmarender. So my Garmin Map is look like Informationfreeway.org now ;-).
If you want test the TYP-File by yourself, load the TDB-File and Typ-File from my site User:saftl, load Computerteddys World File and create a REG-File like on my site. Than you can see the new style of the map in Mapsource and you can downlod it to the handheld. In QLandkarte is no Typ-File working at the moment, so you must use Mapsource.
It would be a nice thing, if mkgmap can include a typ-file in the mapset, than we don't need cgpsmapper for this. It is not so difficult, only the Map ID from the TYP File must set also in the TDB File. I have used ID 42 for my Map.
Best Regards --Stefan 21:07, 17 March 2008 (UTC).

That is cool! Is it not possible to use mkgmap to add the typ-file into the gmapsupp.img file? It is meant to work. I can make it also take note of the family ID in the TDB/TYP files. ..Steve (AcousticNewt 00:09, 20 March 2008 (UTC))

I don't know, if mkgmap can include the Typfile into the gmapsupp.img. I'm more interested in including the Typfile into the Mapset for Mapsource. So it would be cool, if you can add an option to mkgmap "--typfile=file" or so, so that the typfile is added to the compiled mapset. To do this, mkgmap can read out the FamilyID from the Typfile which is specified and can include this into the TDB-file and the mapset is perfect for including in Mapsource. If you make a gmapsupp.img with mkgmap you can also add the typfile automatically to the gmapsupp.img. --Stefan 14:16, 20 March 2008 (UTC)

Are there any news for including Typfile Support in mkgmap? Did you need more information or anything else? --Stefan 16:28, 6 April 2008 (BST)

creating tdb-files

the option --tdbfile doesn't seem to work with custom names. The programm returns 63240000.img and 63240000.tdb files, while --tdbfile option is turned on, even when requested --mapname=12345678 which works for the img-name without tdbfile-option. The option use like --tdbfile=12345678 doesn't seem to work either. Dieterdreist 23:01, 29 April 2008 (UTC)

Hello, you need to use --overview-mapname=12345678 option, this makes both the overview mapname and the tdb name the same - as I believe they have to be. Thats probably worth me noting in the documentation as it is not obvious. The --tdbfile option does not take an argument. ..Steve (AcousticNewt 07:13, 30 April 2008 (UTC))

Hi, I investigated why Mapsource crash with German map from Computerteddy. It seems that parent map number for detailed maps is harcoded to 63240000. It should be equal to overview map number, so when you set overview map name to anything else then "63420000.img" then Mapsource will crash reading TDB. Just initialise value for parent with overview map number, it seems that you have "TODO parent =" comment in right place in TdbBuilder.java file :-) --Popej. 12:26, 21 June 2008 (UTC)

OK its time to do the TODO :) I've committed the fix, thanks. I didn't see the crash though, so I'd appreciate if you or someone who was having the problem can check that it works ..Steve (AcousticNewt 15:27, 21 June 2008 (UTC))

Older versions of mkgmap had a bug that the .tdb file and the overview map .img would not be created if there is only one .osm file. For two or more .osm files it would work. Does this bug still exist in current versions or was it fixed sometime? --Nop 20:23, 19 January 2009 (UTC)

Well actually that was intended behaviour. The --tdbfile option always causes a TDB file to be generated and the option is implied when there are more than file to be processed. Perhaps that is too much magic. ..Steve

TDB bug

mkgmap r1673 TDB file bug - when compiling mp files.

The --overview-mapnumber option creates a non usable TDB file. Mapsource aborts. The documentation says this should be a 8-digit number. But this is not correct, cgpsmapper allows creation of TDB files with alpha chars.

Just using --overview-mapname=name is suffcient to create a working TDB file. But then the resulting map seems to be shifted right and downwards - ie the img map does not fall inside the cream color box in mapsource (mapsource v6.15.7 thru v16.16.2). The cream color box appears to be incorrectly overlaid as I have also created the same map with cgpsmapper and the .img map appears to be correct but the cream color backgound box is incorrectly positioned by mkgmap. Also the resulting map is truncated because it extends outside the cream color box limits.

Mick

multiple tag parsing

It would be really cool to have multiple tag parsing. I propose that more than one OSM-tag could be used to determine the rendered feature. This would be useful to lots of things: rendering oneway-streets, different tracktypes, rendering of highway-areas (Squares, but also big traffic-zones, an extension at the end of a small road... ), which are tagged highway=xy, area=yes (right now, you have to decide which tag you are going to interpret: highway or area). It would also allow to use different icons for different restaurants (using the cuisine-tag as well) and the like. It can also be used for other areas besides highways, where the tagging convention recommends the use of area=yes property (Key:area) -- Dieterdreist 23:16, 29 April 2008 (UTC)

Yes it would be cool. The current re-write of the map-features system will allow for things like that, or that is the plan anyway. (AcousticNewt 07:19, 30 April 2008 (UTC))

One-way streets should already work though, as they are special cased, as is elevation for contours.

If I interpret the use map-features file properly, only the first match that is made is used... so doing multiple tags could be coded up to parse for a '&' symbol. --Mungewell 23:56, 10 September 2008 (UTC)

point|amenity & cuisine|restaurant & italian|0x2a|0x08|20
point|amenity & cuisine|restaurant & pizza|0x2a|0x0a|20
point|amenity|restaurant|0x2a|0x00|20

Multiple tag parsing revisited (+ multiple rule matching)

Any news on multiple tags support? It would really be great to have it. I'm trying to build specialized maps (i.e. hiking) and the most of the map features cannot be distinguished using just a single tag (example: a trail path that is trailblazed as opposed to the one which is not). I even tried playing around with TYP files to create two lines from a single OSM way (one dashed and half-transparent), but it seems Mkgmap just uses the first rule which it encounters and then ignores any other ones for the same OSM way. --Breki 17:45, 26 October 2008 (UTC)

Until this is done in mkgmap you can use OSM composer for that (a GUI for mkgmap that parses the osm file before it's handed over to mkgmap and can copy/change tags). The only limitation is, that it only works on small areas (so you would have to compile several tiles to cover greater areas). See here: http://wiki.openstreetmap.org/index.php/OSM_Composer

More important would be to have 3 byte .typ file support, because the number of possible polylines is now really limited. --Extremecarver 23:17, 26 October 2008 (UTC)

Thanks, I'll try that. --Breki 17:32, 27 October 2008 (UTC)

This is coming very soon now. Do you have some particular examples? --AcousticNewt 20:03, 8 November 2008 (UTC)

AcousticNewt, you mean the multiple tag parsing will come very soon? How do you want to achieve it? By placing for example two identical polylines with the same tag (a)), or by matching - i.e. in case that 2 tags to watch out are found on the same way, you can now define as what they will show instead (b)).

a) A highway=bicycleway is tagged also as foot=yes. Now the highway=bicycleway is copied and placed as highway=foot  (not highway=footway!!!) on top. 

Now you have two options. Either you place one above the other --> I am only interested in highway=bicycleway so this is drawn on top of highway=foot. OR --> You assign highway=foot a rendering that is shown besides of highway=bicycleway to see that the way is a bicycleway, but also people walking by foot are allowed to use it - that would be drawn using a transparent footway besides it. (of course the preference to foot/footway would be possible too).

b) You have now a new type like highway=bicyclefootway that you assign a special rendering too via typfile. 

Doing b) it takes up one more place in your typfile (not important if we had rgn2,3,4 support (often wrongly called 3byte support), but takes less work with transparent ways in your typfile. Is definitely the prefered option in case we can display rgn2,3,4 objects (you could now still achieve the same drawing as under a) via typfile, but you don't have to do this but you could introduce a new type too.

Yes more like b) you could do something like:

highway=bicycleway & foot=yes [0x1 level 2]
highway=bicycleway [0x2 level 3]

and ways that had both tags would have a garmin type of 1 and an end-level of 2, whereas ways that only had the bicycleway tag would have type 2 and an endlevel of 3. You can also do things like population > 10000 for example and that is why I was asking for more examples of what people are wanting to do, so I could see if there was anything else I could add that would be widely used. You will also be able to test for the mere existance of a tag (highway=*) and combine these tests together in any way with & and | operations. --AcousticNewt 11:42, 9 November 2008 (UTC)

Is this only valid for the style branch or also normal r 692?--Extremecarver 18:32, 9 November 2008 (UTC)

Only in the style branch. All the new stuff is rather untested, but produces identical results when not using any new feature, so I shall probably merge it to trunk soon. Perhaps today ..Steve --AcousticNewt 18:55, 9 November 2008 (UTC)

Thanks I'll SVN checkout the style branch then. Might be easier overall then using OSM Composer. (or maybe not easier, but a quicker compile time). I'll see if I can rebuild my maps just like they were done with osmcomposer.--Extremecarver 22:55, 9 November 2008 (UTC)

Or do you mean that 3byte .typ support is coming very soon (I know that basically there's only a few things to find out/steps to implement), while for multiple tag parsing OSM_Composer may be used (doing the example above like in a), but with Regex also b) should be somehow possible (needs some brainthought). --Extremecarver 23:20, 8 November 2008 (UTC)

No unfortunately I don't mean that :( ..Steve

Bug in rendering order?

I just used mkgmap 586 to create a gmasupp img from Computerteddy's tiles from April, 30th (created with mkgmap 586, as well) and I stumbled across a problem which can be seen in this area:

The lake on the left ("Adenauerweiher") and the long, narrow lake in the forest on the right both have the property natural=water, and both are in a forest area tagged with layer=-1. However, on my Legend Hcx, only the lake on the right is displayed correctly; the "Adenauerweiher" on the left can be seen briefly, however the forest area is rendered on top of it, in spite of the layer-property.

I could probably change the map data so that both lakes would show up on the Garmin, but from my understanding, this area should be displayed correctly the way it is, so it'd probably better to fix the underlying bug in mkgmap(?) than to cure this particular symptom.

Now I don't know anything about mkgmap's immer workings, so here's the small list of differences I could find between the two lakes. I hope that one of them is the culprit:

1. The lake on the right hand side was added after the forest area was already there. (Forest ID: 7368706, lake ID: 23222611) However, on the left hand side, the lake was added before the forest. (Forest ID: 23976701, lake ID: 23897058)
2. The lake on the left has a "name" attribute, the one on the right doesn't.
3. The lake on the left is fully inside of the forest area, whereas the one on the right is only partially within that area.

My money would be on the first one being the problem, but like I said, I have no idea how mkgmap does its magic. :-)

Anyway, thanks for any help. If you need any further info, I'll be happy to provide it.

--Baumi 13:38, 2 May 2008 (UTC)

Is there a way to specify rendering order (maybe in styles)? So that all lakes (natural=water) would be above large forests (natural=wood or landuse=forest). As otherwise it would require either tagging layer on them (does not look natural to me), or forest "islands" would have to be created above lakes...

Tstraupis 17:10, 12 March 2009 (UTC)

POI Bus_Stop and Motorway_Links

Hello,

is it possible to export the POI bus_stop with a name "Teststraße" as "Bus:Teststraße", because the Garmin Device shows all POI's in a list and a can not see, whether the name "Teststraße" is a bus_stop or another POI. If there is no name, the POI is called "Bushaltestelle", thats ok, "Bushaltestelle: Teststraße" would be optimal but is too long for the Garmin Device.

On the Etrex Vista there is a POI-Button Motorway-Links but the list is empty ...

I think your work is very very helpfull for the community, i use the maps from Computerteddy made with mkgmap. Thanks a lot for your work ...

-- huber08, 12 Juni 2008

There are also POIs on [3]

OSM World compilation by ComputerTeddy

Hi, compilation form 9. Juli 2008 doesn't work under Mapsource. There are maps with wrong positions, for example 63255241.img. This is an empty map only with background area. Unfortunatly its latitude is from N90 00.000 to N90 00.001. Maybe there is an error in function generating backgrounds or map boundary. Wrong is value in TRE header. --Popej. 13:48, 13 July 2008 (UTC)

That tile has a polygon of type 1, (which is not in the standard style) that has latitude of 90deg. Everything else then expands to fit. I'd have to see the input file to say more.

I'm not sure, maybe code in Area.java can create false position value. IMHO it should check for lat/lon limits.--Popej. 18:57, 13 July 2008 (UTC)

Combining an osm file with the Garmin Topo Germany

Hi,

i have tried to combine a very large (500MB) Image File (the complete Garmin Topo Germany) with a small osm file (250KB) with the following result:

java -Xmx1500M -jar mkgmap.jar --gmapsupp gmapsupp_topo_germany.img map.osm

Exception in thread "main" java.lang.NumberFormatException: For input string: "I0612309"
        at java.lang.NumberFormatException.forputString(Unknown Source)
        at java.lang.Integer.parseInt(Unknown Source)
        at java.lang.Integer.parseInt(Unknown Source)
        at uk.me.parabola.tdbfmt.OverviewMapBlock.setMapName(OverviewMapBlock.java:113)
        at uk.me.parabola.mkgmap.combiners.TdbBuilder.addToTdb(TdbBuilder.java:112)
        at uk.me.parabola.mkgmap.combiners.TdbBuilder.onMapEnd(TdbBuilder.java:97)
        at uk.me.parabola.mkgmap.main.Main.endOptions(Main.java:241)
        at uk.me.parabola.mkgmap.CommandArgs.readArgs(CommandArgs.java:121)
        at uk.me.parabola.mkgmap.main.Main.main(Main.java:89)

In the img file i have found the string "I0612309LBL", maybe the 'I' is unusual and currently not supported by mkgmap?.

I am using mkgmap-r630.

--Duesentrieb1 13:31, 20 July 2008 (UTC)

Number I0612309 is typical. Letter I means, that the number is in hexadecimal format. In this example numer is equal to decimal 06365961. For combining maps you can try GMapTool http://www.anpo.republika.pl/download.html#gmaptool --Popej. 00:00, 21 July 2008 (UTC)

Thanks Popej. Your program is great! --Duesentrieb1 20:07, 21 July 2008 (UTC)

--net feature and Mapsource

When using the --net feature in release 630 mapsource can't copy the file to the device or card. It says:"Mapset is 77MB but you have only 1937MB left on your card". I stole the temp map file out of the mapsource temp directory and copied it on the card. The mapset itself seems to be okay.

--McClane80

That kind of Mapsource message suggest, that there is an error in TDB file. But I never was able to trace down the reason of this error. --Popej. 00:05, 21 July 2008 (UTC)

-- BUG in net feature and Mapsource

There seeems to be a severe bug in --net feature. At least for r_680 and r_683. (I think too for r_659). The problem is, that once activated, the tooltip on the roads sometimes pops up at a wrong place. When dragging the map (in Mapsource or too on the Garmin Unit), then the dragging will start at the place where the tooltip was shown. This can result in drags to places up to around 1km away, even though one only dragged 50-100m....--Extremecarver 15:31, 19 October 2008 (UTC)

Rendering rivers!

I have observed some behavior that I do not understand. In trying to learn to use these GREAT tools I have been trying to make a map of London to use on a Garmin Nuvi. The Thames comes out looking odd for me.

Looking at the xml content of the .osm file I can see that the river is defined as a sequence of nodes that represent the banks with each bank a number of ways separately grouped and tagged as <tag k="waterway" v="riverbank"/>.

When the data is converted with mkgmap (both r590 and r630) to a .img file and displayed on the GPS or displayed with GPSMapEdit each bank segment is rendered as a polygon that includes the bank and a straight line joining the ends covering over a lot of land area on the inside of each bend in the river. I see this same behavior both on maps I have assembled myself and on the maps I find in the OSM Map On Garmin/Download page.

Interestingly, when I look at the Seine it is composed of a sequence of abutting polygons and renders as expected.

Any clue as to what I am doing incorrectly or how to otherwise resolve this would be much appreciated. --Lynn 17:58 UTC, 23 Jul 08

Hi, yes mkgmap treats waterway=riverbank as a polygon since the map features page says that it how is is used. So the Seine looks fine as it is taged as a sequence of polygons. However for the Thames the ways are just lines, so they get converted to polygons by drawing a line from the start to the end as you've observed.

Since the Thames also has natural=coastline tags, I think the best that can be done quickly for now is to make the coastline take priority over riverbank. This will mean that there is a line at both sides of the Thames but there will be no blue fill. Not perfect, but it will look better than it does now, its also how it was in the past (see the image on the mkgmap wiki page). So I have made that change in version r653. ..Steve

Thanks for the quick response Steve, it is good to know I am not crazy. I tried r653 and it seems to work as expected though I am still a little unclear as to why a riverbank would be considered a polygon but that is beyond my neophyte awareness! --Lynn

GUI and more

Hello !

Just letting you know that I tried to ease the work with the different tools available for OSM-Maps.

Have a look at my User Page and have fun...

You find the tool here : DoMyMaps

--Lao

Internationalization(I18n)

Name tag of OSM data contains various language alphabet. However, garmin device can display only latin character(As i know). Other alphabet except latin is displayed as ??? in garmin.

So it's very useful that mkgmap has a option using name:en tag instead of name tag. --HanDDol

I found out that my nüvi 255 can display the Romanian characters (codepage 1250). I used cgpsmapper on a .mp file created with osm2mp from OSM data. However, mkgmap will apparently not preserve the special characters, whether I use the same .mp file or the OSM data directly. I tried with the option --charset=windows-1250. Maybe it is not implemented? Unfortunately, I have no clue about java programming. --Endlessjourney 12:08, 15 April 2009 (UTC)

Sorry, I posted before reading more... I found in the meantime the options that make mkgmap work:

mkgmap.jar --xcode-page=1250 --charset=windows-1250

I tested only with MapSource and now I see the Ro characters, albeit with uppercase labels. The option --lower-case does not seem to have any effect. --Endlessjourney 13:03, 15 April 2009 (UTC)

Bitmaps in TDB file

I notice that the TDB file spec mentions that bitmaps for copyright can be added, presumably to display in MapSource. How much effort it is to include the OSM Magnifying Glass? --Mungewell 15:18, 27 August 2008 (UTC)

FIND MENU - Address search

I want to search for addresses. I know that in some commercial maps it's possible to look for street names and house numbers. I think we have enough data to do such a search but so far I know it is not possible at the moment. Does anybody understand what affects the categories in the Garmin FIND-Menu? When I use the maps from Computerteddy, there are just a few categories in the FIND-Menu. When I take the default settings from mkgmap and render my own map there are much more categories. It looks that nobody knows what's going on there. Is there a way to affect the entries in that menu?

Greetings from Dresden (Germany) --Master 16:52, 5 September 2008 (UTC)

Aggregated map doesn't work

Hello, I am trying to make a topo map for a large part of Germany. I use srtm2osm+mkgmap to generate topo tiles. The areas convered by the tiles do not intersect. The tiles all have distinct 8-digit names. I now arbitrarily sort my tiles into two sets, set A and set B. When I create a gmapsupp.img from set A alone or from set B alone and copy it to my GPSmap 60Csx the map works. Now, when I make a gmapsupp.img from set A and set B combined the resulting map is not displayed in the receiver, sometimes one can see the progress bar of the map loading process and loading seems to stop half-way. I have a 2G micro SD card in the receiver and I am far from the alleged limit of 2025 tiles. Any idea what this may be due to? Is there a faster way of testing a map than copying it to the receiver? Thank you for your help Winlemski 23:32, 24 September 2008 (UTC)

I have tried assembling the gmapsupp.img with GMapTool, and that worked. So the problem seems to be with mkgmap --gmapsupp.

Sometimes you have to create the individual maps without the --gmapsupp option and then combine them with java -jar mkgmap.jar --gmapsupp map1.img map2.img>. --Ævar Arnfjörð Bjarmason 05:50, 25 September 2008 (UTC)

That is actually what I did - with the described result. Winlemski 20:30, 25 September 2008 (UTC)

I'm doing the same thing with the US and have the same problem. I think I've narrowed it down to maps being broken when they are larger than 64MB in size - my Vista Cx doesn't display the map, and qlandkarte segfaults when trying to read it. Removing arbitrary tiles until it is below 64MB in size seems to fix the problem. Is there a too-small buffer in mkgmap someplace? Cluening 14:19, 4 December 2008 (UTC)

Yes, we seem to have a problem here, follow on: http://www.mkgmap.org.uk/pipermail/mkgmap-dev/2008q4/000141.html --AcousticNewt 22:20, 4 December 2008 (UTC)

Excellent, revision 779 works perfectly for me. Cluening 20:56, 6 December 2008 (UTC)

Use of uninitialized value $c error

I keep getting screens full of the following errors when running the preprocessor on osm files I have created myself using WGET. The last number changes for each pair of errors :

Use of uninitialized value $c in exists at preprocess.pl line 146, <GEN1> line 87256.

Use of uninitialized value $c in exists at preprocess.pl line 147, <GEN1> line 87256.

If I convert the OSM file directly with mkgmap, the map displays on my Garmin just fine. The data.osm is only 4513 KB. I'm using Windows Vista if that is significant.

I downloaded a bz2 from here and that processed fine.

Please can anyone tell me what the problem might be?

--AntonyW 08:24, 25 September 2008 (UTC)

Missing Feature: Support of Multipolygons

The :inner mulitpolygon is not shown. Therefore a correct rendering of a forest will not show. The same is probabely true for all other Multipolygons: i.e. a forest clearing inside forest would usually be tagged just as multipolygon:inner with reference to the outer polygon. It should then be rendered like empty area, except if you add an optional string like: landuse:scrubs. See more here: http://wiki.openstreetmap.org/index.php/Relation:multipolygon It would be great if mkgmap would render this correctly - unlike mapnik and osmarender which still produce errors (both only work correctly if outerpolygon is going clockwise, and inner anti-clockwise - it should work without depending on the direction at all however). --Edited: I noticed it being mentioned on the mkgmap developper wiki talk section. --Extremecarver 16:39, 1 October 2008 (UTC)

Thrashing on Linux

Hi, I've recently switched from Windows XP to Ubuntu Hardy. Now, Linux starts thrashing when mkgmap needs virtual (as opposed to physical) memory. This happens with both the sun jre6 jvm and the openjdk-6 jvm. As far as I remember the problem did not arise on Windows, so I guess it's more an OS or JVM problem than a problem with mkgmap. Nevertheless, I would be grateful for suggestions what I can do (besides splitting the input file or buying more RAM). --Winlemski 19:44, 14 October 2008 (UTC)

Setting a product ID in mkgmap?

I tried to work with a .TDB generated by mkgmap and a custom .TYP file in MapSource, but MapSource would not accept the .TYP file. According to the registry check of MapSetToolKit.exe, the reason for this was that the .TDB contained invalid values for product code = 42 and family id = 0. The name of the .TDB was the default in spite of using a custom image name. After patching the .TDB to proper IDs and renaming it, MapSource works nicely.

• Is there a way to set product ID and family ID for .TDB files?
• Is there a way to get a properly named .TDB? --Nop 01:32, 18 October 2008 (UTC)

Have you tried this: http://wiki.openstreetmap.org/index.php/Mkgmap/help/usage look for "Product description options" ; I believe what you want to achieve is already implemented. I'll have a look how to use it for the cyclemap with typ-file support too. Might be much easier for everyone not using mapsettoolkit then. --Extremecarver 15:34, 19 October 2008 (UTC)

I tried --product-id but didn't get it to work with r_683. - so for the moment the only way seems to me to use gmaptol from OSM user popej

Another way is to use OSM Composer which patches the .TDB files or do this with a hex editor. --Nop 19:30, 8 November 2008 (UTC)

Watch out with levels when building topographical maps

According to the principle, that a map is never allowed to have an empty layer, if you have two input files for mkgmap, you have to specify --levels for each input file, this is especially important when one of the input files consists exclusively of contour lines. Take the following command as example on how to create such a map.

java -jar mkgmap.jar --map-features=D:\Garmin\mkgmap_680\resources\cycling_map_features_typfile.csv --levels=0:24,1:22,2:20,3:18,4:16,5:14,6:12,7:10 data.osm --levels=0:24,1:22,2:20 srtm.osm

This would assume that you contour lines are are in layer 24 (minor), 22 (medium), 20 (major), and your normal osm data spread between 24 and 10. If you don't adhere to proper levels you will get problems with the map not displaying at lower zoom levels, not displaying at higher zoom levels, or not displaying at all (you'll only see the background polygon 0x4c).

There are 2 alternatives to circumvent having to assign different levels on compile.

a) introduce dummy objects at the lowest level into your map. A POI in the lowest level per input file is enough.
b) Merge your osm files (either by script, or in text editor (text editor may crash though on opening huge .osm files), and then use the lowest resulting level.

Concluding the easiest is to include dummy objects at lowest level. (it should be thought about mkgmap doing this by default). The lower your lowest level the later the basemap will exchange your osm map.

Clipping not always working as expected?

Sometimes when a way exits then reenters the bound, a spurious connection is drawn between the points at the clipped ends of the way.

This is version 681 and 704... I tried to make a simpler repro case, but of course they all worked fine.  :-/ But here is an example of a single real way on Angel Island just east of the Golden Gate Bridge in San Francisco Bay: badclip.osm, gmapsupp.img from v704

Command line was: java -Xmx512M -jar ~/bin/mkgmap/mkgmap.jar --gmapsupp ./badclip.osm

Hardware is an eTrex Vista HCx patched up to 2.80.

Again, I made up some simple working cases of ways exiting and entering bounds and being clipped properly, so it doesn't always occur. Or maybe I'm just doing something lame, I admit.

(ObPraise: overall, a wonderful utility, this.) Beej71 09:15, 13 November 2008 (UTC)

Thanks for the very clear description and example, it should make it easy to track down. I think the bug occurs because one of the points is exactly on the bounding box but I will update when I have a fix for it.--AcousticNewt 09:54, 16 November 2008 (UTC)

This is now fixed in r707. I'm not entirely sure what conditions would cause it to happen, you probably need two points parallel to an edge that are also very close to the edge. Anyway it works on you example now ..Steve --AcousticNewt 12:59, 16 November 2008 (UTC)

Cool! Works! Thanks! --Beej71 06:39, 17 November 2008 (UTC)

Typo in garmin_feature_list.csv

I'm not sure if that file originates with this project or from elesewhere, but the line:

point|0x10|0x2f|0x0e|others|garmin-dealer|Car Wash

should actually be something like:

point|0x10|0x2f|0x0f|others|garmin-dealer|

(i.e. 0x2e has been copied from the previous line instead of 0x2f). It doesn't affect the functionality of mkgmap in any way of course, but might help people (like me) looking for "unused" Garmin features to map OSM POIs to. (SomeoneElse 15:32, 27 December 2008 (UTC))

Garmin_feature_list.csv is since quite a long time not used anymore.

Support for reading bzip2 compressed files

The support for .osm.gzip'ed files sort of breaks with the .osm.bz2 compression seen used with planet.osm-snapshots, daily diffs and other OSM applications. Can mkgmap be extended to support bzip2-compressed OSM-files as well? I want to be able to compress OSM-files that I don't edit and use them across several tools. — vibrog 09:41, 11 January 2009 (UTC)

New file splitter

The new file splitter sounds very useful. Does it keep the order of data it processes or does it change the order around? --Nop 20:19, 19 January 2009 (UTC)

Yes, if a way precedes another way in the input file it may not precede it in an output file.

Is it possible to get a version that keeps the drawing order? I would need it for the same reasons as I needed mkgamp to keep it. Just a question, if it is not feasible, I'll have to write my own, less intelligent splitter. --Nop 21:09, 19 January 2009 (UTC)

Restored drawing order

Exremcarver wrote mkgmap works now conserving the draw order. Which version should I get to try this out? --Nop 21:09, 19 January 2009 (UTC)

It was changed in version 835 ..Steve

Additional information for POIs is ommitted

Hi. I have noticed, that the only information for POIs included in .img file is the name. In many cases full address, telephone, opening hours, description, etc. is available and is often really useful (as far as available on commercial maps). I have found address and telephone fields in POIRecord class, but it seems to stay unused. Which part is not implemented yet, and where can I look for it to make it functioning. --Paul 23.01.2009

A very good thought. Having the phone number and maybe the opening times of a POI in the map would be very convenient. --Nop 19:26, 23 January 2009 (UTC)

You can add it with Regex to the name filed. You just need to do it in the style-file. I don't think mkgmap can yet write to other fields then the name however.--Extremecarver 19:34, 23 January 2009 (UTC)

Map titled "family name"

In the Maps menu of my Garmin Edge 705, the gmapsupp.img that I create from OSM data with mkgmap or mkgmap-nod r844 is always listed with the title "family name". It would be nice to see the --description text there instead.

I guess you need to add the --family-name parameter with the desired description to your Mkgmap commandline. --Lambertus 10:02, 25 January 2009 (UTC)

Thanks, that fixed it. However, I'm having another problem: --family-name=OpenStreetMap-2009-02-25 will result in just "OpenStreetMap" being displayed in the map settings menu of the Edge 705. Similarly, OSM-2009-02-25 will be displayed as "Osm". Any ideas how to display the creation date of the map in the menu? --Skela 22:17, 25 February 2009 (UTC)

Just guessing: Probably "-" is not supported by mkgmap or by the GPS. Try a different character there, "OSM_2009_02_15" or simply "OSM20090215" --R kleineisel 14:02, 10 March 2009 (UTC)

Problems trying to generate contour lines for France

Hi,

I have generated 160 .osm files with srtm2osm to generate a garmin elevation map for France. When trying to run mkgmap-r844 on the folder containing the files, I got a problem :

Exception in thread "main" java.lang.NullPointerException
	at sun.misc.FloatingDecimal.readJavaFormatString(FloatingDecimal.java:991)
	at java.lang.Double.parseDouble(Double.java:510)
	at uk.me.parabola.mkgmap.reader.osm.xml.Osm5XmlHandler.addNode(Osm5XmlHandler.java:316)
	at uk.me.parabola.mkgmap.reader.osm.xml.Osm5XmlHandler.startElement(Osm5XmlHandler.java:102)
	at com.sun.org.apache.xerces.internal.parsers.AbstractSAXParser.startElement(AbstractSAXParser.java:501)
	at com.sun.org.apache.xerces.internal.parsers.AbstractXMLDocumentParser.emptyElement(AbstractXMLDocumentParser.java:179)
	at com.sun.org.apache.xerces.internal.impl.XMLDocumentFragmentScannerImpl.scanStartElement(XMLDocumentFragmentScannerImpl.java:1339)
	at com.sun.org.apache.xerces.internal.impl.XMLDocumentFragmentScannerImpl$FragmentContentDriver.next(XMLDocumentFragmentScannerImpl.java:2747)
	at com.sun.org.apache.xerces.internal.impl.XMLDocumentScannerImpl.next(XMLDocumentScannerImpl.java:648)
	at com.sun.org.apache.xerces.internal.impl.XMLDocumentFragmentScannerImpl.scanDocument(XMLDocumentFragmentScannerImpl.java:510)
	at com.sun.org.apache.xerces.internal.parsers.XML11Configuration.parse(XML11Configuration.java:807)
	at com.sun.org.apache.xerces.internal.parsers.XML11Configuration.parse(XML11Configuration.java:737)
	at com.sun.org.apache.xerces.internal.parsers.XMLParser.parse(XMLParser.java:107)
	at com.sun.org.apache.xerces.internal.parsers.AbstractSAXParser.parse(AbstractSAXParser.java:1205)
	at com.sun.org.apache.xerces.internal.jaxp.SAXParserImpl$JAXPSAXParser.parse(SAXParserImpl.java:522)
	at javax.xml.parsers.SAXParser.parse(SAXParser.java:395)
	at javax.xml.parsers.SAXParser.parse(SAXParser.java:198)
	at uk.me.parabola.mkgmap.reader.osm.xml.Osm5MapDataSource.load(Osm5MapDataSource.java:78)
	at uk.me.parabola.mkgmap.main.MapMaker.loadFromFile(MapMaker.java:124)
	at uk.me.parabola.mkgmap.main.MapMaker.makeMap(MapMaker.java:43)
	at uk.me.parabola.mkgmap.main.Main.processFilename(Main.java:150)
	at uk.me.parabola.mkgmap.CommandArgs$Filename.processArg(CommandArgs.java:329)
	at uk.me.parabola.mkgmap.CommandArgs.readArgs(CommandArgs.java:119)
	at uk.me.parabola.mkgmap.main.Main.main(Main.java:91)

Am I doing something wrong ? FredB 22:38, 27 January 2009 (UTC)

Tile Splitter on OSX

I have tried the new tile splitter for splitting the big OSM-Files on OSX and there are only errors, maybe somebody can help.

mkgmap saftl$ java -Xmx1000m -jar splitter.jar data.osm
Exception in thread "main" java.lang.UnsupportedClassVersionError: Bad version number in .class file
	...

Any ideas? I have Leopard 10.5.6 and there is no update for java available. --Stefan 18:47, 5 February 2009 (UTC)

You need java 1.6, it looks like a lower version is being used to get that error.

I use SoyLatte on my Intel OS X 10.4 (Tiger) system for splitter.jar. It works well in this environment. See SoyLatte: Java 6 Port for Mac OS X 10.4 and 10.5 (Intel) --Clinton Gladstone 16:54, 6 February 2009 (UTC)

OS X Leopard 10.5.6 are still using Java 1.5 AFAIK (I myself is a Leopard user), if you need java 1.6 before it gets upgraded in Leopard, check out the official Java site, or another java source. --Skippern 17:26, 6 February 2009 (UTC)

Um, as far as I know, Sun does not offer Java for Mac OS. Please correct me if you know otherwise. It does appear, however, that Apple offers Java 1.6 as a software update, but only for 64 Bit Intel OS X 10.5 environments[4]. I do not have OS X 10.5, so I cannot verify. This blog indicates that Java 1.6 will be installed on 64 Bit Intel OS X 10.5, but is not the default. You may have to directly execute the Java 1.6 bin, or change the links, etc. Or if your platform does not fit the requirements for the Java update, you can use SoyLatte as I do. --Clinton Gladstone 16:14, 7 February 2009 (UTC)

export JAVA_HOME=/System/Library/Frameworks/JavaVM.framework/Versions/1.6/Home will help you

Special codes in polyline Labels don't work

This was initially reported on Talk:Mkgmap/routing

Hi, first of all, i don't know if it's the same in the non-routable version of mkgmap. With v830 of mkgmap special codes in polyline label like '~[0x1e]' etc. will not be converted into img-format. If the label defintion in the mp-file is e.g. 'anyinfo~[0x1e]Mühlenweg' in the resulting img-file the label is 'anyinfo[0x1e]Mühlenweg'.

'~' is missing.

In fact of this MS shows always the whole string 'anyinfo[0x1e]Mühlenweg'. But it should depend on zoomlevel if only 'Mühlenweg' or the whole string will be shown.(Different special codes works in different way. For more info e.g. see cgpsmapper manual) Another effect is that the routing preview doesn't work correct. Normaly the second part should be shown on this side e.g. "Right on Mühlenweg". and not "Right on anyinfo[0x1e]Mühlenweg" Regards papaluna 11.January.2009

Meanwhile i found out why '~' is missing. In fact though i provided codepage=1252 and lblcoding=9 in the mp-format inputfile, mkgmap needs the parameters --latin1 --codepage=1252 for coming to the allmost same compilation result as e.g. cgpsmapper. Now i get the expected 'anyinfo~[0x1e]Mühlenweg' but furthermore, the specialcode will not be recognized by mkgmap and only will be shown in the gps as the full string 'anyinfo~[0x1e]Mühlenweg'. --Papaluna 12:16, 22 January 2009 (UTC)

Update: meanwhile, introduced with v1073 of mkgmap, special label codes can be used in style file. Starting with v1077, mkgmap also can handle codes like above reading the data from mp-input files. --Papaluna 11:49, 17 July 2009 (UTC)

Resolution of POIs

Great tool! I'm using it to convert osm files to img for a Garmin etrex Vista HCx. The only problem is, I'd like to remove certain types of POI from the map, as mine are full of public telephones, petrol stations, car parks and other stuff I'm not too interested in and they clutter up the map when I zoom in. So I copied the default style directory to a new one (called 'fewerphones') and reference this directory when I call mkgmap. It works, and generates the img file, but my changes don't seem to be recognised- either my definitions are wrong or the receiver is ignoring them perhaps. In the "points" file I changed it to read amenity=telephone [0x5100 resolution 24] and amenity=pub [0x4600 resolution 13], but it doesn't make any difference - the img file does have a different md5 sum than before but the effect on the screen is the same - both are visible at the same zoom levels as they were before. In the receiver I have points set to max zoom "auto" and the detail on "more", but even changing these doesn't have the effect I want- making the telephones less important than other points. Am I doing something wrong here or is it all the receiver's fault? Eric2 19:19, 9 March 2009 (UTC)

Alternatively, if there is a way to just *remove* certain POIs from the OSM file, perhaps before Mkgmap sees it, that would be a way of getting round the resolution problem. Is this possible? Eric2 14:33, 18 March 2009 (UTC)

So I came to the conclusion that this isn't possible with mkgmap (shame), I've no idea whether it's supposed to be possible or not, whether it's just an etrex problem or not, but anyway. So I had to write a file converter to take the osm map and a list of amenity types, and then write out the new osm file with all nodes of that amenity type removed. It's just a simple hack but it does achieve what I wanted. I called it OsmWrangler. If anyone else is interested (although it appears not) then see http://activityworkshop.net/software/ Eric2 08:44, 6 April 2009 (UTC)

I tried out resolution on POI and it sure works. Are you sure that mkgmap really used the style-file? Try to take amenity=telephone completely out of the style-file to see wheter it still shows up. There is no remark by mkgmap if it can't find the style-file and default to the default one. Maybe however some 0x???? behave different than others. It could be that on some of them the resolution has no effect while it has on others. Try out changing the type too therfore.

Well I *was* sure that it was using the file, because I checked that the md5sum was different, so I assumed it had had an effect. And it was complaining about not finding styles when I typed the name wrong, so I was sure. But now I'm not. And I didn't realise that I could just delete the line from the file, which is even better. So it's now working - I extracted all the files from the jar and specified the main.Main directly - when running it from the jar it couldn't find the style-file. I'm not sure if that's by design. Also the resolution didn't appear to have any effect on the telephones (maybe a handset issue) and changing the icon to a pub symbol worked for toilets but not for telephones. But removal worked for everything, that's great! So not much use for the OsmWrangler now :) Eric2 19:16, 30 April 2009 (UTC)

I've had some trouble with telephones and toilets not working at the correct resolution. It seems that my GPS (Garmin Legend HCx) tends to shows telephones at a higher resolution than specified in the map. It looks as if the garmin boosts them perhaps 2 or 3 steps in the resolution above that set in the map. If I change the garmin code used for telephones/toilets in the style file to something completely different then they work fine (other than having the wrong category and icon). I don't think it is a problem with mkgmap more some combination of things on the GPS unit itself. --MarkS 13:17, 1 June 2009 (UTC)

I've also been unable to change the level that Telephones and Pubs appear. I can remove them completely by taking them out of the style file altogether, but I can't seem to control which zoom level they appear at. I use a GPSMap76Csx csdf 10th July 2009

The units have their own idea of what POIs they will display at different zoom levels, even if you say you want to see at lower resolutions. There is nothing you can do about this, as far as we know.--AcousticNewt 09:49, 11 July 2009 (UTC)

Is there a list of the objects that can be affected by the resolution parameters in the styles files (and conversely, those objects which cannot)?csdf 08:47, 13 July 2009 (UTC)

GUIs

I noticed that the owner of freegeographytools.com has written a GUI for mkgmap - the post is at http://freegeographytools.com/2007/converting-openstreetmap-data-into-gpx-or-garmin-img-format however it's closed source and windows-only. So not being able to try his out (so I don't know what it looks like or how it works) it inspired me to write my own very simple frontend in java. It doesn't support all the many command line options for mkgmap, in fact it only does two things - conversion from osm to img, and combination of several imgs with the --gmapsupp option. But it makes it easier for me to use, I can just doubleclick on the icon and use the buttons and file selection dialogs instead of using the command line. And it's java so it should run wherever mkgmap is likely to be used. Feel free to check it out at http://activityworkshop.net/software/mkgmapgui/ Eric2 14:33, 18 March 2009 (UTC)

Debugging missing names and oneways

I think it would be useful to be able to produce debugging garmin maps with emphasis on residential streets with no names, and also displaying oneway (together with direction if possible). The goal is to help map contributors to see where these important information are missing directly on the GPS. Is this feasible?

This is what the custom styles are for. Have a look at the "noname" style, which is described as follows: "This style is to help find roads that don't yet have a name in OSM by highlighting those roads. Roads that have a name or a ref are shown as thin lines, ones that are missing a name are shown as thick lines." Eric2 09:14, 30 March 2009 (UTC)

Ok, but where can we found this custom style? An what about oneways?

in \resources. You can create them yourself. Customize yourself. You could create a oneway style if you want to.--Extremecarver 00:03, 5 April 2009 (UTC)

Just to be clear: the noname style is built into mkgmap. You use the option --style=noname to use it.

BUG: Country-abbr still GBR

I'm trying to specify the country abbreviation with --country-abbr=CHE but on the maps the cities are still labeled with "FooCity, GBR" in the city-finder.--blk 22:08, 1 April 2009 (UTC)

Are you perhaps using a config file? CH works here, I guess CHE will work too. 17:32, 18 April 2009 (UTC)

PS: Perhaps take a look at my Script. —[[User:Granjow|Granjow]] 12:28, 20 April 2009 (UTC)

Styles

I made a style, put it in \resources\styles, but if I run the command with --style=stylename mkgmap seems to use the default style. If I use --list-styles, it also doesn't show my style, and even more: if I delete a style (noname) from \resources\styles it still shows them! I would be grateful if someone helped me with this... --Willem1 18:18, 14 April 2009 (UTC)

(I'm using v858. --Willem1 16:46, 17 April 2009 (UTC))

Just an idea, try running ant after putting the style there. Granjow 17:35, 18 April 2009 (UTC)

What does Ant do then? Am I doing something wrong when making a new style? --Willem1 13:02, 19 April 2009 (UTC)

Ant compiles everything and creates the jar file. Perhaps mkgmap includes the resources directory in the jar file and only looks there for new styles. —[[User:Granjow|Granjow]] 14:28, 19 April 2009 (UTC)

Isn't it possible to use an external style then? (--style-file doesn't work for me...) It doesn't sound easy to compile every time you create a new style. --Willem1 15:18, 19 April 2009 (UTC)

Yes, it's possible to use an external style, and no you shouldn't need ant and you shouldn't have to recompile. I got it working by making a copy of the default style in the styles/ directory, and editing that. Then I called mkgmap with --style-file=styles/mystylename. I'm not sure if this is the best way to do it but it appears to work. Eric2 19:19, 30 April 2009 (UTC)

I copied the default style, changed one rule and renamed the directory to fietskrt. I used the following command:

C:\Users\Willem\Documents\OpenStreetMap\mkgmap>java -jar mkgmap.jar map.osm --style-file=resources\styles --style=fietskrt --transparent --tdbfile

and it still uses the default style... It also gives no error message, which is pretty annoying. --Willem1 15:39, 1 May 2009 (UTC)

Order of files using --gmapsupp

I have two small img files from different, non-overlapping areas of Britain. One is 400k, the other is 600k, and both were generated from osm files using mkgmap. I tried to combine them using --gmapsupp into one img file, but the results seem different depending on the order in which I give the files. I assumed that the order should not matter, right? If I give file1 file2, then the resulting gmapsupp.img file is 500k, and only contains detail about the first area. If I give file2 file1, then the gmapsupp.img file is only 300k, and only contains detail about the second area. What could be the problem? Eric2 06:31, 1 May 2009 (UTC)

That is strange. The gmapsupp.img file should contain both maps and so be roughly the same size in either case. What was the command line used? ..Steve

Simply java -Xmx512M -jar mkgmap.jar --gmapsupp ~/file1.img ~/file2.img (version number says 858). This has worked before with other img files. Eric2 18:38, 1 May 2009 (UTC)

Zooming Out

I'm having some trouble getting maps to work properly as I zoom out on my eTrex. At the high zoom levels roads disappear and appear correctly as the zoom levels changes (for example if I move from a zoom level of 1.2miles to 2.0m then the secondary roads disappear - this fits with a resolution of 19 being specified in the mkgmap style file). However, if I zoom further out things start to go wrong. For example the style file gives trunk roads a resolution of 16 which suggests to me that trunk roads should disappear once I get to about 30miles zoom level on the etrex, but even if I go out to 300m or more I still have the trunk roads being drawn. As well as an empty type file I've also tried a user defined type file, which mostly works but when the zoom level changes from 5m to 8m (ie a resolution of 18 to 17 in the style file) then the background colour in the type file nolonger works (although roads still get the right colour) - this may be related or a completely separate issue. I've tried using the both the main release of mkgmap and the latest version (r1101), I've also tried using both a customised style file and the default style but I still see the same behavior. Is anybody able to confirm if this always happens or give me some pointers as to where I should look to fix this? --MarkS 09:18, 1 May 2009 (UTC)

After playing around it seems to be a combination of levels and resolutions which cause the issue. As far as I can see Mkgmap supports 8 levels, which you can set directly if you wish. Each level represents a different resolution. If you specify a resolution itself then mkgmap seems to create an extra level if a level doesn't already exist for that resolution. The standard style file includes more than 8 different resolutions which means it tries to create more than 8 levels. It can't do that and so the higher resolutions get merged or something and roads that should disappear at higher levels don't. The solution is probably to decide the 8 resolutions you want at the outset, then only use these (and for safety define these resolutions as levels as well).

---

Removing roads/points

I've been looking at creating a map with things that need fixing (eg. objects with the FIXME key). I was intending to create a transparent map that overlays my main map. I've created a new style file which just processes the required items - the style file has a fairly simple lines file and no points file. However, the output from mkgmap contains all roads and lots of points of interest as well the processed roads. However, this extra information means it doesn't really work as an overlay for my normal map. Is there anyway to remove objects? ----

Which command did you use? If mkgmap appears to use the default style, this could be the same problem as the paragraph "Styles" above. Perhaps a bug (which prevents from choosing another style)? --Willem1 18:57, 15 May 2009 (UTC)

I'm using --style-file="U:\Garmin Maps\MyUKMap\mkgmap\resources\styles\2fix". I'm confident it is picking up my style file because I can alter things in my style file and they follow through to the maps. The issue is for things where I don't specify them in the style file. For example originally the style file only asked for roads which didn't have a name, the result was a map with roads with no name in it, but also all the other roads as well. It looks to me as if the Mkgmap reads the default style first and then added my style file afterwards. At the moment I'm using a workaround which forces (via my style file) all the roads I don't want to use an unused garmin code which the garmin doesn't display. The result works as only the noname roads are rendered but the drawback is a large IMG file as all the other roads are effectively also in the map.--MarkS 19:14, 28 May 2009 (UTC)

It should not use also use the default style unless your style tells it to. You make it pick up the default style by putting base-style: default in the info file. So in your case, you need to make sure that you do not have such a line. --AcousticNewt 06:58, 29 May 2009 (UTC)

That's what I was doing wrong. I'd copied the default nonames style to work from and that contains base-style: default. Thanks for the help. --MarkS 13:49, 29 May 2009 (UTC)

Creating large maps

When i download several areas in JOSM, save them into file and feed this file to mkgmap, only the area i downloaded last is rendered into .img file. It's very inconvenient, and there was no such behavior until recently. --Alexey 14:19, 27 June 2009 (UTC)

Try to use '--ignore-osm-bounds' parameter (e.g. 'java -jar mkgmap.jar --ignore-osm-bounds mymap.osm'). --Dmitriyp 17:36, 30 April 2015 (MSK)

Tile border visibility

At the most zoomed-out levels, I can see a border around each individual tile in the gmapsupp.img using my GPSMap76Csx. How can I control the zoom level at which these borders are visible? I've had a look through the default style and the tile borders don't seem to be specified. Is it perhaps a default behaviour of the GPS unit, rather than a property of the gmapsupp.img file? csdf 13:05, 10 July 2009 (UTC)

Yes that is the behaviour of the GPS unit. --AcousticNewt 09:51, 11 July 2009 (UTC)

Showing more details of POIs

Hello,

in the last time I'm creating my own map for my Garmin Vista Hcx with this great program. But there's still one feature I miss:

I'd like to write more details of POIs into the info box. For your information: With 'info box' I mean the window, which is opened when you click with the pointer on a point. For example I would like to add the text 'with CNG' if a fuel station has the tag fuel:cng=yes or the text 'with shelter' if a bus_stop has the tag shelter=yes to the info box. Until now I had to solve this problem with a construction like this: name '${name} (${ref})' | '${ref}' | '${name}' But so the name label was very long. It would be very good, if I could set this text in the typfile or another configuration file for mkgmap. I think it wouldn't be difficult for you, because the address of a point is already shown in the info box.

Rurseekatze from Germany

mkgmap produces “Could not create or write to file”

I installed mkgmap, and ran

"java -jar mkgmap.jar data.osm" from a command window in vista. I put a test data.osm (27Kb) in the same folder as the mkgmap. I tried what I could but still get the “Could not create or write to file” message without a .img file being produced. What do I overlook?

Hein Schouwenaars(NL)

Solved by email. This was a permissions problem, the user didn't have permissions to create files in the directory in which mkgmap was stored. Changing directory and referencing the path to mkgmap.jar solved the problem :) Eric2 09:52, 24 August 2009 (UTC)

mkgmap problem

I got error "Too many items in the polygon section". But I can't split my map to smaller files. Is there some way how to compile unmodified map ?

That is an unusual problem. What is the area you are creating a map for and does it have an unusually large number of polygons of a particular type? If you really can't split the map, then you need create a style without whatever polygon type that is causing the problem. It is essential a bug so might get fixed at some point. --AcousticNewt 16:46, 8 August 2009 (UTC)

: In my opinion, this problem is caused by mkgmap's probably unhandled TRESIZE parameter. This map segment covers part of the central Slovakia, it is topo map with much 10m land contour (source - SRTM) and "shaded" terrain model based on tutorial at http://www.cgpsmapper.com/download/Creating%20custom%20types%20to%20represent%20elevation%20data.pdf I can't find problematic polygons :(

Whats wrong with 1130? "..contains zero length arc"

Hi,

in current 'latest version' (1130) the following errors occurs What is wrong on my usage? in 1087 the error doesnt occur.

SCHWERWIEGEND (RoadNetwork): Road unclassified (OSM id 4229163) contains zero length arc
SCHWERWIEGEND (RoadNetwork):   http://www.openstreetmap.org/?lat=47.98508&lon=7.83677&zoom=17
SCHWERWIEGEND (RoadNetwork): Road K 3749 (OSM id 34951605) contains zero length arc
SCHWERWIEGEND (RoadNetwork):   http://www.openstreetmap.org/?lat=48.69952&lon=8.11145&zoom=17
SCHWERWIEGEND (RoadNetwork): Road null (OSM id 32066479) contains zero length arc

the command mkgmap is calling with:

(in one line)

java -Xmx8000M -jar mkgmap.jar --style-file=../styles/masterstyle --description='Openstreetmap' --country-name=germany --country-abbr=DE --family-id=3 --product-id=45 --series-name='master-edition' --family-name=OpenStreetMap --area-name=DE --latin1 --mapname=63240345 --draw-priority=10 --add-pois-to-areas --road-name-pois --net --route --gmapsupp ../tiles/*.osm.gz /home/myuser/osm/styles/master.TYP --Rudi56 08:51, 12 August 2009 (UTC)

Thanks to AcousticNewt: Using the "--remove-short-arcs" option, now it works fine. --Rudi56 18:52, 14 August 2009 (UTC)

secondary_links

Hello, right now secondary links are not in the default templates and show up as dotted lines on my eTrex. The GPS won't use them for routing and will instead prefer long detours. Could a line like highway=secondary_link [0x04 road_class=2 road_speed=2 resolution 20] be added to the lines file for the default template? Thanks. Nakor 13:53, 14 August 2009 (UTC)

3-byte-types cause bufferoverflow with larger osm files

i'm using 0x010000 to 0x010007 line types in my custom style. larger osm files cause a nio.BufferOverflowException (whatever that is, i know next to nothing about java). result is an overview map that seems empty and a zero byte .img

i don't have much time for testing right now, but 2mb of osm are fine, 170mb are not. after deactivating the 3-byte-types types in the style, the 170mb file is ok.

i'm using latest-mkgmap of 25 aug

seems solved with latest 27 aug

Using multiple img files to create gmapsupp results in filesize error from QLandKart

When I first started using mkgmap a year or more ago I could download different tiles from osm and patch them together into a gmapsupp and upload them to my gpsr with QLandkarte with no problem.

Some time later, after a reinstall and downloading a newer version of mkgmap I began having a problem combining img files. QLandkarte began giving me an error whenever I tried to upload. "Program error: wrong number of blocks written"

I did everything I could think of at the time to fix this but was unable. I resorted to using single tiles at a time which qlandkart had no problem uploading.

I've downloaded several versions of mkgmap since then (858, 1188, 1471) and I still have the same problem. This time I tried running qlandkarte in terminal to check the output there. When I try to upload a multi img gmapsupp created by mkgmap with two files of size 3685376 bytes and 6566912 bytes I am given this error:

GMAPSUPP.IMG file size: 10229760 characteristics: 2048 18432 4995 27 tiles: 1 file size: 10229760 should be: 3690496 blockcnt: 1802 optBlocksize: 2048

Now, as I see in a couple of cases below in this discussion, if I change the order of the files the "should be" section reports the other filesize. The gmapsupp, when loaded in qlandkarte, does display the info from both img files used. Why is it that qlandkarte thinks that the filesize should equal only the first file? I'm curious how it even knows what the filesizes of the original img files are.

Where is the problem in this scenario? Is this mkgmap or qlandkarte?

I'd greatly appreciate any help with this problem. Thanks

New Problem SCHWERWIEGEND (MultiPolygonRelation):

There is a new error "SCHWERWIEGEND (MultiPolygonRelation):" what does this meaning?

SCHWERWIEGEND (MultiPolygonRelation): Multipolygon http://www.openstreetmap.org/browse/relation/215183 contains intersected ways

What do i wrong in this case? (new parameter, or missing old one?)

Thanks a lot for help.

This was introduced by the new multipolygon code - it doesn't stop anything from working so just ignore it for the time being. Or go back to an older version of mkgmap if you prefer. csdf 10:17, 26 January 2010 (UTC)

Thank you!

Is it an error: SCHWERWIEGEND (MapSplitter)?

I run mkgmap after splitter an OSM-File and get this error on nearly every file. What happend? How can it fixed?

SCHWERWIEGEND (MapSplitter): 21000008.osm.gz: Area too small to split at http://www.openstreetmap.org/?mlat=47.44472&mlon=13.03556&zoom=17 (reduce the density o f points, length of lines, etc.)

--Stepborc 18:53, 26 April 2010 (UTC)

NSIS problem

I am generating gmapsupp.img with included typ with --nsis.

problem: Section "MainSection" SectionMain

 SetOutPath "$INSTDIR"                                                         
 File "${MAPNAME}.img"                                                         
 File "/var/www/garmin/kraje/routable/osm/42020100.TYP"                        
 File "${MAPNAME}.tdb"                                                         
 File "42020001.img"                                                           
 File "42020002.img"                                                           

....

typ file is present with its full path entered, this is wrong and installer could not be compiled. command used:

/usr/bin/java -Xmx512m -jar /var/www/garmin/kraje/routable/mkgmap.jar --overview-mapname=42020000 --tdbfile --country-name=czechrepublic --country-abbr=CZ --family-name=walleycz --family-id=150 --product-id=152 --series-name='OSMCZ by walley' --description='walley' --nsis --gmapsupp /var/www/garmin/kraje/routable/osm/*.img /var/www/garmin/kraje/routable//contours/*img /var/www/garmin/kraje/routable/osm/42020100.TYP

Is this a bug or am I doing it wrong? --walley 14:40, 4 June 2010 (UTC)

It is a bug. For now please put the TYP file in the same directory as your IMG files. Thanks. Nakor 17:26, 4 June 2010 (UTC)

BUG/Issue through SVN 1650 Update

I had suddenly problems to build the AIO garmin maps on my own. I traced this to a change with the 1650 commit.

Exception in thread "main" java.lang.IllegalAccessError: tried to access method uk.me.parabola.imgfmt.app.ImgReader.position()J  from class uk.me.parabola.img
fmt.app.trergn.RGNFileReader$RgnOffsets
       at uk.me.parabola.imgfmt.app.trergn.RGNFileReader$RgnOffsets.<init>(RGNFileReader.java:227)
       at uk.me.parabola.imgfmt.app.trergn.RGNFileReader$RgnOffsets.<init>(RGNFileReader.java:201)
       at uk.me.parabola.imgfmt.app.trergn.RGNFileReader.getOffsets(RGNFileReader.java:186)
       at uk.me.parabola.imgfmt.app.trergn.RGNFileReader.pointsForSubdiv(RGNFileReader.java:71)
       at uk.me.parabola.imgfmt.app.map.MapReader.pointsForLevel(MapReader.java:107)
       at uk.me.parabola.mkgmap.combiners.MdrBuilder.addPoints(MdrBuilder.java:170)
       at uk.me.parabola.mkgmap.combiners.MdrBuilder.onMapEnd(MdrBuilder.java:113)
       at uk.me.parabola.mkgmap.main.Main.endOptions(Main.java:374)
       at uk.me.parabola.mkgmap.CommandArgsReader.readArgs(CommandArgsReader.java:124)
       at uk.me.parabola.mkgmap.main.Main.main(Main.java:122)

When I do change the "protected long position()" in /src/uk/me/parabola/imgfmt/app/ImgReader.java back to "public long position()" it seems to work fine again :) -- Tgoti 21:23, 5 June 2010 (UTC)

I believe that is caused by a partial re-compile. Make sure that you completely clean first and build (ant rebuild should do it). AcousticNewt 21:18, 8 June 2010 (UTC)

Wish List

A .TYP file compiler / editor (mkgtyp?) would be nice, compatible with the source format of the online editor / decompiler http://ati.land.cz/gps/typdecomp/editor.cgi --Gerchla 09:39, 1 August 2010 (UTC)

Splitting of gmapsupp.img into tiles, overview map, typ file, etc. would be useful for people using QLandkarteGT. --Gerchla 09:39, 1 August 2010 (UTC)

Incorrect character transliteration to ASCII

Recently I noticed, that character "ý" (in HTML &yacute , in TeX \'y ) in labels is incorrectly recoded to "u" in place of the correct "y". I have used both stable (1625) and development (1667) version of mkgmap without any language options (i.e. without --charset, --latin1, etc.). I looked even into the source and the transliteration table seems correct. Mystery :-)

For demonstration, please look at lat="49.1760664" lon="16.5597638", where is suburb name Nový Lískovec. On my Garmin Legend HCx it is however rendered as Novu Liskovec. Any idea?

Japanese place names

I have a question about the conversion of Japanese place names. For all place names written in Japanese characters, mkgmap provides the Chinese and not the Japanese reading in Latin characters. For example, instead of "Tokyo" it says "Dongjing" and instead of "Osaka" it says "Dabanshi". I noticed this on the worldfile by Computerteddy and he suggested that I contact the makers of mkgmap. Computerteddy creates his place names in the sequence name,name:de,name:latin,name:en and assumes that the Chinese readings of Japanese place names are listed in the tag "name". Is it possible to correct this so that maps created with mkgmap show the Japanese reading of all place names in Japan? Thank you. --Fred

This is due to the way the Japanese community did their bilingual map. They did not separate the Japanese and the English but mixed it into a single name tag. The characters used also appear in Chinese so mkgmap does transliterate them into Dongjing. So the problem is in the underlying data, not in mkgmap. A better solution would be to tag the names in separate tags. For example Japanese in name, English in name:en. The map creator can then choose to prefer name:en resulting in English names in the map. --Stephankn 18:28, 3 January 2011 (UTC)

Create routable map from gpx data

Hi, I am trying to create a map from my gpx data (tracks and waypoints) through Mkgmap. That's what I do:

gpsbabel -i gpx -f mydata.gpx -o osm,tag="highway:unclassified",created_by="me" -F mymap.osm

then:

java -jar mkgmap.jar --net --route --gmapsupp mymap.osm

It works right, but the resulting map is not routable. I also tried to add --index and --tdbfile options, but this didn't help.

Any suggestion? Thanks!

Hi, two things to mention:

• Remove the created_by tag. It just blows up the osm file and is not used by mkgmap
• Two streets are crossing on one node. In case gpsbabel creates two nodes (one for each street) for the crossing, routing cannot work. In this case, open the mymap.osm with JOSM and fix that manually.

--WanMil 20:59, 7 January 2011 (UTC)

Thanks for your reply. I use gpsbabel to convert from gpx to osm format because this is the only tool I know that can do that. Maybe is there a tool that does such conversion so that the resulting osm file is better suited to be an input to Mkgmap?

I don't think that you find such a tool. There is one fundamental problem: How should this tool know if two crossing GPX tracks are crossing on a crossroads which means they must be connected in one point or if one GPX track is a bridge and therefore they must not be connected in one point? The GPX format is not an adequate format for routing purposes. --WanMil 13:35, 9 January 2011 (UTC)

Thanks a lot for your explanation which helped me to understand this important point.

Rendering rivers that are also tagged boundary=administrative data

As a result of importing a lot of government data into OSM for Australia there are many boundaries that are tagged and boundary=administrative and waterway=river.

Try as I might I cannot get mkgmap to render those that are rivers as rivers and those that are not as boundaries. mkgmap can handle this for roads as indicated by the following comment in the default lines style file:

The following boundary styles are after the highway rules because ways
are frequently tagged with both and we want the highway to take priority.

I have tried:

1. Putting my waterway= styles before the boundary=administrative rules.
2. The reverse of this.
3. Adding NOT operators to boundary=administrative rules e.g. boundary=administrative & admin_level<7 !waterway=* [0x1c resolution 20].
4. Adding NOT operators to waterway= rules e.g. waterway=river !boundary=administrative [0x1f resolution 18]

Any suggestions would be welcome.

At the moment, since I need to show waterways, I have hashed out all the boundary=administrative rules but that is not really a satisfactory solution.

-Swanilli 08:02, 13 February 2011 (UTC)

Tag motor_vehicle=no seems to be ignored in routing

I've set a grade1 to motor_vehicle=no, agricultural=yes. Despite this, my Nuvi360 is still trying to route me onto this grade1 as it is a shortcut. Can this be fixed, or am I just using wrong options in creating the map? --Chasu 20:51, 18 August 2011 (BST)

This is fixed in the default style since r2092. -- Jetthe 21:16, 17 November 2011 (UTC)

Can not specify style file directory

This is happening when we specify a folder for the style. When we package the style as .zip it is working well. Tested with 2179.

$ mkgmap --product-version=3 --style-file=/folder/to/our/style -c config.cfg data.osm
java.lang.StackOverflowError
	at java.nio.HeapByteBuffer.<init>(HeapByteBuffer.java:70)
	at java.nio.ByteBuffer.wrap(ByteBuffer.java:367)
	at java.nio.ByteBuffer.wrap(ByteBuffer.java:390)
	at java.lang.StringCoding$StringEncoder.encode(StringCoding.java:254)
	at java.lang.StringCoding.encode(StringCoding.java:289)
	at java.lang.String.getBytes(String.java:954)
	at java.io.UnixFileSystem.getBooleanAttributes0(Native Method)
	at java.io.UnixFileSystem.getBooleanAttributes(UnixFileSystem.java:243)
	at java.io.File.isDirectory(File.java:771)
	at uk.me.parabola.mkgmap.osmstyle.StyleFileLoader.createStyleLoader(StyleFileLoader.java:55)
	at uk.me.parabola.mkgmap.osmstyle.StyleImpl.<init>(StyleImpl.java:132)
	at uk.me.parabola.mkgmap.osmstyle.StyleImpl.readBaseStyle(StyleImpl.java:518)
......

--Alexm 17:35, 22 January 2012 (UTC)

Please read the thread http://www.mkgmap.org.uk/pipermail/mkgmap-dev/2012q1/013515.html --WanMil 18:20, 22 January 2012 (UTC)

Mapsource 6.16.3 crashed with TDB-File

The following change can solve the problem. The Number of the Overviewmap (the parent for the Detailmaps) in the TDB-File is the same like the number of the first Detailmap. This is the reason for the crash. Setting the number to "99999999" (seen by Garmin) solve the Problem. I believe you can do that in TdbBuilder.java in the function onFinish() with tdb.setOverview(..., "99999999"), but i am not a java-guru.

A second little error is in DetailMapBlock.java. The Order of the rgn-, tre- and lbl-Data is different in the constructor and the function write(). My suggestion is, take the same order like Garmin: lbl, rgn, tre, net, nod, dem.

mkgmap for dummies

Here is a description of a quick way to get data from a small region in OSM, into a map for display in a Garmin GPS receiver or a Garmin program such as MapSource.

A. Install mkgmap

1. Download the latest version of mkgmap [5]. Unzip it to install on your disk.

This will provide the required program mkgmap.jar (you need Java 6 installed to use mkgmap), along with some documentation and examples of styles used to convert osm tags to Garmin codes.

B. Download OSM Data

1. Visit OSM Web map [6]. Make the area you want to cover fill the whole map view.

2. Select >Export menu >Manually Select (for a smaller area) >OpenStreetMap XML Data >Export button.

3. Save this file as data.osm in your mkgmap directory.

4. In theory, you can first make changes to downloaded OSM data using JOSM [7], then save your changed version as a local osm file. I had a problem with this as the file saved from JOSM had ‘quotes’ around OSM tag values (revealed by osm2style) which interfered with some steps below. If in doubt, use an osm file saved directly from the OSM server.

C. Generate an img file (First rename or delete any previous img file in your mkgmap directory)

1. Open a command prompt and go to the mkgmap directory. e.g. enter the command:

cd C:\garmin\mkgmap

2. Now you can simply generate an img file by entering the command:

java -jar mkgmap.jar data.osm

You may want to rename the resulting img file which is generated in your mkgmap directory (by default as 63240001.img).

D. Import Into MapSource and GPS receiver

1. It is simplest to use MapSetToolkit [8] on the img file produced above.

2. Maps can be sent to the GPS receiver as usual from MapSource, MapInstall, SendMap or similar.

E. Adjusting the content and appearance of data elements transferred from OSM to img

You can change the range of OSM elements converted, through use of ‘styles’. An mkgmap style is a set of text files specifying how OSM tags are converted into Garmin point, line or polygon area codes (and more complex matters for routable maps).

1. Download styles that may suit your purpose; for example try the Base style for GPS units from Charlie Ferroro [9]. Then you can launch mkgmap with an option to use the specified style file; e.g.:

java -jar mkgmap.jar --style-file=C:\garmin\mkgmap\examples\styles\CF_GPS data.osm

2. You can check whether a particular style covers the data types in your osm file, using osm2style [10] (it may not display points that have no tags other than name in osm). You can then edit the style (text) files to convert other data types of interest into appropriate Garmin codes.

3. Custom (mkgmap) styles generally work best with a corresponding custom (Garmin) TYP file, which controls the appearance of the converted data elements in the final map. For example, CFMaster.TYP [11] is designed to match elements in the style by the same author. Elements not specified in the TYP file are rendered according to Garmin default settings (they might be invisible).

4. You can edit the TYP file to change the appearance of displayed elements, with help from a program like TYPWiz [12]. You will probably need to examine the TYP file first to identify available Garmin codes before you use them in an edited style, as mentioned above.

5. Other resources that can help if you are going to tweak styles and TYP files are a list of Garmin codes and symbols [13], and a palette showing the colours your GPS receiver can render (MapTK [14] displays a Garmin 256-colour palette in its icon library function).

F. For More Information: see the mkgmap wiki [15]

1. To progress to larger areas you will need to learn how to split them into workable tiles [16].

2. You can also learn more command options to adjust mkgmap data processing, and to use mkgmap without MapSetToolkit [17].

3. You may find it easy to use OSM Composer [18] as a graphical interface (in German only at this time).

4. To add contours, you will need a separate data source (they are not on OSM), which may be accessed automatically using a program like Srtm2Osm [19] or GroundTruth [20]. In GroundTruth you can apply a workaround to use the superior height data from Viewfinder [21] (by substituting in the hgt file(s) from viewfinder for the same tiles after groundtruth contours has been run once to cache the relevant hgt file(s) from the NASA srtm server).

Contours work well as a separate map with transparent background overlaid on the map from OSM data in a GPS receiver. They can also be merged into a single map with OSM data for display simultaneously in MapSource.

If the alignment of contour and osm maps is imperfect (decisions in background data processing can flow through unexpectedly) some programs have an offset option to tweak the horizontal alignment (corrxy option in Srtm2Osm).

5. The programs available to help in this exercise are developing rapidly. Fall back on the OSM-Garmin wiki [22] for periodically updated links.

Truncated or wrong street names

With the recent version of mkgmap (e.g. 3596) I have issues with the street names.
The names are fully random and very often they are truncated.
This does not happen with *all* map extracts or regions!
With a quite outdated version of mkgmap (2340) I do not have this issue.
Does anybody have the same issue? How can this be fixed?

How to reproduce:
1.) Download and unpack the following file:
http://download.geofabrik.de/europe/germany/bayern/oberpfalz-latest.osm.bz2
2.) Split the file using the following osmosis parameters: osmosis.bat --read-xml enableDateParsing=no file=oberpfalz-latest.osm --bounding-box top=49.55 left=11.25 bottom=48.8 right=13.25 --write-xml Oberpfalz2.OSM
Note: it is also sufficient to uses this bounding box: top=49.1 left=11.9 bottom=48.9 right=12.2
3.) Run mkgmap:
mkgmap.jar --mapname=63240001 Oberpfalz2.OSM
4.) Check the names (e.g. in the city of Regensburg) and compare them with real life.

Note: I checked the osmosis version and I have the most recent one. I also doublechecked with other Java versions ( 1.7.0_75, 1.8.0_25), operating systems (WindowsXP and Windows7) and have this issue every time.
--Flomigulau (talk) 12:06, 30 May 2015 (UTC)