Hi Dave, the improvement of the documentation is an ongoing process. The right way to improve it is to describe the problem with the current documentation and - very welcomed - to post a patch or a complete file containing the changes to improve it. This allows others to verify that the changed version is really an improvement.
Reg. the source for the typ file: Of course, all options which should have an influence (--codepage, --family-id, --product-id) should precede it. It is a good idea to place it at the end because it is a small input input file which makes it special. If you omit the --max-jobs option it might cause problems if the typ file is the first input file. See http://www.mkgmap.org.uk/doc/tuning for details. I don't know any reason to place the typ anywhere else but at the end of the mkgmap options, but it is not mandantory, that's why I say "it is a good idea". You could also say "preferable" or maybe even "recommended". I think the vast majority of options should appear before any input file. Only a few options like --mapname and --description are special as they can(!) be used with different values for each input file. The --description option is even more special as its last given value also influences the gmapsupp.img. A few other options are also special, e.g. --check-styles is only useful when used after --style-file, else it would check the mkgmap builtin style. Although it is possible I would not recommend to create tiles with different styles in a single mkgmap execution, or with different --codepage or with different --family-id. That's why I proposed to add a check to detect this use case and print a warning when this is done. I think we can strongly recommend to avoid this and maybe even stop execution if any of the combiner options is also used in that situation. So, a bad combination of codepages like in this example java -jar mkgmap.jar --latin1 myfile.osm --codepage=unicode --index -c template.args could be detected before any tile is computed. It should also detect that the same output file would be computed twice or more, I think this also happened in the past. The combiner options (--tdbfile, --index, --gmapsupp, --gmapi, and --nsis) are also special because they can appear anywhere (I think), still it is a good idea ;) to use them before any input file. The combiners are special as they use the compiled tiles and maybe the typ file as input. Quite special is the usage of *.img files as input. This only makes sense in combination with one or more combiner options, but it may also require some other options like --codepage to be the same as in that run where the *.img was calculated. Gerd ________________________________________ Von: Dave Swarthout <[email protected]> Gesendet: Freitag, 5. Juni 2020 01:52 An: Gerd Petermann Cc: Development list for mkgmap Betreff: Re: [mkgmap-dev] mkgmap-dev Digest, Vol 143, Issue 10 Those were my suggestions based on my rather limited experience. I knew there are options for the java environment that require a single hyphen (ex: -Xmx4000m -jar), and then there is the configuration file parameter (which I forgot) but I ignored those for the sake of simplicity. I think given what you just said, the need for a comprehensive help guide is essential. Otherwise these sorts of questions and the amount of time it takes to sort out the answers will only increase as the program grows more complicated. Also, if your 3rd point is true it only adds more confusion to the debate " 3) The typ file can appear anywhere but it is a good idea to place it at the end" How can it be "a good idea" to place the filespec for the TYP file at the end if it is also true that it "can appear anywhere"? The two assertions appear to be in conflict in my reading of that statement Dave On Thu, Jun 4, 2020 at 10:34 PM Gerd Petermann <[email protected]<mailto:[email protected]>> wrote: Hi Dave, sorry, but your suggestion would be very wrong, esp. this one: "These parameters must be preceded by a double dash (two hyphens with no spaces between them) which are immediately followed by a command string. Each such parameter must be terminated with a comma with no space before or after it. (example: java -jar mkgmap.jar --parm1,--parm2,--parm3)" 1) For historic reasons, some parameters require only one dash, e.g. -c or -n. 2) Only some parameters expect a comma separated option list, and since r4517 a "dangling" comma in those lists should provoke an error message. 3) The typ file can appear anywhere but it is a good idea to place it at the end The option handling is very difficult to understand, esp. as mkgmap offers so many different ways to do it. There is no way to document it in a few short sentences. Gerd ________________________________________ Von: mkgmap-dev <[email protected]<mailto:[email protected]>> im Auftrag von Dave Swarthout <[email protected]<mailto:[email protected]>> Gesendet: Donnerstag, 4. Juni 2020 17:05 An: Development list for mkgmap Betreff: Re: [mkgmap-dev] mkgmap-dev Digest, Vol 143, Issue 10 Pitney wrote: "The issue with options and order (of precedence?) still confuses me after using mkgmap for years." I reckon that was my point in opening this topic all along. I think I've got it now and it makes sense but the documentation could still be made clearer IMO. For example: Invoking the mkgmap java program involves supplying a list of parameters or commands that allow the user to control the operation of the program and the output generated by it. These parameters must be preceded by a double dash (two hyphens with no spaces between them) which are immediately followed by a command string. Each such parameter must be terminated with a comma with no space before or after it. (example: java -jar mkgmap.jar --parm1,--parm2,--parm3) All input file specifications (filename.ext) must follow the last option in the invocation string. You may use a full path for that filespec as long as it is enclosed in quotes. (Windows/Dos example: "C:\Users\username\Downloads\Maps\MyState.osm") Any type file specification (filename.typ) containing custom bitmaps for Garmin lines, polygons and points must be the last file specification in the list of input files. Etc. Thanks also to Gerd for the latest releases which addressed the spurious space issue and improved the program's error reporting. I'm sure these will go a long way toward smoother operations for those of us who are only casual users of mkgmap. Dave On Thu, Jun 4, 2020 at 9:12 PM Pitney <[email protected]<mailto:[email protected]><mailto:[email protected]<mailto:[email protected]>>> wrote: Hello The issue with options and order (of precedence?) still confuses me after using mkgmap for years. My solution is to not use option files and to hard code all file references. Not good scripting practice but it works. I think this is a case of where examples are worth a thousand words. I understand in theory option and file order but do not know how to implement it in practice. Examples (in a separate file?) and how to work out which files they will effect may reduce confusion. I only have a tablet in quarantine so I apologize for any formatting issues. Pitney On June 4, 2020, at 2:11 AM, [email protected]<mailto:[email protected]><mailto:[email protected]<mailto:[email protected]>> wrote: Send mkgmap-dev mailing list submissions to [email protected]<mailto:[email protected]><mailto:[email protected]<mailto:[email protected]>> To subscribe or unsubscribe via the World Wide Web, visit http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev or, via email, send a message with subject or body 'help' to [email protected]<mailto:[email protected]><mailto:[email protected]<mailto:[email protected]>> You can reach the person managing the list at [email protected]<mailto:[email protected]><mailto:[email protected]<mailto:[email protected]>> When replying, please edit your Subject line so it is more specific than "Re: Contents of mkgmap-dev digest..." _______________________________________________ mkgmap-dev mailing list [email protected]<mailto:[email protected]><mailto:[email protected]<mailto:[email protected]>> http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev -- Dave Swarthout Homer, Alaska Chiang Mai, Thailand Travel Blog at http://dswarthout.blogspot.com -- Dave Swarthout Homer, Alaska Chiang Mai, Thailand Travel Blog at http://dswarthout.blogspot.com _______________________________________________ mkgmap-dev mailing list [email protected] http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
