> 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 _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev