[mkgmap-dev] Options overhaul

Fri Mar 25 19:57:15 GMT 2011

> Hi
>
> There is a new branch for an overhaul of the options. There are a
> number of recent (and not so recent!) posts about options that are
> badly documented, have the wrong defaults or just plain shouldn't
> exist.

That's great! I think we should invest some time on mkgmap 
documentation. Some pages of the osm-wiki should also rewritten or 
removed. Either the documentation is up to date or we should throw it away.

>
> The first couple of things I plan to do in preparation are:
>
> 1. Make it possible to negate any option by pre-pending it with 'no'
> (eg --no-route).  This has the effect of turning off the option for
> the following files. This is not currently possible. It will also give
> a consistent way to turn off options that are by default active.

Good idea although I think it does not make sense for all options. What 
about options that are not boolean?

>
> 2. Add a way to document old options and and give a warning that the
> option is no longer in use and what should replace it if anything.
> This will allow for options to be removed from the help list, without
> actually removing them from the program, so as not to break existing
> scripts.

That's a kind of option deprecation. I am not a big supporter for 
keeping old options for a very long time. If an option does not make 
good sense and has no function just remove it. If anyone wants to stick 
on this old option one can use older mkgmap releases.

The help file should differ between "normal" options that are useful for 
any mkgmap user (route, index, family-name, family-id etc.), "advanced" 
options for higher requirements (max-jobs, drive-on-left, 
check-roundabouts, ignore-maxspeeds etc) and "developer" options that 
need a somehow deep knowledge of mkgmap (block-size, 
preserve-element-order, max-flare-length-ratio, keep-going etc.).

>
> If anyone has any thoughts on how the options could be improved now
> would be a good time to discuss it.

The generate sea option has a kind of its own option system. I would 
prefer to break that and use single options.
generate-sea=multipolygon,close-gap=3000,floodblocker
=>
sea-generation=multipolygon
sea-close-gap=3000
sea-floodblocker

What about the report-XXX options? Shouldn't this be configured in the 
log.properties of the logging system?

What about dropping the support for .csv files? The help file points out 
that support will be dropped. I vote for this. Keep mkgmap slight.

>
> Things already on the list include: --charset, --remove-short-arcs,
> --ignore-osm-bounds, setting options inside the style (which can
> already be done, its just not really used properly).

If we want to use the option file in the styles then the mkgmap deploy 
should not pack the style files into the jar file. Put all classes into 
the jar file but the styles (and some other resources?) should be 
deployed easily changeable as flat files.

>
> ..Steve

WanMil