Hi, I have created a short HowTo in the wiki for first time users: http://wiki.openstreetmap.org/wiki/Mkgmap/How_to_create_a_map I think that's a good thing for first time users because the other wiki pages contain a bit too much information if you are using mkgmap for the first time. Please have a look on it if I have forgotten something or if something is wrong. Thanks! WanMil
On 07/30/11 15:41, WanMil wrote:
Hi,
I have created a short HowTo in the wiki for first time users: http://wiki.openstreetmap.org/wiki/Mkgmap/How_to_create_a_map
I think that's a good thing for first time users because the other wiki pages contain a bit too much information if you are using mkgmap for the first time.
Please have a look on it if I have forgotten something or if something is wrong.
maybe worth adding/linking to info on how to have routing support and how to be able to search for, let's say, hotels that are mapped as areas instead of nodes :)
Thanks! WanMil -- Rich
On 07/30/11 15:41, WanMil wrote:
Hi,
I have created a short HowTo in the wiki for first time users: http://wiki.openstreetmap.org/wiki/Mkgmap/How_to_create_a_map
I think that's a good thing for first time users because the other wiki pages contain a bit too much information if you are using mkgmap for the first time.
Please have a look on it if I have forgotten something or if something is wrong.
maybe worth adding/linking to info on how to have routing support and how to be able to search for, let's say, hotels that are mapped as areas instead of nodes :)
Routing support is already enabled (--route). I have added --add-pois-to-areas. Thanks for the hint. WanMil
Thanks! WanMil
On Sat, Jul 30, 2011 at 02:41:42PM +0200, WanMil wrote:
I have created a short HowTo in the wiki for first time users: http://wiki.openstreetmap.org/wiki/Mkgmap/How_to_create_a_map
Thanks your the great work, WanMil!
I think that's a good thing for first time users because the other wiki pages contain a bit too much information if you are using mkgmap for the first time.
One thing that might be too much information is character encodings. The wiki page does not mention them and does not include a --code-page option. Perhaps this could be a link to the more advanced documentation? Or could --code-page=1252 be a reasonable "default" worth mentioning? I am embarrassed for not doing that much recently, and do not really feel entitled to ask this: How difficult would it be to write the address index information in the device format, eliminating the need for MapSource? Best regards, Marko
On Sat, Jul 30, 2011 at 02:41:42PM +0200, WanMil wrote:
I have created a short HowTo in the wiki for first time users: http://wiki.openstreetmap.org/wiki/Mkgmap/How_to_create_a_map
Thanks your the great work, WanMil!
I think that's a good thing for first time users because the other wiki pages contain a bit too much information if you are using mkgmap for the first time.
One thing that might be too much information is character encodings. The wiki page does not mention them and does not include a --code-page option. Perhaps this could be a link to the more advanced documentation? Or could --code-page=1252 be a reasonable "default" worth mentioning?
Is --code-page=1252 the default setting of mkgmap? If not it should be added to the options on the wiki page. I want to keep the article as short as possible because it should be a first "HowTo" without too much information overhead. But maybe it's worth to add some hints about further configuration steps to the "Tweak your map" section.
I am embarrassed for not doing that much recently, and do not really feel entitled to ask this: How difficult would it be to write the address index information in the device format, eliminating the need for MapSource?
I don't know. Steve might be able to estimate how much work it will be to fix that. The work to do is to create a map including gmapsupp.img, install it in Mapsource, upload it to the device and compare the mkgmap created gmapsupp.img and the MapSource created gmapsupp.img. Probably that's easy but the non easy part is to understand the differences... WanMil
Best regards,
Marko
On 07/31/2011 11:37 AM, WanMil wrote:
I am embarrassed for not doing that much recently, and do not really feel entitled to ask this: How difficult would it be to write the address index information in the device format, eliminating the need for MapSource? I don't know. Steve might be able to estimate how much work it will be to fix that. The work to do is to create a map including gmapsupp.img, install it in Mapsource, upload it to the device and compare the mkgmap created gmapsupp.img and the MapSource created gmapsupp.img. Probably that's easy but the non easy part is to understand the differences...
This should IMHO be the overall goal of the whole mkgmap project. I made a partial start on this last year. Steve supplied me with a pair of maps as described above: one straight from mkgmap and one after MapSource had been at it. Unfortunately, I just ended up too busy at work to be able to put any work into it. So as Marco said, I too am "embarrassed at not having done that much recently" :-( However, as WanMil points out - understanding what MapSource does is tricky. Basically, MapSource changes some of the tables in the MDR files, shortening some and extending others. It creates a few new MDR tables of its own. There is a wiki recording the known format of the MDR file on "http://wiki.openstreetmap.org/wiki/OSM_Map_On_Garmin/MDR_Subfile_Format" , but Steve has done tons of work on MDR files over the last year or so that have not been documented in that wiki. It would be helpful if someone (not Steve - he's busy!) could get the documentation updated. I was doing my best on it before I got swamped last year. Not much has changed since then. The trouble is that it *seems* as if the header "flags" bytes in the MDR file tell the parser which options to expect on the matching data table. We don't know exactly what the flags are saying. When MapSource changes tables from what Steve's mkgmap had generated, it changes the flags, but we need to do some detective work to understand how the flags reflect the edits. We probably could get away in many case just copying the flags and structures that we see from MapSource, true understanding may not be needed immediately. But documentation *will* be needed (unless one sole enthusiast goes it alone) and a fair bit of experimentation will be inevitable. It's possible that MapSource makes changes to the other subfiles in the .img - I don't remember what I saw of that (if anything) last year. Steve Hosgood.
On 07/31/2011 11:37 AM, WanMil wrote:
I am embarrassed for not doing that much recently, and do not really feel entitled to ask this: How difficult would it be to write the address index information in the device format, eliminating the need for MapSource? I don't know. Steve might be able to estimate how much work it will be to fix that. The work to do is to create a map including gmapsupp.img, install it in Mapsource, upload it to the device and compare the mkgmap created gmapsupp.img and the MapSource created gmapsupp.img. Probably that's easy but the non easy part is to understand the differences...
This should IMHO be the overall goal of the whole mkgmap project.
Agreed!
I made a partial start on this last year. Steve supplied me with a pair of maps as described above: one straight from mkgmap and one after MapSource had been at it. Unfortunately, I just ended up too busy at work to be able to put any work into it. So as Marco said, I too am "embarrassed at not having done that much recently" :-(
Yes. I have started with the same procedure today. The main work is to get the toolchain running: 1. Create a map with 2 small tiles using splitter and mkgmap 2. Install the map in MapSource 3. Create an environment so that it is easily possible to work with the display project Once that has been done the work can start.
However, as WanMil points out - understanding what MapSource does is tricky. Basically, MapSource changes some of the tables in the MDR files, shortening some and extending others. It creates a few new MDR tables of its own.
There is a wiki recording the known format of the MDR file on "http://wiki.openstreetmap.org/wiki/OSM_Map_On_Garmin/MDR_Subfile_Format" , but Steve has done tons of work on MDR files over the last year or so that have not been documented in that wiki.
It would be helpful if someone (not Steve - he's busy!) could get the documentation updated. I was doing my best on it before I got swamped last year. Not much has changed since then.
That's quite important although it's very much work to sort out the format from the source code and from the display outputs.
The trouble is that it *seems* as if the header "flags" bytes in the MDR file tell the parser which options to expect on the matching data table. We don't know exactly what the flags are saying. When MapSource changes tables from what Steve's mkgmap had generated, it changes the flags, but we need to do some detective work to understand how the flags reflect the edits.
We probably could get away in many case just copying the flags and structures that we see from MapSource, true understanding may not be needed immediately. But documentation *will* be needed (unless one sole enthusiast goes it alone) and a fair bit of experimentation will be inevitable.
I am not sure if the MDR description in the wiki is enough for development work. During development you need a lot of "maybe" variants where you can just guess parameters. We should find a common markup for such variants in the wiki.
It's possible that MapSource makes changes to the other subfiles in the .img - I don't remember what I saw of that (if anything) last year.
I haven't seen that so far. But MapSource creates a new .md2 file that does not have the common img format. From my point of view we should start with a better understanding and description of the MDR17 section. It's a section which is created by MapSource and has a tricky but manageable format. Then start to code a simple MDR17 for small maps and the changes to other MDR sections for quite small maps (max 2 tiles, < 100 street names, < 10 cities, one country). Once we have a small map running we might be better able to expand the map size and the changes to the MDR sections. I am not sure at the moment if we should create a MapSource MDR file and then convert it by mkgmap to the device MDR or should we directly create the GPS device MDRs? What do you think?
Steve Hosgood.
WanMil
Wanmil,
This should IMHO be the overall goal of the whole mkgmap project. Agreed!
NOT AGREED. At least not completely! You should take into consideration the user's necessity to visually select tile subsets for an interesting region. You would also have to clone and engineer the visual tile selection facility of Mapsource if you go GPS only with mkgmap. No GPS device in the foreseeable future will have so much memory that you can have the complete OSM Europe/World/.. map on a SDHC card. Not to mention the transfer times and handling difficulties for tons of *.img data ... I also think that Osmosis and the other existing splitting tools are no choice from the standpoint of usability today ... you're lacking the visual user interface to select an area of suitable tiles in an intuitive way. You can see on the OSM AiO download area where the gmapsupp approach leeds to. It workes as long as continents fit on a 4GB card ... ftp://ftp5.gwdg.de/pub/misc/openstreetmap/download.openstreetmap.de/aio/regions-europe/ Downloads for "Aachen, Wien, Alpen, Alsace, EU4G, CH-D-F, ..." Where should it end? And more important: what is missing??
The main work is to get the toolchain running: 1. Create a map with 2 small tiles using splitter and mkgmap 2. Install the map in MapSource 3. Create an environment so that it is easily possible to work with the display project Once that has been done the work can start.
The described toolchain and concentrating on small samples is essential for all reverse engineering regarding the garmin format. If we get this easy and understandable, I'd be able to spent more time on testing and trying. At the moment I'm lost with eclipse, java and svn ... ;-(
It would be helpful if someone (not Steve - he's busy!) could get the documentation updated. I was doing my best on it before I got swamped last year. Not much has changed since then.
I liked the wiki documentation you updated, Wanmil! We should build on that and keep it updated ... BTW: I'm partially confused by the documentation in the svn repository. It seems to be partially outdated ... can we (can I?) move this to the wiki? Is it really needed in the svn repository? Peter
On 08/01/2011 10:09 PM, Peter Lerner wrote:
Wanmil,
This should IMHO be the overall goal of the whole mkgmap project. Agreed! NOT AGREED. At least not completely!
You should take into consideration the user's necessity to visually select tile subsets for an interesting region....
You are right, Peter. However, it is also true that these goals are independent of each other, and to some extent what you describe is a goal to be achieved by the splitter tools, not mkgmap itself. I suppose it is true that from the user's POV, the splitter and mkgmap should not be seen: what they want to do is select an area and select some map parameters (whatever) and press a button. The system spits out an .img file and they load it into their machine and use it. Job done! I was being specific just to the (invisible) "mkgmap" part of that process. It would indeed be good to launch a project to write what you, Peter, have described. ( There is a superb GTK widget called "osm-gps-map" which provides a scrollable OSM map in a panel ready for you to use to write a custom GUI application to do pretty much anything. ) Steve.
Steve,
This should IMHO be the overall goal of the whole mkgmap project. Agreed! NOT AGREED. At least not completely!
You should take into consideration the user's necessity to visually select tile subsets for an interesting region....
You are right, Peter. However, it is also true that these goals are independent of each other, and to some extent what you describe is a goal to be achieved by the splitter tools, not mkgmap itself.
The needed parts for the gmapsupp.img are determined *after* the users manual tile selection. The selected tiles define what goes in the GPS device index. So the "goals" can't be independent.
It would indeed be good to launch a project to write what you, Peter, have described. ( There is a superb GTK widget called "osm-gps-map" which provides a scrollable OSM map in a panel ready for you to use to write a custom GUI application to do pretty much anything. )
Fine, no problem with that. But the problem is that you loose functionality and flexibility. Workflow I: (1) create small tiles with local index information; it doesn't matter how they are split, assumed they are "small" (2) user can manually select tiles for specific region (3) Mapsources combines all tiles index information into a global MDR17 index for use on a GPS device Workflow II: (1) let user define region of interest via JOSM download (limited size) or rely on available datasources (geofabrik, limited choice) (2) split, use mkgmap and upload to GPS device with global MDR17 index all in one step In either workflow you need to know the secrets of the MDR17. In workflow II you loose functionality. If it's an *option* in mkgmap to create a global index, MDR17, ... I have no problem with that. But it shouldn't be the "overall goal of the whole mkgmap project". Currently we have Mapsource .... IMHO there are some other OSM/mkgmap issues to solve first ... That's the reasoning for my "not completely agreed" to the above mentioned definition of an overall project goal. Peter
On 08/01/2011 08:58 PM, WanMil wrote:
I made a partial start on this last year. Steve supplied me with a pair of maps as described above: one straight from mkgmap and one after MapSource had been at it. Unfortunately, I just ended up too busy at work to be able to put any work into it. So as Marco said, I too am "embarrassed at not having done that much recently" :-( Now I am embarrassed again - can't spell "Marko"! Sorry!
It would be helpful if someone (not Steve - he's busy!) could get the documentation updated. I was doing my best on it before I got swamped last year. Not much has changed since then. That's quite important although it's very much work to sort out the format from the source code and from the display outputs.
It's true - irritatingly for me, most of Steve's old "format deciphering" tools were written in Java, which isn't a language I'm very familiar with. A proper update of the wiki would now require a read through the source code of mkgmap. Which is also written in £$µ%##&* Java!
The trouble is that it *seems* as if the header "flags" bytes in the MDR file tell the parser which options to expect on the matching data table. We don't know exactly what the flags are saying. I am not sure if the MDR description in the wiki is enough for development work. During development you need a lot of "maybe" variants where you can just guess parameters. We should find a common markup for such variants in the wiki.
I tried, but I was never happy with the way it came out. Even though I changed the format several times to try and make it more readable (use of wikitables etc). Feel free to try your own changes..
It's possible that MapSource makes changes to the other subfiles in the .img - I don't remember what I saw of that (if anything) last year. I haven't seen that so far. But MapSource creates a new .md2 file that does not have the common img format.
That's news. I never noticed that last year.
From my point of view we should start with a better understanding and description of the MDR17 section. It's a section which is created by MapSource and has a tricky but manageable format.
The existing wiki entries on MDR17 were I think done by me, based entirely on what I saw in the Garmin NT maps for the UK that came with my Streetpilot. Tricky indeed, but critical in getting street searching (and I think PostCode searching) to work. I only got some of the way into it.
Then start to code a simple MDR17 for small maps and the changes to other MDR sections for quite small maps (max 2 tiles,< 100 street names,< 10 cities, one country). Once we have a small map running we might be better able to expand the map size and the changes to the MDR sections.# You'll probably have to use MapSource to generate an MDR17 section for a small, well-known map. I'd start with just a single village, generate the maps, then add one new streetname, generate the maps again, compare.
Currently, my knowledge of MDR17 (see wiki) is nowhere near good enough to be able to create a working MDR17.
I am not sure at the moment if we should create a MapSource MDR file and then convert it by mkgmap to the device MDR or should we directly create the GPS device MDRs? What do you think?
Directly create the device MDRs for certain. Whilst you're inside mkgmap you have all the info you need. To try and do it later, you'll need to decode all the LBL subfiles and other stuff first. Better to do it all with the raw data. Steve
On Sun, Jul 31, 2011 at 12:37:46PM +0200, WanMil wrote:
On Sat, Jul 30, 2011 at 02:41:42PM +0200, WanMil wrote:
I have created a short HowTo in the wiki for first time users: http://wiki.openstreetmap.org/wiki/Mkgmap/How_to_create_a_map [...] I want to keep the article as short as possible because it should be a first "HowTo" without too much information overhead.
Another thing that I think would be nice to explain is why the precompiled bounds are needed and what happens when they are not provided (mkgmap seems to run just fine). I compiled Geofabrik's finland.osm.pbf using mkgmap r2012, using my normal workflow (no --index, no MapSource, just copy the gmapsupp.img to the Edge 705). It seemed to go fine, with one exception: a few streets that I tried to search for in my Edge 705 were displayed to be in Nurmijärvi (post code 01900), even though the correct area is Vantaa. Before the location branch was merged, the Edge 705 would display as "city" name the name of the closest place=* node, and no post code (because none is given for place=* nodes in Finland). I cannot see anything obviously wrong in the source data, other than the boundary relations in Finland do not have role names. I loaded the boundaries in JOSM like this: osmosis --rb finland.osm.pbf --tf accept-relations \ boundary=administrative --used-way --used-node --wx finland-boundary.osm josm finland-boundary.osm Vantaa and Nurmijärvi have common border (http://www.openstreetmap.org/browse/way/27487479) but the streets I searched for where far away (to the east) from the border. Both relations are at admin_level=8, but one way (30075154) belonging to the Vantaa border carries admin_level=6 instead of admin_level=8. Similarly, way 27481199 of the Nurmijärvi border is admin_level=7. Best regards, Marko
On Sun, Jul 31, 2011 at 12:37:46PM +0200, WanMil wrote:
On Sat, Jul 30, 2011 at 02:41:42PM +0200, WanMil wrote:
I have created a short HowTo in the wiki for first time users: http://wiki.openstreetmap.org/wiki/Mkgmap/How_to_create_a_map [...] I want to keep the article as short as possible because it should be a first "HowTo" without too much information overhead.
Another thing that I think would be nice to explain is why the precompiled bounds are needed and what happens when they are not provided (mkgmap seems to run just fine).
Two things come to my mind: 1. Should the error message that no precompiled bounds are applied be more visible (put to System error instead of the logfile)? 2. The "How to" in the wiki shall be a short first how to. So no deeper explanation why something works or why something doesn't work. It's just a how to for your first map. But of course such things might and should be explained better than they are at the moment on one of the other pages. Feel free to change the wiki!
I compiled Geofabrik's finland.osm.pbf using mkgmap r2012, using my normal workflow (no --index, no MapSource, just copy the gmapsupp.img to the Edge 705). It seemed to go fine, with one exception: a few streets that I tried to search for in my Edge 705 were displayed to be in Nurmijärvi (post code 01900), even though the correct area is Vantaa. Before the location branch was merged, the Edge 705 would display as "city" name the name of the closest place=* node, and no post code (because none is given for place=* nodes in Finland).
Can you search for streets without using the --index option? Is that a special of the Edge 705?
I cannot see anything obviously wrong in the source data, other than the boundary relations in Finland do not have role names. I loaded the boundaries in JOSM like this:
osmosis --rb finland.osm.pbf --tf accept-relations \ boundary=administrative --used-way --used-node --wx finland-boundary.osm josm finland-boundary.osm
Vantaa and Nurmijärvi have common border (http://www.openstreetmap.org/browse/way/27487479) but the streets I searched for where far away (to the east) from the border. Both relations are at admin_level=8, but one way (30075154) belonging to the Vantaa border carries admin_level=6 instead of admin_level=8. Similarly, way 27481199 of the Nurmijärvi border is admin_level=7.
Best regards,
Marko
WanMil
On Sun, Aug 07, 2011 at 10:03:09PM +0200, WanMil wrote:
Two things come to my mind: 1. Should the error message that no precompiled bounds are applied be more visible (put to System error instead of the logfile)?
Perhaps. I did see the message in the log today, after trying with --index. Without --index, no message is issued, but the maps are broken, as far as the Edge 705 and presumably similar models, such as the GPSMap 60CSx are concerned.
2. The "How to" in the wiki shall be a short first how to. So no deeper explanation why something works or why something doesn't work.
Sure. I was looking for an explanation for myself too. :-)
Can you search for streets without using the --index option? Is that a special of the Edge 705?
Yes. It used to work fine until the locator branch was merged. The menu would allow me to search for all streets from the current tile or close to the current location. How do I know? There are quite a few Kisatie in Finland, but the menu would list only a few of them. If I put the Edge 705 to the basement for some time so that it would allow me to set the location, and I faked the location to elsewhere, I would see a different bunch of results. The results were good but not perfect, because the "city" name usually was a suburb, sometimes a neighbouring suburb. I believe that the "city" info came from the closest place=* node. With the locator branch and without --index, the gmapsupp.img produced by mkgmap seems to claim that every street belongs to Nurmijärvi, zip code 01900. I did not try to fake the location to see other tiles. I did not successfully try --index yet, because I am a little hesitant to play with MapSource on my Linux system. Could we have the previous behaviour of runs without --index back, please? Best regards, Marko
On 07/30/11 15:41, WanMil wrote:
Hi,
I have created a short HowTo in the wiki for first time users: http://wiki.openstreetmap.org/wiki/Mkgmap/How_to_create_a_map
I think that's a good thing for first time users because the other wiki pages contain a bit too much information if you are using mkgmap for the first time.
Please have a look on it if I have forgotten something or if something is wrong.
heya. i think this is a wonderful idea - a beginner-friendly page might be very useful, because it took me quite some time to figure out several things - mkgmap wiki pages (and other resources) have lots of contradicting, outdated or just missing information. a few suggestions regarding newbie page. note that i don't claim that "somebody should do something about it", i offer to do this ;) didn't want to rush in and just start to mess up things. if there are no objections, i could slowly change wiki pages in this direction. 1. i believe it should only list most important, simple steps - thus i'd remove 'tile splitter' from main requirements list and only list it when talking about splitting data; 2. i personally have been using osmosis to cut out regions, especially if i'm just going to visit one city - no need to build extra tiles, smaller dataset. if that is deemed to be useful, it could be linked to from mkgmap beginner page; 3. i'd move address search to a separate page and link to it from the beginner's intro - have a section "further reading" or so (and as such, nuke --nsis option from the default suggested ones); 4. on the beginners page, all used options should be explained - what they do and, especially, why would one use them. one of my biggest sources of frustration with mkgmap was inability to figure out what options do or what options to use for some functionality 4.1. --tdbfile ok, this is a quite wonderful one - especially if we look at the help output of it :D Write a .tdb file. i've used mkgmap to generate maps for various regions a few hundred times by now. i have never used this option and i have no idea what it does (help wasn't very... helpful). is it really useful for newbies ? and, not directly related to newbie guide - it might be useful to add some description on what that file is and why would one want it to the help output ;) (http://wiki.openstreetmap.org/wiki/Mkgmap didn't provide much more information either) 4.2. --route - is this still experimental, as --help suggests ? side note : a newcomer might be put off by the fact that it's not listed in http://wiki.openstreetmap.org/wiki/Mkgmap at all - maybe it would be better to keep cli options on a separate page (would make main page also readable). and also maybe just regenerate cli option page from --help=options output every now and then so that two sets of options won't have to be maintained ? 4.3. --remove-short-arcs : again, not listed in the main page at all. help output has something on that option, but for beginners, it might be helpful to explain what short arcs are, what might be consequences. on a more general note, what's a suggestion regarding this option, should it be used with some non-zero value ? also, what actually are "zero-length arcs" ? if i don't specify this option at all, would they be kept ? if so, why not remove them by default ? 4.4. --add-pois-to-areas : i suggested adding this one, so i could try to document it as best as i could :) 4.5. --gmapsupp - what happens if i don't specify this option ? i seem to get img just fine anyway
Thanks! WanMil -- Rich
heya. i think this is a wonderful idea - a beginner-friendly page might be very useful, because it took me quite some time to figure out several things - mkgmap wiki pages (and other resources) have lots of contradicting, outdated or just missing information. a few suggestions regarding newbie page.
note that i don't claim that "somebody should do something about it", i offer to do this ;) didn't want to rush in and just start to mess up things. if there are no objections, i could slowly change wiki pages in this direction.
That's great! By the way: this is a wiki, so anybody should do changes if one thinks they are good.
1. i believe it should only list most important, simple steps - thus i'd remove 'tile splitter' from main requirements list and only list it when talking about splitting data;
Yes, it should contain the most important simple steps. And therefore splitter should remain there. Usually if you start with mkgmap you don't download data and split it yourself. And most downloads are bigger than one tile, so you have to split the data.
2. i personally have been using osmosis to cut out regions, especially if i'm just going to visit one city - no need to build extra tiles, smaller dataset. if that is deemed to be useful, it could be linked to from mkgmap beginner page;
I would call that advanced usage if you use osmosis to cut out such small areas that fit into one tile. You need to know the osmosis parameters (which is definetly complicated) and you must know that your area must be small enough to fit into one tile. For the tile splitter you just have to download it and start it without any special parameters. Quite easy, isn't it?
3. i'd move address search to a separate page and link to it from the beginner's intro - have a section "further reading" or so (and as such, nuke --nsis option from the default suggested ones);
I agree to move that to a separate page. I would not nuke the --nsis option from the address search parameters. Otherwise you have to explain in detail how the generated map can be installed in MapSource. With --nsis you just have to say: Use the .nsis script to create an executable map setup and run that.
4. on the beginners page, all used options should be explained - what they do and, especially, why would one use them. one of my biggest sources of frustration with mkgmap was inability to figure out what options do or what options to use for some functionality
I do not aggree. Don't explain the options on the beginners page. This is a short "How-To" and therefore I would leave it as short as possible. But it would be great if you can add links to the pages with more detailed explanations for all options. Then you don't have to search for them.
4.1. --tdbfile ok, this is a quite wonderful one - especially if we look at the help output of it :D Write a .tdb file. i've used mkgmap to generate maps for various regions a few hundred times by now. i have never used this option and i have no idea what it does (help wasn't very... helpful). is it really useful for newbies ?
I don't know too. I thought it would be necessary but don't know why it is needed or why not.
and, not directly related to newbie guide - it might be useful to add some description on what that file is and why would one want it to the help output ;) (http://wiki.openstreetmap.org/wiki/Mkgmap didn't provide much more information either)
4.2. --route - is this still experimental, as --help suggests ? side note : a newcomer might be put off by the fact that it's not listed in http://wiki.openstreetmap.org/wiki/Mkgmap at all - maybe it would be better to keep cli options on a separate page (would make main page also readable). and also maybe just regenerate cli option page from --help=options output every now and then so that two sets of options won't have to be maintained ?
Fully agree! Throw away all option descriptions from the main mkgmap page and move them to one or more separate pages where we can do links to. If you improve some descriptions for options I will also be happy to commit them the mkgmap help file which is available with --help.
4.3. --remove-short-arcs : again, not listed in the main page at all. help output has something on that option, but for beginners, it might be helpful to explain what short arcs are, what might be consequences. on a more general note, what's a suggestion regarding this option, should it be used with some non-zero value ? also, what actually are "zero-length arcs" ? if i don't specify this option at all, would they be kept ? if so, why not remove them by default ?
Fully agree! Don't know about a good default value but I usually use the --remove-short-arcs without any special value set-
4.4. --add-pois-to-areas : i suggested adding this one, so i could try to document it as best as i could :) 4.5. --gmapsupp - what happens if i don't specify this option ? i seem to get img just fine anyway
Ok, as I wrote before: I vote for having the following structure: http://wiki.openstreetmap.org/wiki/Mkgmap: No option descriptions. Just an overall description what mkgmap does and some important links: - Download - How to - Options - Styles - Contact (Mailing list etc.) How to: Just as it is. A short list of steps you have to perform to build your first routable map. Most steps should have links to further information. How to address search: Move the list of steps to create a address searchable map to the new page with links to further information. Options: Descriptions for all options. Maybe with a good grouping and maybe more than one page. Styles: Description how the style system works and what one can do with it. Contact: The common links to mkgmap relevant pages and the mailing list Go ahead!! Thanks! WanMil
On 2011-07-30 13:41, WanMil wrote:
Hi,
I have created a short HowTo in the wiki for first time users: http://wiki.openstreetmap.org/wiki/Mkgmap/How_to_create_a_map
A suggestion for an addition to this page: Please put in details of how to get MapSource to install at all! I tried to install 6.16.3 on my Vista box, but all I got was a message "Previous MapSource not found! Setup will terminate". Which it did! Leaving me with no MapSource. I'm eager to have a play with it in order to get the address-search stuff working (and maybe to find out how to do that independently) but obviously I need a usable MapSource in the first place. Any ideas please? Steve
On 16 Nov 2011, at 14:42, Steve Hosgood <steve@stoneship.org.uk> wrote:
On 2011-07-30 13:41, WanMil wrote:
Hi,
I have created a short HowTo in the wiki for first time users: http://wiki.openstreetmap.org/wiki/Mkgmap/How_to_create_a_map
A suggestion for an addition to this page:
Please put in details of how to get MapSource to install at all! I tried to install 6.16.3 on my Vista box, but all I got was a message "Previous MapSource not found! Setup will terminate".
Which it did! Leaving me with no MapSource. I'm eager to have a play with it in order to get the address-search stuff working (and maybe to find out how to do that independently) but obviously I need a usable MapSource in the first place.
Any ideas please? Steve
_______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
I just reinstalled windows from scratch and had the same problem. The solution is to install the version of mapsource or trip and waypoint manager that came on a cd with your gps, then update mapsource to the newest version.
This page should help: http://www.raymond.cc/blog/archives/2009/03/29/download-mapsource-from-garmi... The short version: - get Universal Extractor (http://legroom.net/software/uniextract) - use universal extractor to extract all files from MapSource update installer (7Zip may work also) - run Main.msi first! - run Setup.msi, later. This bypasses the previous version check. I own two Garmin Quest devices (2004 was a good year) and this saved me the hassle of digging up the CDs. Nuno. On 16 November 2011 10:52, Minko <ligfietser@online.nl> wrote:
Install Basecamp first and then Mapsource? _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
On 2011-11-16 11:03, Nuno Pedrosa wrote:
This page should help:
http://www.raymond.cc/blog/archives/2009/03/29/download-mapsource-from-garmi...
The short version: - get Universal Extractor (http://legroom.net/software/uniextract) - use universal extractor to extract all files from MapSource update installer (7Zip may work also) - run Main.msi first! - run Setup.msi, later.
This bypasses the previous version check. I own two Garmin Quest devices (2004 was a good year) and this saved me the hassle of digging up the CDs.
Excellent - that worked (just the "short version" of the instructions above was plenty enough). Thank you Nuno. Now - can this be added to the "Short HowTo" wiki page please? Steve
Sure! I can add it. Could you just let me know where it is? :) Nuno. On 16 November 2011 12:10, Steve Hosgood <steve@stoneship.org.uk> wrote:
On 2011-11-16 11:03, Nuno Pedrosa wrote:
This page should help:
http://www.raymond.cc/blog/archives/2009/03/29/download-mapsource-from-garmi...
The short version: - get Universal Extractor (http://legroom.net/software/uniextract) - use universal extractor to extract all files from MapSource update installer (7Zip may work also) - run Main.msi first! - run Setup.msi, later.
This bypasses the previous version check. I own two Garmin Quest devices (2004 was a good year) and this saved me the hassle of digging up the CDs.
Excellent - that worked (just the "short version" of the instructions above was plenty enough). Thank you Nuno.
Now - can this be added to the "Short HowTo" wiki page please? Steve
_______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Hi, I'm new to this lists but with osm for quite some time. I'd really like to contribute to improving the wiki pages about mkgmap (being a user, not a developer - but that isn't necessarily all bad from my point of view as long as the developers are willing to help with questions users can't answer). I think the new how-to page describing simple usage is a good idea. After some thinking, it is probably a good idea as well to start using the splitter right away rather than creating a very small map that does not require to split the data. The latter would be even simpler but most people likely would want to create larger maps. Suggestions: The main page (http://wiki.openstreetmap.org/wiki/Mkgmap) seems a little overcrowded and misleading ("The goal of the project is to take OpenStreetMap data and put it on my Garmin Legend Cx"). I'd expect a description here, maybe links to alternatives for those who are looking for something else (prebuilt maps or a graphical interface). Also, it would probably be easier to link to the download page (http://www.mkgmap.org.uk/snapshots/) than trying to keep the version number of the latest stable up to date. The link list seems a good idea, but I would move it to be the last topic in the help section rather. The options page (http://wiki.openstreetmap.org/wiki/Mkgmap/help/usage - should be renamed if possible?) does not need the paragraph on creating a map anymore as the new how-to page covers that. Instead, all available option should be explained. Charlie Ferrero has put together quite a lot of information on his page which he might be willing to share (Charlie, you are probably reading the list?). If we are not able to put together (and maintain) something that is similarly detailed, I would rather link to his page. Then, the troubleshooting section might become a page of its own, also explaining errors and warning messages. E.g. the message "area too small to split" just left me scratching my head when it was thrown, and I'm still not sure how to identify the objects that trigger it (or if I need to track this down at all). Ok, a question at last: any objections against these suggestions? I would like to start contributing but would not want this to be perceived as vandalism. Best regards, g0ldfish -- View this message in context: http://gis.638310.n2.nabble.com/Short-mkgmap-HowTo-tp6636149p7004211.html Sent from the Mkgmap Development mailing list archive at Nabble.com.
Hi,
I'm new to this lists but with osm for quite some time.
Welcome!
I'd really like to contribute to improving the wiki pages about mkgmap (being a user, not a developer - but that isn't necessarily all bad from my point of view as long as the developers are willing to help with questions users can't answer).
Great! There's much improvement possible.
I think the new how-to page describing simple usage is a good idea. After some thinking, it is probably a good idea as well to start using the splitter right away rather than creating a very small map that does not require to split the data. The latter would be even simpler but most people likely would want to create larger maps.
Suggestions:
The main page (http://wiki.openstreetmap.org/wiki/Mkgmap) seems a little overcrowded and misleading ("The goal of the project is to take OpenStreetMap data and put it on my Garmin Legend Cx"). I'd expect a description here, maybe links to alternatives for those who are looking for something else (prebuilt maps or a graphical interface). Also, it would probably be easier to link to the download page (http://www.mkgmap.org.uk/snapshots/) than trying to keep the version number of the latest stable up to date. The link list seems a good idea, but I would move it to be the last topic in the help section rather.
The options page (http://wiki.openstreetmap.org/wiki/Mkgmap/help/usage - should be renamed if possible?) does not need the paragraph on creating a map anymore as the new how-to page covers that. Instead, all available option should be explained. Charlie Ferrero has put together quite a lot of information on his page which he might be willing to share (Charlie, you are probably reading the list?). If we are not able to put together (and maintain) something that is similarly detailed, I would rather link to his page.
That's ok for me. Maybe it's worth to check if Charlie has added some good descriptions and merge them back to the help texts included in the mkgmap distribution.
Then, the troubleshooting section might become a page of its own, also explaining errors and warning messages. E.g. the message "area too small to split" just left me scratching my head when it was thrown, and I'm still not sure how to identify the objects that trigger it (or if I need to track this down at all).
Ok, a question at last: any objections against these suggestions? I would like to start contributing but would not want this to be perceived as vandalism.
Go ahead! From my point of view it's time to restructure the mkgmap page as you described. All in all it is a wiki so don't by too shy to change things. If someone dislikes your changes one can post comments or improve it directly in the wiki. Thanks a lot in advance for your help! Have fun! WanMil
Best regards, g0ldfish
The main page (http://wiki.openstreetmap.org/wiki/Mkgmap) seems a little overcrowded and misleading ("The goal of the project is to take OpenStreetMap data and put it on my Garmin Legend Cx"). I'd expect a
Can't believe I wrote that! I hate it when projects say what their goal is rather than what they are. Anyway that was a long time ago and I've no objection to you removing any of that old stuff. Your ideas of the changes to make seem good to me. In particular the downloading section has proved to be difficult to keep up to date, especially across the different languages, so should be reformed in the way you suggest. I'd like to add my add my support to Charlie Ferrero's help pages. The arguments file at http://www.cferrero.net/maps/downloads/options_GCC_GPS.args is a great example of how a complete map creation project can be handled. ..Steve
On Fri, Nov 18, 2011 at 12:03:38AM +0000, Steve Ratcliffe wrote:
The main page (http://wiki.openstreetmap.org/wiki/Mkgmap) seems a little overcrowded and misleading ("The goal of the project is to take OpenStreetMap data and put it on my Garmin Legend Cx").
Can't believe I wrote that! I hate it when projects say what their goal is rather than what they are.
Hey, you never know how big the project is going to be. This reminds me of another one that began with a humble announcement (see http://liw.fi/linux20/). Back on topic: Should we have some sort of a bug tracking system? Even a list of the important bugs would do. When a bug is fixed, it would be moved to another list that specifies the svn revision of the fix. There are bug tracking systems, such as Trac and Mantis, but running those might be more trouble than it is worth. After all, mkgmap is of more manageable size than JOSM, for example. Marko
Hi
Hey, you never know how big the project is going to be. This reminds me of another one that began with a humble announcement (see http://liw.fi/linux20/).
Thanks, that was a pretty interesting article!
Back on topic: Should we have some sort of a bug tracking system? Even a list of the important bugs would do. When a bug is fixed, it would be moved to another list that specifies the svn revision of the fix. There
Yes, we can try that. I kind of like the idea that bugs go to the mailing list first, at least while the project is small enough for that to be reasonable. Still, something that we don't do very well is showing progress that has been made and this could help a lot with that. ..Steve
On Mon, Nov 21, 2011 at 10:23:25PM +0000, Steve Ratcliffe wrote:
I kind of like the idea that bugs go to the mailing list first, at least while the project is small enough for that to be reasonable.
Still, something that we don't do very well is showing progress that has been made and this could help a lot with that.
I think that the mailing list is OK for simple bugs that can be fixed quickly. For things that involve a nontrivial amount of coding or reverse-engineering, it could be useful to have a bug tracker or even a wiki page where users and developers would have an overview of the status and could post results of their tests. I guess it could be as simple as someone creating a page on wiki.openstreetmap.org and posting the link here. For example, the routing test map would naturally belong to a new wiki page on broken routing restrictions on newer Garmin software and firmware. Marko
I guess it could be as simple as someone creating a page on wiki.openstreetmap.org and posting the link here. For example, the routing test map would naturally belong to a new wiki page on broken routing restrictions on newer Garmin software and firmware.
A wiki page is a good thing for some (limited) time, but the more reports aggregate there the less helpful it seems (see http://wiki.openstreetmap.org/wiki/Talk:Mkgmap which is still one of the recommended ways to report issues). From my point the benefit in setting up a ticket system is that information is structured and therefore can be filtered according to the given needs. Thus, instead of manually cleaning up and removing solved issues we could rather not show them by default but still have them available for reference. -- View this message in context: http://gis.638310.n2.nabble.com/Short-mkgmap-HowTo-tp6636149p7019875.html Sent from the Mkgmap Development mailing list archive at Nabble.com.
participants (11)
-
Charlie Ferrero -
g0ldfish -
Marko Mäkelä -
Minko -
Nuno Pedrosa -
Peter Lerner -
Rich -
Steve Hosgood -
Steve Hosgood -
Steve Ratcliffe -
WanMil