Still tweaking the old and new servers. The old one is a bit faster now and the new one should become a bit less stop-and-go as it did the past few days.
Hi there. Thanks for the great service… However, I received a map-ready email but following the links I get to a download location which contains only the _tiles.zip, licence.txt and the typ file. In the mail it says that it should also contain:
- _windows.exe = Installer for Garmin BaseCamp/MapSource (Windows).
- _macosx.zip = Installer for Garmin BaseCamp/RoadTrip (Mac OSX)
- _gmapsupp.zip = Combined image for direct manual placement on the GPS device (gmapsupp.img)
Something went wrong?
Regards
Rein
Please post the download link from the email too.
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!