i'm shifting from a consumer of Dave Hansen's roll ups of the Lambertus maps to generating specific maps on my own with mkgmap. the first one i generated looks good, but i'm trying to sort out correct population of the address index. i downloaded an extract from osm via xapi, and ran mkgmap with these parameters: $ java -jar ../mkgmap/mkgmap-r2379/mkgmap.jar capitaldistrict-2012-11-23.osm --index --gmapsupp i got a bunch of errors which look like complaints about malformed data in osm, which i'll go look at and clean up later (an example: SEVERE (RoadNetwork): capitaldistrict-2012-11-23.osm: Road (South Lake Avenue, http://www.openstreetmap.org/browse/way/5579946) contains zero length arc at http://www.openstreetmap.org/?mlat=42.65485&mlon=-73.78075&zoom=17) i installed the map on my nuvi 255w. the map looks good, although i haven't gone out and tried to route with it yet. my main interest right now is getting a properly populated address index, and it doesn't seem to have one. i went back and reviewed the .osm file and verified that there are POIs in it with what appear to be properly populated addr: fields. are there any specific requirements for OSM data to get the address index populated properly? admin_boundary data perhaps? (this would be an issue in the US where address data doesn't usually match up well with admin_boundaries.) thanks, richard
El 24/11/12 03:08, Richard Welty escribió:
i'm shifting from a consumer of Dave Hansen's roll ups of the Lambertus maps to generating specific maps on my own with mkgmap. the first one i generated looks good, but i'm trying to sort out correct population of the address index.
i downloaded an extract from osm via xapi, and ran mkgmap with these parameters:
$ java -jar ../mkgmap/mkgmap-r2379/mkgmap.jar capitaldistrict-2012-11-23.osm --index --gmapsupp
From mkgmap help: "Note that option order is significant: An option only applies to subsequent input files." So you should put your *.osm file last in the mkgmap call
i got a bunch of errors which look like complaints about malformed data in osm, which i'll go look at and clean up later (an example: SEVERE (RoadNetwork): capitaldistrict-2012-11-23.osm: Road (South Lake Avenue, http://www.openstreetmap.org/browse/way/5579946) contains zero length arc at http://www.openstreetmap.org/?mlat=42.65485&mlon=-73.78075&zoom=17)
You can get rid of those errors using --remove-short-arcs
i installed the map on my nuvi 255w. the map looks good, although i haven't gone out and tried to route with it yet. my main interest right now is getting a properly populated address index, and it doesn't seem to have one.
i went back and reviewed the .osm file and verified that there are POIs in it with what appear to be properly populated addr: fields.
are there any specific requirements for OSM data to get the address index populated properly? admin_boundary data perhaps? (this would be an issue in the US where address data doesn't usually match up well with admin_boundaries.) You can use pre-compiled boundaries from [1] giving the --bounds option. Also --location-autofill is useful for addresses to be populated. Have a look at mkgmap options for more info about their use.
On 11/24/12 10:07 AM, Carlos Dávila wrote:
El 24/11/12 03:08, Richard Welty escribió:
$ java -jar ../mkgmap/mkgmap-r2379/mkgmap.jar capitaldistrict-2012-11-23.osm --index --gmapsupp
From mkgmap help: "Note that option order is significant: An option only applies to subsequent input files." So you should put your *.osm file last in the mkgmap call ah, i missed that. the change seems to have done it, address lookups in the nuvi now work.
thanks, richard
Richard Welty <rwelty@averillpark.net> writes:
On 11/24/12 10:07 AM, Carlos Dávila wrote:
El 24/11/12 03:08, Richard Welty escribió:
$ java -jar ../mkgmap/mkgmap-r2379/mkgmap.jar capitaldistrict-2012-11-23.osm --index --gmapsupp
From mkgmap help: "Note that option order is significant: An option only applies to subsequent input files." So you should put your *.osm file last in the mkgmap call ah, i missed that. the change seems to have done it, address lookups in the nuvi now work.
There's something else that I think is highly non-obvious to new people: there are a ton of options (no surprise), but the defaults are not really useful. The norm among mkgmap users is to give a large number of options, but for some reason (perhaps trying to keep behavior consistent) these options are not default. In the --remove-short-arcs case, I don't understand why anyone wouldn't want it. Another point is that you probably want --route in addition to --index. FWIW, here are the options I use that I suspect everyone should use (or mine are off from the consensus and I should change): --tdbfile \ --reduce-point-density=4 \ --reduce-point-density-polygon=8 \ --merge-lines \ --route \ --check-roundabouts \ --check-roundabout-flares \ --remove-short-arcs=6 \ --adjust-turn-headings \ --report-similar-arcs \ --report-dead-ends=2 \ --add-pois-to-areas \ --index \ (Actually, "everyone should use add-pois-to-areas" is perhaps controversial.) I think it would be good for all options to have a --no-option variant, and then to default each option to what the group consensus is in terms of "what should a user (who doesn't really understand all the subtleties yet) who just wants to take OSM bits and make a map for their device for general use want".
Hi
There's something else that I think is highly non-obvious to new people: there are a ton of options (no surprise), but the defaults are not really useful. The norm among mkgmap users is to give a large number of options, but for some reason (perhaps trying to keep behavior consistent) these options are not default. In the --remove-short-arcs case, I don't understand why anyone wouldn't want it.
I do agree that there are far too many options and I did start work on dealing with this a while back. But I suspect that while everyone might say that things are confusing there is not all that much consensus on actually removing any option. But I will try again, this time working in smaller chunks. The very first thing is to implement (and it is done or mostly done already) is to have --no-option versions of any option, because without that we can't really change any defaults. To start we should classify every option according to why it exists. I'll suggest the following list of reasons to start with. 1. options that are basically --make-it-work (and 1b --make-it-fail!) 2. workarounds because the automatic algorithm fails in some cases. 3. matters of taste and style. 4. add information to the map (eg --family-id) 5. select what is created 6. control operations with a large performance impact (time or memory) 7. control warnings about the input osm file 8. modify the map (eg make cycleways) 9. obsolete options 10. supports some random thing that someone wanted to do once 11. selecting input files The I think every option should have two questions asked of it: - Why and when would you want to set this - Why and when would you not want to set this Then remove it or change the default as appropriate. For several options I have no idea what the answers are.
Another point is that you probably want --route in addition to --index.
Yes I agree.
FWIW, here are the options I use that I suspect everyone should use (or mine are off from the consensus and I should change):
OK I will classify these by way of example and do the whole list in the next few days.
--tdbfile \
Reason 5. I think it should be the default and option removed.
--reduce-point-density=4 \ --reduce-point-density-polygon=8 \
Reason 3. Although if 4 is really the recommended value it should be the default value. Likewise 8 for polygons.
--merge-lines \
I think this is 1 and 2, (perhaps some of 6?). We should always merge lines if we can without breaking anything, but I think the current way isn't ideal doesn't always work? (not sure).
--route \
Probably should be default now.
--check-roundabouts \
R 1 (and 7?) just do it and remove option.
--check-roundabout-flares \
R-7?
--remove-short-arcs=6 \
Already defaulted and should be removed.
--adjust-turn-headings \
R 1 its just part of making routing work well?
--report-similar-arcs \ --report-dead-ends=2 \
R 7 should just be one warnings/report flag: --warnings=similar-arcs,dead-ends,etc
--add-pois-to-areas \
R 8. But could be considered to be just making it work in the Garmin format. Are there any downsides?
--index \
5 and 6. I'd be inclined not to make it the default ..Steve
On 29.11.2012 12:57, Steve Ratcliffe wrote:
Hi
There's something else that I think is highly non-obvious to new people: there are a ton of options (no surprise), but the defaults are not really useful. The norm among mkgmap users is to give a large number of options, but for some reason (perhaps trying to keep behavior consistent) these options are not default. In the --remove-short-arcs case, I don't understand why anyone wouldn't want it. I do agree that there are far too many options and I did start work on dealing with this a while back. But I suspect that while everyone might say that things are confusing there is not all that much consensus on actually removing any option.
But I will try again, this time working in smaller chunks.
The very first thing is to implement (and it is done or mostly done already) is to have --no-option versions of any option, because without that we can't really change any defaults.
To start we should classify every option according to why it exists. I'll suggest the following list of reasons to start with.
1. options that are basically --make-it-work (and 1b --make-it-fail!) 2. workarounds because the automatic algorithm fails in some cases. 3. matters of taste and style. 4. add information to the map (eg --family-id) 5. select what is created 6. control operations with a large performance impact (time or memory) 7. control warnings about the input osm file 8. modify the map (eg make cycleways) make cycleways should be obsoleted and removed. That was mentioned several times already. Continue and Continue with_actions are much better to achieve opposite cycleways and their like (even more as the option opposite-cycleways doesn't work on Basecamp >=3, nor on any newer Garmin GPS device anymore) 9. obsolete options 10. supports some random thing that someone wanted to do once 11. selecting input files
The I think every option should have two questions asked of it: - Why and when would you want to set this - Why and when would you not want to set this Then remove it or change the default as appropriate.
For several options I have no idea what the answers are.
Another point is that you probably want --route in addition to --index. Yes I agree.
FWIW, here are the options I use that I suspect everyone should use (or mine are off from the consensus and I should change): OK I will classify these by way of example and do the whole list in the next few days.
--tdbfile \
Reason 5. I think it should be the default and option removed.
--reduce-point-density=4 \ --reduce-point-density-polygon=8 \
Reason 3. Although if 4 is really the recommended value it should be the default value. Likewise 8 for polygons. Well I would say the Reason is not really taste or style, but on device performance. This option would be even better, if it had a steeper ramp up, on zooming out // lower resolutions.
--merge-lines \
I think this is 1 and 2, (perhaps some of 6?). We should always merge lines if we can without breaking anything, but I think the current way isn't ideal doesn't always work? (not sure).
--route \
Probably should be default now.
--check-roundabouts \
R 1 (and 7?) just do it and remove option. I don't use this option. If car routing ist not the focus, then it doesn't matter much. Same goes for check-roundabout-flares. So it it has performance impact, then please don't make it default.
--check-roundabout-flares \
R-7?
--remove-short-arcs=6 \
Already defaulted and should be removed. yip, and 6 ain't a good value. Either 5.6 (or 5.4?) or 2.8 I think, or what are the actual values being set (Garmin max resolution for autorouting being definitely not worse than 5.6m).
--adjust-turn-headings \
R 1 its just part of making routing work well?
--report-similar-arcs \ --report-dead-ends=2 \
R 7 should just be one warnings/report flag: --warnings=similar-arcs,dead-ends,etc Oh and please implement a mode, to get rid of not important warnings. I want to log if the whole tile breaks (mostly too high max-nodes on splitter), or anything other major. However stuff like: "Area to small to split" is not very important, and shouldn't be shown by default.
--add-pois-to-areas \
R 8. But could be considered to be just making it work in the Garmin format. Are there any downsides? Well it could lead to performance impact on the GPS device. For someone who doesn't need POI search, this option would be bad. I would say making it default, and allowing to switch it off would be better though.
--index \
5 and 6. I'd be inclined not to make it the default
..Steve _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://lists.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
-- keep on biking and discovering new trails Felix openmtbmap.org & www.velomap.org
Am 29.11.2012 13:14, schrieb Felix Hartmann:
--add-pois-to-areas \
R 8. But could be considered to be just making it work in the Garmin format. Are there any downsides? Well it could lead to performance impact on the GPS device. For someone who doesn't need POI search, this option would be bad. I would say making it default, and allowing to switch it off would be better though. In general I agree to you, but not in this case. If you wont create a POI-Index, then you also wont adress POI in your points-file and then no one of these created points where used for creating the map. I don't know how much performance it coast, but I think not so much. So turning this off wont be necessary.
As already mentioned in "Happy-Birthday"-Mail. For beginners it would be good to have only some options set and get a working map. Eg. --routing --address-index --poi-index --gampsupp --mapsource --style= --mapname=... data.osm and then mkgmap does everything, this seems to be necessary for this. All other options could be as is for experts. Henning
--check-roundabouts \
R 1 (and 7?) just do it and remove option. For the check options, I think there's a tradeoff between useful debugging and noise. So I wonder if by default there should be a file written (with a name derived from something) that has all the warnings, with each type having a unique first word, so one can grep out the ones one wants. Then they can perhaps just be on, maybe with a single option "--no-check" to skip the output. I don't see a lot of value in fine-grained warnings; getting the warnings that are the current consensus seems like the right thing, and I don't see a machine that is big enough to run mkgmap having trouble with the warnings file.
--add-pois-to-areas \
R 8. But could be considered to be just making it work in the Garmin format. Are there any downsides? The only downside is that if there is a node and an area, then you get two, but one could say that there are two in the source data, so that's ok. I think it belongs on, because otherwise POI-type things represented as areas vanish, index or not.
--index \
5 and 6. I'd be inclined not to make it the default I don't understand if the index code is stable enough, but I thought that generally people should want this. If that's off, though, it makes sense to default to off until such time as it's stable. Another usability comment is that I find the precompiled bounds situation a bit confusing. But maybe I haven't tried hard enough.
--index \
5 and 6. I'd be inclined not to make it the default
I don't understand if the index code is stable enough, but I thought that generally people should want this. If that's off, though, it makes sense to default to off until such time as it's stable.
Another usability comment is that I find the precompiled bounds situation a bit confusing. But maybe I haven't tried hard enough.
What do you think is confusing? Do you have a better idea? What do you expect and what do you think is useful? I would like to make it easier if possible. WanMil
i agree that the usage of pre-compiled bounds could be clearer, especially to "outsiders" who don't/can't read whole threads in the archives and distill their conclusions from there... How do I use mkgmap to make a perfectly up-to-date map, including a similarly up-to-date index? One "obvious" way is to simply use the downloaded pbf file, without pre-compiled bounds. The pre-compiled bounds which are available for download are updated rather infrequently, and I have been doing a lot of work on boundaries recently. Do I *have* to create my own bounds files from the downloaded PBF and then use them as "pre-compiled"? Is using "pre-compiled bounds" merely a performance enhancement, or is there a functional difference between the maps obtained with and without their usage? I can imagine similar questions arise about the use of pre-compiled sea. Colin On 02/12/2012 12:50, WanMil wrote:
> --index \ 5 and 6. I'd be inclined not to make it the default
I don't understand if the index code is stable enough, but I thought that generally people should want this. If that's off, though, it makes sense to default to off until such time as it's stable.
Another usability comment is that I find the precompiled bounds situation a bit confusing. But maybe I haven't tried hard enough.
What do you think is confusing? Do you have a better idea? What do you expect and what do you think is useful? I would like to make it easier if possible.
WanMil
_______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://lists.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Hi, take a look at http://wiki.openstreetmap.org/wiki/Mkgmap/help/options It wont be perfect, because it might not be written for beginners. If there are Ideas how to make mkgmap-wiki-pages more useful, be free. It's not really maintained and there is no clear structure. Henning
On 02/12/12 00:41, Greg Troxel wrote:
I don't understand if the index code is stable enough, but I thought that generally people should want this. If that's off, though, it makes sense to default to off until such time as it's stable.
Oh I think it is stable enough. Its just that I often run the index step separately, but perhaps no-one else does. It also uses enough memory to be a problem for smaller machines I think, although I did reduce the memory use a lot, so maybe it is not a problem. Anyway I could be convinced to make --index the default, its just my opinion. ..Steve
$ java -jar ../mkgmap/mkgmap-r2379/mkgmap.jar
capitaldistrict-2012-11-23.osm --index --gmapsupp
From mkgmap help: "Note that option order is significant: An option only applies to subsequent input files." So you should put your *.osm file last in the mkgmap call ah, i missed that. the change seems to have done it, address lookups in the nuvi now work.
Are you sure that made a difference? Although order matters it only matters to options that affect how the following files are compiled. Both --index and --gmapsupp are options that cause a file to be created at the very end and so it does not matter where they are placed. ..Steve
On 11/29/12 5:26 AM, Steve Ratcliffe wrote:
| ah, i missed that. the change seems to have done it, address lookups in | the nuvi now work. Are you sure that made a difference? Although order matters it only matters to options that affect how the following files are compiled. Both --index and --gmapsupp are options that cause a file to be created at the very end and so it does not matter where they are placed.
as far as i can recall, moving the input file to the end was the only change i made to the arguments. but i could be wrong. richard
On 29/11/12 11:47, Richard Welty wrote:
as far as i can recall, moving the input file to the end was the only change i made to the arguments. but i could be wrong.
OK. If there are any circumstances where changing the position of either --index or --gmapsupp makes a difference then it is a bug. Option processing isn't deliberately obscure ;) ..Steve
On 11/29/12 6:47 AM, Richard Welty wrote:
On 11/29/12 5:26 AM, Steve Ratcliffe wrote:
| ah, i missed that. the change seems to have done it, address lookups in | the nuvi now work. Are you sure that made a difference? Although order matters it only matters to options that affect how the following files are compiled. Both --index and --gmapsupp are options that cause a file to be created at the very end and so it does not matter where they are placed.
as far as i can recall, moving the input file to the end was the only change i made to the arguments. but i could be wrong.
i went through my shell history, and found the before & after. i see two other differences in the command line; i added --location-autofill and i indadvertantly included --add-pois-to-areas twice. both are below. i can try to reproduce this with simplified arguments if you like. richard ######## failed java -jar ../mkgmap/mkgmap-r2379/mkgmap.jar capitaldistrict-2012-11-23.osm \ --index \ --gmapsupp \ --remove-short-arcs \ --description="Emergency Response Map prototype" \ --add-pois-to-areas \ --route \ --family-id=787 \ --family-name="OSM ER 2012" \ --country-abbr="US" \ --country-name="United States" \ --region-abbr="NY" \ --region-name="New York" \ --link-pois-to-ways \ --road-name-pois \ --adjust-turn-headings \ --drive-on-right \ --check-roundabouts \ --check-roundabout-flares ######## succeeded java -enableassertions \ -Xmx2048m \ -jar ~/Projets/mkgmap/mkgmap-r2379/mkgmap.jar \ --index \ --gmapsupp \ --remove-short-arcs \ --description="Emergency Response Map prototype" \ --add-pois-to-areas \ --route \ --family-id=787 \ --family-name="OSM ER 2012" \ --country-abbr="US" \ --country-name="United States" \ --region-abbr="NY" \ --region-name="New York" \ --link-pois-to-ways \ --road-name-pois \ --adjust-turn-headings \ --drive-on-right \ --check-roundabouts \ --check-roundabout-flares \ --add-pois-to-areas \ --location-autofill \ capitaldistrict-2012-11-23.osm
On 29/11/12 12:19, Richard Welty wrote:
java -jar ../mkgmap/mkgmap-r2379/mkgmap.jar capitaldistrict-2012-11-23.osm \ --index \ --gmapsupp \ --remove-short-arcs \ --description="Emergency Response Map prototype" \ --add-pois-to-areas \ --route \ --family-id=787 \ --family-name="OSM ER 2012" \ --country-abbr="US" \ --country-name="United States" \ --region-abbr="NY" \ --region-name="New York" \ --link-pois-to-ways \ --road-name-pois \ --adjust-turn-headings \ --drive-on-right \ --check-roundabouts \ --check-roundabout-flares
Ah.. right, it will be one of the other options. They do apply to the individual tiles and so need to be before the tile they apply to. ..Steve
participants (8)
-
Carlos Dávila -
Colin Smale -
Felix Hartmann -
Greg Troxel -
Henning Scholland -
Richard Welty -
Steve Ratcliffe -
WanMil