But thats what miszczu1983 is asking for I think. Which program do you use for that? And what is the result of adding a typfile? That program cannot export it?
Splitting a gmapsupp.img means to have the tiles back (e. g. 63240001, 63240002 …) and the .mps. If I want to change the look of the map on my Garmin Unit I can add different typefiles (I have searched for different typfiles around the web).
To split a foreign gmapsupp.img I am using gmt (GMapTool, the binary for linux). For my own gmapsupp.img I can use my tiles and different typfiles.
As far as I experienced it is not possible to add the road-names as pois in this way, because the road-names are included in the tiles (.img files)!
And this was the question I think …
flux.
Do I understand correctly that you invoke mkgmap again on some selected tyles to generate one gmapsupp.img and that the result depends on a used style file?
The first part is correct, it is what my website is doing all the time. The second part (of adding a typ file); I’m not sure about that. I’ve never used typ files before, but I assume that it would work this way.
So what you can do is download a bunch of tiles from my site and recombine them using Mkgmap or another tool (perhaps MapSetToolkit) while adding a typ file. But that won’t give you the road POI’s, for that you will need to download the OSM data and render your map yourself (or wait until next weekend when I’ll release the next update).
Here two screenshots (Garmin Etrex Vista HCx, Night), based on the same gmapsupp.img (I only added a typfile with a special family-id to receive the look of the second screenshot):
Original look (without typfile)
Customized look (with typfile from user:Christoph, AIO-Map)
The map with the typfile is looking different, but the map is much slower at the Vista HCx and it is to customized at the Oregon 300.
Therefore I do NOT use any typfile in my own maps.
flux.
Sorry… I still do not understand completerly the process.
– do you add the typefile to some directory in your garmin device? So indeed use the same gmapsupp.img
– do you generate a new gmapsupp.img (using mkgmap with that typefile)?
Which of the two?
By the way: How do you manage to make such clear pictures of the garmin screen?
At first I have to say, that I use linux for my work, the only exception is the Garmin program xImage for the screenshots (–> http://www8.garmin.com/support/agree.jsp?id=545), because there is no equivalent for linux.
-
I have a gmapsupp.img.
-
If it is a foreign one, I use gmt (–> http://www.anpo.republika.pl/download.html) to split the gmapsupp.img to its tiles.
-
If it is my own, I have the tiles before I merge the tiles to a gmapsupp.img.
-
Then I add a typfile with the corresponding and needed family-id to the tiles and merge a gmapsupp.img:
java -jar mkgmap-version.jar --gmapsupp --family-id=4 --family-name=MYMAP *.img MYTYPEFILE.TYP
–family-id=4 is depending on the typfile, you have to find the correct id for the used typfile, normally the creator of the typfile can give you the id or you can find it in the web
*.img are my tiles (63240001.img and so on) I want to merge to a gmapsupp.img
MYTYPEFILE.TYP is the used typfile, the .TYP must be in upper letters! In the second screenshot you see the typfile of Christoph (AIO-Map) and the needed family-id=4 …
- I have a new gmapsupp.img with a customized look!
flux.
Edit: You can open the typfile (stylefile) in the online editor and there you can see the needed family-id → http://ati.land.cz/gps/typdecomp/editor.cgi
Here a screenshot:
Thank you flux for all explications. I understand now. Thank you too for xImage. It works out of the box. Just grabbing a screenshot by connecting a USB cable. Great.
Hahaha, I thought that I massively improved the loading time of the tile definitions because I rewrote the OpenLayers section in the webpage scripts that loads the KML file with the tile definitions…
Well think again, it turns out that disabling gzip output in the server side script did the trick all by itself. The strange thing is: the AJAX call is downloading the data immediately and the processing of the zipped data also seems to be immediate (according to a spike in CPU and bandwidth usage), however the result is only shown about 12-13 seconds later… mystery.
Compression is handled by adding the following two lines to the server side PHP scripts:
ob_start("ob_gzhandler");
[my functional code]
ob_flush();
I’ll see if there are other, better, ways of doing compression…
Edit1: When I let the compression be handled by the webserver (controlled through .htaccess) then it works fast as expected. Investigating further…
Edit2: This seems like a browser issue. FF 3.5.5, 3.5.7, 3.6 and IE 8 are slow in displaying the tiles from a zipped source, but webkit is very fast. Thanks to crschmidt for the pointer.
Edit3: Problem solved, the error originated from this side of the monitor ofcourse: The PHP script that returns the gzipped KML content also returned the content-length header set to the size of the source KML file instead of the gzipped size… So as a result the browser is expecting more data and is waiting for it until a timeout occurs. Duh.
Well, the KML output script is fixed now and facilitates browsers that support compressed content as well as those browsers that do not.
i am trying to follow flux instructions.
here is what I did:
downloaded mkgmap.
Placed tiles (smal .img files) in mkgmap folder.
When I enter any command in command prompt, i have error : invalid or corrupr jarfile 6324004.img
(which is first tile).
If I remove this file, the error repeats on next tile.
What am I doing wrong? Do I have to use .osm files instead of .img files?
The splitter returns me same error for .gz2 files.
Try this if you have some OSM files from splitter (or extracts from Cloudmade or Geofabrik):
java -Xmx1024M -ea -jar mkgmap.jar --overview-mapname=63240000 --road-name-pois --series-name='My first routable map' --latin1 --description='My first routable map' --gmapsupp --route --product-id=53 --tdbfile --gmapsupp *.osm
Or this if you have some images lying around:
java -Xmx1024M -ea -jar mkgmap.jar --overview-mapname=63240000 --road-name-pois --series-name='My first routable map' --latin1 --description='My first routable map' --gmapsupp --product-id=53 --tdbfile --gmapsupp *.img
And this is also helpful:
java -jar mkgmap.jar --help=options
I deleted the sections --series and --descriptions.
Then gmapsupp.img is created from tiles.
But streets are still not visible as pois.
I added --road-name-pois between 63240000 and --latin.
I’ve updated my post, thanks. The parameter order doesn’t matter for Mkgmap.
Update:
A new version of the website is up.
New feature: If a country map is already available on the server then a direct download link is provided. For all other situations the process of filling out the email form and wait for the server to create the map for you is still the same.
You are missing the first step: Download a countryname.osm.bz2 from Cloudemade → http://downloads.cloudmade.com/ or Geofabrik → http://download.geofabrik.de/osm/ and run
java -Xmx2600M -jar ../splitter-r105/splitter.jar --status-freq=30 --cache=. --max-nodes=800000 countryname.osm.bz2
Replace the path to splitter.jar and insert your version.
I use 2600M for 3 GB RAM, de- or increase this value according to your RAM
You can increase 800000 to 1000000 or 1200000
This will split your countryname.osm.bz2 to single tails which you can use with mkgmap
java -Xmx2600M -jar ../mkgmap-r1543/mkgmap.jar --family-name=DE --area-name=DE --max-jobs=2 --latin1 --description=DE --country-name=DE --country-abbr=DE --route --gmapsupp --draw-priority=1 --add-pois-to-areas --make-all-cycleways --link-pois-to-ways --remove-short-arcs --net --check-roundabouts --check-roundabout-flares --max-flare-length-ratio=5 --series-name=DE --adjust-turn-headings --code-page=1252 --location-autofill=1 --road-name-pois 6324*
Replace the path to mkgmap.jar and insert your version.
The created gmapsupp.img has streetnames as pois.
Just a short instruction, my way to create a useable map for Garmin units.
flux.
Always enjoy the service, thanks.
But is there a disk problem again? The maps are coming up empty.
<http://planetosm.oxilion.nl/~lambertus/garmin/routable//0f66fbc75d3733aac5a347d5b0d9793f>
I was hoping to pick up some maps for a trip tomorrow.
Thanks
Nope, no disk problems. I think I’ve got that sorted permanently now. But I see there is a new bug somewhere: the directory from which the map tiles are copied is not correct anymore…
Edit 1: I guess you saw this error in the confirmation webpage?
Edit 2: Ok, the problem is fixed. It was a silly copy/paste error. Everyone who has requested a map since yesterday evening CET has been effected unfortunately. I’m removing all erroneous maps. Please request your map again. Sorry for the inconvenience.
Yep, that is the error I saw. I wasn’t sure if it was critical or not.
Guess it was.
I’ll try again later.
Thanks
Thanks. I did some try on kazakhstan - I have questions marks everywhere.
When I download .img directly from labertus it is OK.
What may be the reason?
Is the paremaeter --latin1 responsible for that?
I created a map of Ukraine with the options --latin 1 and --lowercase=yes, the streetnames and cities are shown proberly.
flux.
Edit: The names and streets for Ukraine are shown proberly even I do not use --latin or --lowercase …
Edit2: I found the osm-datas from Kasakhstan and it is working with --latin 1 and --lowercase=yes, I have cities and streetnames.
Afaik Mkgmap has limited transliteration capabilities and characters that do not fit into the selected code table will be converted into questionmarks (? characters). Afaik the best support is in the ASCII mode, so you should try without the --latin1 parameter.
My maps are OK because greencaps made a special preprocessor that transliterated names before Mkgmap processes the OSM data.