Mkgmap is a very nice program. I was not negative about it in any way (ehh… well… transliteration is not it’s strength … ha ha). But I would not use it in the context we are talking about as sendmap20 would do all so much easier. Moreover I’m focussing on users who only want to generate a gmapsupp.img where you want them to be able to all kind of things with mapsource.
No no no. We are talking here about a possibility to download the tiles not manually. A download program will be used.
How will they download the tiles and that exe?
That exe is sendmap20 as that is all that you need once the tiles are on your computer.
That was the first thing the OP wanted to let it do…
Sorry. That was not the problem I had in mind. See my earlier post.
Edit by Lambertus: I moved an offtopic discussion about the sendmap20 alternative Gmaptool to a topic of it’s own: Here.
I will be travelling the world in an expedition vehicle, and offline (laptop) navigation is one of my requirements. I’m currently using nroute and mapquest. Is there any way to download all maps (besides the obvious - select all)? If necessary, I can select a bunch (or all) countries, but I understand that’s pushing it as far as resources are concerned.
A first rough version is now implemented. Seems to work fine. Start hitting that F5-key y’all
Note: Only works for new requests…
I’m sorry but bad behaviour of users in the past made me disable the option to download all maps easily. Probably the best solution is to request all countries you’re about to visit and which you can’t already download immediately. It involves a bit of work and waiting time from you, but that’s how it is unfortunately…
Surely you mean Mapsource, not Mapquest? I wouldn’t download too many tiles in advance, as data is added all the time (until they delete all the data from people who didn’t agree to the new licence…). Just download what you need for the next couple of weeks, then go to an internet connection and download more. Uninstall the old tiles before installing the new ones.
Note: I’ve reduced the map caching time from 42 to 36 hours in order to speed the queue up a bit. Please make sure to download the map quickly after you’ve received the map-is-ready notification email.
Some new tweaks to use the resources more efficiently (hopefully):
The color/presence of the notification text (urging users to behave nice) is now dependent on the queue length.
The service now detects in all stages whenever a combination of tiles is actually a country combination, even when the user adds/removes tiles using manual tile selection. Countries are cached longer then the other requests (currently only 12 hours, but this can be tuned further).
A new version is released which uses a new tile-vs-countrypolygon matching algorithm. In previous versions there were always predefined countries that missed tiles or used too many tiles. The new matcher fixes this. It was especially a lot of work to efficiently handle corner cases like Russia and New Zealand who cross the +/-180 degrees longitude line. Running into -and working around- obscure bugs in libraries also took quite some time to figure out.
One of the neat functions of the new PHP Matchit script is that it can output an image of a polygon selection (cortesy of the polygon PHP class). This class isn’t perfect (the bugs that needed working around I mentioned earlier) and it’s quite slow: it takes 20 minutes on a not-too-fast Xeon single core to match the countries. But I can work around that in a next version that uses threads which should provide an almost linear speedup with the amount of cores available.
Anyway, the images, I’ve uploaded two examples for you to marvel at
Brazil:
Thailand:
The blue boxes are the polygons that define a country (they don’t need to be rectangles as e.g. the Netherlands is defined as a single large polygon). The black box is the bounding box of the country that is used to prefilter the tiles (this provides an enormous speed improvement over matching each tile against each polygon of ~100x). If a tile passes the country prefilter it will be tested against each polygon in the country definition file. The matched tiles are shown in red.
Heh, you got me there. I really should be going out on the bike more often. Actually I have an on-off relationship with my projects. I can spend weeks on end working on it straight away when I come home from work until bedtime, like I pretty much did in the last two weeks. But then I get to a stage when the most important stuff is working as I want it and the energy leaves me to work on the project. I then put the project on hibernation and maybe start working on my other projects (OSM and non-OSM related) or relax a bit. Anyway, spring and summer are coming and it looks like the Garmin map service will have to make due until winter again (apart from map upgrades now and then).
As far as I know there are no simple rules and many exceptions. Even the “official” tool Chulalongkorn University: Thai Romanization Program is far from being perfect. The method of romanization is changing and even the authorities don’t follow them. Thus you can get different versions from the tool and the sign at the street. In another country there are other rules. Thus the map generation program ought to follow the exact border. I guess currently not doable.
I think the best way is to tag “name” and “name:en”. Where this is done a convenient bilingual map can be created, e.g. in Khon Kaen and the map is still useable if there’s only the local Thai name for some places given, e.g. at Chatuchak. A navigation program can offer switching the map between English and local Thai language, e.g. as Mapfactor Navigator Free does.
I startet using the “Worldwide routable Garmin map” of Thailand not long ago and I like it more and more. As I see it is using name:en, name. This is fine where name:en is given. But where there’s only name in Thai letters I see strange words in roman letters. I don’t know why. Get they converted during the map generation or are non Thai Garmin devices and programs not able to display Thai letters?
Many thanks to Lambertus and the other contributors
Willi
This service has a nice trick up it’s sleeve which -afaik- other OSM Garmin map providers don’t have, namely the addition of a custom transliteration application created by user Greencaps. This transliteration apparently works quite well for e.g. Slavic languages but frankly I don’t know how well it performs for other countries, so I’ll leave the more detailed answers to Greencaps…
And, yes, the way preference is given to OSM English and international names over transliterated and finally a fallback to the OSM name does help a little too.
Well you saw only one… I wrote a program which given the relation id of a country’s border downloads recursivly all containing relations and ways and finally the nodes. Then the individual ways often have to be sorted and some reversed to make it a nice closed loop boundary which I save as a .gpx file. Much later I discovered http://ra.osmsurround.org/analyze.jsp?relationId= which can analyse relations when given a relation id. At the end it offers a download possibility of the ‘border’ as gpx file.
Having these possibilities the bunch of work is to determine -by hand- the relation id’s of the borders.
Yes. Translit could do that too I think. But as I don’t know anything of Thai I did not even start. When there are many ways Thai can be transliterated (as Willi2006 said) then we could still choose one. If you are willing to help me to make a translitertation table then I will make a webpage wilth a Thai alfabet where you can fill in the transliteration (in the english way).
That is very well doable. As you can read in http://forum.openstreetmap.org/viewtopic.php?id=5554 translit was first designed to use country borders for the different languages. But then ‘I found out’ that country borders were not needed as every language occupied its own set of utf-8 characters. I think I can put in some thai-states-borders again. (I said I think. Did not see the code for quite some time now.)
I wish I could help you there, but I don’t read or understand Thai. I had a quick look at the transliteration table on the uni website (following Will’s link), but it looks very complicated.
Interestingly, the maps I compile myself strip out all Thai names in the name field, except for borders. Your maps show labels with long strings of gibberish. I guess we can conclude from that that Garmin MS and devices don’t display Thai characters, except for localised units, of course.
I guess the best thing to do would be for mappers (like myself) to run all Thai-only names through something like Google translate and then create then name:en field. Or should that be name:int?
Can anything be done about the borders?
SW of Yala the border is a complicated looking web of relations and multi-polygons. It’s interesting to note that the name for Malaysia can’t even be displayed in JOSM (it shows as a bunch of squares, this is the result of a copy and paste: မလေးရှားနိုင်ငံ), although Malaysia uses the roman script. I think this is an error.
The name field for the border line itself is Border Thailand - Malaysia, so I don’t know where mkgmap takes all the gibberish from.
