Worldwide routable Garmin maps: URL REMOVED

My request is number #1631 in the queue, 6.8 days to wait… too late I’m afraid :frowning: I miss predefined groups of countries in the listboxes: I need (north of)Germany+Denmark+(south of)Sweden. Would it be possible to add very common combinations like Germany+Austria+Switzerland or Germany+Sweden+Denmark to the list of predefined maps? Country queries are much faster, but I have an old Garmin etrex and cannot combine maps manually.

Just install all those countries on your computer and use Basecamp’s Mapinstall or Mapsource to send a selection of map tiles to your GPS.

Thanks, in the new map update just out it is OK now.

Regards,
Peter.

Just a quick heads-up:
The custom map queues have been really long the past few weeks (up to 1700 requests waiting), but I’m happy to announce that later this weekend I hope to be able to add a second custom map server which adds 2x the cpu power but unfortunately only supports 1/3rd of the disk space which is limiting. Anyway it looks like a nice addition.

It looks like only the mail daemon needs configuring…

Thank you again for providing this invaluable service. It keeps getting better all the time.

Regards,
Peter.

Lambertus, if you are short of disk space, does a mirror server like the NLUUG server for the Openfietsmap help?
They asked me if we need more disk space.

The new server is live. At first all new custom requests will be routed to the new server and the original custom server is enabled again when it has caught up.

I’m aware of one last problem on the new server: fancy directory listing isn’t working yet.

Edit: fixed. Needed to change AllowOverrides None → all

This is difficult. As it stands now, disk space alone has little value to this service, especially the custom maps need disk space AND cpu power. The country maps could be hosted offsite but there is no need for that at this moment.

How often are the predefined maps updated?

Approximately once a week.

Whoops! 600 GB of custom maps in ~half a day: disk full. Map generation is idling now …

Edit: We’re updating and rebooting osm2 now and will bring it back up asap. Warning: This will kill ongoing downloads!

After updating two custom map servers will be available (but both very very busy).

Edit: I’m told that a lot of emails got stuck at another other mail server because we’re using a temporary domain. Many people will receive their ‘Map ready’ mail much later then necessary.

Now that there are two custom mapserver I needed to implement some kind of load sharing. The first version was simply based on a random selection. But it was pretty soon clear that this is not enough, so I added adaptive load balancing: if one custom map server is full then all requests go to the other.

Small steps…

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.