Talk:Mkgmap/dev

Hello, very useful utility, many thanks. I'm using the latest development version of mkgmap to generate a map for Slovenia and I have some questions:

1. I couldn't find any exact info about command line options. How exactly do you specify map-features file and set the levels in the command line?
2. A general question about Garmin maps: is using the Garmin map features the only way to specify how a certain map object should look like? I'm asking because, for example, on my Vista Cx the footways and tracks are shown in the same manner. I checked the map-features file and the two are using different Garmin features, so I presume the problem is in the way how the Garmin renders them. So is there a way to specify exactly how a feature should look like on Garmin (the line color, thickness and so on)?--Breki 20:18, 3 October 2007 (BST)

---

Sure. I will add some information on the wiki about how to specify the map-features file over the next couple of days. As far as I know the lines and roads are built in and you can't change them. You can load custom icons for points, but they are extra and don't replace the built in ones. There is a feature of mkgmap that allows you to build a map containing all of the possible points, lines and polygons. Just run:

java -jar mkgmap.jar test-map:all-elements

you can change where the map starts by setting two environment variables first. Eg on linux, to start the map at 50N, 10E do this first:

  export BASE_LAT=50.0
  export BASE_LONG=10.0

-- AcousticNewt 23:23, 4 October 2007 (BST)

Great, I will try this. Looking forward to your updated instructions :) --Breki 09:15, 5 October 2007 (BST)

let me know if there is anything specific ..Steve

I tried the test map and it works, thanks. I checked Garmin's rendering of footways and tracks and they differ only slightly in color (both are thin dashed lines), so I suppose that for a specialized map (hiking, for example) it would be better to create a separate map-features file with such features shown more distinctly. But that's up to the person who generates the map.--Breki 07:04, 9 October 2007 (BST)

Contours

There is some very quick code to process contour lines as produced by Srtm2Osm in mkgmap from version 307. This section is to discuss how to make it better.

My initial thoughts:

• On the Garmin devices there are three kinds of land contour and three for the sea, both major, medium and minor contours. So we need to decide which heights should have the major contour (eg every 1000ft perhaps) and the same for the medium and minor ones.
• The case is tricky, because we have to look at two tags to work out what line should be produced.
• I think that the heights have to be given in feet inside the file, what units are the 'ele' tags in?

I looked at contours I'm already using on my Garmin (also generated from SRTM by DEM2TOPO), few observations: they are in meters, every 400th m is drawn in black color, others are in brown. Also, when zoomed out to 800m zoom, only 200th meter contours are visible, with every 400th drawn in black. I don't have any experience with the commercial products, though.

I think it would be best to extend Mkgmap to use some sort of XML-based rules file for features mapping (something like Osmarender rules?), that way you could combine two or more tag filters to produce the Garmin feature.

As for the Srtm2Osm tool, currently meters are used (anyway, 'ele' key is specified to be in meters on the OSM Features page). I could extend the tool to support feet too.

We also have to experiment with the larger area of coverage too see the sizes of produced IMG files and if this is feasible for usage. The existing contours I'm using cover the whole Slovenia and are about 18 MB in size. But Slovenia is a small country :-) --Breki 14:21, 15 October 2007 (BST)

OK, I will make mkgmap interpret 'ele' as meters.

How would that work in case you want to have contours displayed in feet? I will add support for feet into Srtm2Osm in the next day or two. I will probably add an aditional tag, ele_units = m / feet. Would that help?

Well the garmin converts to whatever unit you set. But sure, having a option for ele_units is good too.

For large areas you are meant to divide them into tiles and create separate img files for each one. An overview map ties them all together and several tiles can be loaded onto the device at a time. Mkgmap supports creating the overview map already.

OK, that's already possible with the existing Srtm2Osm.

I'm looking at some other example contour files to get a feel for good default rules.

I've just remembered that Garmin usually offers web viewer application for its maps, you can see the contours too, if you zoom in. I've tried U.S. TOPO 2008, here.--Breki 06:02, 16 October 2007 (BST)

Hello Steve, just to let you know that I've published a new version of the Srtm2Osm tool. It now supports feet units and it can also categorize contours into three categories (major, medium, minor). Now it is possible to select each category with a single key=value rule, so it should work fine with Mkgmap.--Breki 16:54, 31 October 2007 (UTC)

I've been experimenting with srtm2osm and mkgmap, and it would appear that my Garmin Vista HCx interprets contours in feet. If i make 10m contours with srtm2osm, and load them into the unit, it displays them as 3m, 6m, 9m, etc contours. If I use srt2osm to create 33 foot contours (it won't let me have decimals), i get 10, 20, 30m contours, but then as rounding errors accumulate i get 91m, 162m, and so on. Suggestion: allow specification of contour step/minor/major in one unit, and output in another unit? (Or is there a way to tell mkgmap that contours are in m?) Sciuro 13:05, 19 February 2008 (UTC)

I'm getting the same problem here... everything done in meters, my Garmin GPSmap 60CSx also then converts the elevation value as if it were actually feet... I made a contour .osm file, made that into an IMG using mkgmap then merged that, along with OSM data into a gmapsupp.img and put it on the unit... The unit displays the contours and map data together nicely apart from the units problem... Dtucny

Yes I believe that they have to be feet in the file, and in OSM ele is defined to be meters. I've now fixed it in svn - I may now get complaints from people that have got used to it being wrong... so I may be forced to add an option. (AcousticNewt 22:30, 12 May 2008 (UTC))

Just starting to look at contours and think it would be a good idea to be able to load the two bits of data (contour data and planet excerpt data) separately into Mkgmap (because the contour file will not change much over time)? --Lambertus 14:03, 12 March 2008 (UTC)

I've completed a few tests using contour data and it confirms my ideas about feeding the planet excerpt and contour data separately to Mkgmap. Would it be possible to add this feature? --Lambertus 17:53, 13 March 2008 (UTC)

There are two ways of doing this. You could have separate maps and make the contour map transparent and load them both at the same time. There isn't an option to make the map transparent yet, but I think it can be done easily. ..Steve (AcousticNewt 22:52, 15 March 2008 (UTC))

If transparent maps require a more expensive GPS, or it makes using the map much more difficult, or it makes the map less readable, then a combined map might be better. Otherwise I think a transparent map would be the best option by far. --Lambertus 09:55, 17 March 2008 (UTC)

I will also look into combining more than input file together. ..Steve (AcousticNewt 22:52, 15 March 2008 (UTC))

That would be a cool feature anyway, besides the reasons stated above :) --Lambertus 09:55, 17 March 2008 (UTC)

Currently getting contours via the "<tag k="contour" v="elevation" />" tag works fine for me. One suggestion to make it even better: When I convert SRTM to OSM with Srtm2Osm.exe every contour gets an additional "contour_ext" tag. It can have the values "elevation_minor", "elevation_medium" or "elevation_major". I can use it to create maps with different contour resolutions at different zoom levels:

polyline|contour_ext|elevation_minor|0x20||22
polyline|contour_ext|elevation_medium|0x21||20
polyline|contour_ext|elevation_major|0x22||18

But when I do this mkgmap does not put the height information into the garmin file. My GPS shows all height lines but with "0 m" height. The height information seems to be used with the "contour" tag only. Would it be possible to add the height information to the "contour_ext" as well? R kleineisel 10:29, 18 July 2008 (UTC)

Yes no problem, I've commited this change to subversion at version 644 ..Steve

Great, works perfect, thanks. R kleineisel 09:06, 25 July 2008 (UTC)

Rendering entire countries

The Mkgmap tool is great and I've used it a lot while trying to map parts of The Netherlands, but the recent addition of the AND data is giving me problems now. Although The Netherlands is only a small country, the current OSM file is about 1.3 GB. Loading it in Mkgmap requires a Java heap size of 2GB of which ~1.7GB max is used at some point. Such amounts of RAM is something most people don't have (I abused a server at work for this). The resulting map is about 32MB in size and Mkgmap prints a warning that the map is probably too big. This warning seems to be correct because my GPSmap 60CSx does not allow me to select the new map. Any ideas on how to tackle the two problems mentioned here (memory usage and map size)? --Lambertus 08:57, 16 October 2007 (BST)

I can see two possible solutions for this, both involving breaking the OSM into smaller chunks. The first approach would be to break it into geographical sub-areas. You would have to have some OSM cropping tool (does any exist?) which would crop ways and areas precisely at the borders of chunks. The other approach would be to break OSM according to features (example: one for physical features, one for major roads, one for minor etc). This could probably be achieved by using different map-feature files in Mkgmap.--Breki 15:31, 16 October 2007 (BST)

Yes the map has to be broken down into smaller tiles as you will be hitting internal limits on the size of sections in the map. These tiles can then be combined into one file. If you go to User:Computerteddy you can find a piece of software called osmcut, he uses this to cut up the planet file into small tiles and create a world map and a Germany map. I've never run it and I imagine that it takes a lot of memory for the whole planet file, but for just the Netherlands it might not be too bad.

To combine the maps into one you need an overview map and a tile description file (with a .tdb suffix). I've recently added the ability to produce these files to mkgmap. I'll write a better description later, but basically if you supply more than one .osm file on the command line, then it will automatically produce these two files. These can then be loaded in to eg. QLandkarte and viewed or uploaded. (In QLandkarte you select 'Import map' and then select the directory where all the .img files are and then the name of the overview map, which by default is 63240000.img). This is quite new, but the UK is now too big to do as one as well and I've produced a whole UK map with it. One problem is that the tiles do not join well and ideally we need a map splitting tool that will split ways that cross a tile border and place a node right on the border. ..Steve (AcousticNewt 22:42, 16 October 2007 (BST))

Awesome, I read somewhere that you are working on that but had no idea it is functional already. I'll try some splitting tools (Osmosis, planet-excerpt-polygon, osmcut) to see which is suitable.

For uploading I currently use the USB mass storage mode of my Garmin and copy the img files manually. Is this possible with the .tdb construction as well, or does Qlandkarte some real magic? --Lambertus 08:09, 17 October 2007 (BST)

It does some real magic in that it combines them all into one large .img file. mkgmap can't currently do this yet.

Actually, I'm using Sendmap for that and it works very well.--Lambertus 22:53, 20 October 2007 (BST)

UK

[Splitting tangled thread]

The maps section has not been updated for quite a while now, so I was trying to create a map of the uk. Is there any easy way to download the current osm data for the whole of the uk, and will mkgmap create the *.img file easily on my (4 year old) home computer?--Mapper32 09:25, 23 November 2007 (UTC)

You can go to the uk only data directory and download the latest uk file there. It is too big to make into a single .img file any more, so you have to cut it up into at least two pieces first. The osmcut program is probably the easiest way to do this. You can just give mkgmap all of the resultant files and it will create separate .img files for each one. From version 388 on, you can give the --gmapsupp switch which will produce a single file that contains all the individual maps and can be directly loaded onto a Garmin device. I don't think there is any problem with a 4 year old computer as long as you have enough disk space and enough memory. The more pieces that you cut the map up into, the less memory it will take. So thats a start, let us know how you get on.

My computer doesn't have much hard drive space free (2.9G), and even using "-Xmx1500M" gives a "Could not reserve enough space for object heap" error. If I run using "-Xmx1000M" then instead I get "Bitte richtige Argumente ⁿbergeben. <Kachelgroesse in ░> <Quelldatei> <Zielordner>" which I assume means I'm giving it the wrong command line? My command line was "java -Xmx1000M -jar osmcut.jar uk-071121.osm EnglandBits".--Mapper32 13:06, 26 November 2007 (UTC)

If you are starting from the UK only data, I find that-Xmx300m works well enough, so it is possible that would work for you. But it is true that the initial splitting up is going to be the bottleneck here - once you have split the file into small enough pieces you will need very little memory to process them with mkgmap.

The three command line options in english are: (1) the area measured in degrees in which to cut the file - try 0.5 or less here, (2) the file to read eg: uk-071121.osm, (3) the directory/folder in which place the generated files ..Steve (AcousticNewt 21:48, 26 November 2007 (UTC))

Great thanks! I was calling osmcut with the wrong number of parameters. So the new problem is that I generated 240 files (including one *.tdb), and I don't know how to get the gps to recognise them. I also don't know which file is which bit of the UK, which makes checking it on the gps hard (I should blatantly get QLandKarte).

QLandkarte is good if your GPS is supported as you can just select several of the tiles and upload them directly. With mkgmap you can give the --gmapsupp flag which will produce a file called gmapsupp.img which can be copied to the SD card (if you have such a unit). It doesn't allow you to pick and choose individual .img files to combine into the gmapsupp file -- a later version will do ..Steve AcousticNewt 22:45, 27 November 2007 (UTC)

NL

I've tried the 388 version with the --gmapsupp option which results in lots of errors and finally it runs out of memory ({Link removed}, {Link removed}). I have put the script, planet files and the results in {Link removed}. --Lambertus 11:53, 25 November 2007 (UTC)

I don't understand this. I've run against the files downloaded from your site and there are no errors in making the map and the map itself works fine both in QLandkarte and the gmapsupp.img works on my Legend.

So we must be missing something somewhere. I notice that you are using -Xmx3072m on the java command line, but I cannot run java with that value - so I guess you are on a 64bit system? Yes thats what it says at the bottom: amd64 x86_64. So perhaps it is that. First thing to try is without the -Xmx argument, it really doesn't need that amount of memory, at least not for me. It takes about 30 seconds to do the whole lot for me. I get this gmapsupp.img.gz

The 'map is too big' message usually means exactly what it says; the .img file is bigger that it is allowed to be. This happens somewhere over 12Mb (there is no strict limit in total, it is the size of the internal data structures that are limited). But your files are all well within this with the biggest just over 1Mb. Is there any chance that the 'ls *.osm' is picking up a complete planet or something? ..Steve (AcousticNewt 20:17, 25 November 2007 (UTC))

Bingo Steve, well done! The --gmapsupp stuff works as you said even without the -Xmx Java option. A stray .osm file caused the error. The only problem I now see is a gap in the combined map where two subtiles meet. Also some render errors (e.g. completely empty screen) while browsing over the 'devide'. This might be caused by the way Osmosis extracts the data though, I'm not sure about that. I guess for now I just need fewer subtiles so this behavior is less frequent/obvious. --Lambertus 20:55, 26 November 2007 (UTC)

Cool! Ideally I guess we need a splitting program that splits ways at the edges of a tiles and places a node there. It may also work to have overlapping tiles, I've not tried that ..Steve (AcousticNewt 21:48, 26 November 2007 (UTC))

I'm going to try overlapped first, then Osmcut, then adding nodes to edges. I'll let you know how things progress. --Lambertus 22:15, 26 November 2007 (UTC)

Missing or invalid input files

I use Mkgmap in an automated image building process and it happens that some of the *.osm files that are given to Mkgmap on the commandline are not existing or have a size of 0 bytes. Would it be possible for Mkgmap to be more forgiving towards these kind of input files and only e.g. produce a warning, but does not stop rendering the other input files? Oh, and can Mkgmap output the file when it encounters the following error: 'Bad input file format'? --Lambertus 19:02, 25 October 2007 (BST)

OK that is now fixed in version 322 in svn, thanks.

Bad input file format

Mkgmap complains that some files produced by Osmosis have 'Bad input file format'. After browsing through those files I wonder: Can it be that .osm files that contain only nodes are considered bad? --Lambertus 21:56, 25 October 2007 (BST)

No not in general anyway. I've added a message which gives the line number when a format error ocurrs, hope that helps track it down. ..Steve

Thanks a lot for your swift responses. --Lambertus 08:05, 26 October 2007 (BST)

Separate TDB file generation

I'm working on mass Garmin image website for which I use Mkgmap. When trying to genereate the entire country (Netherlands is only the beginning) in one go, by providing multiple (~200) .osm files, Mkgmap (r319) uses a lot of memory (in my test I provided 2GB) and stops generating after 163 files without showing an error. The TDB file does get generated though. Would it be possible to generate the TDB file separate from the image files? I.e. generate the images one-by-one (which works well) and after that generate the TDB file by providing all generated image filenames to mkgmap. --Lambertus 21:35, 2 November 2007 (UTC)

It shouldn't be running out of memory if all the individual files are small enough, so I will look into what is going on. I did fix a problem where files were not closed when I did the img read code (now merged at version 341. As for generating the TDB separately, then that is now nearly possible - it requires being able to read .img files as well as write. I am working on being able to combine the files into a gmapsupp.img and the TDB file will be generated as part of that. ..Steve (AcousticNewt 18:37, 4 November 2007 (UTC))

I've just done a complete run on the whole planet from Computerteddy's tiles and memory use didn't go above 400M for all 2964 files. But then I just ran with r319 and was also OK up until just under a 1000 files when the bug that was fixed kicked in. So I guess it must be something about the data or the options you are using. I'm using java 1.6 if that makes a difference. ..Steve

Thanks for looking into this. I'm not using weird parameters, just straight cuts from the planet and providing them to Mkgmap. I'll try a newer version to see if the problem still occurs.--Lambertus 10:18, 5 November 2007 (UTC)

It appears that I haven't given this a follow-up: The crash resulted from a stray .osm file somewhere that was either corrupt or way too big. --Lambertus 19:20, 28 April 2008 (UTC)

Next question: Is there a specific reason why the resulting .tdb and the overview .img aren't given a name in the same range as provided by the --mapname parameter? The resulting .tdb and overview .img are still named 63240000 when providing Mkgmap e.g. the parameter --mapname=11000000. --Lambertus 19:21, 28 April 2008 (UTC)

There is a --overview-mapname parameter which you can use to control the overview name. (AcousticNewt 21:42, 28 April 2008 (UTC))

Unfortunately, using that parameter results in a .tdb and overview .img that crashes my MapSource installation (6.13.4) consistently. The supplied parameter is: --overview-mapname="11000000". The two files do have the correct name though. --Lambertus 22:15, 29 April 2008 (UTC)

Loading maps in Mapsource

I've created a test batch with TDB- and overview generation using Mkgmap r313 and tried to load the images into MapSource and GPSMapEdit. In both applications I can see the overview image but zooming in does not reveal the detailed maps. Any ideas on what is going on? --Lambertus 10:18, 5 November 2007 (UTC)

I've made some improvements in 358 that seem to improve the loading in QLandkarte, which was showing similar problems to those you described sometimes. There was a bug in setting the size of one of the parts in the file of the overview map - a similar bug was reported to cause problems in loading in mapedit previously, so it may help.

Someone else pointed out that the TDB file created with the test batch contains different (wrong) coordinates as those that were used to export the source data from the images. Also image 63240004.img seems to be invalid. I will try again with the latest snapshot. --Lambertus 13:54, 7 November 2007 (UTC)

Using the latest snapshot r359 seems to have solved the invalid image problem. Unfortunately it has not solved the coordinates problem. My bbox: 5.75, 52 6.25, 52.5 while GPSMapEdit reports: 5.45, 52 6.15, 52.3 Also GPSMapEdit still does not show detailed maps when zooming in GPSMapEdit but this could be caused by the faulty coordinates. I've updated my test batch with the latest results, source files and create script. --Lambertus 14:21, 7 November 2007 (UTC)

I downloaded your files and got them to load in MapSource, they seemed to work well although I can see a couple of bugs, I was kind of surprised as I never got maps that I created to work in there so far...

So I don't know if gpsmapedit is more picky or what, does it normally switch to the detail maps when zooming? I calculate the bounding boxes based on what is actually in them, so I think the bounding boxes are working as designed. Of course if other programs require them to be unaltered then I may have to change this.

Thanks for looking into this, it is nice to see Mkgmap progressing. I'm surprised that the files seem to load fine in MapSource for you. There is a tremendous amount of detail in those maps and all I can see is the overview map but none of the details of the actual maps (I have the latest MapSource), even when zooming. Are you able to see all the little details? I have uploaded another map to the test directory for comparison. This is a 3rd party map made with cGPSMapper which works perfectly with MapSource. About GPSMapEdit; I was mistaken in that it should show details when zooming in. Sorry if this caused any confusion...--Lambertus 21:07, 8 November 2007 (UTC)

Oh yes I see the detail, it is a great map. But there is a problem, that for me the overview map never goes away, so I see the motorway type road from the low detail map and the detailed map. So I guess there is a problem that I am missing something that causes map source to switch from the overview to the detail, but the symptoms are different in our versions of map source. Anyway its the only clue, so I will see if I can fix the problem I see, and then let you know. Here is a picture of what I mean[1], the blue straight line labeled 'A1' is from the overview map. (AcousticNewt 20:57, 10 November 2007 (UTC))

I can confirm what Lambertus is saying: I have tested it with Mapsource (6.13.4) and the free Garmin training center, and for example the "Apeldoorns Kanaal" does have been filled in blue like in your example. what software are you using ? PS keep up the good work, I love you program..;-))--BertMu 09:18, 10 November 2007 (UTC)

I believed that Lambertus could not see any detail at all, like this [2]. I take it that you can see detail (the canals, residential streets when zoomed in far enough etc), but there are some differences to my screenshot. Is that right? I am using MapSource 6.10.2 ..Steve (AcousticNewt 20:57, 10 November 2007 (UTC))

Yes that's it, I can't see any details in MapSource 6.13.4. I think it's paramount that the maps work in MapSource if we want to provide a truly enduser friendly map (imagine: just download the .exe, run it and have the map available in MapSource... awesome). --Lambertus 10:04, 11 November 2007 (UTC)

I just loaded the files that you created into MapSource 6.13.4, so maybe we should confirm how you loaded them. I placed the files in the directory c:\maps\test and created a file called test.reg containing the following:

REGEDIT4

[HKEY_LOCAL_MACHINE\SOFTWARE\Garmin\MapSource\Products\63240000]
"LOC"="C:\\maps\\test\\"
"BMAP"="C:\\maps\\test\\63240000.img"
"TDB"="C:\\maps\\test\\63240000.tdb"

I then imported this using regedit. It all seemed to work apart from the bug that the overview map doesn't disappear when the detail maps appear. If you have another way of loading the maps let me know. Oh, and like User:BertMu says, with the maps I downloaded from your site and the latest map source I see the canals as outlines, not filled ..Steve (AcousticNewt 19:10, 11 November 2007 (UTC))

Aha, I spotted the error in my reg file, it works fine now (except for the basemap ghosting and canal water color). Thank you so much! Time to move to the next task for me: take a look at creating installer based maps for end users. --Lambertus 21:10, 11 November 2007 (UTC)

Cool so it appears that we are all seeing the same things now. The installer sounds good too. I've tried out a lot of things but I haven't made any progress in getting the overview map to switch off ..Steve (AcousticNewt 11:41, 13 November 2007 (UTC))

I have used already a installer for installing maps: Innosetup, a free installer, works OK. Steve: at which layer you are greating the overviewmap ? I have read somewhere that every thing must be on one layer (0?) I will have a look--BertMu 21:22, 13 November 2007 (UTC)

The overview map is in one level and that level is higher than the ones used in the detail maps - although I am varying that to see what happens ..Steve (AcousticNewt 22:50, 13 November 2007 (UTC))

I found this in a readme about making maps: Garmin maps usually have multiple layers. When you are zoomed all the way in, you are looking at layer 0, as you zoom out you are looking at layers 1, 2, etc. which progresively have less detail. The typical map has 3 layers, actually 4 since the last layer has to be empty'' maybe you can do something with this--BertMu 17:45, 16 November 2007 (UTC)

Multiple OSM maps in MapSource

MapSource does not show multiple maps when installing more than one OSM map (tested with r520 and r576). All OSM maps seem to be identified in MapSource as 'OSM map' even when the --description option in Mkgmap is used. It seems that this 'OSM map' text is defined in the .tdb file and is required to be unique for each installed map. Would it be possible that the 'OSM map' text is replaced by the --description parameter when creating the .tdb file? I tested this behavior using these two maps: regular and cycle. --Lambertus 08:01, 28 April 2008 (UTC)

Right. The 'OSM map' text occurs twice as the family-name and the series-name. I don't know which one you need to change (probably either of them) but you can change that with the --family-name and the --series-name options. The --description does go into the tdb file for each individual .img file but its the other options that identify the map set I believe - could be wrong as I've not tried it. (AcousticNewt 21:59, 28 April 2008 (UTC))

Just to be complete... there are also the --product-id and --family-id options to try (both are integers).

Thanks, I clearly haven't read the Mkgmap/help/usage page in a while. Sorry about that. --Lambertus 12:07, 29 April 2008 (UTC)

Crash in MapSource

After playing a little bit with my new Legend HCx an some programs, i think i know the reason (or maybe one of them) why Mapsource crashes when zooming in. I used the maps supported by Computerteddy, latest version built with mkgmap 384, in connection with TTQV. This works fine, no problem when displaing or sending the map to the GPSr. With Mapsource i had the reported problems when zooming in. But on the GPSr i missed some larger lakes and forrests on the maps transfered whith TTQV. In TTQV, they where visible. So my conclusion was, if the GPSr cannot work whith this large areas, maybe the same apply for Mapsource. And yes, while using a nearly empty tile without such large areas, Mapsource had no problem when zooming in. As next step i recompiled some of the problematic tiles with Mapedit and cGPSmapper. CGPSmapper splitted the large areas in two or more pieces. The result: Mapsource has no problem and the areas are shown on the GPSr. As I read in the changelog, there is a spliting function for lines integrated in mkgmap. Is it possible to extend that to areas, even if it is far more complicated?--Lobelt 18:02, 27 November 2007 (UTC)

It could very well be it. It is certain that polygons should be split as lines are for them to be properly visible on a GPS and the only reason I've not done it is, as you say, its not as easy as splitting lines... But perhaps its not too hard and it would allow me to add sea areas properly which would make a lot of people happy too ..Steve AcousticNewt 21:15, 27 November 2007 (UTC)

Unfortunately, I can now say that is not it as I've tried throwing out large polygons and there is now code to split them up. It seems to me to be that it is just large tiles bigger than, say, 1M that MapSource cannot cope with. This would be odd, as garmin devices themselves have no trouble. ..Steve AcousticNewt 21:06, 3 December 2007 (UTC)

I just tested build 404, but the problem ist still there. When loading the tiles in Mapedit i see that the polygons are not splited. The limit seems to be the number of points. Polygons with mor then around 250 points will not be shown on the GPSr.

Tiles over 1M should not be an problem, as there are maps with far more then that. Maybe this is related to some other thing cGPSmapper is reporting when recompiling. It criticises the value of TREsize and RGNlimit and set the TREsize to 5000 (from something around 6100 in the tile i tested). For RGRlimit the documentation of cGPSmapper advise an value of 1024, in my test tile it was set to 127.--Lobelt 13:28, 4 December 2007 (UTC)

Yes the code is not in 404, its on the filters branch. I'll probably merge it later on today.

Fundamentally you are right about the size, it is going to be size of something internal rather than the raw size of the file which I'm sure is not important at all. Still for the style of map that mkgmap produces (no routing etc) 1M seems to a good rule of thumb for spotting maps that don't work. If I subdivide the UK enough so that no file is over 1M then there is no crash in map source, also if I take a map set where there are larger files and delete those larger files then there is no crash either.

Would it be possible to point me towards the tile that cgpsmapper criticises? I might be able to see what it is complaining about. ..Steve AcousticNewt 16:25, 4 December 2007 (UTC)

The tile i tested most is 63255575.img (here) of Computerteddys world tile set. Loaded in Mapedit and saved without changings as .mp, cGPSmapper reports the two warnigs for TREsize and RGNlimit, sets TREsize to 5000 an goes on. When changing the values before in Mapedit to 5000 for TREsize and 1024 for RGNlimit there are no warnings. In booth cases the resulting tiles are working in Mapsource without problems.--Lobelt 17:04, 5 December 2007 (UTC)

OK thanks, I'll grab it before it changes and take a look. AcousticNewt 20:17, 5 December 2007 (UTC)

Just run a test with build 423 and as far as I can see, my major problem ist solved. The large polygons are splitted and when uploading with Sendmap or TTQV I can see them on the GPSr. Many thanks!

The bad news: Mapsource still don't like the tile. So there is really an other problem involved.

Additionally my findings to the problem of shifted polygons, reported on the other page. It seems there is a reduction of points for all lines and polygons by an factor of 2/3 to 3/4 when switching from zommlevel 0 to zoomlevel 1. It's not really a problem on the little screen of the GPSr, where it is hard to spot the differences. But it looks sometimes funny on an large PC screen.--Lobelt 12:56, 6 December 2007 (UTC)

Yea ok, its a bit excessive, I'll tune it down a bit ..Steve

Fixed

So it was the file size after all... There are constants in the header that give the max size, not looked at them for ages, but they were set to a max size of 1M and so I've turned it up to 128M. This should be fixed in tonights build version 451 or above. Please try it out everyone who has had problems with this. ..Steve AcousticNewt 21:17, 12 December 2007 (UTC)

Confirmed! Now it's easier to tune up the maps with TYP-Files, as I can check it in Mapsource before loading up to the GPSr. Thanks!--Lobelt 18:21, 14 December 2007 (UTC)

mkgmap-r359 : map displays fine in QLandkarte but not on my etrex vista cx

Hi,

I generated this map with mkgmap-r359 : it displays fine in QLandkarte but not on my etrex vista cx. At all the scales, I can read "overzoom" at the bottom of my device. Does the problem come from my GPS or from this revision ? FredB 22:59, 8 November 2007 (UTC)

Sorry, my fault, I checked in something I didn't mean to. Version 359 has been removed, try 361. ..Steve (AcousticNewt 00:31, 9 November 2007 (UTC))

Thanks the problem is fixed. FredB 21:53, 11 November 2007 (UTC)

memory usage of current version

Im tried to transform the current germany osm-part with the version (472). I use an pc with 2GB ram. For about one month I have seriously trouble with the memory usage. The program still brakes down due to less memory. May it is possible to lay more stress on a version, that use more temporary filespace and less memory? --waschbaer 22:38, 21 December 2007 (UTC)

It shouldn't be using that much memory to cause a problem on a 2GB machine. The german osm file is too big now to convert into a single .img, but even that only takes about 400M for me. For tiles of a more reasonable size less memory is required, for example I can do the complete planet file when it is cut up as in User:Computerteddy without running out of memory. But perhaps there is a bug that only shows up in your environment, could you give me some details of the version of java and operating system and exactly what files you are compiling? How much memory do you think it is using? ..Steve AcousticNewt 23:50, 21 December 2007 (UTC)

shure, the memory usage was about 700m virtual memory. Ive startet mkgmap without any option. I think this file is real large and has exeeded a certain limit. But 1 mounth ago it was possible to convert germany in one img file. I got a filesize of about 11m. Now, with the files from User:Computerteddy, germany need more the 70m, but my garmin gpsmap has only 64m memory. I cant imagine the size difference.

file: http://download.geofabrik.de/osm/europe/germany.osm.bz2
error message: 
  SCHWERWIEGEND (BufferedWriteStrategy): Map is too big and will not work
  SCHWERWIEGEND (BlockManager): overflowed directory with max block 202, current=222
java: 
    java version "1.5.0_10"
    Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_10-b03)
    Java HotSpot(TM) Server VM (build 1.5.0_10-b03, mixed mode)
mkgmap: 388 and 506
 

I should probably change mkgmap so that it doesn't carry on after detecting that the map is too big. There are 24bit pointers within the file that limits certain sections to about 16M or so. The main reason why this is the case now and not a month ago (apart from the rapid growth of the OSM data), is probably that the default map-features file was changed to show a lot more detail at lower zoom levels. Although this makes a better map it also makes for a larger file. By using a different map-features file or levels definition you could still do the whole country as one.

Latest versions and map-features option

It seems that the latest Mkgmap versions contain a bug in handling the --map-features option. All is well when generating a cycle-centric map with a supplied rule file using r520, but with r579 and r584 the resulting maps don't seem to use the supplied render rule file and fall back to the default rendering rules instead. --Lambertus 20:24, 28 April 2008 (UTC)

Hi, that is certainly a big change of the latest versions. If you use --style-file instead of --map-features then it will work as before. The old --map-features flag is meant to work so I will fix that. ..Steve

OK should be fixed in the nightly build.

Multipolygons

Would it be possible to add support for multipolygons to this tool? Two tasks I see directly is

• The import of data (remember way id, xml parse relations)
• Translating to the rendering of the .img (??)

The reason I ask is that I also use the maps on the water and am missing a lot of islands. I'm willing to get my hands dirty, but have not touched Java code in 6 years. --Rene A 19:26, 23 June 2008 (UTC)

That would be a great addition, I'll get in touch to discuss further what to look at. ..Steve (AcousticNewt 20:01, 23 June 2008 (UTC))

I haven't forgotten, just had no time. I wonder how I can 'cut out' the holes, first attempt will be to append coordinates from the inner way to the outer. Will probably be wrong but I have to start somewhere. --Rene A 19:06, 27 June 2008 (UTC)

Are you still working on this? Multipolygons are appearing more and more frequently.....--Extremecarver 15:41, 19 October 2008 (UTC)

Not sure to what extent this helps, but osm2mp writes multipolygons simply as polygons with multiple Data sections, the first being the outer way, and subsequently holes. Not sure whether orientation comes in. Robx 11:06, 12 December 2008 (UTC)

As far as I know it should be in mkgmap-latest Rene_A 12:00, 13 December 2008 (UTC)

Additional points for areas tagged as shops etc. (Garmin devices)

On my 60CSx I can search for shops and they appear, if they are just a point on the map. But if I tag an area with building=yes and e.g. amenity=restaurant, it won't show up on the device. Here it would make sense to add an additional point somewhere in the area with the same tags as the area so that the 60CSx (and assumedly also older/newer devices) can find it. Granjow 14:01, 18 April 2009 (UTC)

Roundabouts

As has been discussed recently on the talk-au list, this does not generate correct exit counts for routing at roundabouts when the entry and exit ways use the same node. Can someone please have a look at the coding and possibly modify it to count exits where the node is also an entry. --Rosscoe 03:56, 19 December 2009 (UTC)

Did you try using the --frig-roundabouts option? If this doesn't help, I would suggest posting information about the problem to the mkgmap mailing list: you should get a better and faster response there. --Clinton Gladstone 13:10, 21 December 2009 (UTC)

mkgmap distribution

Hi there,

I'm using mkgmap since a long time and meanwhile I have created a script which makes it easy to use. Now I'd would like to distribute this script and also my style files. My idea was to create a package, which could be downloaded and after extraction everybody should be able to create his own maps like they are provided on my download page http://maps.team-oid.de This script includes all steps for map creation starting with the download of the source data (OSM Data), over splitting and compilation. The package should contain all necessary files like style files, splitter.jar and mkgmap.jar.

Are there any objections on this? What do you think? In my opinion, the licensing allows the distribution of mkgmap and splitter. Am I right?

UPDATE:

Hi my distribution is online now for downloading. You will find it here: http://www.team-oid.de/garmin_maps/mkgmap_dist.tar.gz Documentation is still missing. Just download, extract and use the create_maps.sh script. It does the download, splitting and compiling of the mapsets. You just need a linux pc, installed java, wget, bzip2 and minimum 4GB of RAM. I will do regular updates, by updating my styles, types, mkgmap and splitter binaries. Feedback is welcome.

Marco