Re: [mkgmap-dev] logging improvements

2021-03-30 Thread Gerd Petermann
Hi Mike,

I agree that it would be good to have the version in the output.
I have no idea how users handle the different output files. I guess they do 
anything that works somehow.

Gerd


Von: mkgmap-dev  im Auftrag von Mike 
Baggaley 
Gesendet: Montag, 29. März 2021 21:57
An: 'Development list for mkgmap'
Betreff: Re: [mkgmap-dev] logging improvements

Hi Gerd,

If the changes to the logging are applied without also changing the handling
of --check-routing-island-len, users who are using the option to remove
routing islands but do not have Level=INFO enabled (i.e. don't want to see
the messages) are likely to get a lot of unexpected messages. Similarly, if
the --report-dead-ends change is not also implemented at the same time,
users who do not specify --report-dead-ends and do not have Level=WARNING
enabled will start to get a lot of unwanted messages because
--report-dead-ends is on by default.

For --version, how about we output the following:
Version 

and give notice that at some point the second line will be removed? I'm not
entirely sure whether the link you passed was referring to --version or
$MKGMAP_VERSION$. There seems little point in using a script to extract the
version so that you can write it to the license file when you can specify it
directly anyway.

I also think it would be useful to write the version number to the log file
along with the start date and time. Does that sound reasonable to you?

I would have thought most people would be using 2>&1 to redirect both stdout
and stderr to the same file. I certainly don't want messages arbitrarily
going to different places. That and the problems with multiple threads were
my motivation for the patch. I will have a look at your codepage issue - I
use a Microsoft msbuild script to run the various programs involved in
building my maps and normally my logfile correctly displays non-Latin
characters, but occasionally they are corrupted and I think it may be when
mkgmap is the only program that needs to run, so it may be that there is a
problem if mkgmap creates the file, but it works if it appending to an
existing file.

I'll have a look at your config file. Mine seems to work OK; I see that we
are both using SimpleFormatter rather than UsefulFormatter.

I've attached a patch for the parts that were just removing commented out
System.out.println and System.err.println statements (so that they don't get
found when using search on the source). We can at least get those out of the
way...

Cheers,
Mike

-Original Message-
From: Gerd Petermann [mailto:gpetermann_muenc...@hotmail.com]
Sent: 29 March 2021 08:03
To: Development list for mkgmap 
Subject: Re: [mkgmap-dev] logging improvements

Hi Mike,

I do not yet understand why we can't do the logging changes without changing
the meaning of options.
Anyway, a few observations:
- I think we have to be careful regarding the output of --version. Those who
extract the version number with a script probably expect two lines. See
http://gis.19327.n8.nabble.com/version-numbers-tp5734654p5734862.html

- style functions echo and echotags are now writing to the logger instead of
stderr, this looks like a major change. There also seems to be a difference
reg. codepages, I tried with a lines file containing just highway=*
{echotags "hw"} and the german road names with umlauts are unreadable.
Output of chcp command:
D:\mkgmap>chcp
Aktive Codepage: 850.

- the changes are not compatible with my existing config file for logging
which expects a prefix like WARNING, INFO or SEVERE (see attachment), not a
show stopper but others may face this problem as well. See attached file.

Gerd




Von: mkgmap-dev  im Auftrag von Mike
Baggaley 
Gesendet: Sonntag, 28. März 2021 16:43
An: 'Development list for mkgmap'
Betreff: Re: [mkgmap-dev] logging improvements

Hi Gerd,

To assist with examining the patch, most of the source files have very small
changes. Here is a breakdown:

RouteArc - remove commented System.out.println
ExtTypeAttribues - remove commented System.err.println
TypElement - remove commented System.out.println
ImgHeader - - remove commented System.out.println
Locator - - remove commented System.out.println

FileBackedImgFileWriter - replace one System.err.println
MdxFile - replace one System.err.println
MdrFile - replace one System.err.println
NumberStyle - replace one System.err.println
EchoAction - replace one System.err.println
EchoTagsAction - replace one System.err.println
AbstractOp - replace one System.err.println
HousenumberGenerator - replace one System.err.println
OsmXlmHandler - replace one System.err.println
RestrictionHelper - replace one System.err.println
LblFileReader - replace one dubious System.err.println("Map has tide
prediction, please implement! ")
OverviewBuilder - replace System.out.println (2) + remove commented one
CommandArgs - replace System.out.println and System.err.println (2)

TdbBuilder - remove u

Re: [mkgmap-dev] tile takes very long time to generate

2021-03-30 Thread Ticker Berkin
Hi Gerd

I'm revising my opinion about considering the geometry to determine
inner and outer.  All the different BitSets, containsMatrix etc logic
is too complex, and if it then conflicts with the explicit definition
of the MP it just gets worse.

I'd simpify it along these lines:

 split the polygon/joinedWay list:
   error: the explicit conflicting inner/outer
   inners: at least one inner element
   outers: all the rest

 for each inner
   find a larger_area outer that contains a part of it
 add to the outer.listOfInners
 error if more than one

 for each outer
   cut out listOfInners
   apply tags
   output to the wayMap

This copes correctly with outer with inner hole that
contains another outer. If, in the above logic, more than one larger
outer is found, then choosing the smallest would allow this nesting to
any level.

Ticker

On Thu, 2021-03-18 at 10:21 +, Gerd Petermann wrote:
> Hi all,
> 
> I still struggle with the unit test because it's hard to say what we
> want to get in special cases.
> The current code doesn't really work in the way that I expected. I
> always thought that roles like "inner" and "outer" are completely
> ignored and that mkgmap calculates and uses the correct roles. This
> is only partly true. See attached file with MP were a forest contains
> a lake that contains a forest.
> For a nested polygon where the innermost ring has wrong role "inner"
> this doesn't work as expected. The forest  in the lake is ignored.
> With the correct role "outer" it is not ignored. No idea if this is
> intended or an error. Fortunately nested MP are very rare.
> 
> Gerd

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


Re: [mkgmap-dev] rules test

2021-03-30 Thread Steve Ratcliffe



On 29/03/2021 22:47, Mike Baggaley wrote:

I have been having difficulties with the mkgmap test  code which uses the
discontinued javax.xml.bind.DatatypeConverter for a single function
printHexBinary. Despite downloading a copy of the library and telling
Eclipse to use it, it doesn't seem to want to work. I found a replacement
bit of code on the Internet, but as I can't compare the two outputs I can't
confirm its output is identical. Can you take a look at the attached patch
which does away with the dependency on javax and allows the tests to run
under the latest version of Eclipse?



So java 1.11 has removed all of the javax.* classes, so we need a 
replacement.


The patch is fine and gives the same results, but since we are
now using java 1.8 you can do this in one line like so:

   String s = String.format("%032x", new BigInteger(1, 
digest)).substring(0, 8);


[You can add '.toUpperCase(Locale.ROOT)' if you want to preserve the 
uppercase names which I don't think is important.]


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