Worldwide routable Garmin maps: URL REMOVED

Sure. Sorry for that.
http://osm2.pleiades.uni-wuppertal.de/garmin/openfietsmap_lite/17-07-2014/5305df984533df6144e2dc7baa514998/

No idea what happened. The tiles are missing and I don’t know why but it does not appear to be symptomatic. I’ve added some extra logging so hopefully next time I know more.

I see that you requested a newer map, did that go alright?

Yesterday I requested two maps:
http://osm2.pleiades.uni-wuppertal.de/garmin/openfietsmap_lite/17-07-2014/5305df984533df6144e2dc7baa514998
and
http://osm2.pleiades.uni-wuppertal.de/garmin/openfietsmap_lite/17-07-2014/1ade0af0b48ee8c263c674135a37a8f3

Both have the same issues…

This morning I retried one of the requests, it is still in the queue:
http://osm2.pleiades.uni-wuppertal.de/garmin/status.php?id=5df6dcebababc8e9dff6994db8a71205

Regards.

hmm, investigating further I notice that your request contains tiles that are non-existent:

63241424.img;63241428.img;63241429.img;63241430.img**;6324**1431.img;63241433.img;63241434.img

While OFM_lite maps contain only tiles that start with: 6344

Your latest request uses the correct tile numbers. How did you select the tiles? Do you use a permalink or some such?

I just clicked the tiles after selecting:
http://garmin.openstreetmap.nl/
Routable Bicycle (Openfietsmap Lite)
Enable manual tile selection: checked
and selected the tiles in the map presented.
Then entered my mailadres and clicked: build my map…

The latest request has been placed in the same way.

Latest request is through the queue and looks ok!

Ok, glad to hear all is well this time. Still no idea why the tile-id’s were wrong during the previous requests. Other people didn’t seem to suffer the same problem.

On another note:
Improved the load balancing a bit more yesterday evening: the server is now chosen based on disk space AND queue length. If disk space is available then the server with the shortest queue gets the request.

I’ve got a question / concern about rendering with the Mapnik and new-style maps…minor roads in forests are very difficult to see against the landcover on my Montana 650. E.g. http://www.openstreetmap.org/way/19729384 where it passes through natural=wood. I’ve tried setting the landcover zoom level on the device to “none”, which has worked with some other maps but doesn’t appear to have any effect. My use case is operating a dual-sport motorcycle and looking for roads and tracks through the woods, particularly when trying to find a way through an area with lots of dead ends—it’s very tough to tell, especially at a glance, if ways are mapped as going through or not.

Here’s a partial shot of the map as displayed on the Garmin, which makes the road look more obvious than it does when viewing the GPS directly:

(ignore the yellow dots, those are an overlay map I built from Vermont AOT data and indicate private roads)

Lack of contrast varies from unit to unit. In the typ file those roads are not defined, so it makes use of the internal Garmin rendering type (which makes it a Garmin problem). The only thing that you could do is adjusting the TYP file with a typ file editor and give it your own colours.
The forests are polygon type 0x15, residental roads poly lines 0x06. A good editor is TYP viewer, https://sites.google.com/site/sherco40/home

The map (generic routable, new style) of Belgium had a large void area (i.e. no map data) in the west of Belgium. I downloaded it on friday.

This is probably caused by an old version in the history cache of Basecamp. Try ctrl-G (2x) to clear it?

Hi, I have accidentally found there are some areas with the same .img number but different name (and different real place) in the map generated yesterday. I have found these:
63242597, named ID-Denpasar (western coast of Australia + lot of water) and ID-Banjarmasin (northern Java and southern Borneo)
63242700, named VN-Ho Chi Minh City (south-east Vietnam + Malaysia) and PH-Taguig (small area in Phillippines south-east of Manila)
63242866, named TR-Istanbul (Istanbul + Black sea north to Istanbul) and IT-Busto Arsizio (west to Milan)
As I know close to nothing about the map creation, maybe this is not the right place to report it - sorry then.

Yes it is the right place to report those issues, thanks David.
I hope Lambertus can have a look at this?

That is very strange. Does this relate to the generic map or one of the other two maps?

As far as those tiles are concerned, only the generic. If you download Indonesia, one tile will be missing.
Perhaps filling up the sea tiles will solve this issue? Now only the generic map does not have a complete coverage of sea tiles.

The past three weeks two custom map generation servers have been added together with a lot of software development and encountering some interesting bugs. So, after last night, the queues are finally empty again. Many thanks to those who made this possible. Onwards!

Turkey map selection:
When selecting Turkey is leaves out the Istanbul tile. When manually selecting tiles it leaves this tile out as well in the final installation. It has been this way for at least a month I believe. I use my maps in Mapsource / 276C.

I believe it is map tile TR-Istanbul, 63242890.img

KP

I’ve also received several emails by different users about this problem and been looking at this problem for a while, but didn’t spot the cause earlier. Now I think I found it and implemented a fix.

When Splitter is called to subsplit a tile but cannot find a good solution it will produce only one result (instead of the two it is ordered to produce). This is spotted by the build-script which then simply re-renders the original tile without further subsplitting. However the sub-split attempt leaves two ‘orphaned’ files behind which aren’t cleaned-up though cause double use of a tile number later on, e.g. tile number 63242074 is defined twice as US-Long Beach and US-Los Angeles. The same happens with Istanbul and other places as described by DavidOb a few posts above. I thought that this problem had been fixed with an earlier update, but clearly it didn’t.

The problem should be fixed by removing the subsplit files which are not going to be rendered. When the Openfietsmap_lite render process is finished a new map update will be started. I hope that solves this issue.

Many thanks for the reports!

150 people downloading countries from the same server while an update process is running: Madness. Both harddisks are fully occupied :sunglasses:

To make it worse, the OFM mirror server from NLUUG seems down for some time so people have to use the Wuppertal server too :confused:

Good to have a fall-back server then, even if it’s not the fastest :smiley:

Anyway, I’m in the process of moving the render chain to the new server: It has much more ram, cpu-cores and disk space and so is able to do much more in parallel. That’ll free one harddisk in the osm server allowing me to use it for sharing country maps. This means there will be twice the I/O bandwidth available for country (and OFM) downloaders. But several other things need to be in place before this happens.

For those familiar with Linux, I’ve rarely seen a quad-core server having more then 100% I/O-wait, the last few hours it was at 400%. All four cores are 100% waiting for the disks to return the requested data that is needed to do any useful work. In other words: all cores were starved of data and could do nothing but wait almost 100% of the time.