[mkgmap-dev] Splitter diagnostic messages

Sat Aug 6 07:24:51 BST 2016

Hi Mike,

splitter should end with a non-zero return code if something went wrong.

In that case you should keep the complete log and you should not try to process the output with mkgmap.

Besides that you may want to keep lines from splitter output containing the text "Warning" or "warning" or "Incomplete multipolygon relation".

I think I should change the code so that all warning messages really start with "Warning".

All other messages are either about progress or performance (e.g.

"Executing multi-tile analyses phase 3",

"Multi-tile analyses phase 3 took 109587 ms",  or

"JVM Memory Info: Current 978MB (632MB used, 346MB free) Max 1333MB".

In case that you stop splitter because it seems to hang in an infinite loop it will help (me) to see them.

Gerd

________________________________
Von: mkgmap-dev <mkgmap-dev-bounces at lists.mkgmap.org.uk> im Auftrag von Mike Baggaley <mike at tvage.co.uk>
Gesendet: Freitag, 5. August 2016 21:41:29
An: 'Development list for mkgmap'
Betreff: Re: [mkgmap-dev] Splitter diagnostic messages

HI Gerd, I don’t need to keep any information, unless splitter fails/crashes, in which case I need some idea of what went wrong (this very rarely happens). Perhaps I need to add something to my map build script to wait until splitter has completed before deciding what to do with the logging details, adding them to the log file if it fails and discarding if it succeeds. That would save making changes to splitter. Currently, I just redirect stdout of each step in the build process to the same file, so I would need to replace this with something more intelligent.

Regards,
Mike

From: Gerd Petermann [mailto:GPetermann_muenchen at hotmail.com]
Sent: 05 August 2016 06:16
To: Development list for mkgmap <mkgmap-dev at lists.mkgmap.org.uk>
Subject: Re: [mkgmap-dev] Splitter diagnostic messages

Hi Mike,

I've once tried to change the code to allow this and stopped because it is quite a lot of work

and in my eyes nearly all information printed by splitter is for performance analyses or debugging

in case that splitter crashes because of memory limits or when the split algo doesn't find a correct split.

I think the lines starting "Length" in following messages are no longer needed:

Statistics for coords map:
Length-1 chunks: 4.586.254, used Bytes including overhead: 47.435.504
Length-2 chunks: 13.128, used Bytes including overhead: 160.832
...
Length-63 chunks: 153, used Bytes including overhead: 25.464
Length-64 chunks: 191, used Bytes including overhead: 26.152

Number of stored ids: 11.933.022 require ca. 7.16 bytes per pair. 1397668 chunks are used, the avg. number of values in one 64-chunk is 8.
Map details: bytes/overhead 17.823.524 / 67.718.172, overhead includes 4 arrays with 16 MB

I also like to remove the bbox messages from the precompiled sea:
Counting nodes of precompiled sea data ...
Bounding box -4.921875 48.515625 -4.218749999 49.21875
Bounding box -4.218749999 48.515625 -3.515625 49.21875
Bounding box -3.515625 48.515625 -2.8125 49.21875
Bounding box -2.8125 48.515625 -2.109374999 49.21875
Bounding box -2.109374999 48.515625 -1.40625 49.21875

What information would you like to keep? Maybe you can extract those?

Gerd

________________________________
Von: mkgmap-dev <mkgmap-dev-bounces at lists.mkgmap.org.uk<mailto:mkgmap-dev-bounces at lists.mkgmap.org.uk>> im Auftrag von Mike Baggaley <mike at tvage.co.uk<mailto:mike at tvage.co.uk>>
Gesendet: Donnerstag, 4. August 2016 23:58:30
An: mkgmap-dev at lists.mkgmap.org.uk<mailto:mkgmap-dev at lists.mkgmap.org.uk>
Betreff: [mkgmap-dev] Splitter diagnostic messages

Hi Steve/Gerd (or whoever is the splitter expert), I was just wondering whether it would be possible to reduce the amount of diagnostic information produced by Splitter. I use a batch file to build my map, and the output from each process is appended to a log file. I get an enormous amount of uninteresting info from Splitter that I have to scroll past to see the output from mkgmap. Not a major problem, but it would be useful if there was an option to reduce this (I already have --status-freq=0 in my command line).

Cheers,

Mike

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.mkgmap.org.uk/pipermail/mkgmap-dev/attachments/20160806/56a7a57f/attachment-0001.html>