[mkgmap-dev] address index question

Thu Nov 29 12:14:22 GMT 2012

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 at 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