Great idea I think a sea option particularly in the UK, Greece etc would be useful Possibly drive left/right ? Nick On 11/02/2019 09:50, Gerd Petermann wrote:

I think we can create a file in examples called maybe good-options.cfg which contains options like route index housenumbers gmapi gmapsupp nsis ... (to be defined)

Do we really need more?

________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Henning Scholland <osm@hscholland.de> Gesendet: Montag, 11. Februar 2019 10:10 An: Development list for mkgmap Betreff: Re: [mkgmap-dev] documentation improvement patch

Hi, Maybe it is a good idea to introduce some switch like 'just create a simple map'='for Garmin device and BaseCamp' , where mkgmap is always doing, what is currently best practice and new people get easily a map eg. for copying to their Garmin device or Basecamp or MapSource. So he don't need to worry an index is missing...

All the existing users still can keep their scripts with their specific settings.

Henning On 11 Feb 2019, at 02:12, Mike Baggaley <mike@tvage.co.uk<mailto:mike@tvage.co.uk>> wrote:

Hi Gerd, I have attached a patch to improve the documentation of the command line. I did it some time ago and had forgotten about it, but the discussion on whether to change default options prompted me to come back to it. The change is purely to the documentation, no code changes.

Please review and if it meets with your approval, commit.

Thanks, Mike

________________________________

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

key driving_side=left is tagged in UK boundary https://www.openstreetmap.org/relation/62149 ----- Mensaje original ----- De: "Gerd Petermann" <gpetermann_muenchen@hotmail.com> Para: "osm@pinns" <osm@pinns.co.uk>, "mkgmap-dev" <mkgmap-dev@lists.mkgmap.org.uk> Enviados: Lunes, 11 de Febrero 2019 7:06:51 Asunto: Re: [mkgmap-dev] documentation improvement patch Hi Nick, the sea and bounds options are problem cases as they require further files. Since drive-on=detect depends on the bounds this is even more complex. Gerd ________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von osm@pinns <osm@pinns.co.uk> Gesendet: Montag, 11. Februar 2019 10:54 An: mkgmap-dev@lists.mkgmap.org.uk Betreff: Re: [mkgmap-dev] documentation improvement patch Great idea I think a sea option particularly in the UK, Greece etc would be useful Possibly drive left/right ? Nick On 11/02/2019 09:50, Gerd Petermann wrote:

I think we can create a file in examples called maybe good-options.cfg which contains options like route index housenumbers gmapi gmapsupp nsis ... (to be defined)

Do we really need more?

________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Henning Scholland <osm@hscholland.de> Gesendet: Montag, 11. Februar 2019 10:10 An: Development list for mkgmap Betreff: Re: [mkgmap-dev] documentation improvement patch

Hi, Maybe it is a good idea to introduce some switch like 'just create a simple map'='for Garmin device and BaseCamp' , where mkgmap is always doing, what is currently best practice and new people get easily a map eg. for copying to their Garmin device or Basecamp or MapSource. So he don't need to worry an index is missing...

All the existing users still can keep their scripts with their specific settings.

Henning On 11 Feb 2019, at 02:12, Mike Baggaley <mike@tvage.co.uk<mailto:mike@tvage.co.uk>> wrote:

Hi Gerd, I have attached a patch to improve the documentation of the command line. I did it some time ago and had forgotten about it, but the discussion on whether to change default options prompted me to come back to it. The change is purely to the documentation, no code changes.

Please review and if it meets with your approval, commit.

Thanks, Mike

________________________________

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

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

Hi Gerd, It was a draft that shouldn't had left my computer. :-( Sorry. Anyway, shouldn't the information be verified for inconsistencies between OSM's driving_side tag and the file LocatorConfig.xml? M. ----- Mensaje original ----- De: "Gerd Petermann" <gpetermann_muenchen@hotmail.com> Para: "muralito" <muralito@montevideo.com.uy>, "mkgmap-dev" <mkgmap-dev@lists.mkgmap.org.uk> Enviados: Lunes, 11 de Febrero 2019 12:39:39 Asunto: AW: documentation improvement patch Hi muralito, not sure what you mean by that. What I wanted to say is that you need a working location hook which requires the bounds.zip to be able to use the information in LocatorConfig.xml which finally contains the information about lefthand/righthand traffic for all countries. Gerd ________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von muralito@montevideo.com.uy <muralito@montevideo.com.uy> Gesendet: Montag, 11. Februar 2019 16:33 An: mkgmap-dev Betreff: Re: [mkgmap-dev] documentation improvement patch key driving_side=left is tagged in UK boundary https://www.openstreetmap.org/relation/62149 ----- Mensaje original ----- De: "Gerd Petermann" <gpetermann_muenchen@hotmail.com> Para: "osm@pinns" <osm@pinns.co.uk>, "mkgmap-dev" <mkgmap-dev@lists.mkgmap.org.uk> Enviados: Lunes, 11 de Febrero 2019 7:06:51 Asunto: Re: [mkgmap-dev] documentation improvement patch Hi Nick, the sea and bounds options are problem cases as they require further files. Since drive-on=detect depends on the bounds this is even more complex. Gerd ________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von osm@pinns <osm@pinns.co.uk> Gesendet: Montag, 11. Februar 2019 10:54 An: mkgmap-dev@lists.mkgmap.org.uk Betreff: Re: [mkgmap-dev] documentation improvement patch Great idea I think a sea option particularly in the UK, Greece etc would be useful Possibly drive left/right ? Nick On 11/02/2019 09:50, Gerd Petermann wrote:

I think we can create a file in examples called maybe good-options.cfg which contains options like route index housenumbers gmapi gmapsupp nsis ... (to be defined)

Do we really need more?

________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Henning Scholland <osm@hscholland.de> Gesendet: Montag, 11. Februar 2019 10:10 An: Development list for mkgmap Betreff: Re: [mkgmap-dev] documentation improvement patch

Hi, Maybe it is a good idea to introduce some switch like 'just create a simple map'='for Garmin device and BaseCamp' , where mkgmap is always doing, what is currently best practice and new people get easily a map eg. for copying to their Garmin device or Basecamp or MapSource. So he don't need to worry an index is missing...

All the existing users still can keep their scripts with their specific settings.

Henning On 11 Feb 2019, at 02:12, Mike Baggaley <mike@tvage.co.uk<mailto:mike@tvage.co.uk>> wrote:

Hi Gerd, I have attached a patch to improve the documentation of the command line. I did it some time ago and had forgotten about it, but the discussion on whether to change default options prompted me to come back to it. The change is purely to the documentation, no code changes.

Please review and if it meets with your approval, commit.

Thanks, Mike

________________________________

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

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

Hi Gerd, I think it's quite similar to my idea. Just I was thinking to have one option to summarise the option file, you were suggesting. As option file is more easy to implement, I think its better to go your way first. The only advantage of my approach is that we later on can change the options if best practice is changed and user don't need to update any option file Henning On 11 Feb 2019, 17:50, at 17:50, Gerd Petermann <gpetermann_muenchen@hotmail.com> wrote:

I think we can create a file in examples called maybe good-options.cfg which contains options like route index housenumbers gmapi gmapsupp nsis ... (to be defined)

Do we really need more?

________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Henning Scholland <osm@hscholland.de> Gesendet: Montag, 11. Februar 2019 10:10 An: Development list for mkgmap Betreff: Re: [mkgmap-dev] documentation improvement patch

Hi, Maybe it is a good idea to introduce some switch like 'just create a simple map'='for Garmin device and BaseCamp' , where mkgmap is always doing, what is currently best practice and new people get easily a map eg. for copying to their Garmin device or Basecamp or MapSource. So he don't need to worry an index is missing...

All the existing users still can keep their scripts with their specific settings.

Henning On 11 Feb 2019, at 02:12, Mike Baggaley <mike@tvage.co.uk<mailto:mike@tvage.co.uk>> wrote:

Hi Gerd, I have attached a patch to improve the documentation of the command line. I did it some time ago and had forgotten about it, but the discussion on whether to change default options prompted me to come back to it. The change is purely to the documentation, no code changes.

Please review and if it meets with your approval, commit.

Thanks, Mike

________________________________

mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

Hi Gerd, I think you are right. I must have stopped and left it at the point where I needed the logging configuration details. Please find attached an updated patch. Note I am not quite clear of the symbols used to format the documentation (or why we need to manually generate two almost identical copies instead of deriving one from the other). Can you point me to web pages that describe the two formats? Cheers, Mike -----Original Message----- From: Gerd Petermann [mailto:gpetermann_muenchen@hotmail.com] Sent: 13 February 2019 13:46 To: Development list for mkgmap <mkgmap-dev@lists.mkgmap.org.uk> Subject: Re: [mkgmap-dev] documentation improvement patch Hi Mike, sorry for the late response. I like most of the patch but the introdution stops with "The configuration contains lines in the form" I guess that was the reason why you didn't post it in the past. Maybe just like to the wiki page: https://wiki.openstreetmap.org/wiki/Mkgmap/dev ? Gerd ________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Mike Baggaley <mike@tvage.co.uk> Gesendet: Sonntag, 10. Februar 2019 19:12 An: 'Development list for mkgmap' Betreff: [mkgmap-dev] documentation improvement patch Hi Gerd, I have attached a patch to improve the documentation of the command line. I did it some time ago and had forgotten about it, but the discussion on whether to change default options prompted me to come back to it. The change is purely to the documentation, no code changes. Please review and if it meets with your approval, commit. Thanks, Mike

HI Gerd, Thanks for the pointer to the script. That explains the handling of the options file. Having looked more closely at the doc folder, I realise that the background section I added would be better in the index.txt file rather than options.txt and options. I gather that the txt files in the doc folder are used to generate the HTML on the web site. Can you point me to the process for building the HTML? Is there some reason why we use this text format rather than creating them directly as HTML? I'll have a look to see whether the options.txt file or web page could be built directly from the options file. Having run mkgmap with --help=options, I see that there are quite a few overflowing lines. I'll also fix those. Note I am moving house on Thursday, so may be a little busy! Cheers, Mike -----Original Message----- From: Gerd Petermann [mailto:gpetermann_muenchen@hotmail.com] Sent: 22 February 2019 11:21 To: Mike Baggaley <mike@tvage.co.uk>; Development list for mkgmap <mkgmap-dev@lists.mkgmap.org.uk> Subject: Re: [mkgmap-dev] documentation improvement patch Hi Mike, I'd also prefer to have only one source for both files. Note that resources\help\en\options is not only documentation, it is also parsed by mkgmap to build a list of known options. I have no idea about the tools which are used, see scripts\options_to_doc.py for details. Gerd ________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Mike Baggaley <mike@tvage.co.uk> Gesendet: Freitag, 22. Februar 2019 08:58 An: 'Development list for mkgmap' Betreff: Re: [mkgmap-dev] documentation improvement patch Hi Gerd, I think you are right. I must have stopped and left it at the point where I needed the logging configuration details. Please find attached an updated patch. Note I am not quite clear of the symbols used to format the documentation (or why we need to manually generate two almost identical copies instead of deriving one from the other). Can you point me to web pages that describe the two formats? Cheers, Mike -----Original Message----- From: Gerd Petermann [mailto:gpetermann_muenchen@hotmail.com] Sent: 13 February 2019 13:46 To: Development list for mkgmap <mkgmap-dev@lists.mkgmap.org.uk> Subject: Re: [mkgmap-dev] documentation improvement patch Hi Mike, sorry for the late response. I like most of the patch but the introdution stops with "The configuration contains lines in the form" I guess that was the reason why you didn't post it in the past. Maybe just like to the wiki page: https://wiki.openstreetmap.org/wiki/Mkgmap/dev ? Gerd ________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Mike Baggaley <mike@tvage.co.uk> Gesendet: Sonntag, 10. Februar 2019 19:12 An: 'Development list for mkgmap' Betreff: [mkgmap-dev] documentation improvement patch Hi Gerd, I have attached a patch to improve the documentation of the command line. I did it some time ago and had forgotten about it, but the discussion on whether to change default options prompted me to come back to it. The change is purely to the documentation, no code changes. Please review and if it meets with your approval, commit. Thanks, Mike

Hi Gerd, please find attached a new patch. This moves the background info to index.txt, amends the positions of new lines, so that lines don't overflow when viewed in a standard 80 character command window (except one I have intentionally allowed to overflow as it is better that way), and added some simple java code to generate the options file from options.txt. The attached options file has been generated. Hope this looks OK. Cheers, Mike -----Original Message----- From: Mike Baggaley [mailto:mike@tvage.co.uk] Sent: 22 February 2019 20:04 To: 'Development list for mkgmap' <mkgmap-dev@lists.mkgmap.org.uk> Subject: Re: [mkgmap-dev] documentation improvement patch HI Gerd, Thanks for the pointer to the script. That explains the handling of the options file. Having looked more closely at the doc folder, I realise that the background section I added would be better in the index.txt file rather than options.txt and options. I gather that the txt files in the doc folder are used to generate the HTML on the web site. Can you point me to the process for building the HTML? Is there some reason why we use this text format rather than creating them directly as HTML? I'll have a look to see whether the options.txt file or web page could be built directly from the options file. Having run mkgmap with --help=options, I see that there are quite a few overflowing lines. I'll also fix those. Note I am moving house on Thursday, so may be a little busy! Cheers, Mike -----Original Message----- From: Gerd Petermann [mailto:gpetermann_muenchen@hotmail.com] Sent: 22 February 2019 11:21 To: Mike Baggaley <mike@tvage.co.uk>; Development list for mkgmap <mkgmap-dev@lists.mkgmap.org.uk> Subject: Re: [mkgmap-dev] documentation improvement patch Hi Mike, I'd also prefer to have only one source for both files. Note that resources\help\en\options is not only documentation, it is also parsed by mkgmap to build a list of known options. I have no idea about the tools which are used, see scripts\options_to_doc.py for details. Gerd ________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Mike Baggaley <mike@tvage.co.uk> Gesendet: Freitag, 22. Februar 2019 08:58 An: 'Development list for mkgmap' Betreff: Re: [mkgmap-dev] documentation improvement patch Hi Gerd, I think you are right. I must have stopped and left it at the point where I needed the logging configuration details. Please find attached an updated patch. Note I am not quite clear of the symbols used to format the documentation (or why we need to manually generate two almost identical copies instead of deriving one from the other). Can you point me to web pages that describe the two formats? Cheers, Mike -----Original Message----- From: Gerd Petermann [mailto:gpetermann_muenchen@hotmail.com] Sent: 13 February 2019 13:46 To: Development list for mkgmap <mkgmap-dev@lists.mkgmap.org.uk> Subject: Re: [mkgmap-dev] documentation improvement patch Hi Mike, sorry for the late response. I like most of the patch but the introdution stops with "The configuration contains lines in the form" I guess that was the reason why you didn't post it in the past. Maybe just like to the wiki page: https://wiki.openstreetmap.org/wiki/Mkgmap/dev ? Gerd ________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Mike Baggaley <mike@tvage.co.uk> Gesendet: Sonntag, 10. Februar 2019 19:12 An: 'Development list for mkgmap' Betreff: [mkgmap-dev] documentation improvement patch Hi Gerd, I have attached a patch to improve the documentation of the command line. I did it some time ago and had forgotten about it, but the discussion on whether to change default options prompted me to come back to it. The change is purely to the documentation, no code changes. Please review and if it meets with your approval, commit. Thanks, Mike

Hi Gerd, it looks like I inadvertently indented one section of the file which caused the blanks. I have reworked the program so that it now has a very basic understanding of paragraphs and can do the line length limiting itself. It only has a very basic understanding of HTML (just ,<p>, <pre> and </pre> and only when on a line by themselves). I have reverted my manual chopping up of lines in options.txt, so there are now far fewer changes (though I have fixed a few more typos) so it's much easier to see what is going on (still lots of changes in the generated options file of course). I have chopped out a number of <p> tags in options.txt for consistency - there were some places where it was used before a new option and some where it was not. Looking at the existing web page, you can see a small difference in spacing between the two cases. I just run the buildoptions program from within my Eclipse Java environment. You can compile and run it by following the following steps assuming you have a command prompt with its working directory set to the mkgmap root directory: cd options javac buildoptions\main.java java buildoptions.main Note that so that the above works, I have changed the hard coded paths to the input and output files to be relative to the options folder, so if running from Eclipse, you need to set the working directory to ${workspace_loc:mkgmap/options} instead of using the default. Cheers, Mike -----Original Message----- From: Gerd Petermann [mailto:gpetermann_muenchen@hotmail.com] Sent: 30 December 2019 09:40 To: Mike Baggaley <mike@tvage.co.uk>; 'Development list for mkgmap' <mkgmap-dev@lists.mkgmap.org.uk> Subject: AW: [mkgmap-dev] documentation improvement patch Hi Mike, thanks for the work. The patch applies fine now. I don't understand some of the reformatting in options.txt. I think they were not intended. See for example --split-name-index: Blanks at the beginning of the lines and "See also option road-name-config." is no longer on a separate line. It seems I am to stupid to run the java program on my machine :( Please desribe the steps to compile and run it. Looking at the source it seems you want to force max. 80 characters on one line in the options.txt file so that the buildoptions program doesn't have to reformat paragraphs? This looks like a complicated work flow when I edit options.txt: Edit, save, run buildoptions program, check if it complains about lines longer than 80 characters, edit again ... I think the java code should be able to detect a paragraph and split it into pieces? Gerd

Hi Gerd, it might be reasonable to move the following section to the background section of index.txt, as it is not directly about the command options: A typical simple example using both splitter and mkgmap: : java.exe -Xmx2g -jar splitter.jar england-latest.o5m : java.exe -jar mkgmap.jar --gmapsupp -c template.args The first command splits the Open Street Map data into smaller files with each file containing the data for one tile of the map. It also produces a file named template.args that contains the names of all the generated files. The second command takes as input all the individual files listed in the template.args file generated by splitter, produces a .img file for each tile, then merges all the tiles together into a single gmapsupp.img file. The rest of it is all about options and how to use them as far as I can see, though some of the obsolete/ignored options could be removed, as presumably they are now old enough to have no relevance. Regards, Mike -----Original Message----- From: Gerd Petermann [mailto:gpetermann_muenchen@hotmail.com] Sent: 04 January 2020 08:12 To: Mike Baggaley <mike@tvage.co.uk>; 'Development list for mkgmap' <mkgmap-dev@lists.mkgmap.org.uk> Subject: Re: [mkgmap-dev] documentation improvement patch Hi Mike, thanks again. My 1st thought about the additions in options.txt was that it produces a mix of FAQ /README and documentation about the options. I think we should not do that. I'll have a closer look again when the work on the is_in style function is done. Gerd ________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Mike Baggaley <mike@tvage.co.uk> Gesendet: Dienstag, 31. Dezember 2019 01:31 An: 'Development list for mkgmap' Betreff: Re: [mkgmap-dev] documentation improvement patch Hi Gerd, it looks like I inadvertently indented one section of the file which caused the blanks. I have reworked the program so that it now has a very basic understanding of paragraphs and can do the line length limiting itself. It only has a very basic understanding of HTML (just ,<p>, <pre> and </pre> and only when on a line by themselves). I have reverted my manual chopping up of lines in options.txt, so there are now far fewer changes (though I have fixed a few more typos) so it's much easier to see what is going on (still lots of changes in the generated options file of course). I have chopped out a number of <p> tags in options.txt for consistency - there were some places where it was used before a new option and some where it was not. Looking at the existing web page, you can see a small difference in spacing between the two cases. I just run the buildoptions program from within my Eclipse Java environment. You can compile and run it by following the following steps assuming you have a command prompt with its working directory set to the mkgmap root directory: cd options javac buildoptions\main.java java buildoptions.main Note that so that the above works, I have changed the hard coded paths to the input and output files to be relative to the options folder, so if running from Eclipse, you need to set the working directory to ${workspace_loc:mkgmap/options} instead of using the default. Cheers, Mike -----Original Message----- From: Gerd Petermann [mailto:gpetermann_muenchen@hotmail.com] Sent: 30 December 2019 09:40 To: Mike Baggaley <mike@tvage.co.uk>; 'Development list for mkgmap' <mkgmap-dev@lists.mkgmap.org.uk> Subject: AW: [mkgmap-dev] documentation improvement patch Hi Mike, thanks for the work. The patch applies fine now. I don't understand some of the reformatting in options.txt. I think they were not intended. See for example --split-name-index: Blanks at the beginning of the lines and "See also option road-name-config." is no longer on a separate line. It seems I am to stupid to run the java program on my machine :( Please desribe the steps to compile and run it. Looking at the source it seems you want to force max. 80 characters on one line in the options.txt file so that the buildoptions program doesn't have to reformat paragraphs? This looks like a complicated work flow when I edit options.txt: Edit, save, run buildoptions program, check if it complains about lines longer than 80 characters, edit again ... I think the java code should be able to detect a paragraph and split it into pieces? Gerd

Hi Mike, I see a few problems in the generated file options: - some scrambled characters around Xmx4g . Seems this is a special hyphen character? I think the example file for the log configuration should be moved into another file. I used the command java -jar dist\mkgmap.jar --help=options | more to read the help and was tempted to think that the program crashed when I saw those lines with # The default level FINE, WARNING, INFO, SEVERE .level=SEVERE #handlers: java.util.logging.ConsoleHandler handlers: java.util.logging.FileHandler java.util.logging.ConsoleHandler # package or class name with .level appended and ... It looks almost like a stacktrace ;) We already have the file logging.properties in the resources folder, but it is not copied to the dist\examples directory. Maybe we should distribute both versions. e.g. as default.logging and detailed.logging in examples? - a few lines are much longer than the others, e.g. "is somewhere between 1648 and 5520 for 1'' hgt input files (3312 is often used), and 5520 to 9942 for 3'' hgt input files." " multipolygon, polygons and land-tag. The coastlinefile option is ignored if precomp-sea is set." Looks like a special case for buildoptions? Gerd ________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Mike Baggaley <mike@tvage.co.uk> Gesendet: Montag, 13. Januar 2020 20:17 An: 'Development list for mkgmap' Betreff: Re: [mkgmap-dev] documentation improvement patch Hi Gerd, please find attached an updated patch that moves the section mentioned below to index.txt. Cheers, Mike -----Original Message----- From: Mike Baggaley [mailto:mike@tvage.co.uk] Sent: 04 January 2020 18:42 To: 'Gerd Petermann' <gpetermann_muenchen@hotmail.com>; 'Development list for mkgmap' <mkgmap-dev@lists.mkgmap.org.uk> Subject: RE: [mkgmap-dev] documentation improvement patch Hi Gerd, it might be reasonable to move the following section to the background section of index.txt, as it is not directly about the command options: A typical simple example using both splitter and mkgmap: : java.exe -Xmx2g -jar splitter.jar england-latest.o5m : java.exe -jar mkgmap.jar --gmapsupp -c template.args The first command splits the Open Street Map data into smaller files with each file containing the data for one tile of the map. It also produces a file named template.args that contains the names of all the generated files. The second command takes as input all the individual files listed in the template.args file generated by splitter, produces a .img file for each tile, then merges all the tiles together into a single gmapsupp.img file. The rest of it is all about options and how to use them as far as I can see, though some of the obsolete/ignored options could be removed, as presumably they are now old enough to have no relevance. Regards, Mike -----Original Message----- From: Gerd Petermann [mailto:gpetermann_muenchen@hotmail.com] Sent: 04 January 2020 08:12 To: Mike Baggaley <mike@tvage.co.uk>; 'Development list for mkgmap' <mkgmap-dev@lists.mkgmap.org.uk> Subject: Re: [mkgmap-dev] documentation improvement patch Hi Mike, thanks again. My 1st thought about the additions in options.txt was that it produces a mix of FAQ /README and documentation about the options. I think we should not do that. I'll have a closer look again when the work on the is_in style function is done. Gerd ________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Mike Baggaley <mike@tvage.co.uk> Gesendet: Dienstag, 31. Dezember 2019 01:31 An: 'Development list for mkgmap' Betreff: Re: [mkgmap-dev] documentation improvement patch Hi Gerd, it looks like I inadvertently indented one section of the file which caused the blanks. I have reworked the program so that it now has a very basic understanding of paragraphs and can do the line length limiting itself. It only has a very basic understanding of HTML (just ,<p>, <pre> and </pre> and only when on a line by themselves). I have reverted my manual chopping up of lines in options.txt, so there are now far fewer changes (though I have fixed a few more typos) so it's much easier to see what is going on (still lots of changes in the generated options file of course). I have chopped out a number of <p> tags in options.txt for consistency - there were some places where it was used before a new option and some where it was not. Looking at the existing web page, you can see a small difference in spacing between the two cases. I just run the buildoptions program from within my Eclipse Java environment. You can compile and run it by following the following steps assuming you have a command prompt with its working directory set to the mkgmap root directory: cd options javac buildoptions\main.java java buildoptions.main Note that so that the above works, I have changed the hard coded paths to the input and output files to be relative to the options folder, so if running from Eclipse, you need to set the working directory to ${workspace_loc:mkgmap/options} instead of using the default. Cheers, Mike -----Original Message----- From: Gerd Petermann [mailto:gpetermann_muenchen@hotmail.com] Sent: 30 December 2019 09:40 To: Mike Baggaley <mike@tvage.co.uk>; 'Development list for mkgmap' <mkgmap-dev@lists.mkgmap.org.uk> Subject: AW: [mkgmap-dev] documentation improvement patch Hi Mike, thanks for the work. The patch applies fine now. I don't understand some of the reformatting in options.txt. I think they were not intended. See for example --split-name-index: Blanks at the beginning of the lines and "See also option road-name-config." is no longer on a separate line. It seems I am to stupid to run the java program on my machine :( Please desribe the steps to compile and run it. Looking at the source it seems you want to force max. 80 characters on one line in the options.txt file so that the buildoptions program doesn't have to reformat paragraphs? This looks like a complicated work flow when I edit options.txt: Edit, save, run buildoptions program, check if it complains about lines longer than 80 characters, edit again ... I think the java code should be able to detect a paragraph and split it into pieces? Gerd

Hi Mike My utf-8 patch, topic "StandardCharsets and try (with-resources)" changes the charset used to read mkgmap.jar:help/{lang}/{topic} ie includes 'options' from the default charset to UTF-8. What is your default charset? The characters in --mdr7-excl are utf-8. I didn't find the hyphens. Ticker On Tue, 2020-01-14 at 12:05 +0000, Mike Baggaley wrote:

Hi Gerd,

It appears that mkgmap can only display ASCII characters, so although non-ASCII characters are copied faithfully from options.txt to options, mkgmap cannot display them. I have added an ASCII test to the code which displays the line number and offending text, - it transpires there was a non ASCII letter in the example usage of --mdr7-excl=name plus three special hyphens.

For the long lines, I hadn't handled the case where adding two lines together exceeded 160 characters and hence needed chopping twice. Now fixed.

I did wonder about taking out the example file. I have removed this from options.txt and put it in a new file logging.txt and referenced it from index.txt. I've also put it in a logging file for display from the command line with help=logging. It may still look like a stack trace there, but should at least be more expected. I have added a bit more information and a reference to the Java documentation on logging at the end (primarily so you can see something after the 'stacktrace').

How does that seem? Mike

-----Original Message----- From: Gerd Petermann [mailto:gpetermann_muenchen@hotmail.com] Sent: 14 January 2020 09:12 To: Mike Baggaley <mike@tvage.co.uk>; 'Development list for mkgmap' <mkgmap-dev@lists.mkgmap.org.uk> Subject: AW: [mkgmap-dev] documentation improvement patch

Hi Mike,

I see a few problems in the generated file options: - some scrambled characters around Xmx4g . Seems this is a special hyphen character? I think the example file for the log configuration should be moved into another file. I used the command java -jar dist\mkgmap.jar --help=options | more to read the help and was tempted to think that the program crashed when I saw those lines with # The default level FINE, WARNING, INFO, SEVERE .level=SEVERE #handlers: java.util.logging.ConsoleHandler handlers: java.util.logging.FileHandler java.util.logging.ConsoleHandler # package or class name with .level appended and ... It looks almost like a stacktrace ;) We already have the file logging.properties in the resources folder, but it is not copied to the dist\examples directory. Maybe we should distribute both versions. e.g. as default.logging and detailed.logging in examples? - a few lines are much longer than the others, e.g. "is somewhere between 1648 and 5520 for 1'' hgt input files (3312 is often used), and 5520 to 9942 for 3'' hgt input files." " multipolygon, polygons and land-tag. The coastlinefile option is ignored if precomp-sea is set." Looks like a special case for buildoptions?

Gerd

________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Mike Baggaley <mike@tvage.co.uk> Gesendet: Montag, 13. Januar 2020 20:17 An: 'Development list for mkgmap' Betreff: Re: [mkgmap-dev] documentation improvement patch

Hi Gerd, please find attached an updated patch that moves the section mentioned below to index.txt.

Cheers, Mike

-----Original Message----- From: Mike Baggaley [mailto:mike@tvage.co.uk] Sent: 04 January 2020 18:42 To: 'Gerd Petermann' <gpetermann_muenchen@hotmail.com>; 'Development list for mkgmap' <mkgmap-dev@lists.mkgmap.org.uk> Subject: RE: [mkgmap-dev] documentation improvement patch

Hi Gerd, it might be reasonable to move the following section to the background section of index.txt, as it is not directly about the command options:

A typical simple example using both splitter and mkgmap:

: java.exe -Xmx2g -jar splitter.jar england-latest.o5m : java.exe -jar mkgmap.jar --gmapsupp -c template.args

The first command splits the Open Street Map data into smaller files with each file containing the data for one tile of the map. It also produces a file named template.args that contains the names of all the generated files.

The second command takes as input all the individual files listed in the template.args file generated by splitter, produces a .img file for each tile, then merges all the tiles together into a single gmapsupp.img file.

The rest of it is all about options and how to use them as far as I can see, though some of the obsolete/ignored options could be removed, as presumably they are now old enough to have no relevance.

Regards, Mike -----Original Message----- From: Gerd Petermann [mailto:gpetermann_muenchen@hotmail.com] Sent: 04 January 2020 08:12 To: Mike Baggaley <mike@tvage.co.uk>; 'Development list for mkgmap' <mkgmap-dev@lists.mkgmap.org.uk> Subject: Re: [mkgmap-dev] documentation improvement patch

Hi Mike,

thanks again. My 1st thought about the additions in options.txt was that it produces a mix of FAQ /README and documentation about the options. I think we should not do that. I'll have a closer look again when the work on the is_in style function is done.

Gerd

________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Mike Baggaley <mike@tvage.co.uk> Gesendet: Dienstag, 31. Dezember 2019 01:31 An: 'Development list for mkgmap' Betreff: Re: [mkgmap-dev] documentation improvement patch

Hi Gerd, it looks like I inadvertently indented one section of the file which caused the blanks. I have reworked the program so that it now has a very basic understanding of paragraphs and can do the line length limiting itself. It only has a very basic understanding of HTML (just ,<p>, <pre> and </pre> and only when on a line by themselves). I have reverted my manual chopping up of lines in options.txt, so there are now far fewer changes (though I have fixed a few more typos) so it's much easier to see what is going on (still lots of changes in the generated options file of course). I have chopped out a number of <p> tags in options.txt for consistency - there were some places where it was used before a new option and some where it was not. Looking at the existing web page, you can see a small difference in spacing between the two cases. I just run the buildoptions program from within my Eclipse Java environment. You can compile and run it by following the following steps assuming you have a command prompt with its working directory set to the mkgmap root directory:

cd options javac buildoptions\main.java java buildoptions.main

Note that so that the above works, I have changed the hard coded paths to the input and output files to be relative to the options folder, so if running from Eclipse, you need to set the working directory to ${workspace_loc:mkgmap/options} instead of using the default.

Cheers, Mike

-----Original Message----- From: Gerd Petermann [mailto:gpetermann_muenchen@hotmail.com] Sent: 30 December 2019 09:40 To: Mike Baggaley <mike@tvage.co.uk>; 'Development list for mkgmap' <mkgmap-dev@lists.mkgmap.org.uk> Subject: AW: [mkgmap-dev] documentation improvement patch

Hi Mike,

thanks for the work. The patch applies fine now. I don't understand some of the reformatting in options.txt. I think they were not intended. See for example --split-name-index: Blanks at the beginning of the lines and "See also option road-name-config." is no longer on a separate line.

It seems I am to stupid to run the java program on my machine :( Please desribe the steps to compile and run it.

Looking at the source it seems you want to force max. 80 characters on one line in the options.txt file so that the buildoptions program doesn't have to reformat paragraphs? This looks like a complicated work flow when I edit options.txt: Edit, save, run buildoptions program, check if it complains about lines longer than 80 characters, edit again ... I think the java code should be able to detect a paragraph and split it into pieces?

Gerd

_______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

Hi Gerd, no issues with those changes. I think I also inadvertently lost a blank line immediately before === Mkgmap options ===. However, I think it is illogical to use stderr to display the version. I was considering following up with a small patch to change the version output from stderr and stop the program exiting after outputting the version. It seems illogical to exit if --version is anywhere on the command line regardless of the other options, and the documentation doesn't say it does this (the splitter documentation does). I'm off on holiday shortly, so probably won't be sending anything else for a while. Cheers, Mike -----Original Message----- From: Gerd Petermann [mailto:gpetermann_muenchen@hotmail.com] Sent: 30 January 2020 09:30 To: mkgmap-dev@lists.mkgmap.org.uk Subject: Re: [mkgmap-dev] documentation improvement patch Hi Mike, if I got that right you didn't compile help\options before you created doc-v7.patch. I also have some problems checking your patch because you changed the line endings to windows style (0d0a) instead of unix(0a) I've attached two patches: doc-v7-unix.patch: used your patch with line endings converted to unix and create a new patch. This is much smaller. doc-v8.patch: - two small changes in options.txt + --version writs to stderr, this information is considered important, see http://www.mkgmap.org.uk/websvn/revision.php?repname=mkgmap&rev=2642 + addedd missing "when" - freshly compiled help\options If you agree with these small changes I'll commit the v8. doc-v7-unix.patch <http://gis.19327.n8.nabble.com/file/t318326/doc-v7-unix.patch> doc-v8.patch <http://gis.19327.n8.nabble.com/file/t318326/doc-v8.patch> Mike Baggaley wrote

Hi Gerd,

It appears that mkgmap can only display ASCII characters, so although non-ASCII characters are copied faithfully from options.txt to options, mkgmap cannot display them. I have added an ASCII test to the code which displays the line number and offending text, - it transpires there was a non ASCII letter in the example usage of --mdr7-excl=name plus three special hyphens.

For the long lines, I hadn't handled the case where adding two lines together exceeded 160 characters and hence needed chopping twice. Now fixed.

I did wonder about taking out the example file. I have removed this from options.txt and put it in a new file logging.txt and referenced it from index.txt. I've also put it in a logging file for display from the command line with help=logging. It may still look like a stack trace there, but should at least be more expected. I have added a bit more information and a reference to the Java documentation on logging at the end (primarily so you can see something after the 'stacktrace').

How does that seem? Mike doc-v7.patch (200K) <http://gis.19327.n8.nabble.com/attachment/5956414/0/doc-v7.patch>;

-- Sent from: http://gis.19327.n8.nabble.com/Mkgmap-Development-f5324443.html