Talk:Mkgmap/help/options

• How can I set Map Priority / Draw Order?

Standard is 25, but I would like to set 29. --Extremecarver 17:16, 19 October 2008 (UTC)

• What's the syntax for setting Map-ID and Family-ID? I tried the following for setting 4000/1 but none worked: --family-id=4000 --product-id=1 ; -family-id=4000 -product-id=1; --familiy-id4000 ...; family-id 4000....

overview-mapname

Discusion moved from the usage page.
Using this option seems to crash MapSource. These options are buggy in V590. The overview mapname will NOT be used correctly, also the family and product ID are not entered correctly into the .tdb files. If the registry entries for a map are installed, the .tdb and .img files must be present with correct names or MapSource will crash. Removing the OSM map references from the Registry will enable MapSource to start properly for another map. OSM Composer patches/renames the output map files from mgkmap so things will work. If your Mapsource crashes, you can use MapSetToolKit.exe to check for problems. --Nop 09:23, 11 January 2009 (UTC)

Could you please switch to current stable rev 827 or even better v830 (or the newest version). v590 is really old and it makes no sense to even talk about errors in 590. The map files themselves don't have FID and PID. FID and PID are only used in .tdb BTW.--Extremecarver 11:01, 10 January 2009 (UTC)

I still need the old rule file for a while. Even moving to r659 does not work as something has changed in the drawing order there. Also, I have no information whether the bugs concerning .img names and .tdb IDs have been fixed or remain present in current versions, so these hints may still be valid until someone verifies they have been fixed. --Nop 09:23, 11 January 2009 (UTC)

There have been many fixes in this area since r590. It would be very helpful to say what the bugs actually are, then we could say if they are fixed, or fix them if they are not already. ..Steve AcousticNewt 22:35, 11 January 2009 (UTC)

Ok, as far as I remember I had to work around the following bugs:

• mapname is only working for map images, the overview image and the .tdb are always named the same: 63240000.*
• product code is not written to .tdb
• product family is not written to .tdb

There have been fixes related to all of these things since 590, so I believe that those are fixed. AcousticNewt 21:27, 13 January 2009 (UTC)

I have tested this option using r830 by adding --overview-mapname="11000000" to the commandline, building the maps and mapinstaller and installing it in MapSource 6.14.1. The result is that MapSource crashes in TDB_REGIONDIR.CPP line 102. Without the parameter the map works fine including the product-id and series-name parameters. --Lambertus 15:27, 14 January 2009 (UTC)

This would be typical for a mismatch of product id and/or map names and would indicate that the bugs still exist. Can you check with MapSetToolKit what exactly is wrong? --Nop 15:57, 14 January 2009 (UTC)

I've checked the working and non-working maps and the only difference I found is in GPSMapEdit where the field "unique integer number of map" shows 63240000 for the working map and 11000000 for the non-working map. TDBChanger and MapSetToolkit don't see any difference between the maps and indicate everything is fine. If you're interested you can download the good and the bad map. Both executables are NSIS installers, you cannot install both of them at the same time. The commandline used to create these maps:

Good: java -Xmx512M -jar mkgmap.jar --mapname=11000000 --description="OSM NL Normal" --gmapsupp `ls $source/1*.osm` --product-id=50 --series-name="OSM NL Normal"

Bad: java -Xmx512M -jar mkgmap.jar --mapname=11000000 --description="OSM NL Normal" --gmapsupp `ls $source/1*.osm` --product-id=50 --series-name="OSM NL Normal" --overview-mapname="11000000"

I've looked at the bad map and I believe the problem is that the overview map name is used as a detail map name as well. So I believe that you should use --mapname=11000001 (keep the --overview-mapname as you have it). I was able to repair the map by deleting the '0000.img and tdb files and recreating them with the following: mkgmap --product-id=50 --overview-mapname=11000000 *.img

Yep, that appears to be the correct trick. Thanks a lot! --Lambertus 21:34, 15 January 2009 (UTC)

Bugtracker

While we are discussing changes: Is there a bugtracker or a whatsnew for mkgmap anywhere?

map-features vs style-file

The documentation page states that "--map-features=file" is deprecated and may cause errors. What sort of errors? Is it still save to use the old .csv files here or with the --style-file option? What is the difference?

I have added this remark. This was based on Computerteddys maps that showed various faults when used with --map-features. Since the convert to --style-file they dissappeared. Some problems could relate to the fact that the map-features file was parsed even if there was wrong syntax inside, without telling about erros, but producing faulty maps. Error checking seems to be better for style-file. The main difference is, that within the style-file you can use Regex operations and much more controll in how something is actually rendered.

So when you use --style-file <old_format.csv> this will work better? --Nop 23:11, 11 January 2009 (UTC)

Well I had no problem with the old structure, but I do make use of some new features, so yes for me it's better. (BTW OSM_Composer crashes on compilation of austria.osm with any version above approx 800 - so right now I simply create 6 tiles and join them to get the same map as with OSM_Composer before but for whole of austria)--Extremecarver 23:32, 11 January 2009 (UTC)

How can OSMC crash depending on the mkgmap version? It just calls it? What does happen there? --Nop 00:09, 12 January 2009 (UTC)

You can read what's new by reading through the mkgmap mailinglist. on each SVN commit there is an email generated - usually with user explications. --Extremecarver 23:06, 11 January 2009 (UTC)

I feared an anwer like that. Reading through a whole mailing list/SVN log is far beyond my available time at the moment. --Nop 23:11, 11 January 2009 (UTC)

--Nop 22:56, 11 January 2009 (UTC)

The --map-features and --style-file options are identical. You can pass an old map features csv file to either. The old .csv map-feature format will be kept for backward compatibility for a long time. I believe that Extremecarver is saying that if you make errors in the map-features file, then they are not caught by mkgmap and you might get results you weren't expecting. I don't mind adding some more error checking to reading the file if someone comes up with a patch. ..Steve AcousticNewt 21:27, 13 January 2009 (UTC)

Yip correct. There is more error checking for style-files. If you have wrong syntax in map-features you get unexpected results, if you have syntax errors in a style-file you get an error with the line of the style-file the error is in, so you can fix it.--Extremecarver 00:59, 14 January 2009 (UTC)

Drawing order

Was there a deliberate change of the drawing order? In r590 ways are drawn in the order they are given in the OSM, in r659 the order is different and some ways are drawn on top that are supposed to be underlays. Do the current versions have the same behaviour?

There was no deliberate change of drawing order. Looking through to see what change may have caused this, I think that it must have been adding relation support. Before, ways would be processed as soon as they were read. For relations though, it is necessary to save them and process them at the end and so they get written out in the order they are read out of the hash map. How important is this? Surely you can't rely on any particular order from planet derived .osm files anyway? AcousticNewt 21:27, 13 January 2009 (UTC)

Yes, that is likely the reason. My application is heavily dependent on the drawing order to produce a reasonable map. I am not using planet OSM data directly, but I am compiling it with my application and enriching it with some "pre-rendering" to overcome the limitations of the Garmin format. To do this I use underlays and overlays. E.g. a hiking route is marked by putting a way with the same nodes before the orignal way, drawn as a wide white line. This way it is drawn before the original way and outlines it. An unusable way is marked with an overlay, putting a way with the same nodes after the original. In mkgamp r590 the objects are drawn in this order and I am able to produce a map with seemingly many more styles than possible on a garmin by overlaying up to 4 differently rendered versions of the same geometry. This kind of composite ways is also much better to configure than all possible combinations expanded, even if this was possible with 3byte encoding.

Changing the drawing order at random (hash map is non-deterministic) breaks this totally, so I cannot use any version of mkgmap after r590. My observations confirm your suggestion, the ways are drawn in random order.

Can you restore the conservation of the data order to mkgamp? I guess there is no reason why the data needs to be jumbled, using an ArrayList in addition to a Hashmap should do the job. --Nop 23:00, 13 January 2009 (UTC)

I see, I could change it to preserve the order. There would be a cost in memory and speed for all users though. It perhaps will not be that large and if so, I will consider doing it. AcousticNewt 22:21, 14 January 2009 (UTC)

I am doing something very similar in my tool. If you just hold the references in an ArrayList for writing and use the HashMap only as a lookup table, the overhead should be minimal. I am also at the point where I would like to switch over to a current version of mkgamp. Can you give me any idea when an order-preserving version might become available? --Nop 16:55, 16 January 2009 (UTC)

name-tag-list

I'm trying to generate a map in a certain language (Frisian) and are using the name-tag-list parameter for this: --name-tag-list=name:fy,name. I am certain there are some place names in the source OSM files tagged with name:fy but I can only see the non-name:fy names, so it appears that this feature is broken somehow in r830. Or am I doing something wrong? --Lambertus 22:50, 15 January 2009 (UTC)

There are not that many name:py tags and I got different results with the option and without, but found it difficult to see if it was working properly because all the name:fy values were also values for name. What happens if you do --name-tag-list=highway,name ?

Grep name:fy on some of the source OSM files did reveal multiple placenames which did not show up on the map. I also rebuild the Frisian map using the suggestion above, which should show the highway type instead of the highway name. But unfortunately that didn't happen (still showing the name). I used the following command: java -Xmx512M -jar mkgmap.jar --mapname=13000001 --description="OSM NL Frysk" --gmapsupp `ls 1*.osm` --product-id=52 --series-name="OSM NL Frysk" --overview-mapname="13000000" --name-tag-list=highway,name Any ideas? --Lambertus 10:16, 16 January 2009 (UTC)

You need the option before the file name. The command line is a bit different than on most unix commands, think of it more a sequence of instructions. For example if you had --name-tag-list=name:fy,name A.osm --name-tag-list=name B.osm then the map from A.osm would have name:fy but B would have name. Well, thats how it is supposed to work anyway. ..Steve

I had no idea that the option worked like that. A new test shows that it works fine now. I will update the usage information to reflect that. Thanks! --Lambertus 13:34, 16 January 2009 (UTC)

family, series etc.

I'm still a little confused about family id/name, series id/name and so on. I guess some of these are only visible in non-free software tools? What I really want to know is how to group maps on my Legend HCx, if that's possible - in the "Setup Map" section to choose what maps to show, the context menu has "Hide Basemap" and "Hide Open Streetmap" because I've used --family-name="Open Streetmap" when composing the individual maps into a gmapsupp.img. It doesn't seem to work when making the individual images though - is it impossible for a gmapsupp.img to hold maps of more than one family? It would be really nice to turn contours on and off conveniently without having to tick a couple of dozen items...--Tms13 17:52, 23 January 2009 (UTC)

No they are basically only visible in freeware tools. Best integrate the maps from mkmap into Mapsource. You can do this with either "Mapsettoolkit" or "gmaptool" ---> simply google for it. For gmaptool User:Popey (the developer) has written an intro here in the wiki on his user page. You can integrate maps of up to 2048MB into you gmapsupp.img of as many FID as you like. If you wan't to have contourlines with openstreetmap best make them a transparent map with their own FID. Or integrate them by creating a new tdb (with any of the two tools above plus cgpsmapper) into the FID used for you OSM map.

Problems combining maps with draw-priority

Hello. I'm trying to compile a map for my Garim etrex vista HCx for my next longer trip but have failed so far. First, I think I have some bad tiles lurking somewhere that break the final map. But boiling things down to a smaller area, the maps do work in principle, but the intended drawing priority is not observed. I made a test map with

mkgmap --gmapsupp --draw-priority=20  6330* --draw-priority=1000 --transparent 5330*.img

but the resukt is as follwos: When the GPS renders a corresponding portion of the map

1. it draws the contour lines
2. it draws the map data overriding the contours

Ultimately, only the normal map without countours remains visible. In fact the test above with Solomon Islands reveiled a few left-over contours, e.g. near S 09°31' E159°55' - apparently a very small island with 50m hills that has not yet been recognized as such by osm, so contours "in the water" remain visible (BTW, is such a contour found this way from srtm data a valid source for entering an island into OSM?). The way I understand the command line options, the contours should have been placed transparently on top of (i.e. visible) the normal map!? Reversing the priorities given did not help, nor did switching the order of the files. What am I doing wrong? BTW, my mkgmap is the one from kubuntu, identifying its version as 618-svn.--hagman 22:26, 5 January 2010 (UTC)

Well most obvious DP is only from 0-30. So your bogus 1000 value might create crap. Transparency vs opaque has nothing to do with DP. There should ONLY be one transparent mapset (or tile per area) and no more, and the DP of that tile does not matter. You should also compile mgkmap from svn source instead of using some very old version (though I don't believe the version is 618...., current is >1470) --Extremecarver 23:53, 5 January 2010 (UTC)

option --reduce-point-density

Missing the description of this option.

osmconvert and osmfilter

Osmconvert and osmfilter are relatively fast, but the resulting boundary data contains unused stuff that eats memory when creating boundary files. – What does this mean? There should not be any difference in comparison to Osmosis' output. --Marqqs (talk) 09:07, 5 January 2014 (UTC)

Hi Marqqs, I broadly remember that osmfilter includes parent relations which are not required but osmosis does not. I'll have to check that again. --WanMil (talk) 08:09, 11 January 2014 (UTC)