Worldwide routable Garmin maps: URL REMOVED

I think it is problematic. To make maps routable over the borders I have to cut the whole area out of the worldfile … especially for Russia, Turkey and Kasakhstan. I have not the CPU power to handle it. Europe is no problem, but there are great parts of Asia …

I can offer you a gmapsupp.img with all mentioned countries (routable within the single country, streetnames as pois), different family-ids, so that you can switch on and off single countries.

flux.

That will be OK.

May I ask: why go through all the trouble when a new version comes out next weekend using the --road-name-pois Mkgmap parameter?

No problem for me to wait … may be miszczu1983 is able to wait too?

flux.

My brother is leaving to Africa on friday.
It would be nice if I can have searchable map before friday morning.
But if I am bothering You too much it is not a problem.

No problem, I will start now …

flux.

Edit: You can download this samplemap (128 MB) with the six countries, routable within the borders, roadnames as pois, you can switch off/on every single country:

http://mirror.live-modules.org/quax/fluxflux-sl/playground/gmapsupp-samplemap.img

This is what \i was trying to do!
Thanks a lot man.
BTW, the map is routable together with my basemap.

Can You post exact codes which you used to create .img files and then to merge it into one gmapsupp.img?

I created for the each of the six countries a gmapsupp.img with a different family-id (with the posted mkgmap command in my former posts and the additional option --family-id=xy) and then I merged the six gmapsupp.img to a new gmapsupp.img with gmt (I posted the link in my former posts).

Due to the different family-ids I am able to switch on/off single countries on my Garmin Vista HCx, which cannot handle more than one gmapsupp.img. On my Oregon 300 I could have used the six gmapsupp.img of the six countries and store them on the SDHC with different names (gmapsupp1.img, gmapsupp2.img and so on), because the Oregon is able to handle more than one gmapsupp.img and to switch these on/off.

flux.

Great. Thanks a lot.

Suggestions (not at all critical but I guess handy)
*) sort the countries by alphabet
*) permit selecting multiple countries (within a continent)
*) permit selecting one continent as a whole

It seems that there are problems in certain us states (new york e.g. produces a completely scattered selection of tiles)

Thanks for the suggestions.

I’m working on that one but, surprisingly, sorting XML loaded with SimpleXML in PHP isn’t trivial.

Good one.

I’m not sure about this one. This service was never meant for downloading huge maps, but rather for downloading personalized maps. There are lots of other people who provide country maps and perhaps continent maps as well. Besides, there are no continent poly definition files available from Cloudmade. So if someone has poly files defining the continents then they can send it to me.

I’ve seen those too and they seem to be bugs in the matching applications. I’m sure that will be sorted out soon.

It looks like the update this morning came at an inconvenient moment. The server disk was already quite occupied due to the website changes earlier this week so there was already little room for the typical surge that happens after each update, but now every request is just locked in the queue waiting for some disk space to come available… Currently there are 71 requests queued.

Price of success? :sunglasses:

Edit: (2.5 hours later) 100 requests in the queue.

The former list of choosen tiles was better for people who did their download manually. E. g. I choosed 10 tiles, then I copied the name of the tiles per copy and paste to a textfile and downloaded the tiles with a bashscript to build my gmapsupp.img manually and with my typefile.

With the new names (townname instead of tilenumber) this is not possible any more, because the name of the tile and the name in the downloadlink is different. Now I have to request for a gmapsupp.img or I have to download each single tile manually before I can build my own gmapsupp.img.

flux.

EDIT: Ok, I found a solution to download the choosen tiles without a request to your server for a gmapsupp.img. I copied the names of the tiles and together with the world.kml of your homepage I have the names of the tiles to download directly. A bashscript will download the needed tiles via wget, no more requests to your server neccessary.

EDIT2: The implementation of the streetnames as POIS is working as expected, great! Now all Oregon users can search for addresses via ‘All POIS’ or ‘Geografic points’ (preferred), thank you very much!!!

Great, that is what I thought of too, but I didn’t dare to suggest it :wink:

You’re welcome! :slight_smile:

Edit: Blegh, the back-off changes were implemented a bit too early in the script. It didn’t cause the script to backoff when it was already running (an processing 100 requests). So the result, again, is that some requests failed. I’ve now moved the free-disk-space check to be within the request processing loop. I hope this was the last time requests failed because of that reason. Again, I’m sorry for any inconvenience.

Lambertus, could you please give us the source (cloudemade or geofabrik), the commandline options of mkgmap and the used version of mkgmap you are using to build your routable maps?

It would be helpful for users who want to build their own maps or who want to compare their own maps with yours.

Thank you,

flux.

Download the planet file if you plan to render the entire world, like I do. Otherwise download from a Geofabrik or Cloudemade extract or from any other extract source.

The next two steps are performed recursively until Mkgmap was able to render the source data successfully.

  1. Split the planet into tiles that can be processed by Mkgmap:
java -Xmx3400m -ea -jar ~/garmin/utils/splitter/splitter.jar --no-trim --max-areas=150 --cache=cache --mapid=$mapid --max-nodes=$max_nodes --write-kml=$name.kml --geonames-file=../../cities15000.zip planet-latest.translit.osm.gz
  1. Render step (done before each release):
ulimit -t 600 && java -Xmx1792M -ea -jar ~/garmin/utils/mkgmap/mkgmap.jar --road-name-pois --adjust-turn-headings --latin1 --name-tag-list=name:en,int_name,name:zh_py,name:engels,name --remove-short-arcs --add-pois-to-areas --make-opposite-cycleways --link-pois-to-ways --route --description='OSM World Routable' --series-name='OSM World Routable' $file

Combining step (done on request of the user):

Java -Xmx2048M -jar $utils_dir/mkgmap/mkgmap.jar --index --overview-mapname=63240000 --series-name='OSM World Routable' --latin1 --description='OSM World Routable' --product-id=3 --family-id=2000 --tdbfile --nsis --gmapsupp *324*.img

The Mkgmap and Splitter tools versions are mostly the latest available. There is another too, which isn’t opensource (yet, I certainly hope) that transliterates non-English names to English. Anyone doing some serious map building outside the ASCII or Latin1 language areas should experiment to make their Mkgmap parameters suit that situation. I don’t have any experience with that, so I can’t help unfortunately.

Thank you,

flux.

It looks as if it is grabbing the corners of the state selected and not quite firguring out the rest between them.
Does the same for Colorado, Wyoming and others, though CO & WY are square so there’s only four corners to see.

Lambertus, Any idea what the current queue time is. Replies seem to run over 12 hours? Or has something gone wrong with my e-mail address? Hugo

There are about 180 requests in the queue at this moment, yesterday evening 130. I’ve cleared some old files so I hope the queue is shortening a bit.

Edit 1: But looking at the CPU usage graph, having much more spare disk space wouldn’t have helped much. The CPU is pretty much running flat out most of the time anyway. I guess, it’s just more busy then usual after an update.

Edit 2: The download stats confirm the busyness: twice the usual bandwidth usage the last two days.

Edit 3: The cleanup script allowed 72 hours downloading before deleting, it has been reduced to 48 which resulted in a lot free disk space. I think the queue of 200 request will reduce now.

Yes but matchit cannot do much about it. It is designed to work with country polygons that describe a closed loop boundary. Then it is 100 percent correct. But instead it is offered polygons (from cloudmate mostly) wich are mostly many rectangles within the country boundary. Mostly this will go ok but sometimes like for italy some small tiles miss. So for italy a plolygon from geofabrik is taken. I’m pretty sure that the new york scattering has the same reason. All can be sorted out by supplying good country poligons.

Sorting countries on alphabet is done by machit now also.