Missing Tiles in Map

Is this problem the same as described (in Dutch) here?

http://forum.openstreetmap.org/viewtopic.php?id=13826

Yes, that’s the problem exactly! Sadly I cannot speak Dutch so I can’t determine whether the posters came up with a solution or not.

Google Translate does a pretty good job with this. But no fix is suggested.

Have you tried opening the problem tile in OSM? Or perhaps opening the IMG with GPSmapedit?

If you haven’t considered this already, you might also want to reduce the tile size. csdf’s spreadsheet in the following link handles this nicely.
http://forum.openstreetmap.org/viewtopic.php?id=11770
It can be tweaked to generate a large tile grid.

Just an FYI update…based on Yggdrasil’s suggestion, I re-rendered the map with the r2012 version of mkgmap; no changes to the script, just the version of the program. The file size was the same, but the map does indeed render properly; I haven’t found any empty spots on the new version.

Nice to hear, that I am not the only one struggling with this. Although I hoped that something in my configuration is wrong.
Hope that someone who reads this, can change the situation. I am hoping for a corrected version of mkgmap. I downgraded to r2012 too.
In comparison of the newer versions (2042, 2047, 2052) to the r2012, I found several changes in its behavior:

  • inter-tile routing now works - if the tile contains data :slight_smile:
    Although mkgmap is said to be capable of inter-tile routing since ancient times, I have never had a map compiled that worked properly
  • transparent background

Maybe you should post your comments on the mkgmap mailing list, I started a thread about this issue here:
http://www.mail-archive.com/mkgmap-dev@lists.mkgmap.org.uk/msg10477.html

Wanmil has adapted the mgkmap version, maybe tachoknight or Yggdrasil can test this out?

Thanks, Wanmil and ligfietser.
Test is in progress and still running.

Well done!
No missing tiles with r2052-subdivcheck
Thanks again

I concur with Yggdrasil; I reran my tests with the r2052-subdivcheck version and the maps do not have any problems; the big blank spaces are gone!

Thanks a lot, this is awesome!

Thanks for your test!

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.

Have fun!
WanMil

I recently updated to r2052 (standard build), and let my script run. Sorry, I cannot find any log file.

Here you are: http://kartenmacher.org/missingtiles.zip
There is a info.txt included that contains all information you need.

Hey WanMil-

I used the default style (still learning how to make those :slight_smile: ).

The splitter command was:

java -Xmx4G -jar …/splitter-r180/splitter.jar ./illinois.osm.pbf

The areas.list file:

List of areas

Generated Mon Oct 24 22:48:45 CDT 2011

63240001: 1929216,-4265984 to 1982464,-4159488

: 41.396484,-91.538086 to 42.539063,-89.252930

63240002: 1724416,-4163584 to 1847296,-4077568

: 37.001953,-89.340820 to 39.638672,-87.495117

63240003: 1945600,-4159488 to 1982464,-4077568

: 41.748047,-89.252930 to 42.539063,-87.495117

63240004: 1847296,-4184064 to 1900544,-4077568

: 39.638672,-89.780273 to 40.781250,-87.495117

63240005: 1900544,-4265984 to 1929216,-4159488

: 40.781250,-91.538086 to 41.396484,-89.252930

63240006: 1724416,-4265984 to 1847296,-4163584

: 37.001953,-91.538086 to 39.638672,-89.340820

63240007: 1900544,-4159488 to 1945600,-4077568

: 40.781250,-89.252930 to 41.748047,-87.495117

63240008: 1847296,-4265984 to 1900544,-4184064

: 39.638672,-91.538086 to 40.781250,-89.780273

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?

Hi Yggdrasil and tachoknight,

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”.

WanMil

Hi all,

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

Thanks for all your effort!

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.

Have fun!
WanMil

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.

Ok, but obviously this is not a permanent solution because you won’t be able to do an update with new features.

Style files cannot cause that some areas are not visible in the map. If they do it is a bug.

r2042 is running with 100% cpu because you set the same name for lot’s of ways. Steve is working on it to fix this and has created the mkgmap-simplify-sorted-roads branch (see also http://www.mkgmap.org.uk/pipermail/mkgmap-dev/2011q4/012671.html)).

Did you try r2038? This is the previous mkgmap version. If this does not contain any missing tiles this would be a hot lead to find the problem.

This still indicates a problem with the subdivisions but I can only have a look on it if I really know exactly which areas are missing.

WanMil