[mkgmap-dev] complete list of all mkgmap options
Hello list, I searched for a complete list of all mkgmap command-line options and what they should do, but I couldn't find a good and up-to-date list. The list in the wiki is much too old. In the last few month they were very cool and usefull improvements of mkgmap but it's sometimes not easy to use and test them because they are not known. I would wish to have a Wiki page with all mkgmap options, their functionality, their usage and their status (stable, unstable...). Do you think this is a good idea? Where can I find a list of the options to fill the wiki page? Thank you and have a nice day! Christoph from Dresden signature.asc Description: OpenPGP digital signature ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] complete list of all mkgmap options
Christoph Wagner escribió: > Hello list, > I searched for a complete list of all mkgmap command-line options and > what they should do, but I couldn't find a good and up-to-date list. The > list in the wiki is much too old. > In the last few month they were very cool and usefull improvements of > mkgmap but it's sometimes not easy to use and test them because they are > not known. > I would wish to have a Wiki page with all mkgmap options, their > functionality, their usage and their status (stable, unstable...). > > Do you think this is a good idea? > Where can I find a list of the options to fill the wiki page? > I think most options are included in the file /resources/help/en/options that you can find in the source code. Regards Carlos ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] complete list of all mkgmap options
You should get this list by calling mkgmap --help (or similar) Christoph Wagner schrieb: > Hello list, > I searched for a complete list of all mkgmap command-line options and > what they should do, but I couldn't find a good and up-to-date list. The > list in the wiki is much too old. > In the last few month they were very cool and usefull improvements of > mkgmap but it's sometimes not easy to use and test them because they are > not known. > I would wish to have a Wiki page with all mkgmap options, their > functionality, their usage and their status (stable, unstable...). > > Do you think this is a good idea? > Where can I find a list of the options to fill the wiki page? > > Thank you and have a nice day! > Christoph from Dresden > > > > > ___ > mkgmap-dev mailing list > mkgmap-dev@lists.mkgmap.org.uk > http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] complete list of all mkgmap options
Johann Gail wrote: > You should get this list by calling mkgmap --help (or similar) > > Unfortunalty the developers have not kept this list up to date, which was the reason for Christoph Wagner post below. Garvan > Christoph Wagner schrieb: > >> Hello list, >> I searched for a complete list of all mkgmap command-line options and >> what they should do, but I couldn't find a good and up-to-date list. The >> list in the wiki is much too old. >> In the last few month they were very cool and usefull improvements of >> mkgmap but it's sometimes not easy to use and test them because they are >> not known. >> I would wish to have a Wiki page with all mkgmap options, their >> functionality, their usage and their status (stable, unstable...). >> >> Do you think this is a good idea? >> Where can I find a list of the options to fill the wiki page? >> >> Thank you and have a nice day! >> Christoph from Dresden >> >> ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] complete list of all mkgmap options
On Aug 1, 2009, at 13:26, Garvan & maew wrote: > Johann Gail wrote: >> You should get this list by calling mkgmap --help (or similar) >> > Unfortunalty the developers have not kept this list up to date, which > was the reason for Christoph Wagner post below. Yes, I think we need to go through the source code and check which options are present and being used. For example, the --frig-roundabouts option is still referenced in the source code, but I don't know if this is necessary any more. ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] complete list of all mkgmap options
I searched for a complete list of all mkgmap command-line options and what they should do, but I couldn't find a good and up-to-date list. The list in the wiki is much too old. I would wish to have a Wiki page with all mkgmap options, their functionality, their usage and their status (stable, unstable...). I have started to do some documentation update; see doc/README.* in the sources. There is help in the top-level README about options, and also the options file within resources/. I agree with others that we should spiff up the file used for --help=options and have that be the authoritative list, and it's on my todo list - but please don't let that stop anyone else from sending in patches. pgpogMdFGaRUG.pgp Description: PGP signature ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] complete list of all mkgmap options
On Aug 2, 2009, at 2:26, Greg Troxel wrote:
> I searched for a complete list of all mkgmap command-line options and
> what they should do, but I couldn't find a good and up-to-date
> list. The list in the wiki is much too old.
I grepped the mkgmap source for the following terms:
args.get(
args.exists(
getProperty
containsKey
opt.equals(
This, I hope should, find most of the options. The next step would be
to confirm their function and status.
Here is the list, with the source code file and the line where the
option appears. You can also, in many cases, see the default values:
src/uk/me/parabola/mkgmap/combiners/GmapsuppBuilder.java:
familyId =
args.get("family-id", 0);
src/uk/me/parabola/mkgmap/combiners/GmapsuppBuilder.java:
productId =
args.get("product-id", 1);
src/uk/me/parabola/mkgmap/combiners/GmapsuppBuilder.java:
familyName
= args.get("family-name", "family name");
src/uk/me/parabola/mkgmap/combiners/GmapsuppBuilder.java:
areaName =
args.get("area-name", null);
src/uk/me/parabola/mkgmap/combiners/TdbBuilder.java:overviewMapname
= args.get("overview-mapname", "OSM_map");
src/uk/me/parabola/mkgmap/combiners/TdbBuilder.java:
overviewMapnumber = args.get("overview-mapnumber", "6324");
src/uk/me/parabola/mkgmap/combiners/TdbBuilder.java:
overviewDescription = args.get("overview-description", "Overview Map");
src/uk/me/parabola/mkgmap/combiners/TdbBuilder.java:int familyId =
args.get("family-id", 0);
src/uk/me/parabola/mkgmap/combiners/TdbBuilder.java:int productId =
args.get("product-id", 1);
src/uk/me/parabola/mkgmap/combiners/TdbBuilder.java:short
productVersion = (short)args.get("product-version", 100);
src/uk/me/parabola/mkgmap/combiners/TdbBuilder.java:String
seriesName = args.get("series-name", "OSM map");
src/uk/me/parabola/mkgmap/combiners/TdbBuilder.java:String
familyName = args.get("family-name", "OSM map");
src/uk/me/parabola/mkgmap/main/MapMaker.java: String s =
args.get("add-pois-to-areas", null);
src/uk/me/parabola/mkgmap/main/MapMaker.java: String rnp =
args.get("road-name-pois", null);
src/uk/me/parabola/mkgmap/combiners/TdbBuilder.java:if
(args.exists("tdb-v3")) {
src/uk/me/parabola/imgfmt/app/trergn/TREHeader.java:
setDisplayPriority(props.getProperty(key, 0x19));
src/uk/me/parabola/log/Logger.java: String logconf =
props.getProperty("log.config");
src/uk/me/parabola/mkgmap/build/MapBuilder.java:countryName =
props.getProperty("country-name", countryName);
src/uk/me/parabola/mkgmap/build/MapBuilder.java:countryAbbr =
props.getProperty("country-abbr", countryAbbr);
src/uk/me/parabola/mkgmap/build/MapBuilder.java:regionName =
props.getProperty("region-name", null);
src/uk/me/parabola/mkgmap/build/MapBuilder.java:regionAbbr =
props.getProperty("region-abbr", null);
src/uk/me/parabola/mkgmap/build/MapBuilder.java:
if(props.getProperty("no-poi-address", null) != null)
src/uk/me/parabola/mkgmap/build/MapBuilder.java:String
autoFillPar =
props.getProperty("location-autofill", null);
src/uk/me/parabola/mkgmap/build/MapBuilder.java:
if(props.getProperty("no-sorted-roads", null) != null)
src/uk/me/parabola/mkgmap/CommandArgs.java: return
currentOptions.getProperty(name, def);
src/uk/me/parabola/mkgmap/CommandArgs.java: return
currentOptions.getProperty(name, def);
src/uk/me/parabola/mkgmap/CommandArgs.java: return
currentOptions.getProperty("description");
src/uk/me/parabola/mkgmap/CommandArgs.java: return
currentOptions.getProperty("mapname");
src/uk/me/parabola/mkgmap/CommandArgs.java: String charset =
currentOptions.getProperty("latin1");
src/uk/me/parabola/mkgmap/CommandArgs.java: charset =
currentOptions.getProperty("charset",
currentOptions.getProperty("xcharset"));
src/uk/me/parabola/mkgmap/CommandArgs.java: String s =
currentOptions.getProperty("code-page",
currentOptions.getProperty("xcode-page", "0"));
src/uk/me/parabola/mkgmap/CommandArgs.java: return
currentOptions.getProperty("lower-case") == null;
src/uk/me/parabola/mkgmap/CommandArgsReader.java: mapname
=
args.getProperty("mapname");
src/uk/me/parabola/mkgmap/main/Main.java:
if(!
args.getProperties().getProperty("keep-going", false)) {
src/uk/me/parabola/mkgmap/main/MapMaker.java: if
(args.getProperties().getProperty("route", false))
src/uk/me/parabola/mkgmap/osmstyle/StyledConverter.java:
ignoreMaxspeeds = props.getProperty("ignore-maxspeeds") != null;
src/uk/me/parabola/mkgmap/reader/dem/DEM.java: String
Re: [mkgmap-dev] complete list of all mkgmap options
Hi Clinton, > > I searched for a complete list of all mkgmap command-line options and > > what they should do, but I couldn't find a good and up-to-date > > list. The list in the wiki is much too old. What I believe we need is some fascist check in the options processing code that prints a message and quits the program if you specify an option that isn't recognised. Furthermore, it would then be possible to list the supported options with nothing left out or spelt incorrectly, etc. Cheers, Mark ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] complete list of all mkgmap options
> What I believe we need is some fascist check in the options processing
> code that prints a message and quits the program if you specify an
> option that isn't recognised. Furthermore, it would then be possible
> to list the supported options with nothing left out or spelt
> incorrectly, etc.
>
> Cheers,
>
> Mark
Something we've done at my current job is to write a CLI framework that makes
managing command line params very very easy. I think this project could benefit
greatly from this approach due to its large number of (frequently changing?)
parameters. Unfortunately I can't contribute our code, however I can describe
in detail what we did and help with the implementation. Basically each
application
that uses command line params defines an interface that looks something like
this:
public interface MkGMapParams {
@Option(defaultValue = "0", description = "The Family ID for the generated
map")
int getFamilyId();
@Option(defaultValue = Option.REQUIRED, description = "The Product ID for
the generated map")
int getProductId();
@Option(defaultValue = Option.OPTIONAL, description = "The country the
map represents")
String getCountryName();
@Option(description = "Specify this to make cycleways")
boolean isMakeCycleways();
enum MyEnum { One, Two }
@Option(name = "custom-enum", defaultValue = "One", description = "My custom
enum")
MyEnum getEnum();
// etc
}
To parse the parameters in code, we basically just make a call to our parser
as follows:
MkGMapParams params = CliParser.parse(MkGMapParams.class, arguments); //
where arguments is a String... parameter
That's it, the 'params' object now has all our command line params, parsed
into the correct type. If any of the parsing failed, error(s) explaining
what was wrong, along with a list of valid options and descriptions, are
displayed to the user.
Some valid usage examples:
java -jar mkgmap --product-id 99 --country-name bhutan --make-cycleways
java -jar mkgmap --product-id 99 --custom-enum Two
Some invalid usage examples:
java -jar mkgmap --family-id 99 --country-name bhutan --make-cycleways
(fails because --product-id is a required parameter)
java -jar mkgmap --product-id 99 --enum One(fails because the 'enum'
parameter must be specified as --custom-enum, not --enum)
java -jar mkgmap --product-id abc(fails because --product-id is not an
integer)
java -jar mkgmap --product-id 11 --family-id --make-cycleways (fails because
no value was specified for --family-id)
Here's how it works under the hood:
We have a converter interface defined as follows:
interface Converter {
T convert(String param) throws Exception; // Convert from the string
provided on the command line to a typesafe object.
List getValidValues() throws Exception; // Provide a list of valid
options (optional). eg a list of enum values.
String getDefaultValue() throws Exception;// Returns the default
value (or null if the parameter is required).
}
We then have a map from type to converter class, eg:
defaultConverters.put(String.class, StringConverter.class);
defaultConverters.put(Integer.class, IntegerConverter.class);
defaultConverters.put(Integer.type, IntegerConverter.class);
We then use reflection (and the annotation info) to examine the interface
and determine what the valid parameters are, whether they're required, what
type they are etc. For each parameter we parse we convert the string to the
appropriate type using the above map. Once that's done and no errors were
found, we use Proxy.newProxyInstance() to create an instance of the parameter
interface for the client application.
Note that we have a lot of additional functionality too like list handling,
custom converters, inter-parameter dependency handling, custom validation,
Guice support etc but the above is the guts of it. I hope it doesn't sound
like too much work - it's really not! The best thing is it will force people
to clearly define their parameters in the MkGMapParams interface since that's
the only thing that'll be available anywhere beyond the main() method. It's
very easy to use once the scaffolding is in place and it makes for nice
centralised
management of params and user friendly help and error messages.
Chris
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] complete list of all mkgmap options
Apologies, the formatting got all messed up by either my newsreader or NNTP! I'm sure you get the idea though. ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] complete list of all mkgmap options
On Mon, Aug 3, 2009 at 10:38 PM, Mark Burton wrote: > What I believe we need is some fascist check in the options processing > code that prints a message and quits the program if you specify an > option that isn't recognised. Yeah, maybe we could make an option for this? ;-) Cheers. ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] complete list of all mkgmap options
Sounds good to me!
Maybe there is an open source framework we could use:
http://www.cyclopsgroup.org/projects/jcli/
Best wishes
Christian
Chris Miller schrieb:
> Something we've done at my current job is to write a CLI framework that makes
> managing command line params very very easy. I think this project could
> benefit
> greatly from this approach due to its large number of (frequently changing?)
> parameters. Unfortunately I can't contribute our code, however I can describe
> in detail what we did and help with the implementation. Basically each
> application
> that uses command line params defines an interface that looks something like
> this:
>
> public interface MkGMapParams {
> @Option(defaultValue = "0", description = "The Family ID for the generated
> map")
> int getFamilyId();
>
> @Option(defaultValue = Option.REQUIRED, description = "The Product ID for
> the generated map")
> int getProductId();
>
> @Option(defaultValue = Option.OPTIONAL, description = "The country the
> map represents")
> String getCountryName();
>
> @Option(description = "Specify this to make cycleways")
> boolean isMakeCycleways();
>
> enum MyEnum { One, Two }
> @Option(name = "custom-enum", defaultValue = "One", description = "My
> custom
> enum")
> MyEnum getEnum();
> // etc
> }
>
> To parse the parameters in code, we basically just make a call to our parser
> as follows:
>
> MkGMapParams params = CliParser.parse(MkGMapParams.class, arguments); //
> where arguments is a String... parameter
>
> That's it, the 'params' object now has all our command line params, parsed
> into the correct type. If any of the parsing failed, error(s) explaining
> what was wrong, along with a list of valid options and descriptions, are
> displayed to the user.
>
> Some valid usage examples:
> java -jar mkgmap --product-id 99 --country-name bhutan --make-cycleways
> java -jar mkgmap --product-id 99 --custom-enum Two
>
> Some invalid usage examples:
> java -jar mkgmap --family-id 99 --country-name bhutan --make-cycleways
> (fails because --product-id is a required parameter)
> java -jar mkgmap --product-id 99 --enum One(fails because the 'enum'
> parameter must be specified as --custom-enum, not --enum)
> java -jar mkgmap --product-id abc(fails because --product-id is not an
> integer)
> java -jar mkgmap --product-id 11 --family-id --make-cycleways (fails because
> no value was specified for --family-id)
>
>
> Here's how it works under the hood:
>
> We have a converter interface defined as follows:
>
> interface Converter {
> T convert(String param) throws Exception; // Convert from the
> string
> provided on the command line to a typesafe object.
> List getValidValues() throws Exception; // Provide a list of valid
> options (optional). eg a list of enum values.
> String getDefaultValue() throws Exception;// Returns the default
> value (or null if the parameter is required).
> }
>
> We then have a map from type to converter class, eg:
>
> defaultConverters.put(String.class, StringConverter.class);
> defaultConverters.put(Integer.class, IntegerConverter.class);
> defaultConverters.put(Integer.type, IntegerConverter.class);
>
> We then use reflection (and the annotation info) to examine the interface
> and determine what the valid parameters are, whether they're required, what
> type they are etc. For each parameter we parse we convert the string to the
> appropriate type using the above map. Once that's done and no errors were
> found, we use Proxy.newProxyInstance() to create an instance of the parameter
> interface for the client application.
>
> Note that we have a lot of additional functionality too like list handling,
> custom converters, inter-parameter dependency handling, custom validation,
> Guice support etc but the above is the guts of it. I hope it doesn't sound
> like too much work - it's really not! The best thing is it will force people
> to clearly define their parameters in the MkGMapParams interface since that's
> the only thing that'll be available anywhere beyond the main() method. It's
> very easy to use once the scaffolding is in place and it makes for nice
> centralised
> management of params and user friendly help and error messages.
>
> Chris
>
>
>
> ___
> mkgmap-dev mailing list
> mkgmap-dev@lists.mkgmap.org.uk
> http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
>
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] complete list of all mkgmap options
Yep that framework takes a pretty similar approach to ours. We'd actually evaluated that (and about 10 others) before deciding to roll our own due to various requirements we had that no frameworks were able to provide but you're probably right, something like JCLI would be a good match for mkgmap. JewelCLI (http://jewelcli.sourceforge.net/) and Args4J (https://args4j.dev.java.net/) are a couple of others that take this approach. I'd recommend steering clear of the various alternatives that aren't annotation-based; I don't think we managed to find any that worked particularly well or had clean syntax with minimal lines of code required to use them. This was a year or so ago though, perhaps that has changed. FWIW, JOpt has a list of some of the more well known CLI parsers: http://jopt-simple.sourceforge.net/ Chris > Sounds good to me! > > Maybe there is an open source framework we could use: > http://www.cyclopsgroup.org/projects/jcli/ > > Best wishes > Christian ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
