- mkgmap-dev - The mkgmap lists

Commit r4646: (slightly modified) codepage.patch by Mike Baggaley
by svn commit 09 Apr '21

09 Apr '21

Version mkgmap-r4646 was committed by gerd on Fri, 09 Apr 2021 (slightly modified) codepage.patch by Mike Baggaley - improve documentation for logging output http://www.mkgmap.org.uk/websvn/revision.php?repname=mkgmap&rev=4646

1 0

Commit r4645: LinePrepOpt.patch by Ticker Berkin
by svn commit 09 Apr '21

09 Apr '21

Version mkgmap-r4645 was committed by gerd on Fri, 09 Apr 2021 LinePrepOpt.patch by Ticker Berkin - improve efficency of bitstream optimization in LinePreparer "If starting with unsigned deltas in polyline encoding, and attempting to reduce the length by testing reduced x/yBase values, there isn't any point in testing Base-1, as the normal number of bits will be the same (added sign bit) and there will be some overflows. Patch attached to change this - it gives me a very slight reduction in RGN size and might give a performance improvement (I didn't detect any). I've also fixed a couple of log. logic errors and changed minDx/y initial to 0, which is much less confusing because they are symmetric with maxDx/y which do use 0." http://www.mkgmap.org.uk/websvn/revision.php?repname=mkgmap&rev=4645

1 0

Unit Tests Patch
by Mike Baggaley 08 Apr '21

08 Apr '21

Hi Gerd, Please find attached a patch that fixes the unit tests when using logging instead of writing to stderr/out (a few of the tests will fail if used against the current mkgmap release as I have changed some checkNoError() calls to checkError("Number of ExitExceptions: 0") - this was written to stdout, but is written to stderr under logging control. Cheers, Mike

1 0

logging improvements
by Mike Baggaley 07 Apr '21

07 Apr '21

Dear all, Please find attached a first stab at improving the way error and other messages are written, which at present is an ad hoc mixture of writing to stderr, stdout and using Java logging, with no apparent logical structure. Writing to stderr or stdout is not thread safe and causes problems when max_jobs is greater than 1. When stderr is redirected to a file and threads simultaneously attempt to write to it, you end up with extra numbered log files containing a few lines that you would expect to be in the named log file. As mkgmap supports a configuration file that defines how messages should be logged, it doesn't make much sense writing a significant number of messages to stderr which is not under logging control. There are several diagnostic options that write their output using warning as the severity, but as this is not enabled by default in the logging, they appear to do nothing unless a logging configuration file is also used, which is not intuitive. The --check-routing-island-len option seems somewhat confused as it attempts to combine both reporting and fixing depending on the value supplied. It also requires info level of logging which would include a lot of other not necessarily wanted messages. If you are using it to fix, you don't necessarily also want any messages. In my view the way messages should be handled is as follows: If the message is an informational message about the program itself and is unrelated to processing any data then write it to stdout - this would apply to the output of --version and --help. If the message is an error message about an invalid parameter in the command line, write it to stderr. Once the command line has been processed sufficiently that a file is to be processed then write messages using logging. If a diagnostic option is enabled, the program should automatically log the requested diagnostic messages. This would apply to --check-roundabouts, --check-roundabout-flares, --report-similar-arcs, --check-routing-island-len and --report-dead-ends. The attached patch enhances the existing logging interface by providing the following: A mechanism for writing messages without any formatting getting added and that always get written whatever level of logging is enabled. A mechanism for writing stack trace information to the log file (I don't believe stack traces really have any place in released code but have not attempted to replace any of these). Mostly directs messages as per my above proposal, though there is the occasional place where the best option is not quite obvious to me, as I think some of the code is not part of the main mkgmap program (there are several main functions and some of the code is for testing purposes). Only logs the start and finish times if files are being processed. Outputs requested diagnostic messages regardless of enabled logging levels Changes --report-dead-ends to be off by default, with the value of 1 being the default if --report-dead-ends is specified without a value. Filters duplicated --report-similar-arcs messages and ignores synthesised arcs so that it can be used together with --make-opposite-cycleways. Deprecates --check-routing-island-len, replacing it with --report-routing-islands to handle reporting and --max-routing-island-len to handle fixing. I expect there will be the odd place where others may disagree with the logging level for a message, but no doubt we can come to a consensus. The patch touches quite a few source files, but there are only a few changes that are anything more than altering the message outputting mechanism. There is no change to any map outputs. Cheers, Mike

2 14

Commit r4642: comments.patch by Mike Baggaley, no functional change
by svn commit 07 Apr '21

07 Apr '21

Version mkgmap-r4642 was committed by gerd on Wed, 07 Apr 2021 comments.patch by Mike Baggaley, no functional change - remove commented (dead) code containing System.*.println statements http://www.mkgmap.org.uk/websvn/revision.php?repname=mkgmap&rev=4642

1 0

Commit r4641: FileInfoException.patch by Mike Baggaley
by svn commit 07 Apr '21

07 Apr '21

Version mkgmap-r4641 was committed by gerd on Wed, 07 Apr 2021 FileInfoException.patch by Mike Baggaley - replace ReadFailedException by MapFailedException, so that it is correctly picked up. http://www.mkgmap.org.uk/websvn/revision.php?repname=mkgmap&rev=4641

1 0

Commit r4640: TypSaverException.patch by Mike Baggaley
by svn commit 07 Apr '21

07 Apr '21

Version mkgmap-r4640 was committed by gerd on Wed, 07 Apr 2021 TypSaverException.patch by Mike Baggaley - Add extra check for an empty file in TypSaver http://www.mkgmap.org.uk/websvn/revision.php?repname=mkgmap&rev=4640

1 0

Commit r4639: GmapiBuilderException.patch by Mike Baggaley
by svn commit 07 Apr '21

07 Apr '21

Version mkgmap-r4639 was committed by gerd on Wed, 07 Apr 2021 GmapiBuilderException.patch by Mike Baggaley - In GmapiBuilder, the print stack trace calls have been replaced with throwing ExitExceptions as in the other combiners, so that program execution correctly stops. http://www.mkgmap.org.uk/websvn/revision.php?repname=mkgmap&rev=4639

1 0

Re: [mkgmap-dev] Section of Country Boundary Missing
by dfjkman＠gmail.com 06 Apr '21

06 Apr '21

Hi all, Problem solved that section of the boundary is not included in 'zambia-latest.osm.pbf'. Obviously the bounding poly they use to create the file runs too close to the border and cuts this section off. I know there have been some border disputes in this region, some fairly recently. The problem is the demarcation of the border here in colonial times was not completed as the commission started it's work in the west where the border follows the watershed but the work was interrupted by the 2 world wars and the remaining borderline going east was based on old explorer journals and maps so certain landmarks used in these maps are disputed. Cheers, Dave -----Original Message----- From: dfjkman(a)gmail.com <dfjkman(a)gmail.com> Sent: 06 April 2021 11:32 To: 'Development list for mkgmap' <mkgmap-dev(a)lists.mkgmap.org.uk> Subject: Section of Country Boundary Missing Hi, I have come across a problem where a section of the Zambia DRC boundary is not shown on the map but only when creating a map for Zambia not for the DRC see attached images. It occurs even if using the most basic of options in both splitter and mkgmap and using 'congo-democratic-republic-latest.osm.pbf' and 'zambia-latest.osm.pbf' from Geofabrik, the commands for both maps are as follows:- Splitter version 598 java -Xmx2000m -jar splitter.jar congo-democratic-republic-latest.osm.pbf > splitter.log Mkgmap version 4618 Java -Xmx2000m -jar mkgmap.jar --gmapi --remove-ovm-work-files=true -c template.args > debug.log I have had a look at the missing section on OSM using JOSM and can not see any reason there should be a problem, it is split here as it is also a part of the Kaputa district boundary in Zambia. I went back to a version of map created from data in November last year with mkgmap version 4587 and that had 2 breaks in the boundary, the section that now appears complete in the current maps has since been joined with the section to the west of it and that, it would appear, is the reason it is now complete. Any ideas? Cheers, Dave

2 2

Section of Country Boundary Missing
by dfjkman＠gmail.com 06 Apr '21

06 Apr '21

Hi, I have come across a problem where a section of the Zambia DRC boundary is not shown on the map but only when creating a map for Zambia not for the DRC see attached images. It occurs even if using the most basic of options in both splitter and mkgmap and using 'congo-democratic-republic-latest.osm.pbf' and 'zambia-latest.osm.pbf' from Geofabrik, the commands for both maps are as follows:- Splitter version 598 java -Xmx2000m -jar splitter.jar congo-democratic-republic-latest.osm.pbf > splitter.log Mkgmap version 4618 Java -Xmx2000m -jar mkgmap.jar --gmapi --remove-ovm-work-files=true -c template.args > debug.log I have had a look at the missing section on OSM using JOSM and can not see any reason there should be a problem, it is split here as it is also a part of the Kaputa district boundary in Zambia. I went back to a version of map created from data in November last year with mkgmap version 4587 and that had 2 breaks in the boundary, the section that now appears complete in the current maps has since been joined with the section to the west of it and that, it would appear, is the reason it is now complete. Any ideas? Cheers, Dave

1 0