I want to track down the problem because reverting commit r2028 creates other problems although it seems to fix your problems.
I need your exact mkgmap parameters, the exact splitter settings plus the areas.list file, your style files and the exact position of one or more holes in the map.
Tachoknight posted the mkgmap parameters in the first post of this thread. I assume that you use the default style? So I only need your areas.list file and the positions of one or more holes.
The most âdramaticâ hole was in 63240003, but not completely; I plotted out the areas in Google Earth and what was missing was the overall Chicago-land area. I remember that Joliet was on the map, though according to the area covered by 63240003 Joliet is inside there as well. If you want Iâll re-create the map with the âproblemâ mkgmap version and try to lock down the exact area; I remember distinctly that it was a rectangular area but not aligned to true north, it was in fact angled northwest a bit.
Is this info sufficient or would you like me to regenerate the map and try to get some exact areas?
thanks for the infos! I did not make any progress so far. It would help me a lot if you could try to define exactly (exact coordinates) where the wholes appear. I compile the maps with your settings but did not find any holes.
Instead of coordinates you could also say âthe area (around 1.2km x 1.2km) north of small town XYZ that begins when you follow the primary road NN for 500mâ.
maybe we are searching at the wrong place. I believe there are only some maps/styles affected by this problem, as
I had expected much more response if this was a real problem that affected all maps. As WanMil, you can confirm that it works correctly on your computer. So, I will have a closer look at my styles.
I have noticed that compiling the map with newer versions (r2042 (?), and later) takes much more time than with older mkgmap versions(r2012 and before), ca. 30 minutes instead of 4 minutes. I have tried reducing the tile size, 550k nodes doesnât help.
The last days, I have done many attempts with different mkgmap versions, and I believe that when mkgmap is running fast, there are no holes. But I canât say this for sure, as I have not always watched the compile process, itâs just a feel. tachoknight, did you have the same experience?
If I remember correctly, the modified r2052 (subdivision creation) was the only one that was running slowly, but generated maps without holes.
First of all, I will install other styles and test again, iâll keep you informed
I think it depends also on the Garmin units and their firmware, some people see holes, others not, with exactly the same map.
Btw you can try it yourself with these two gmapsupps: http://code.google.com/p/mkgmap-style-sheets/downloads/list
gmapsupp.img gmapsupp.img of test map
gmapsupp(2011-10-21).zip OSM world routable test
The last one I have compiled with Wanmilâs 2052 patch
It would be good to check that. The internal limits of the subdivision format in the garmin img files are not well known. So maybe we experience a slight violation of the limits and different GPS units behave different to this violation. But it would be good to check that.
For this I need the exact coordinates where you experience the holes. Maybe also with the zoom level. Then I can check myself if there are any abnormalities in the subdivisions in this area.
I donât think this will help, you would have to use the same osm data, the same splitter and mkgmap, and the same style rules.
In the meanwhile I installed mkgmap r1906, and splitter r181, and I am happy with it. Every rendered map is ok.
I had in mind that my style files are wrong. As a test, I installed the velomap styles which I consider as a perfect example for bicycle routing. Like in my own styles, there are also missing tiles (r2062 / r181), and mkgmap is very slow (30 minutes instead of 4 minutes with r1906 / r181, these maps are ok)
Summary of my experiences:
r2042+ versions are running on 100.0% cpu usage the whole time - and then there are missing tiles
older version are at ~90âŚ97% cpu usage, and mkgmap is much faster, new versions need ~30 minutes instead of ~4 minutes (old versions) on my standard map
missing tiles appear at different locations when different styles or slightly changed source data is used, but are reproducable when the script is executed multiple times
reducing tile size by the splitter doesnât help
But Iâm still curious if tachoknight and me are the only ones who have this problem?
I tested the 2011-10-21 version
There is a part of the Netherlands visible on my Oregon 300 (firmware 4.12), from (52.07N, 2.435E) to (52.538N, 6.245E).
I donât know if this was the intended area, maybe it should be larger.
When I pan to the edges of the map, it is entirely covered by a fullscreen âlandâ polygon. This is an indicator that there is something wrong with the map, this happened with my broken maps as well.
A video should be better: http://www.kartenmacher.org/PICT2472.mpeg
The colors are not good visible in the video. When I pan near to the mapâs edge, the standard light-brownish background is drawn over the map.
When the map is displayed, the surrounding is not displayed as the brownish background, but as transparent (white with light yellow grid). This behaviour has changed some weeks ago (before the surrounding was the background brown). This changed be in the same time when the missing tiles appeared. Maybe this is a hint for you.
Both maps are displayed entirely as displayed on your picture. Perfect Do you know with which mkgmap version the 05 September map was built?
If you need a sceptical beta-tester for future, let me know
What did you expect? Steve is still working on it but this work is done on a branch and not the main mkgmap release. There is a download section on http://www.mkgmap.org.uk/snapshots/ for branches. But up to now only some preparations have been done. So it will take some time until real improvements will happen.
So long you can improve it yourself by removing or modifying lines like
This probably creates lots of roads with the same name (e.g. âT (grade1)â or âTrackâ)). Current mkgmap versions have a problem with that and are very slow with lots of roads with the same name.
java -Xmx1300M -ea -esa -jar âŚ..\tools\mkgmap.jar --max-jobs --gmapsupp --styl
e-file=âŚ..\styles\000001\fredbike -c âŚ..\styles\000001\fredbike\options.args
âŚ..\osmsplit*.osm.gz âŚ..\typfile\000001.TYP 1>âŚ..\mkgmap.log
Exception in thread âmainâ java.lang.UnsupportedClassVersionError: uk/me/parabol
a/mkgmap/main/Main : Unsupported major.minor version 51.0
at java.lang.ClassLoader.defineClass1(Native Method)
at java.lang.ClassLoader.defineClassCond(Unknown Source)
at java.lang.ClassLoader.defineClass(Unknown Source)
at java.security.SecureClassLoader.defineClass(Unknown Source)
at java.net.URLClassLoader.defineClass(Unknown Source)
at java.net.URLClassLoader.access$000(Unknown Source)
at java.net.URLClassLoader$1.run(Unknown Source)
at java.security.AccessController.doPrivileged(Native Method)
at java.net.URLClassLoader.findClass(Unknown Source)
at java.lang.ClassLoader.loadClass(Unknown Source)
at sun.misc.Launcher$AppClassLoader.loadClass(Unknown Source)
at java.lang.ClassLoader.loadClass(Unknown Source)
Could not find the main class: uk.me.parabola.mkgmap.main.Main. Program will exi
t.
I thought about several improvements that are regularly done. This was an off topic quoestion, Iâm sorry. I use to install new versions of mkgmap and do not change any parameters in the script, and hope that everything works as intended.