mkgmap command-line argument parsing bugs
Hi all, I have stumbled across a couple of mkgmap command-line argument parsing bugs: 1. (all?) command-line arguments after '-c template.args' are ignored 2. '--generate-sea' produces the following error message (I have to use '--generate-sea=multipolygon' even though multipolygon is supposedly the default): Unknown sea generation option '' Known sea generation options are: multipolygon use a multipolygon (default) polygons | no-mp use polygons rather than a multipolygon no-sea-sectors disable use of "sea sectors" extend-sea-sectors extend coastline to reach border land-tag=TAG=VAL tag to use for land polygons (default natural=land) close-gaps=NUM close gaps in coastline that are less than this distance (metres) floodblocker enable the floodblocker (for multipolgon only) fbgap=NUM points closer to the coastline are ignored for flood blocking (default 40) fbthres=NUM min points contained in a polygon to be flood blocked (default 20) fbratio=NUM min ratio (points/area size) for flood blocking (default 0.5) I'll see what I can do to provide patches to fix these, but it'll take me a while (the argument parsing code does not look trivial). Thanks, Richard
On 13/01/12 19:05, Richard Hansen wrote:
Hi all,
I have stumbled across a couple of mkgmap command-line argument parsing bugs:
1. (all?) command-line arguments after '-c template.args' are ignored
The order of options intentionally matters. Options only affect files that follow them on the command line (or within a command file). So I don't think that there is a bug there.
2. '--generate-sea' produces the following error message (I have to use '--generate-sea=multipolygon' even though multipolygon is supposedly the default):
That is something that should be fixed. ..Steve
On 2012-01-13 16:10, Steve Ratcliffe wrote:
On 13/01/12 19:05, Richard Hansen wrote:
1. (all?) command-line arguments after '-c template.args' are ignored
The order of options intentionally matters. Options only affect files that follow them on the command line (or within a command file). So I don't think that there is a bug there.
Ah, that's good to know. So the bug is that this behavior is not documented in '--help=options'. :) Thanks, Richard
The order of options intentionally matters. Options only affect files that follow them on the command line (or within a command file). So I don't think that there is a bug there. Ah, that's good to know. So the bug is that this behavior is not documented in '--help=options'. :) Does that mean that it does not 'return' after reading a -c, so that only one -c can be used?
Roger
On 2012-01-13 17:48, Roger Calvert wrote:
The order of options intentionally matters. Options only affect files that follow them on the command line (or within a command file). So I don't think that there is a bug there.
Ah, that's good to know. So the bug is that this behavior is not documented in '--help=options'. :)
Does that mean that it does not 'return' after reading a -c, so that only one -c can be used?
If I understand Steve correctly, multiple -c arguments should work. I've never tried it so I don't have any first-hand experience. -Richard
On 14 Jan 2012, at 03:03, Richard Hansen <rhansen@bbn.com> wrote:
On 2012-01-13 17:48, Roger Calvert wrote:
The order of options intentionally matters. Options only affect files that follow them on the command line (or within a command file). So I don't think that there is a bug there.
Ah, that's good to know. So the bug is that this behavior is not documented in '--help=options'. :)
Does that mean that it does not 'return' after reading a -c, so that only one -c can be used?
If I understand Steve correctly, multiple -c arguments should work. I've never tried it so I don't have any first-hand experience.
-Richard
According to a recent post on the OSM forum, multiple -c do work and thus offer a convenient way of calling both a relatively unchanging options file and a potentially frequently changing file list in the template.args.
On Fri, Jan 13, Roger Calvert wrote:
The order of options intentionally matters. Options only affect files that follow them on the command line (or within a command file). So I don't think that there is a bug there. Ah, that's good to know. So the bug is that this behavior is not documented in '--help=options'. :) Does that mean that it does not 'return' after reading a -c, so that only one -c can be used?
I'm using multiple -c to build my maps and it is working fine. Thorsten -- Thorsten Kukuk, Project Manager/Release Manager SLES SUSE LINUX Products GmbH, Maxfeldstr. 5, D-90409 Nuernberg GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer, HRB 16746 (AG Nürnberg)
On 2012-01-13 16:10, Steve Ratcliffe wrote:
On 13/01/12 19:05, Richard Hansen wrote:
Hi all,
I have stumbled across a couple of mkgmap command-line argument parsing bugs:
1. (all?) command-line arguments after '-c template.args' are ignored
The order of options intentionally matters. Options only affect files that follow them on the command line (or within a command file). So I don't think that there is a bug there.
2. '--generate-sea' produces the following error message (I have to use '--generate-sea=multipolygon' even though multipolygon is supposedly the default):
That is something that should be fixed.
Attached are two patches to address these two issues. Thanks, Richard
participants (5)
-
Charlie Ferrero -
Richard Hansen -
Roger Calvert -
Steve Ratcliffe -
Thorsten Kukuk