Re: [mkgmap-dev] mkgmap-dev Digest, Vol 143, Issue 10
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 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 mailto:gpetermann_muenc...@hotmail.com>> 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 mailto:mkgmap-dev-boun...@lists.mkgmap.org.uk>> im Auftrag von Dav
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 < gpetermann_muenc...@hotmail.com> 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 im Auftrag von > Dave Swarthout > 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 mappit...@gmail.com>> 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, mkgmap-dev-requ...@lists.mkgmap.org.uk > <mailto:mkgmap-dev-requ...@lists.mkgmap.org.uk> wrote: > > Send mkgmap-dev mailing list submissions to > mkgmap-dev@lists.mkgmap.org.uk mkgmap-dev@lists.mkgmap.org.uk> > > To subscribe or unsubscribe via the World Wide Web, visit > http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev > or, vi
Re: [mkgmap-dev] mkgmap-dev Digest, Vol 143, Issue 10
Hello Dave I understand your difficulties, i have gone through them as well. But in the mean while I also find out that it is just not that easy unless you make it a very personal execution. I tried to translate your comments into a introduction of ‘the mkgmap command line options manual’ which appears if you use -help or if you look at the website. For now I’m sure It is still not all true, but I like to ask if people think it’s a nice idea to start this manual with this introduction. If so… Then I’ll try to enhance it in the same direction and then some unix guy could give his comment and so make it better. Attached what I have in mind. If to be improved I suggest max another page not a full book… Kind regards Joris Van: mkgmap-dev Namens Dave Swarthout Verzonden: donderdag 4 juni 2020 17:05 Aan: Development list for mkgmap Onderwerp: 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 mailto:mappit...@gmail.com>> 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, mkgmap-dev-requ...@lists.mkgmap.org.uk<mailto:mkgmap-dev-requ...@lists.mkgmap.org.uk> wrote: Send mkgmap-dev mailing list submissions to mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk> 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 mkgmap-dev-requ...@lists.mkgmap.org.uk<mailto:mkgmap-dev-requ...@lists.mkgmap.org.uk> You can reach the person managing the list at mkgmap-dev-ow...@lists.mkgmap.org.uk<mailto:mkgmap-dev-ow...@lists.mkgmap.org.uk> When replying, please edit your Subject line so it is more specific than "Re: Contents of mkgmap-dev digest..." ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk> http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev -- Dave Swarthout Homer, Alaska Chiang Mai, Thailand Travel Blog at http://dswarthout.blogspot.com suggestion for command manual.docx Description: suggestion for command manual.docx ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] mkgmap-dev Digest, Vol 143, Issue 10
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 im Auftrag von Dave Swarthout 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 mailto:mappit...@gmail.com>> 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, mkgmap-dev-requ...@lists.mkgmap.org.uk<mailto:mkgmap-dev-requ...@lists.mkgmap.org.uk> wrote: Send mkgmap-dev mailing list submissions to mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk> 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 mkgmap-dev-requ...@lists.mkgmap.org.uk<mailto:mkgmap-dev-requ...@lists.mkgmap.org.uk> You can reach the person managing the list at mkgmap-dev-ow...@lists.mkgmap.org.uk<mailto:mkgmap-dev-ow...@lists.mkgmap.org.uk> When replying, please edit your Subject line so it is more specific than "Re: Contents of mkgmap-dev digest..." ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk> http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev -- Dave Swarthout Homer, Alaska Chiang Mai, Thailand Travel Blog at http://dswarthout.blogspot.com ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
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 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, mkgmap-dev-requ...@lists.mkgmap.org.uk wrote: > > Send mkgmap-dev mailing list submissions to > mkgmap-dev@lists.mkgmap.org.uk > > 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 > mkgmap-dev-requ...@lists.mkgmap.org.uk > > You can reach the person managing the list at > mkgmap-dev-ow...@lists.mkgmap.org.uk > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of mkgmap-dev digest..." > ___ > mkgmap-dev mailing list > mkgmap-dev@lists.mkgmap.org.uk > http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev > -- Dave Swarthout Homer, Alaska Chiang Mai, Thailand Travel Blog at http://dswarthout.blogspot.com ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] mkgmap-dev Digest, Vol 143, Issue 10
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, mkgmap-dev-requ...@lists.mkgmap.org.uk wrote: Send mkgmap-dev mailing list submissions to mkgmap-dev@lists.mkgmap.org.uk 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 mkgmap-dev-requ...@lists.mkgmap.org.uk You can reach the person managing the list at mkgmap-dev-ow...@lists.mkgmap.org.uk When replying, please edit your Subject line so it is more specific than "Re: Contents of mkgmap-dev digest..." ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
