
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