[mkgmap-dev] Problem when splitter runs out of disk space

[Mike Baggaley]

I recently had a problem where my disk filled up while running splitter, but
splitter did not exit, continuing to run for over an hour before I looked at
it and killed the process. I assume it was waiting for something which could
never happen.

The log file ended with the following:

Exception in thread "worker-4" Exception in thread "worker-2" Exception in
thread "worker-3" Exception in thread "worker-0" Exception in thread
"worker-6" Exception in thread "worker-1"
uk.me.parabola.splitter.SplitFailedException: Thread worker-1 failed to
write element 
at
uk.me.parabola.splitter.SplitProcessor$OSMWriterWorker.run(SplitProcessor.ja
va:421)
at java.base/java.lang.Thread.run(Thread.java:829)
Caused by: java.io.IOException: There is not enough space on the disk
at java.base/java.io.FileOutputStream.writeBytes(Native Method)
at
java.base/java.io.FileOutputStream.write(FileOutputStream.java:354)
at
java.base/java.io.BufferedOutputStream.flushBuffer(BufferedOutputStream.java
:81)
at
java.base/java.io.BufferedOutputStream.write(BufferedOutputStream.java:127)
at
java.base/java.io.ByteArrayOutputStream.writeTo(ByteArrayOutputStream.java:1
87)
at
uk.me.parabola.splitter.writer.O5mMapWriter.writeDataset(O5mMapWriter.java:2
03)
at
uk.me.parabola.splitter.writer.O5mMapWriter.write(O5mMapWriter.java:264)
at
uk.me.parabola.splitter.writer.AbstractOSMWriter.write(AbstractOSMWriter.jav
a:88)
at
uk.me.parabola.splitter.SplitProcessor$OSMWriterWorker.run(SplitProcessor.ja
va:417)
... 1 more
Exception in thread "worker-5" uk.me.parabola.splitter.SplitFailedException:
Thread worker-3 failed to write element 
at
uk.me.parabola.splitter.SplitProcessor$OSMWriterWorker.run(SplitProcessor.ja
va:421)
at java.base/java.lang.Thread.run(Thread.java:829)
Caused by: java.io.IOException: There is not enough space on the disk
at java.base/java.io.FileOutputStream.writeBytes(Native Method)
at
java.base/java.io.FileOutputStream.write(FileOutputStream.java:354)
at
java.base/java.io.BufferedOutputStream.flushBuffer(BufferedOutputStream.java
:81)
at
java.base/java.io.BufferedOutputStream.write(BufferedOutputStream.java:127)
at
java.base/java.io.ByteArrayOutputStream.writeTo(ByteArrayOutputStream.java:1
87)
at
uk.me.parabola.splitter.writer.O5mMapWriter.writeDataset(O5mMapWriter.java:2
03)
at
uk.me.parabola.splitter.writer.O5mMapWriter.write(O5mMapWriter.java:264)
at
uk.me.parabola.splitter.writer.AbstractOSMWriter.write(AbstractOSMWriter.jav
a:88)
at
uk.me.parabola.splitter.SplitProcessor$OSMWriterWorker.run(SplitProcessor.ja
va:417)
... 1 more
uk.me.parabola.splitter.SplitFailedException: Thread worker-2 failed to
write element 
at
uk.me.parabola.splitter.SplitProcessor$OSMWriterWorker.run(SplitProcessor.ja
va:421)
at java.base/java.lang.Thread.run(Thread.java:829)
Caused by: java.io.IOException: There is not enough space on the disk
at java.base/java.io.FileOutputStream.writeBytes(Native Method)
at
java.base/java.io.FileOutputStream.write(FileOutputStream.java:354)
at
java.base/java.io.BufferedOutputStream.flushBuffer(BufferedOutputStream.java
:81)

Regards,
Mike

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

Re: [mkgmap-dev] tag value within regular expression

[Mike Baggaley]

Thanks Ticker,

I now have it working.

Cheers,
Mike

-Original Message-
From: Ticker Berkin [mailto:rwb-mkg...@jagit.co.uk] 
Sent: 26 January 2022 09:43
To: mkgmap-dev@lists.mkgmap.org.uk
Subject: Re: [mkgmap-dev] tag value within regular expression

Hi Mike

It needs to be something like:

highway=* & name=* {set temp='${name|not-contained:" :rn"'}
# the separator char^
# now temp will be set to name or null and can be tested:
highway=* & temp=* {echotags "name not in route"}

Think I've got this right.

I'll adjust the style manual layout sometime

Ticker

On 26/01/2022 01:10, Mike Baggaley wrote:
> I tried the following:
> 
> highway=* & name=* & ${name|not-contained: :rn}!=* {echotags "Highway with 
> name of route"; delete name}
> 
> but I get "Error in style : error : (lines:191): Value '$not-contained:' is 
> not part of an expression".
> 
> Is this a bug or am I doing something wrong?
> 
> Cheers,
> Mike
> 
> -Original Message-
> From: Mike Baggaley [mailto:m...@tvage.co.uk]
> Sent: 25 January 2022 20:14
> To: 'Development list for mkgmap' 
> Subject: RE: [mkgmap-dev] tag value within regular expression
> 
> Hi Ticker,
> 
> I had wondered about using not-contained (although I would prefer to do a 
> case insensitive match, hence my preference for a regular expression).
> I was confused by the example in the manual, as it doesn't contain the tag 
> value or name, but have now realised that the example has been truncated.
> 
> Regards,
> Mike
> 
> -Original Message-
> From: Ticker Berkin [mailto:rwb-mkg...@jagit.co.uk]
> Sent: 25 January 2022 15:03
> To: Development list for mkgmap 
> Subject: Re: [mkgmap-dev] tag value within regular expression
> 
> Hi Mike
> 
> Would the tag filter not-contained (4.4.1) do the job?
> 
> Ticker
> 
> On Tue, 2022-01-25 at 13:51 +, Mike Baggaley wrote:
>> Hi,
>>
>> Section 4.2.3 of the style manual shows how to compare the values of
>> two
>> tags, but does not indicate whether it is possible to use tag values
>> within
>> a regular expression. Is this possible? If the name of a highway is
>> contained within the tag I use to contain the route name, I would
>> like to
>> delete the name tag. Currently I do this if the route name is the
>> same as
>> the highway name, but the route name can contain more than one name.
>>
>> Cheers,
>> Mike
>>
>>
>>
>> ___
>> mkgmap-dev mailing list
>> mkgmap-dev@lists.mkgmap.org.uk
>> https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
> 
> 
> 
> 
> ___
> mkgmap-dev mailing list
> mkgmap-dev@lists.mkgmap.org.uk
> https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev


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

Re: [mkgmap-dev] tag value within regular expression

[Mike Baggaley]

I tried the following:

highway=* & name=* & ${name|not-contained: :rn}!=* {echotags "Highway with name 
of route"; delete name}

but I get "Error in style : error : (lines:191): Value '$not-contained:' is not 
part of an expression".

Is this a bug or am I doing something wrong?

Cheers,
Mike

-Original Message-
From: Mike Baggaley [mailto:m...@tvage.co.uk] 
Sent: 25 January 2022 20:14
To: 'Development list for mkgmap' 
Subject: RE: [mkgmap-dev] tag value within regular expression

Hi Ticker,

I had wondered about using not-contained (although I would prefer to do a case 
insensitive match, hence my preference for a regular expression).
I was confused by the example in the manual, as it doesn't contain the tag 
value or name, but have now realised that the example has been truncated.

Regards,
Mike

-Original Message-
From: Ticker Berkin [mailto:rwb-mkg...@jagit.co.uk] 
Sent: 25 January 2022 15:03
To: Development list for mkgmap 
Subject: Re: [mkgmap-dev] tag value within regular expression

Hi Mike

Would the tag filter not-contained (4.4.1) do the job?

Ticker

On Tue, 2022-01-25 at 13:51 +, Mike Baggaley wrote:
> Hi,
> 
> Section 4.2.3 of the style manual shows how to compare the values of
> two
> tags, but does not indicate whether it is possible to use tag values
> within
> a regular expression. Is this possible? If the name of a highway is
> contained within the tag I use to contain the route name, I would
> like to
> delete the name tag. Currently I do this if the route name is the
> same as
> the highway name, but the route name can contain more than one name.
> 
> Cheers,
> Mike
> 
> 
> 
> ___
> mkgmap-dev mailing list
> mkgmap-dev@lists.mkgmap.org.uk
> https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev




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

Re: [mkgmap-dev] tag value within regular expression

[Mike Baggaley]

Hi Ticker,

I had wondered about using not-contained (although I would prefer to do a case 
insensitive match, hence my preference for a regular expression).
I was confused by the example in the manual, as it doesn't contain the tag 
value or name, but have now realised that the example has been truncated.

Regards,
Mike

-Original Message-
From: Ticker Berkin [mailto:rwb-mkg...@jagit.co.uk] 
Sent: 25 January 2022 15:03
To: Development list for mkgmap 
Subject: Re: [mkgmap-dev] tag value within regular expression

Hi Mike

Would the tag filter not-contained (4.4.1) do the job?

Ticker

On Tue, 2022-01-25 at 13:51 +, Mike Baggaley wrote:
> Hi,
> 
> Section 4.2.3 of the style manual shows how to compare the values of
> two
> tags, but does not indicate whether it is possible to use tag values
> within
> a regular expression. Is this possible? If the name of a highway is
> contained within the tag I use to contain the route name, I would
> like to
> delete the name tag. Currently I do this if the route name is the
> same as
> the highway name, but the route name can contain more than one name.
> 
> Cheers,
> Mike
> 
> 
> 
> ___
> mkgmap-dev mailing list
> mkgmap-dev@lists.mkgmap.org.uk
> https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev




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

[mkgmap-dev] tag value within regular expression

[Mike Baggaley]

Hi,

Section 4.2.3 of the style manual shows how to compare the values of two
tags, but does not indicate whether it is possible to use tag values within
a regular expression. Is this possible? If the name of a highway is
contained within the tag I use to contain the route name, I would like to
delete the name tag. Currently I do this if the route name is the same as
the highway name, but the route name can contain more than one name.

Cheers,
Mike



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

Re: [mkgmap-dev] option --mdr7-del: change or add new option?

[Mike Baggaley]

Hi Gerd,

My suggestion was simply that it was more logical to remove them from
anywhere, I don't actually use the option.
I would be in favour of changing the existing option unless anyone states
they specifically need to only remove the words from the end of the label.
I would not be in favour of adding a new option unless there are users that
need both implementations (which I think is unlikely).

The removal of words from anywhere would also give better results in the
case where a number of words are added to the label, but one or more of the
words has inadvertently been missed from the --mdr7-del option.

Cheers,
Mike

-Original Message-
From: Gerd Petermann [mailto:gpetermann_muenc...@hotmail.com] 
Sent: 17 January 2022 07:58
To: mkgmap-dev@lists.mkgmap.org.uk
Subject: [mkgmap-dev] option --mdr7-del: change or add new option?

Hi all,

the current implementation only removes words from the right.
Felix and Mike both suggested to change that so that the listed words are
removed anywhere,
and I think Arndt's Style would also benefit.

Should I simply change the implementation and documentation 
or is backward compatibility important? 
If we want to be backward compatible we need a new option.
This could be something like --mdr7-delx or --mdr7-del-all

Gerd


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

Re: [mkgmap-dev] Minor documentation patch

[Mike Baggaley]

Hi Gerd, 

Please find an updated patch that I think captures the way the option works.
I've tried to rewrite it as what it does rather than how it is implemented.
I've also included an update to the top level help that removes the link to
the OSM wiki as a provider of further information (it doesn't provide any)
and adds a link to the geofabrik website as a source for input data.

Let me know if you think the change still doesn't quite represent what
happens.
By the way, I'm not sure it is particularly logical to only remove words
from the end of the label.

There is also an error in the mkgmap home page, but the source doesn't seem
to be included in the mkgmap distribution so I can't send a patch. The last
sentence ends "and copy it to the cards in the Garmin directory" and I think
it should say "and copy it to the card's /Garmin directory".

Cheers,
Mike

-Original Message-
From: Gerd Petermann [mailto:gpetermann_muenc...@hotmail.com] 
Sent: 09 January 2022 08:12
To: Development list for mkgmap 
Subject: Re: [mkgmap-dev] Minor documentation patch

Hi Mike,

thanks for the patch.  I fear the original text was really wrong. Your
suggestion is better but it still doesn't catch the case that all(!) words
might
be removed.

Assume  option --mdr7-del=PTH,TRK,UNP,PAV
and label is  "PTH UNP" or just "PTH"
In both cases the processing of --mdr7-del would end up
in an empty label and thus nothing is added to MDR7 section.

With a label "SCHILLERSTRASSE UNP" the part " UNP" is removed.
With a label "UNP SCHILLERSTRASSE" nothing is removed.

The code actually splits the label at every blank (space) into an
array of words. Then it removes from right to left if the last
word appears in the list. A label that doesn't contain a blank
is an array with one element.

I have no idea how well this works with languages that are read from
right to left, but that's a different story.

Maybe you find better wording?

Gerd






____
Von: mkgmap-dev  im Auftrag von Mike
Baggaley 
Gesendet: Samstag, 8. Januar 2022 16:24
An: 'Development list for mkgmap'
Betreff: [mkgmap-dev] Minor documentation patch

Hi Gerd,

Please find attached a minor documentation patch.

Cheers,
Mike



options2.patch
Description: Binary data
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

[mkgmap-dev] Minor documentation patch

[Mike Baggaley]

Hi Gerd,

Please find attached a minor documentation patch.

Cheers,
Mike


options.patch
Description: Binary data
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

Re: [mkgmap-dev] Building display.jar fails

[Mike Baggaley]

I create a separate line for national and regional walking and cycling
routes, thus the name of the route doesn't need to go in the road name. I do
have quite complex rules to handle this as I have national routes in one
colour, cycling in another and alternating where there are both, and these
are shown outside the roads, so I have different width ones for different
road classes and for different resolutions. My lowest level of resolution
just shows national walking routes and motorways.

A snippet from the lines file...

# national and regional hiking and cycling routes
nationalhikingroute=yes {name '${nwrn}'} [0x11803 resolution 14-15 continue]
nationalbicycleroute=yes & nationalhikingroute!=yes {name '${nrn}'} [0x11800
resolution 16-18 continue]
nationalbicycleroute=yes & nationalhikingroute=yes {name '${nrn}'} [0x11801
resolution 16-18 continue]
nationalbicycleroute=yes & nationalhikingroute=yes {name '${nrn}'} [0x11802
resolution 16-18 continue]
nationalbicycleroute!=yes & nationalhikingroute=yes {name '${nrn}'} [0x11803
resolution 16-18 continue]

nationalbicycleroute=yes & nationalhikingroute!=yes &
regionalhikingroute!=yes {name '${rn}'} [0x11800 resolution 19-20 continue]
regionalbicycleroute=yes & nationalbicycleroute!=yes &
nationalhikingroute!=yes & regionalhikingroute!=yes {name '${rn}'} [0x11805
resolution 19-20 continue]
nationalbicycleroute=yes & (nationalhikingroute=yes |
regionalhikingroute=yes) {name '${rn}'} [0x11801 resolution 19-20 continue]
regionalbicycleroute=yes & nationalbicycleroute!=yes &
(nationalhikingroute=yes | regionalhikingroute=yes) {name '${rn}'} [0x11806
resolution 19-20 continue]
nationalhikingroute=yes & (nationalbicycleroute=yes |
regionalbicycleroute=yes) {name '${rn}'} [0x11802 resolution 19-20 continue]
regionalhikingroute=yes & nationalhikingroute!=yes &
(nationalbicycleroute=yes | regionalbicycleroute=yes) {name '${rn}'}
[0x11807 resolution 19-20 continue]
nationalhikingroute=yes & nationalbicycleroute!=yes &
regionalbicycleroute!=yes {name '${rn}'} [0x11803 resolution 19-20 continue]
regionalhikingroute=yes & nationalhikingroute!=yes &
nationalbicycleroute!=yes & regionalbicycleroute!=yes {name '${rn}'}
[0x11808 resolution 19-20 continue]

nationalbicycleroute=yes & nationalhikingroute!=yes &
regionalhikingroute!=yes & tunnel!=* & bridge!=* & (highway!=* |
highway=path | highway=footway | highway=steps | highway=cycleway |
highway=bridleway | highway=track) { name '${rn}' } [0x10010 resolution 21
continue]
nationalbicycleroute=yes & nationalhikingroute!=yes &
regionalhikingroute!=yes & (tunnel=* | bridge=*) & highway=* & (highway=path
| highway=footway | highway=steps | highway=cycleway | highway=bridleway |
highway=track) { name '${rn}' } [0x10010 resolution 21-21 continue]
nationalbicycleroute=yes & nationalhikingroute!=yes &
regionalhikingroute!=yes & (tunnel=* | bridge=*) & highway=* & (highway=path
| highway=footway | highway=steps | highway=cycleway | highway=bridleway |
highway=track) { name '${rn}' } [0x10011 resolution 22 continue]
nationalbicycleroute=yes & nationalhikingroute!=yes &
regionalhikingroute!=yes & tunnel!=* & bridge!=* & highway=* & highway!=path
& highway!=footway & highway!=steps & highway!=cycleway & highway!=bridleway
& highway!=track { name '${rn}' } [0x10012 resolution 21 continue]
nationalbicycleroute=yes & nationalhikingroute!=yes &
regionalhikingroute!=yes & (tunnel=* | bridge=*) & highway=* & highway!=path
& highway!=footway & highway!=steps & highway!=cycleway & highway!=bridleway
& highway!=track { name '${rn}' } [0x10012 resolution 21-21 continue]
nationalbicycleroute=yes & nationalhikingroute!=yes &
regionalhikingroute!=yes & (tunnel=* | bridge=*) & highway=* & highway!=path
& highway!=footway & highway!=steps & highway!=cycleway & highway!=bridleway
& highway!=track { name '${rn}' } [0x10013 resolution 22 continue]
nationalbicycleroute=yes & (nationalhikingroute=yes |
regionalhikingroute=yes) & tunnel!=* & bridge!=* & (highway!=* |
highway=path | highway=footway | highway=steps | highway=cycleway |
highway=bridleway | highway=track) [0x10014 resolution 21 continue]
nationalbicycleroute=yes & (nationalhikingroute=yes |
regionalhikingroute=yes) & (tunnel=* | bridge=*) & highway=* & (highway=path
| highway=footway | highway=steps | highway=cycleway | highway=bridleway |
highway=track) [0x10014 resolution 21-21 continue]
nationalbicycleroute=yes & (nationalhikingroute=yes |
regionalhikingroute=yes) & (tunnel=* | bridge=*) & highway=* & (highway=path
| highway=footway | highway=steps | highway=cycleway | highway=bridleway |
highway=track) [0x10015 resolution 22 continue]
nationalbicycleroute=yes & (nationalhikingroute=yes |
regionalhikingroute=yes) & tunnel!=* & bridge!=* & highway=* & highway!=path
& highway!=footway & highway!=steps & highway!=cycleway & highway!=bridleway
& highway!=track [0x10016 resolution 21 continue]
nationalbicycleroute=yes & (nationalhikingroute=yes |
regionalhikingroute=yes) & (tunnel=* | bridge=*) 

Re: [mkgmap-dev] Building display.jar fails

[Mike Baggaley]

Can't Felix just use substring in his style to limit the length?

Cheers,
Mike

-Original Message-
From: Gerd Petermann [mailto:gpetermann_muenc...@hotmail.com] 
Sent: 06 December 2021 08:25
To: Development list for mkgmap 
Subject: Re: [mkgmap-dev] Building display.jar fails

Hi Felix,

I can try to add code to cut anything after 170 characters and remove
trailing blanks,
but it's not a simple change.
To be honest, I don't understand the idea of those long labels. What's the
purpose?
To me it looks like a random list of words where a road name is expected and
I
wonder what your users do with them.

I've also noticed a problem (without the patch) now with the first gmapsupp:
Search for panorama to find PANORAMAWEG MapSource lists many entries. The
1st one starts with M3. Pth (see sreenshot).
When I select that street and click on find I get a popup with
"The selected street is not valid in this map product.  Please select a
different street."

The map contains a very long label
"M3. PTH IWN VA-R56 VIA ALPINA RED R56 + VA-R57 VIA ALPINA RED R57 & RWN 66
LIECHTENSTEINER PANORAMAWEG & LWN 142 GAFADURAHUETTE - DREI SCHWESTERN -
KEMMI - SILUM - STEG + 144 GAFADURAHUETTE - SILUM - STEG + 143
GAFADURAHUETTE - BARGAELLA - STEG + 29 GAFLEI - PLANKEN + 30 GAFADURAHUETTE
- GAFLEI + 169 GAFADURAHUETTE - HINTERAELPELE (A) - SCHAANWALD + 24 GAFADURA
- GARSELLA ALP - CHEMI - BARGELLA - GAFLEI"

where PANORAMAWEG appears at offset 91, but maybe MapSource cannot handle
the long name.  Basecamp doesn't seem to have that problem. Didn't try my
Oregon.

Gerd


Von: mkgmap-dev  im Auftrag von
Felix Hartmann 
Gesendet: Sonntag, 5. Dezember 2021 11:56
An: Development list for mkgmap
Betreff: Re: [mkgmap-dev] Building display.jar fails

Hi Gerd,
Okay - I counted through a lot of entries - and there is no absolute number
- because it depends a bit on the letters and spacing. However the max
amount of characters (incuding blanks) I could count was 162. So we should
hard cap the name label at 170 characters. In general with latin I got
145-160 characters in Basecamp per label.
Another option would be to split into the next label if one is free after
XXX characters - however I think that is not a good option - Mapsource
cannot display close to that many letters - and the devices also cannot and
it kinda depends on each device. Just clipping at 170 characters will remove
some wasted space.

And thanks for the patch. on the new thread.

On Sun, 5 Dec 2021 at 10:58, Felix Hartmann
mailto:extremecar...@gmail.com>> wrote:
I simply add all route names to the name. Actually mkgmap should cut after
XX characters.

I will count the max for Basecamp and mapsource, devices cannot even show
that long names. It is around 100 but I will check again.

Yes there is no reason to put that long names.

On Sun, 5 Dec 2021, 09:32 Gerd Petermann
mailto:gpetermann_muenc...@hotmail.com>>
wrote:
Hi Felix,

I think the names that you see come from names like "PHILOSOPHENWEG G1 TRK
LWN 156 GAENGLESEE"
in combination with --split-name-index.
I really wonder how you calculate road names like these:
'TRK LWN 105 TRIESENBERG - ROTABODA-SAMIA - SCHLOSS VADUZ - VADUZ + 106
GAFLEI - ROTABODA - TRIESENBERG + 141 TRIESENBERG - BAHOLZ - VADUZ'
'BERGWALD G1 TRK LWN 121 MAUREN - RUGGELL + 123 BENDERN - ST. CORNELI (A) +
120 BENDERN - MAUREN + 35 MAUREN - BUEELKAPPILI - VORDERER SCHELLENBERG'
In what situation are they usefull? Which device is able to display such a
name? Some have a length > 250.

Anyway, I see two ways to reduce the noise in mkgmap:
- add code to avoid that --split-name-index adds index entries for name
parts which are listed in mdr7-del (should have done this anyway)
- add a new option which tells mkgmap that --mdr7-del should remove all
substrings, not only suffixes (the effect will be rather small, looking at
those long names)

Gerd


Von: mkgmap-dev
mailto:mkgmap-dev-boun...@lists.mkgm
ap.org.uk>> im Auftrag von Felix Hartmann
mailto:extremecar...@gmail.com>>
Gesendet: Samstag, 4. Dezember 2021 22:12
An: Development list for mkgmap
Betreff: Re: [mkgmap-dev] Building display.jar fails

Sorry, the slash at the end should not be there:
https://openmtbmap.org/gmapsupp.img

On Sat, 4 Dec 2021, 19:16 Gerd Petermann
mailto:gpetermann_muenc...@hotmail.com>mailto:gpetermann_muenc...@hotmail.com>>
> wrote:
Hi Felix,

the link doesn't work.

Gerd


Von: mkgmap-dev
mailto:mkgmap-dev-boun...@lists.mkgm
ap.org.uk>>> im Auftrag von Felix Hartmann
mailto:extremecar...@gmail.com>>>
Gesendet: Samstag, 4. Dezember 2021 17:25
An: Development list for mkgmap
Betreff: Re: [mkgmap-dev] Building display.jar fails

oh sorry, I forgot --index on the gmapsupp.img creation in that case and did

Re: [mkgmap-dev] relation label patch

[Mike Baggaley]

Hi Gerd,

I do use --housenumbers. Is my name processing likely to be causing problems
in Wales? I only occasionally go to Wales, so probably wouldn't have noticed
any issue.

Cheers,
Mike

-Original Message-
From: Gerd Petermann [mailto:gpetermann_muenc...@hotmail.com] 
Sent: 29 November 2021 10:18
To: Development list for mkgmap 
Subject: Re: [mkgmap-dev] relation label patch

Hi Mike,

OK, that's something I didn't think about before. You probably don't use the
--housenumbers option?

Gerd


Von: mkgmap-dev  im Auftrag von Mike
Baggaley 
Gesendet: Montag, 29. November 2021 11:08
An: 'Development list for mkgmap'
Betreff: Re: [mkgmap-dev] relation label patch

HI Gerd, in Wales many of the names are put as dual nationality in the name
field with name:en and name:cy holding the English and Welsh variants. I use
just the English as the name if there is one, but also add the Welsh name as
another label for roads and places.

In my points and lines files I have:
# set English variant as main name and Welsh variant as secondary in Wales
name=* & name:en=* & name:cy!=* & name:en!=$name &
mkgmap:admin_level4='Wales' {set name:cy='${name}'}
name:cy=* & mkgmap:admin_level4!='Wales' {delete name:cy}
name:en=* & name:en!=$name & mkgmap:option:non-uk!=true {set
name='${name:en}'}
name=$name:cy {delete name:cy}

In my polygons and relations files I just have:
name:en=* & mkgmap:admin_level4='Wales' {set name='${name:en}'}

I don't think this can be achieved with --name-tag-list.

Cheers,
Mike

-Original Message-
From: Gerd Petermann [mailto:gpetermann_muenc...@hotmail.com]
Sent: 28 November 2021 17:18
To: Development list for mkgmap 
Subject: Re: [mkgmap-dev] relation label patch

Hi Mike,

> I have statements to overwrite name with name:en
The nomal way is to use option --name-tag-list. What's the reason for this
trick?

Gerd

____
Von: mkgmap-dev  im Auftrag von Mike
Baggaley 
Gesendet: Sonntag, 28. November 2021 17:59
An: 'Development list for mkgmap'
Betreff: [mkgmap-dev] relation label patch

Hi Gerd,

Please find attached a small patch that allows a node tagged with a role of
label or admin_centre to be still used if it has no name defined, rather
than only if it matches the name on the relation. Also an improvement in the
diagnostic message when a role label node is not being used.

An example relation that has an unnamed role label is
http://www.openstreetmap.org/relation/10090341
An example of a relation having a differently named label role node is :
http://www.openstreetmap.org/relation/7218222

I'm getting a warning that role node
http://www.openstreetmap.org/node/2642288017 is being ignored because it has
a different name than http://www.openstreetmap.org/relation/58437

They both have name=Cymru / Wales, name:en=Wales and name:cy=Cymru, so
should match. However, at the beginning of my points, lines and relations
files I have statements to overwrite name with name:en. This gives me
name=Wales for the relation, but because at the time of processing the label
node it hasn't been processed by the points file, the name of the node is
still Cymru / Wales, thus they don't match and the role label is ignored.

It's only a minor problem, but I'm wondering whether the solution is to
introduce an optional names file (or other named file) that could be read
before reading points lines and relations and also when handling the
admin_centre and label nodes. Not sure whether there are any other places
that this approach would be beneficial.

Cheers,
Mike


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


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

Re: [mkgmap-dev] relation label patch

[Mike Baggaley]

HI Gerd, in Wales many of the names are put as dual nationality in the name
field with name:en and name:cy holding the English and Welsh variants. I use
just the English as the name if there is one, but also add the Welsh name as
another label for roads and places.

In my points and lines files I have:
# set English variant as main name and Welsh variant as secondary in Wales
name=* & name:en=* & name:cy!=* & name:en!=$name &
mkgmap:admin_level4='Wales' {set name:cy='${name}'}
name:cy=* & mkgmap:admin_level4!='Wales' {delete name:cy}
name:en=* & name:en!=$name & mkgmap:option:non-uk!=true {set
name='${name:en}'}
name=$name:cy {delete name:cy}

In my polygons and relations files I just have:
name:en=* & mkgmap:admin_level4='Wales' {set name='${name:en}'}

I don't think this can be achieved with --name-tag-list.

Cheers,
Mike

-Original Message-
From: Gerd Petermann [mailto:gpetermann_muenc...@hotmail.com] 
Sent: 28 November 2021 17:18
To: Development list for mkgmap 
Subject: Re: [mkgmap-dev] relation label patch

Hi Mike,

> I have statements to overwrite name with name:en
The nomal way is to use option --name-tag-list. What's the reason for this
trick?

Gerd

____
Von: mkgmap-dev  im Auftrag von Mike
Baggaley 
Gesendet: Sonntag, 28. November 2021 17:59
An: 'Development list for mkgmap'
Betreff: [mkgmap-dev] relation label patch

Hi Gerd,

Please find attached a small patch that allows a node tagged with a role of
label or admin_centre to be still used if it has no name defined, rather
than only if it matches the name on the relation. Also an improvement in the
diagnostic message when a role label node is not being used.

An example relation that has an unnamed role label is
http://www.openstreetmap.org/relation/10090341
An example of a relation having a differently named label role node is :
http://www.openstreetmap.org/relation/7218222

I'm getting a warning that role node
http://www.openstreetmap.org/node/2642288017 is being ignored because it has
a different name than http://www.openstreetmap.org/relation/58437

They both have name=Cymru / Wales, name:en=Wales and name:cy=Cymru, so
should match. However, at the beginning of my points, lines and relations
files I have statements to overwrite name with name:en. This gives me
name=Wales for the relation, but because at the time of processing the label
node it hasn't been processed by the points file, the name of the node is
still Cymru / Wales, thus they don't match and the role label is ignored.

It's only a minor problem, but I'm wondering whether the solution is to
introduce an optional names file (or other named file) that could be read
before reading points lines and relations and also when handling the
admin_centre and label nodes. Not sure whether there are any other places
that this approach would be beneficial.

Cheers,
Mike


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

[mkgmap-dev] relation label patch

[Mike Baggaley]

Hi Gerd,

Please find attached a small patch that allows a node tagged with a role of
label or admin_centre to be still used if it has no name defined, rather
than only if it matches the name on the relation. Also an improvement in the
diagnostic message when a role label node is not being used.

An example relation that has an unnamed role label is
http://www.openstreetmap.org/relation/10090341
An example of a relation having a differently named label role node is :
http://www.openstreetmap.org/relation/7218222

I'm getting a warning that role node
http://www.openstreetmap.org/node/2642288017 is being ignored because it has
a different name than http://www.openstreetmap.org/relation/58437

They both have name=Cymru / Wales, name:en=Wales and name:cy=Cymru, so
should match. However, at the beginning of my points, lines and relations
files I have statements to overwrite name with name:en. This gives me
name=Wales for the relation, but because at the time of processing the label
node it hasn't been processed by the points file, the name of the node is
still Cymru / Wales, thus they don't match and the role label is ignored.

It's only a minor problem, but I'm wondering whether the solution is to
introduce an optional names file (or other named file) that could be read
before reading points lines and relations and also when handling the
admin_centre and label nodes. Not sure whether there are any other places
that this approach would be beneficial.

Cheers,
Mike


relationlabel.patch
Description: Binary data
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

Re: [mkgmap-dev] Documentation for the new Douglas-Peucker options in low-res-opt branch

[Mike Baggaley]

Hi Gerd,

I think the original documentation for --reduce-point-density and
--reduce-point-density-polygon could do with some improvement. It also seems
bizarre to have a recommended value that is not the default. Is 2.6 the
default if --reduce-point-density is specified without a value, or is it
also the default if the option is not specified? Are the units metres? Is
the distance the same no matter what resolution is used, or does the
distance increase at lower resolution? If the former, wouldn't it be better
to increase by a factor of 1.414 at successive resolutions? Would this be
sufficient to not need to be able to specify individual values for
resolutions?

I'm not keen on having two very differently named options that basically
achieve the same aim and suggest that it would be better to simply extend
the existing --reduce-point-density options with
--reduce-point-density=value|resolution:value[,...] or even better
--reduce-point-density=value[,...] where the first value applies to the
first used resolution and so on, with the last value being scaled for any
further resolutions that have not had a value specified. 

Is there a reason why polygons need different values than lines? Shouldn't
reduce-point-density-polygon default to the reduce-point-density value?

I note that although the documentation belongs to the low-res-branch, it is
showing up on the mkgmap command line web page.

Regards,
Mike

-Original Message-
From: Gerd Petermann [mailto:gpetermann_muenc...@hotmail.com] 
Sent: 14 June 2021 07:43
To: mkgmap-dev@lists.mkgmap.org.uk
Subject: [mkgmap-dev] Documentation for the new Douglas-Peucker options in
low-res-opt branch

Hi all,

I've now added documentation for these new options, see:
https://www.mkgmap.org.uk/websvn/diff.php?repname=mkgmap=%2Fbranches%2F
low-res-opt%2Fresources%2Fhelp%2Fen%2Foptions=4775=4775

Is it clear enough?
I think the recommend value --reduce-point-density-polygon=8 is far too high
at low resolutions. Should this be changed?

Together with the new --improve-overview option this branch version can
produce much better results for the lower resolutions.

Gerd






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

[mkgmap-dev] Commit r4735: improve Logging/ debugging : todegrees.patch

[Mike Baggaley]

>Version mkgmap-r4735 was committed by gerd on Mon, 24 May 2021

>improve Logging/ debugging : todegrees.patch
>- change Coord.toString() to return the same as toDegreeString() instead of
a pair of Garmin units
>- add method toGarminString() to get a string with Garmin units
>- deprecate toDegreeString()

It appears that display no longer compiles as it uses toDegreeString():

compile:
[javac] Compiling 76 source files to
C:\Users\Mike\Documents\MapBuild\Programs\display\build\classes
[javac]
C:\Users\Mike\Documents\MapBuild\Programs\display\src\test\svg\subdiv\SvgDiv
Doc.java:83: error: cannot find symbol
[javac] .setText(String.format("%d: %s",
div.getNumber(), div.getCenter().toDegreeString()));
[javac]
^
[javac]   symbol:   method toDegreeString()
[javac]   location: class Coord
[javac] 1 error

BUILD FAILED

Cheers,
Mike

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

Re: [mkgmap-dev] logging improvement

[Mike Baggaley]

Hi Gerd, https://www.openstreetmap.org/changeset/105053431 and
https://www.openstreetmap.org/changeset/105053358 are examples of fixing of
problems that affected routing. Because one flare had the wrong direction
and hence both flares pointed in the same direction, routing was not
possible in the reverse direction.

Using mkgmap to identify these problems has been convenient for me, as I get
messages on the areas for which I am building maps. But perhaps another tool
might be more suitable - due to the point at which the check is performed,
mkgmap does not have access the actual way data and hence does not have all
the information that would help in determining whether two road segments are
really flares. (e.g. highway tag). Also, because it works on individual
tiles post-splitter, there are usually a few roundabouts that get chopped
into different tiles and hence can't be checked properly.  I'm not aware of
a validator that identifies these issues, and is preferably useable in a
script rather than interactively, but there may well be one.

If you are thinking about removing checks, is this some specific checks, or
all of them?

Cheers,
Mike
-Original Message-
From: Gerd Petermann [mailto:gpetermann_muenc...@hotmail.com] 
Sent: 26 May 2021 09:26
To: Development list for mkgmap 
Subject: Re: [mkgmap-dev] logging improvement

Hi Mike,

the sample file will help.
I think I simply don't understand how flare roads affect routing. Do you
have a real world example for me with a description what's wrong and what
effect that has on routing?
If I got you right you use the messages to fix OSM data? Do you have a link
to a changeset?

Gerd


Von: mkgmap-dev  im Auftrag von Mike
Baggaley 
Gesendet: Mittwoch, 26. Mai 2021 10:12
An: 'Development list for mkgmap'
Betreff: Re: [mkgmap-dev] logging improvement

Hi Gerd,

I created a sample file, but forgot to add it to SVN, so the patch didn't
include it.

Please see updated patch, which hopefully explains what it is trying to do.
You have a point about QA checks but is there a validator that checks
flares? I think there is a usefulness in including checks that directly
affect routing.

Cheers,
Mike

-Original Message-
From: Gerd Petermann [mailto:gpetermann_muenc...@hotmail.com]
Sent: 24 May 2021 16:54
To: Development list for mkgmap 
Subject: Re: [mkgmap-dev] logging improvement

Hi Mike,

I tried the patch with 3 tiles around my home and got two messages about
flare roads from the old code where I could not find a problem. The patched
code doesn't report them with --report-roundabout-issues=all
I got some messages about arcs going in and similar, quite confusing because
the reported way id is on the opposite site of the roundabout (RoadMerger
merged some roundabout ways).
I found no false positive in my quick check.

I still don't know what this new config file is about. Maybe you intended to
add a sample in your patch?
I still prefer to remove all those reporting functions instead of adding
complexity. In my eyes mkgmap is simply not the right tool for OSM QA
checks.

Gerd



Von: mkgmap-dev  im Auftrag von Mike
Baggaley 
Gesendet: Montag, 24. Mai 2021 09:14
An: 'Development list for mkgmap'
Betreff: Re: [mkgmap-dev] logging improvement

Hi Gerd,

I know that the field in CheckRoundabouts is never read. It is because the
roundabout direction check is done elsewhere and it re-evaluates the option.
I felt it was better to have the code evaluate the option here for clarity
even if it is not used in that module.

I don't consider it important that the combination of using deprecated and
non-deprecated options be documented. It won't break anything and is
unlikely to ever be experienced.

I'm not sure what is unclear about "Provide a configuration file containing
the rules to be used with the --check-roundabouts=flares option in
determining whether a pair of roads joining a roundabout should be
considered to be flares".

The existing flare handling code is completely useless as it reports far
more incorrect warnings about roads that are not actually flares than those
than are. This patch uses a set of rules to improve the identification of
flares and drop the majority of undesired warnings. It is not perfect, but
is pretty good at identifying flares in the UK which is the area I've tested
it on (and have used it to correct many of the issues reported). The config
file allows the rules to be tweaked if desired to suit other environments or
requirements. I would not want the rules to be hard coded and thus
unchangeable. I suggest you compare the warnings output by this version to
those by the existing code.

Cheers,
Mike

-Original Message-
From: Gerd Petermann [mailto:gpetermann_muenc...@hotmail.com]
Sent: 24 May 2021 06:06
To: Development list for mkgmap 
Subject: Re: [mkgmap-dev] logging improvement

Hi Mike/all,

some remarks:
-

Re: [mkgmap-dev] logging improvement

[Mike Baggaley]

Hi Gerd,

I created a sample file, but forgot to add it to SVN, so the patch didn't
include it.

Please see updated patch, which hopefully explains what it is trying to do.
You have a point about QA checks but is there a validator that checks
flares? I think there is a usefulness in including checks that directly
affect routing.

Cheers,
Mike

-Original Message-
From: Gerd Petermann [mailto:gpetermann_muenc...@hotmail.com] 
Sent: 24 May 2021 16:54
To: Development list for mkgmap 
Subject: Re: [mkgmap-dev] logging improvement

Hi Mike,

I tried the patch with 3 tiles around my home and got two messages about
flare roads from the old code where I could not find a problem. The patched
code doesn't report them with --report-roundabout-issues=all
I got some messages about arcs going in and similar, quite confusing because
the reported way id is on the opposite site of the roundabout (RoadMerger
merged some roundabout ways).
I found no false positive in my quick check.

I still don't know what this new config file is about. Maybe you intended to
add a sample in your patch?
I still prefer to remove all those reporting functions instead of adding
complexity. In my eyes mkgmap is simply not the right tool for OSM QA
checks.

Gerd



Von: mkgmap-dev  im Auftrag von Mike
Baggaley 
Gesendet: Montag, 24. Mai 2021 09:14
An: 'Development list for mkgmap'
Betreff: Re: [mkgmap-dev] logging improvement

Hi Gerd,

I know that the field in CheckRoundabouts is never read. It is because the
roundabout direction check is done elsewhere and it re-evaluates the option.
I felt it was better to have the code evaluate the option here for clarity
even if it is not used in that module.

I don't consider it important that the combination of using deprecated and
non-deprecated options be documented. It won't break anything and is
unlikely to ever be experienced.

I'm not sure what is unclear about "Provide a configuration file containing
the rules to be used with the --check-roundabouts=flares option in
determining whether a pair of roads joining a roundabout should be
considered to be flares".

The existing flare handling code is completely useless as it reports far
more incorrect warnings about roads that are not actually flares than those
than are. This patch uses a set of rules to improve the identification of
flares and drop the majority of undesired warnings. It is not perfect, but
is pretty good at identifying flares in the UK which is the area I've tested
it on (and have used it to correct many of the issues reported). The config
file allows the rules to be tweaked if desired to suit other environments or
requirements. I would not want the rules to be hard coded and thus
unchangeable. I suggest you compare the warnings output by this version to
those by the existing code.

Cheers,
Mike

-Original Message-
From: Gerd Petermann [mailto:gpetermann_muenc...@hotmail.com]
Sent: 24 May 2021 06:06
To: Development list for mkgmap 
Subject: Re: [mkgmap-dev] logging improvement

Hi Mike/all,

some remarks:
- the field RoundaboutCheck.checkRoundaboutDirections is never read. I also
see no easy way to move that check from StyledConverter to RoundaboutCheck.
- it's a bit unclear what the program will do when a mix of new and old
options is used.
- Looking at the docs I've no clue what
--roundabout-flare-rules-config=filename is about. This looks like total
overkill to me as I have no clue why mkgmap should care about the geometry
of flare roads in the first place. What kind of problem should be detected
by those tests and what are those rules about?

Gerd






Von: mkgmap-dev  im Auftrag von Mike
Baggaley 
Gesendet: Samstag, 22. Mai 2021 10:49
An: 'Development list for mkgmap'
Betreff: Re: [mkgmap-dev] logging improvement

Hi Gerd,

Please find attached a version that functions that way.

Cheers,
Mike

-Original Message-
From: Gerd Petermann [mailto:gpetermann_muenc...@hotmail.com]
Sent: 21 May 2021 18:37
To: Development list for mkgmap 
Subject: Re: [mkgmap-dev] logging improvement

Hi Mike,

I want that --check-roundabouts doesn't produce any messages in the console
when no logging.properties are used, just reverses wrong roundabouts.
That's what happened before the logging changes, right?

Gerd


Von: mkgmap-dev  im Auftrag von Mike
Baggaley 
Gesendet: Freitag, 21. Mai 2021 19:25
An: 'Development list for mkgmap'
Betreff: Re: [mkgmap-dev] logging improvement

Hi Gerd,

Do you mean that --check-roundabouts (and --check-roundabout-flares)  should
not switch on any checks? If so, I think it would be best to change the
wording from deprecated to obsolete in the messages and documentation, to
indicate you won't get any checks.

Another way would be to make those options stop execution, thus forcing
users to choose whatever new option they want.

Cheers,
Mike

-Original Message-

Re: [mkgmap-dev] logging improvement

[Mike Baggaley]

Hi Gerd, 

I know that the field in CheckRoundabouts is never read. It is because the
roundabout direction check is done elsewhere and it re-evaluates the option.
I felt it was better to have the code evaluate the option here for clarity
even if it is not used in that module.

I don't consider it important that the combination of using deprecated and
non-deprecated options be documented. It won't break anything and is
unlikely to ever be experienced.

I'm not sure what is unclear about "Provide a configuration file containing
the rules to be used with the --check-roundabouts=flares option in
determining whether a pair of roads joining a roundabout should be
considered to be flares".

The existing flare handling code is completely useless as it reports far
more incorrect warnings about roads that are not actually flares than those
than are. This patch uses a set of rules to improve the identification of
flares and drop the majority of undesired warnings. It is not perfect, but
is pretty good at identifying flares in the UK which is the area I've tested
it on (and have used it to correct many of the issues reported). The config
file allows the rules to be tweaked if desired to suit other environments or
requirements. I would not want the rules to be hard coded and thus
unchangeable. I suggest you compare the warnings output by this version to
those by the existing code.

Cheers,
Mike

-Original Message-
From: Gerd Petermann [mailto:gpetermann_muenc...@hotmail.com] 
Sent: 24 May 2021 06:06
To: Development list for mkgmap 
Subject: Re: [mkgmap-dev] logging improvement

Hi Mike/all,

some remarks:
- the field RoundaboutCheck.checkRoundaboutDirections is never read. I also
see no easy way to move that check from StyledConverter to RoundaboutCheck.
- it's a bit unclear what the program will do when a mix of new and old
options is used.
- Looking at the docs I've no clue what
--roundabout-flare-rules-config=filename is about. This looks like total
overkill to me as I have no clue why mkgmap should care about the geometry
of flare roads in the first place. What kind of problem should be detected
by those tests and what are those rules about?

Gerd






Von: mkgmap-dev  im Auftrag von Mike
Baggaley 
Gesendet: Samstag, 22. Mai 2021 10:49
An: 'Development list for mkgmap'
Betreff: Re: [mkgmap-dev] logging improvement

Hi Gerd,

Please find attached a version that functions that way.

Cheers,
Mike

-Original Message-
From: Gerd Petermann [mailto:gpetermann_muenc...@hotmail.com]
Sent: 21 May 2021 18:37
To: Development list for mkgmap 
Subject: Re: [mkgmap-dev] logging improvement

Hi Mike,

I want that --check-roundabouts doesn't produce any messages in the console
when no logging.properties are used, just reverses wrong roundabouts.
That's what happened before the logging changes, right?

Gerd


Von: mkgmap-dev  im Auftrag von Mike
Baggaley 
Gesendet: Freitag, 21. Mai 2021 19:25
An: 'Development list for mkgmap'
Betreff: Re: [mkgmap-dev] logging improvement

Hi Gerd,

Do you mean that --check-roundabouts (and --check-roundabout-flares)  should
not switch on any checks? If so, I think it would be best to change the
wording from deprecated to obsolete in the messages and documentation, to
indicate you won't get any checks.

Another way would be to make those options stop execution, thus forcing
users to choose whatever new option they want.

Cheers,
Mike

-Original Message-
From: Gerd Petermann [mailto:gpetermann_muenc...@hotmail.com]
Sent: 21 May 2021 13:56
To: Development list for mkgmap 
Subject: Re: [mkgmap-dev] logging improvement

Hi Mike,

I meant to only set fixRoundaboutDirections to true when --check-roundabouts
is used.
My understanding is that only few users care about the messages from the
checks, they just enabled the option in the hope for better results in the
map.

Gerd


Von: mkgmap-dev  im Auftrag von Mike
Baggaley 
Gesendet: Freitag, 21. Mai 2021 14:12
An: 'Development list for mkgmap'
Betreff: Re: [mkgmap-dev] logging improvement

HI Gerd,

Happy to set --fix-roundabout-direction on if --check-roundabouts is set -
see attached updated patch.

The reversing it message is only shown when fixRoundaboutDirections is set
to true.

Cheers,
Mike

-Original Message-
From: Gerd Petermann [mailto:gpetermann_muenc...@hotmail.com]
Sent: 20 May 2021 14:07
To: Development list for mkgmap 
Subject: Re: [mkgmap-dev] logging improvement

Hi Mike,

sorry, that slipped my mind.
I've not tried it yet but I think the deprecated --check-roundabouts option
should be interpreted as  --fix-roundabout-direction
so that the IMG file is the same as before.
The message "... reversing it " is logged when --check-roundabouts  is used
but the way is not reversed?

Gerd


Von: mkgmap-dev  im Auftrag von Mike
Baggaley 
Gese

Re: [mkgmap-dev] Similar Arcs

[Mike Baggaley]

Hi Gerd,

The primary reason for the patch and hence the rules is to reduce the number
of similar arcs warnings to a manageable number that are actually useful. A
useful side effect is slightly reducing the size of the map. Many of the
warnings are caused by highway areas overlapping linear highways. You are
right that the patch does cause incorrect routing data - the first few I
tried to route over seemed to be OK, but others failed, so I assume it is
just luck when one still works. I can't find any NodCheck in the code, and
with all warnings enabled, I don't see any messages relating to this. I was
following your suggestion about using the code for --report-similar-arcs as
a base to drop overlapping arcs. Checking back, I see you did mention you
didn't know whether this would produce incorrect NOD data. I have realised I
also need to delete the reverse arc and have added code for that, but
haven't discovered how the NOD data is connected. Can you point me in the
right direction? Don't suppose there is any documentation about the code
structure...

Cheers,
Mike

-Original Message-
From: Gerd Petermann [mailto:gpetermann_muenc...@hotmail.com] 
Sent: 22 May 2021 06:31
To: Development list for mkgmap 
Subject: Re: [mkgmap-dev] Similar Arcs

Hi Mike,

what exactly is the benefit of those rules? What's the problem if the
similar arcs are not removed?
I can't belief that this works without causing possibly wrong routing data.
Doesn't NodCheck complain about the removed arcs?

Gerd


Von: mkgmap-dev  im Auftrag von Mike
Baggaley 
Gesendet: Samstag, 22. Mai 2021 00:51
An: 'Development list for mkgmap'
Betreff: [mkgmap-dev] Similar Arcs

Hi Gerd,

Please find attached the patch for deleting similar arcs. It uses a new
mkgmap:nooverlap tag which can be set to a number between 0 and 127 (default
0) in the lines file. If set to a number greater than zero then the
overlapping part of the line will be deleted if it overlaps another line,
providing the access of the other line is a superset of its access. If both
lines have non zero values and have the same access then the line with the
higher value will be deleted.

In my style file I have the following:

highway=service & (area=yes | mkgmap:mp_created=true) & (foot=yes |
foot=designated | foot=official | foot=permissive | (foot!=* & (access!=* |
access=yes | access=permissive))) {set mkgmap:car=no; set mkgmap:bicycle=no;
set foot=yes; set mkgmap:flare-check=no; set mkgmap:numbers=false; set
mkgmap:set_unconnected_type=none; set mkgmap:set_semi_connected_type=none;
set mkgmap:nooverlap=1} [0x13 road_class=0 road_speed=0 resolution 22]

highway=pedestrian & (area=yes | mkgmap:mp_created=true) & (foot=yes |
foot=designated | foot=official | foot=permissive | (foot!=* & (access!=* |
access=yes | access=permissive))) {set mkgmap:car=no; set mkgmap:bicycle=no;
set foot=yes; set mkgmap:flare-check=no; set mkgmap:numbers=false; set
mkgmap:set_unconnected_type=none; set mkgmap:set_semi_connected_type=none;
set mkgmap:nooverlap=1} [0x0d road_class=0 road_speed=0 resolution 22]

amenity=parking & (parking!=* | parking=surface) & (foot=yes |
foot=designated | foot=official | foot=permissive | (foot!=* & (access!=* |
access=yes | access=permissive))) {set mkgmap:car=no; set mkgmap:bicycle=no;
set foot=yes; set mkgmap:numbers=false; set
mkgmap:set_unconnected_type=none; set mkgmap:set_semi_connected_type=none;
set mkgmap:nooverlap=2; set mkgmap:delivery=no; set mkgmap:truck=no; set
mkgmap:bus=no; set mkgmap:taxi=no; set mkgmap:emergency=no } [0x08
road_class=0 road_speed=0 resolution 24 continue]

and similar for railway=platform, man_made=pier, man_made=jetty and
leisure=slipway.

Cheers,
Mike


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

Re: [mkgmap-dev] logging improvement

[Mike Baggaley]

Hi Gerd,

Please find attached a version that functions that way.

Cheers,
Mike

-Original Message-
From: Gerd Petermann [mailto:gpetermann_muenc...@hotmail.com] 
Sent: 21 May 2021 18:37
To: Development list for mkgmap 
Subject: Re: [mkgmap-dev] logging improvement

Hi Mike,

I want that --check-roundabouts doesn't produce any messages in the console
when no logging.properties are used, just reverses wrong roundabouts.
That's what happened before the logging changes, right?

Gerd


Von: mkgmap-dev  im Auftrag von Mike
Baggaley 
Gesendet: Freitag, 21. Mai 2021 19:25
An: 'Development list for mkgmap'
Betreff: Re: [mkgmap-dev] logging improvement

Hi Gerd,

Do you mean that --check-roundabouts (and --check-roundabout-flares)  should
not switch on any checks? If so, I think it would be best to change the
wording from deprecated to obsolete in the messages and documentation, to
indicate you won't get any checks.

Another way would be to make those options stop execution, thus forcing
users to choose whatever new option they want.

Cheers,
Mike

-Original Message-
From: Gerd Petermann [mailto:gpetermann_muenc...@hotmail.com]
Sent: 21 May 2021 13:56
To: Development list for mkgmap 
Subject: Re: [mkgmap-dev] logging improvement

Hi Mike,

I meant to only set fixRoundaboutDirections to true when --check-roundabouts
is used.
My understanding is that only few users care about the messages from the
checks, they just enabled the option in the hope for better results in the
map.

Gerd


Von: mkgmap-dev  im Auftrag von Mike
Baggaley 
Gesendet: Freitag, 21. Mai 2021 14:12
An: 'Development list for mkgmap'
Betreff: Re: [mkgmap-dev] logging improvement

HI Gerd,

Happy to set --fix-roundabout-direction on if --check-roundabouts is set -
see attached updated patch.

The reversing it message is only shown when fixRoundaboutDirections is set
to true.

Cheers,
Mike

-Original Message-
From: Gerd Petermann [mailto:gpetermann_muenc...@hotmail.com]
Sent: 20 May 2021 14:07
To: Development list for mkgmap 
Subject: Re: [mkgmap-dev] logging improvement

Hi Mike,

sorry, that slipped my mind.
I've not tried it yet but I think the deprecated --check-roundabouts option
should be interpreted as  --fix-roundabout-direction
so that the IMG file is the same as before.
The message "... reversing it " is logged when --check-roundabouts  is used
but the way is not reversed?

Gerd


Von: mkgmap-dev  im Auftrag von Mike
Baggaley 
Gesendet: Donnerstag, 20. Mai 2021 13:13
An: 'Development list for mkgmap'
Betreff: Re: [mkgmap-dev] logging improvement

Hi Gerd,

I have already sent you the roundabout checks patch which covers both of the
requests. It may have got missed as I know you are heavily involved in other
issues at the moment. I've attached a copy.

Cheers,
Mike

-Original Message-
From: Gerd Petermann [mailto:gpetermann_muenc...@hotmail.com]
Sent: 20 May 2021 10:20
To: Development list for mkgmap 
Subject: Re: [mkgmap-dev] logging improvement

Hi Mike,

I've hoped for a patch reg. the messages about roundabouts for users without
a logging.config.
I think we need a way to enable the functionality of reversing roundabouts
(done in StyledConverter) without also getting all the check messages from
RoadNetwork.

Gerd


Von: mkgmap-dev  im Auftrag von Mike
Baggaley 
Gesendet: Mittwoch, 19. Mai 2021 12:18
An: 'Development list for mkgmap'
Betreff: Re: [mkgmap-dev] logging improvement

Hi Gerd,

Please find attached the updated patch. In most cases where ways are
duplicated, the duplicate ways are given a faked id. However, there are 3
places in StyledConverter where the id is copied rather than using a faked
id - in addRoad, splitWayAt and makeCycleWay. I am unsure as to whether this
is intentional or an oversight, so have left the id as it is currently (I
have had to introduce new Way copy constructors to handle this). If these
should also use a faked id, I can update the patch.

I have followed your suggestion of amending the similar arcs code to get rid
of duplicated ways, and using my style file have reduced the number of
similar arcs warnings from about 21000 to about 600 which also results in a
reduction in size of the gmapsupp file. I will be posting this patch
shortly.

Cheers,
Mike

-Original Message-----
From: Mike Baggaley [mailto:m...@tvage.co.uk]
Sent: 16 May 2021 08:48
To: 'Development list for mkgmap' 
Subject: RE: [mkgmap-dev] logging improvement

Hi Gerd,

There are lots of pedestrian areas that are relations. Some of these overlap
with adjacent pedestrian areas and produce a warning like:

Similar arcs (generated way) and (generated way) found at
http://www.openstreetmap.org/?mlat=50.728438=-1.143728=17

However, don't commit it yet - I have realised that although this fixes most
of the messages, there are some still being

[mkgmap-dev] Similar Arcs

[Mike Baggaley]

Hi Gerd,

Please find attached the patch for deleting similar arcs. It uses a new
mkgmap:nooverlap tag which can be set to a number between 0 and 127 (default
0) in the lines file. If set to a number greater than zero then the
overlapping part of the line will be deleted if it overlaps another line,
providing the access of the other line is a superset of its access. If both
lines have non zero values and have the same access then the line with the
higher value will be deleted.

In my style file I have the following:

highway=service & (area=yes | mkgmap:mp_created=true) & (foot=yes |
foot=designated | foot=official | foot=permissive | (foot!=* & (access!=* |
access=yes | access=permissive))) {set mkgmap:car=no; set mkgmap:bicycle=no;
set foot=yes; set mkgmap:flare-check=no; set mkgmap:numbers=false; set
mkgmap:set_unconnected_type=none; set mkgmap:set_semi_connected_type=none;
set mkgmap:nooverlap=1} [0x13 road_class=0 road_speed=0 resolution 22]

highway=pedestrian & (area=yes | mkgmap:mp_created=true) & (foot=yes |
foot=designated | foot=official | foot=permissive | (foot!=* & (access!=* |
access=yes | access=permissive))) {set mkgmap:car=no; set mkgmap:bicycle=no;
set foot=yes; set mkgmap:flare-check=no; set mkgmap:numbers=false; set
mkgmap:set_unconnected_type=none; set mkgmap:set_semi_connected_type=none;
set mkgmap:nooverlap=1} [0x0d road_class=0 road_speed=0 resolution 22]

amenity=parking & (parking!=* | parking=surface) & (foot=yes |
foot=designated | foot=official | foot=permissive | (foot!=* & (access!=* |
access=yes | access=permissive))) {set mkgmap:car=no; set mkgmap:bicycle=no;
set foot=yes; set mkgmap:numbers=false; set
mkgmap:set_unconnected_type=none; set mkgmap:set_semi_connected_type=none;
set mkgmap:nooverlap=2; set mkgmap:delivery=no; set mkgmap:truck=no; set
mkgmap:bus=no; set mkgmap:taxi=no; set mkgmap:emergency=no } [0x08
road_class=0 road_speed=0 resolution 24 continue]

and similar for railway=platform, man_made=pier, man_made=jetty and
leisure=slipway.

Cheers,
Mike


similararcs.patch
Description: Binary data
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

Re: [mkgmap-dev] logging improvement

[Mike Baggaley]

Hi Gerd, 

Do you mean that --check-roundabouts (and --check-roundabout-flares)  should
not switch on any checks? If so, I think it would be best to change the
wording from deprecated to obsolete in the messages and documentation, to
indicate you won't get any checks.

Another way would be to make those options stop execution, thus forcing
users to choose whatever new option they want.

Cheers,
Mike

-Original Message-
From: Gerd Petermann [mailto:gpetermann_muenc...@hotmail.com] 
Sent: 21 May 2021 13:56
To: Development list for mkgmap 
Subject: Re: [mkgmap-dev] logging improvement

Hi Mike,

I meant to only set fixRoundaboutDirections to true when --check-roundabouts
is used.
My understanding is that only few users care about the messages from the
checks, they just enabled the option in the hope for better results in the
map.

Gerd


Von: mkgmap-dev  im Auftrag von Mike
Baggaley 
Gesendet: Freitag, 21. Mai 2021 14:12
An: 'Development list for mkgmap'
Betreff: Re: [mkgmap-dev] logging improvement

HI Gerd,

Happy to set --fix-roundabout-direction on if --check-roundabouts is set -
see attached updated patch.

The reversing it message is only shown when fixRoundaboutDirections is set
to true.

Cheers,
Mike

-Original Message-
From: Gerd Petermann [mailto:gpetermann_muenc...@hotmail.com]
Sent: 20 May 2021 14:07
To: Development list for mkgmap 
Subject: Re: [mkgmap-dev] logging improvement

Hi Mike,

sorry, that slipped my mind.
I've not tried it yet but I think the deprecated --check-roundabouts option
should be interpreted as  --fix-roundabout-direction
so that the IMG file is the same as before.
The message "... reversing it " is logged when --check-roundabouts  is used
but the way is not reversed?

Gerd


Von: mkgmap-dev  im Auftrag von Mike
Baggaley 
Gesendet: Donnerstag, 20. Mai 2021 13:13
An: 'Development list for mkgmap'
Betreff: Re: [mkgmap-dev] logging improvement

Hi Gerd,

I have already sent you the roundabout checks patch which covers both of the
requests. It may have got missed as I know you are heavily involved in other
issues at the moment. I've attached a copy.

Cheers,
Mike

-Original Message-
From: Gerd Petermann [mailto:gpetermann_muenc...@hotmail.com]
Sent: 20 May 2021 10:20
To: Development list for mkgmap 
Subject: Re: [mkgmap-dev] logging improvement

Hi Mike,

I've hoped for a patch reg. the messages about roundabouts for users without
a logging.config.
I think we need a way to enable the functionality of reversing roundabouts
(done in StyledConverter) without also getting all the check messages from
RoadNetwork.

Gerd


Von: mkgmap-dev  im Auftrag von Mike
Baggaley 
Gesendet: Mittwoch, 19. Mai 2021 12:18
An: 'Development list for mkgmap'
Betreff: Re: [mkgmap-dev] logging improvement

Hi Gerd,

Please find attached the updated patch. In most cases where ways are
duplicated, the duplicate ways are given a faked id. However, there are 3
places in StyledConverter where the id is copied rather than using a faked
id - in addRoad, splitWayAt and makeCycleWay. I am unsure as to whether this
is intentional or an oversight, so have left the id as it is currently (I
have had to introduce new Way copy constructors to handle this). If these
should also use a faked id, I can update the patch.

I have followed your suggestion of amending the similar arcs code to get rid
of duplicated ways, and using my style file have reduced the number of
similar arcs warnings from about 21000 to about 600 which also results in a
reduction in size of the gmapsupp file. I will be posting this patch
shortly.

Cheers,
Mike

-Original Message-----
From: Mike Baggaley [mailto:m...@tvage.co.uk]
Sent: 16 May 2021 08:48
To: 'Development list for mkgmap' 
Subject: RE: [mkgmap-dev] logging improvement

Hi Gerd,

There are lots of pedestrian areas that are relations. Some of these overlap
with adjacent pedestrian areas and produce a warning like:

Similar arcs (generated way) and (generated way) found at
http://www.openstreetmap.org/?mlat=50.728438=-1.143728=17

However, don't commit it yet - I have realised that although this fixes most
of the messages, there are some still being displayed as generated way,
presumably because the relation is copied prior to being used. I'm looking
at this now. The above example after the patch displays:

Similar arcs (generated way) and
(http://www.openstreetmap.org/relation/9381074) found at
http://www.openstreetmap.org/?mlat=50.728438=-1.143728=17

Cheers,
Mike

-Original Message-
From: Gerd Petermann [mailto:gpetermann_muenc...@hotmail.com]
Sent: 16 May 2021 07:32
To: Development list for mkgmap 
Subject: Re: [mkgmap-dev] logging improvement

Hi Mike,

please help me: In what situation do we create roads from ways which were
created from relations?

Gerd


Von: mkgmap-dev  im Auftra

Re: [mkgmap-dev] logging improvement

[Mike Baggaley]

HI Gerd,

Happy to set --fix-roundabout-direction on if --check-roundabouts is set -
see attached updated patch.

The reversing it message is only shown when fixRoundaboutDirections is set
to true.

Cheers,
Mike

-Original Message-
From: Gerd Petermann [mailto:gpetermann_muenc...@hotmail.com] 
Sent: 20 May 2021 14:07
To: Development list for mkgmap 
Subject: Re: [mkgmap-dev] logging improvement

Hi Mike,

sorry, that slipped my mind.
I've not tried it yet but I think the deprecated --check-roundabouts option
should be interpreted as  --fix-roundabout-direction
so that the IMG file is the same as before.
The message "... reversing it " is logged when --check-roundabouts  is used
but the way is not reversed?

Gerd


Von: mkgmap-dev  im Auftrag von Mike
Baggaley 
Gesendet: Donnerstag, 20. Mai 2021 13:13
An: 'Development list for mkgmap'
Betreff: Re: [mkgmap-dev] logging improvement

Hi Gerd,

I have already sent you the roundabout checks patch which covers both of the
requests. It may have got missed as I know you are heavily involved in other
issues at the moment. I've attached a copy.

Cheers,
Mike

-Original Message-
From: Gerd Petermann [mailto:gpetermann_muenc...@hotmail.com]
Sent: 20 May 2021 10:20
To: Development list for mkgmap 
Subject: Re: [mkgmap-dev] logging improvement

Hi Mike,

I've hoped for a patch reg. the messages about roundabouts for users without
a logging.config.
I think we need a way to enable the functionality of reversing roundabouts
(done in StyledConverter) without also getting all the check messages from
RoadNetwork.

Gerd


Von: mkgmap-dev  im Auftrag von Mike
Baggaley 
Gesendet: Mittwoch, 19. Mai 2021 12:18
An: 'Development list for mkgmap'
Betreff: Re: [mkgmap-dev] logging improvement

Hi Gerd,

Please find attached the updated patch. In most cases where ways are
duplicated, the duplicate ways are given a faked id. However, there are 3
places in StyledConverter where the id is copied rather than using a faked
id - in addRoad, splitWayAt and makeCycleWay. I am unsure as to whether this
is intentional or an oversight, so have left the id as it is currently (I
have had to introduce new Way copy constructors to handle this). If these
should also use a faked id, I can update the patch.

I have followed your suggestion of amending the similar arcs code to get rid
of duplicated ways, and using my style file have reduced the number of
similar arcs warnings from about 21000 to about 600 which also results in a
reduction in size of the gmapsupp file. I will be posting this patch
shortly.

Cheers,
Mike

-Original Message-----
From: Mike Baggaley [mailto:m...@tvage.co.uk]
Sent: 16 May 2021 08:48
To: 'Development list for mkgmap' 
Subject: RE: [mkgmap-dev] logging improvement

Hi Gerd,

There are lots of pedestrian areas that are relations. Some of these overlap
with adjacent pedestrian areas and produce a warning like:

Similar arcs (generated way) and (generated way) found at
http://www.openstreetmap.org/?mlat=50.728438=-1.143728=17

However, don't commit it yet - I have realised that although this fixes most
of the messages, there are some still being displayed as generated way,
presumably because the relation is copied prior to being used. I'm looking
at this now. The above example after the patch displays:

Similar arcs (generated way) and
(http://www.openstreetmap.org/relation/9381074) found at
http://www.openstreetmap.org/?mlat=50.728438=-1.143728=17

Cheers,
Mike

-Original Message-
From: Gerd Petermann [mailto:gpetermann_muenc...@hotmail.com]
Sent: 16 May 2021 07:32
To: Development list for mkgmap 
Subject: Re: [mkgmap-dev] logging improvement

Hi Mike,

please help me: In what situation do we create roads from ways which were
created from relations?

Gerd


Von: mkgmap-dev  im Auftrag von Mike
Baggaley 
Gesendet: Samstag, 15. Mai 2021 14:31
An: 'Development list for mkgmap'
Betreff: [mkgmap-dev] logging improvement

Hi Gerd,

Please find attached a small patch that changes the logging of RoadDef when
the original element is a relation. Currently it just says "generated way";
with the patch it gives the URL of the relation in the same way as it does
for ways.

Cheers,
Mike





roundaboutchecks2.patch
Description: Binary data
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

Re: [mkgmap-dev] logging improvement

[Mike Baggaley]

Hi Gerd,

I have already sent you the roundabout checks patch which covers both of the
requests. It may have got missed as I know you are heavily involved in other
issues at the moment. I've attached a copy.

Cheers,
Mike

-Original Message-
From: Gerd Petermann [mailto:gpetermann_muenc...@hotmail.com] 
Sent: 20 May 2021 10:20
To: Development list for mkgmap 
Subject: Re: [mkgmap-dev] logging improvement

Hi Mike,

I've hoped for a patch reg. the messages about roundabouts for users without
a logging.config.
I think we need a way to enable the functionality of reversing roundabouts
(done in StyledConverter) without also getting all the check messages from
RoadNetwork.

Gerd


Von: mkgmap-dev  im Auftrag von Mike
Baggaley 
Gesendet: Mittwoch, 19. Mai 2021 12:18
An: 'Development list for mkgmap'
Betreff: Re: [mkgmap-dev] logging improvement

Hi Gerd,

Please find attached the updated patch. In most cases where ways are
duplicated, the duplicate ways are given a faked id. However, there are 3
places in StyledConverter where the id is copied rather than using a faked
id - in addRoad, splitWayAt and makeCycleWay. I am unsure as to whether this
is intentional or an oversight, so have left the id as it is currently (I
have had to introduce new Way copy constructors to handle this). If these
should also use a faked id, I can update the patch.

I have followed your suggestion of amending the similar arcs code to get rid
of duplicated ways, and using my style file have reduced the number of
similar arcs warnings from about 21000 to about 600 which also results in a
reduction in size of the gmapsupp file. I will be posting this patch
shortly.

Cheers,
Mike

-Original Message-
From: Mike Baggaley [mailto:m...@tvage.co.uk]
Sent: 16 May 2021 08:48
To: 'Development list for mkgmap' 
Subject: RE: [mkgmap-dev] logging improvement

Hi Gerd,

There are lots of pedestrian areas that are relations. Some of these overlap
with adjacent pedestrian areas and produce a warning like:

Similar arcs (generated way) and (generated way) found at
http://www.openstreetmap.org/?mlat=50.728438=-1.143728=17

However, don't commit it yet - I have realised that although this fixes most
of the messages, there are some still being displayed as generated way,
presumably because the relation is copied prior to being used. I'm looking
at this now. The above example after the patch displays:

Similar arcs (generated way) and
(http://www.openstreetmap.org/relation/9381074) found at
http://www.openstreetmap.org/?mlat=50.728438=-1.143728=17

Cheers,
Mike

-Original Message-
From: Gerd Petermann [mailto:gpetermann_muenc...@hotmail.com]
Sent: 16 May 2021 07:32
To: Development list for mkgmap 
Subject: Re: [mkgmap-dev] logging improvement

Hi Mike,

please help me: In what situation do we create roads from ways which were
created from relations?

Gerd


Von: mkgmap-dev  im Auftrag von Mike
Baggaley 
Gesendet: Samstag, 15. Mai 2021 14:31
An: 'Development list for mkgmap'
Betreff: [mkgmap-dev] logging improvement

Hi Gerd,

Please find attached a small patch that changes the logging of RoadDef when
the original element is a relation. Currently it just says "generated way";
with the patch it gives the URL of the relation in the same way as it does
for ways.

Cheers,
Mike


--- Begin Message ---
Hi Gerd,

Please find attached the previously discussed patch that splits checking and
fixing roundabouts and flares and provides enhanced flare analysis. I note
that some checks are performed when the style is being processed with others
being performed later. I have not attempted to combine these - is there a
technical reason for the separation, or is it just that the checks were
separately developed?

Thanks,
Mike


roundaboutchecks.patch
Description: Binary data
--- End Message ---
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

Re: [mkgmap-dev] logging improvement

[Mike Baggaley]

Hi Gerd,

Please find attached the updated patch. In most cases where ways are
duplicated, the duplicate ways are given a faked id. However, there are 3
places in StyledConverter where the id is copied rather than using a faked
id - in addRoad, splitWayAt and makeCycleWay. I am unsure as to whether this
is intentional or an oversight, so have left the id as it is currently (I
have had to introduce new Way copy constructors to handle this). If these
should also use a faked id, I can update the patch.

I have followed your suggestion of amending the similar arcs code to get rid
of duplicated ways, and using my style file have reduced the number of
similar arcs warnings from about 21000 to about 600 which also results in a
reduction in size of the gmapsupp file. I will be posting this patch
shortly.

Cheers,
Mike

-Original Message-
From: Mike Baggaley [mailto:m...@tvage.co.uk] 
Sent: 16 May 2021 08:48
To: 'Development list for mkgmap' 
Subject: RE: [mkgmap-dev] logging improvement

Hi Gerd,

There are lots of pedestrian areas that are relations. Some of these overlap
with adjacent pedestrian areas and produce a warning like:

Similar arcs (generated way) and (generated way) found at
http://www.openstreetmap.org/?mlat=50.728438=-1.143728=17

However, don't commit it yet - I have realised that although this fixes most
of the messages, there are some still being displayed as generated way,
presumably because the relation is copied prior to being used. I'm looking
at this now. The above example after the patch displays:

Similar arcs (generated way) and
(http://www.openstreetmap.org/relation/9381074) found at
http://www.openstreetmap.org/?mlat=50.728438=-1.143728=17

Cheers,
Mike

-Original Message-
From: Gerd Petermann [mailto:gpetermann_muenc...@hotmail.com] 
Sent: 16 May 2021 07:32
To: Development list for mkgmap 
Subject: Re: [mkgmap-dev] logging improvement

Hi Mike,

please help me: In what situation do we create roads from ways which were
created from relations?

Gerd


Von: mkgmap-dev  im Auftrag von Mike
Baggaley 
Gesendet: Samstag, 15. Mai 2021 14:31
An: 'Development list for mkgmap'
Betreff: [mkgmap-dev] logging improvement

Hi Gerd,

Please find attached a small patch that changes the logging of RoadDef when
the original element is a relation. Currently it just says "generated way";
with the patch it gives the URL of the relation in the same way as it does
for ways.

Cheers,
Mike



originalid2.patch
Description: Binary data
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

Re: [mkgmap-dev] logging improvement

[Mike Baggaley]

Hi Gerd,

There are lots of pedestrian areas that are relations. Some of these overlap
with adjacent pedestrian areas and produce a warning like:

Similar arcs (generated way) and (generated way) found at
http://www.openstreetmap.org/?mlat=50.728438=-1.143728=17

However, don't commit it yet - I have realised that although this fixes most
of the messages, there are some still being displayed as generated way,
presumably because the relation is copied prior to being used. I'm looking
at this now. The above example after the patch displays:

Similar arcs (generated way) and
(http://www.openstreetmap.org/relation/9381074) found at
http://www.openstreetmap.org/?mlat=50.728438=-1.143728=17

Cheers,
Mike

-Original Message-
From: Gerd Petermann [mailto:gpetermann_muenc...@hotmail.com] 
Sent: 16 May 2021 07:32
To: Development list for mkgmap 
Subject: Re: [mkgmap-dev] logging improvement

Hi Mike,

please help me: In what situation do we create roads from ways which were
created from relations?

Gerd


Von: mkgmap-dev  im Auftrag von Mike
Baggaley 
Gesendet: Samstag, 15. Mai 2021 14:31
An: 'Development list for mkgmap'
Betreff: [mkgmap-dev] logging improvement

Hi Gerd,

Please find attached a small patch that changes the logging of RoadDef when
the original element is a relation. Currently it just says "generated way";
with the patch it gives the URL of the relation in the same way as it does
for ways.

Cheers,
Mike


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

[mkgmap-dev] logging improvement

[Mike Baggaley]

Hi Gerd,

Please find attached a small patch that changes the logging of RoadDef when
the original element is a relation. Currently it just says "generated way";
with the patch it gives the URL of the relation in the same way as it does
for ways.

Cheers,
Mike


originalid.patch
Description: Binary data
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

Re: [mkgmap-dev] Commit r4703: improve RoadMerger (based on merge-roads-reversed-v6.patch)

[Mike Baggaley]

That sounds really promising Gerd. Does this only apply to roads, or can it
also handle other lines? I would like to also reduce multiple railway lines
to a single line at lower resolutions.

Cheers,
Mike

-Original Message-
From: Gerd Petermann [mailto:gpetermann_muenc...@hotmail.com] 
Sent: 12 May 2021 16:56
To: Development list for mkgmap 
Subject: Re: [mkgmap-dev] Commit r4703: improve RoadMerger (based on
merge-roads-reversed-v6.patch)

Hi Felix,

see https://www.mkgmap.org.uk/websvn/revision.php?repname=mkgmap=4711

I think I see a way to really improve rendering of dual carriage ways. Needs
some more experimenting. At the moment only size is reduced in
RemoveObsoletePointsFilter, but the new code seems to be able detect dual
carriage ways. Work in progress...

Gerd


Von: mkgmap-dev  im Auftrag von
Felix Hartmann 
Gesendet: Mittwoch, 12. Mai 2021 16:58
An: Development list for mkgmap
Betreff: Re: [mkgmap-dev] Commit r4703: improve RoadMerger (based on
merge-roads-reversed-v6.patch)

Ah true, if the dp filter changes differently it would not be good. I think
the key could include the max level for no direction change. Just on add the
smaller resolution would need to be considered. However with level 0 dp
filter being invisible in changes anyhow, it's really only important for
level 1 or higher if direction for continue ways can be merged or not.

Also oneway street could be reversed at level 1 or higher.

On Wed, 12 May 2021, 22:37 Gerd Petermann
mailto:gpetermann_muenc...@hotmail.com>>
wrote:
Hi Felix,

I don't understand why you think that the direction is only important at
level 0. Doesn't that depend on the TYP file and the style?
Still, you are probably right that mkgmap could ignore the direction if that
doesn't produce visible differences. We just have to find out if there is a
fixed limit or if we need more options or special tags.
What I try to avoid is the situation that the road is merged and therefore
possibly reduced to a straight line while overlay lines are not merged and
possibly zig-zagging along the road.

Gerd


Von: mkgmap-dev
mailto:mkgmap-dev-boun...@lists.mkgm
ap.org.uk>> im Auftrag von Felix Hartmann
mailto:extremecar...@gmail.com>>
Gesendet: Mittwoch, 12. Mai 2021 15:08
An: Development list for mkgmap
Betreff: Re: [mkgmap-dev] Commit r4703: improve RoadMerger (based on
merge-roads-reversed-v6.patch)

Actually besides rivers all lines can be reversed from level1 onwards - Is
that possible or can ways not be reversed if the direction may not be
changed in level 0?

Also it would be good if adding {add mkgmap:has-direction=true}
is only relevant for future lines if continue with_actions is used, but not
if continue is used. E.g. if a road has cycleway = lane:left I display it
only at resolution 24, however the road itself can be reversed. Just not the
cycleway line that is a second line to the left side of the road. The road
also is later in my style vs the cycleway. That way maybe some additional
lines can be reversed.

In general for Austria or Germany this gives pretty nice improvements in map
size. For less developed countries the differences are smaller...

On Tue, 11 May 2021 at 19:21, Gerd Petermann
mailto:gpetermann_muenc...@hotmail.com>mailto:gpetermann_muenc...@hotmail.com>>
> wrote:
Hi Mike,

it is off by default because it will cause trouble with some styles / TYP
files which rely on the direction but don't set that the new special tag
(yet).

Gerd


Von: mkgmap-dev
mailto:mkgmap-dev-boun...@lists.mkgm
ap.org.uk><mailto:mkgmap-dev-boun...@lists.mkgmap.org.uk<mailto:mkgmap-dev-b
oun...@lists.mkgmap.org.uk>>> im Auftrag von Mike Baggaley
mailto:m...@tvage.co.uk><mailto:m...@tvage.co.uk<mailto:mi
k...@tvage.co.uk>>>
Gesendet: Dienstag, 11. Mai 2021 13:15
An:
mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk>mailto:mkgmap-dev@lists.mkgmap.org.uk>>
Betreff: Re: [mkgmap-dev] Commit r4703: improve RoadMerger (based on
merge-roads-reversed-v6.patch)

Hi Gerd,

I may be misunderstanding this, but the explanation of when it is enabled
seems illogical.

It seems to me that reversing should be the default except on ways that have
mkgmap:has-direction=true unless a switch is given to disable it.

Or it could be off by default and a switch enables it, except for ways that
have mkgmap:has-direction=true.

Cheers,
Mike

-Original Message-
From: svn commit
[mailto:s...@mkgmap.org.uk<mailto:s...@mkgmap.org.uk><mailto:s...@mkgmap.org.uk
<mailto:s...@mkgmap.org.uk>>]
Sent: 11 May 2021 11:22
To:
mkgmap-...@lists.mkgmap.org.uk<mailto:mkgmap-...@lists.mkgmap.org.uk>mailto:mkgmap-...@lists.mkgmap.org.uk>>;
mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk>mailto:mkgmap-dev@lists.mkgmap.org.uk>&g

Re: [mkgmap-dev] Commit r4703: improve RoadMerger (based on merge-roads-reversed-v6.patch)

[Mike Baggaley]

Hi Gerd, 

No problem with that, but I don't think it should be a hidden option, and
the use of 'force' suggests it will reverse ways that are direction
sensitive. I suggest --allow-reverse-merge and add it to the documentation
stating that if your style includes mkgmap:has_direction is it on by
default. I don't have any direction sensitive ways in my style and hence
will need to use the option.

Cheers,
Mike

-Original Message-
From: Gerd Petermann [mailto:gpetermann_muenc...@hotmail.com] 
Sent: 11 May 2021 12:21
To: Development list for mkgmap 
Subject: Re: [mkgmap-dev] Commit r4703: improve RoadMerger (based on
merge-roads-reversed-v6.patch)

Hi Mike,

it is off by default because it will cause trouble with some styles / TYP
files which rely on the direction but don't set that the new special tag
(yet).

Gerd


Von: mkgmap-dev  im Auftrag von Mike
Baggaley 
Gesendet: Dienstag, 11. Mai 2021 13:15
An: mkgmap-dev@lists.mkgmap.org.uk
Betreff: Re: [mkgmap-dev] Commit r4703: improve RoadMerger (based on
merge-roads-reversed-v6.patch)

Hi Gerd,

I may be misunderstanding this, but the explanation of when it is enabled
seems illogical.

It seems to me that reversing should be the default except on ways that have
mkgmap:has-direction=true unless a switch is given to disable it.

Or it could be off by default and a switch enables it, except for ways that
have mkgmap:has-direction=true.

Cheers,
Mike

-Original Message-
From: svn commit [mailto:s...@mkgmap.org.uk]
Sent: 11 May 2021 11:22
To: mkgmap-...@lists.mkgmap.org.uk; mkgmap-dev@lists.mkgmap.org.uk
Subject: [mkgmap-dev] Commit r4703: improve RoadMerger (based on
merge-roads-reversed-v6.patch)

Version mkgmap-r4703 was committed by gerd on Tue, 11 May 2021

improve RoadMerger (based on merge-roads-reversed-v6.patch)
This has two effects:
- it allows RoadMerger to merge roads which build a sharp angle, if that is
done an info message is logged
- it allows RoadMerger to merge roads with different directions be reversing
the order of points if special criteria are met
- implement new special tag mkgmap:has-direction=true which tells mkgmap
that the direction of the way is important and should not be reversed. The
routing tags oneway=yes or oneway=-1 have the same effect, but they also
effect routing. Use this tag if you have a TYP file which renders lines
different (e.g. cycleway on the right or on the left side) to prevent a
reverse merge
- implements new experimental option --x-force-reverse-merge

Merging with reverse produces smaller maps, esp. smaller NET and NOD files,
it may have an influence on routing.
Reversing of roads is disabled unless mkgmap detects that the style has at
least one rule which adds mkgmap:has-direction=true in rule file lines or
option --x-force-reverse-merge is used.
The program checks if any line that was added for a given OSM way has the
tag mkgmap:has-direction=true.
If one is found the tag is propagated to the road(s) for that OSM way so no
reversing happens.
Roads with different direction attributes are not merged.

The option --x-force-reverse-merge is meant for those who don't use a TYP
file or don't render left/right attributes with different types. All others
should not use the option and adapt the style instead.

http://www.mkgmap.org.uk/websvn/revision.php?repname=mkgmap=4703

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


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

[mkgmap-dev] multipolygon label

[Mike Baggaley]

Hi Gerd,

Please find attached a small patch that fixes a problem with the use of the
label role in multi-polygon relations. Currently, if a node has the role of
label but has no name or a different name from the polygon, a message is
output saying the node will not be used. However, it is used anyway. The
patch stops the override and does not display a warning for a node with no
name.

Cheers,
Mike


RelationLabel.patch
Description: Binary data
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

Re: [mkgmap-dev] Commit r4703: improve RoadMerger (based on merge-roads-reversed-v6.patch)

[Mike Baggaley]

Hi Gerd,

I may be misunderstanding this, but the explanation of when it is enabled seems 
illogical.

It seems to me that reversing should be the default except on ways that have 
mkgmap:has-direction=true unless a switch is given to disable it.

Or it could be off by default and a switch enables it, except for ways that 
have mkgmap:has-direction=true.

Cheers,
Mike

-Original Message-
From: svn commit [mailto:s...@mkgmap.org.uk] 
Sent: 11 May 2021 11:22
To: mkgmap-...@lists.mkgmap.org.uk; mkgmap-dev@lists.mkgmap.org.uk
Subject: [mkgmap-dev] Commit r4703: improve RoadMerger (based on 
merge-roads-reversed-v6.patch)

Version mkgmap-r4703 was committed by gerd on Tue, 11 May 2021

improve RoadMerger (based on merge-roads-reversed-v6.patch)
This has two effects: 
- it allows RoadMerger to merge roads which build a sharp angle, if that is 
done an info message is logged
- it allows RoadMerger to merge roads with different directions be reversing 
the order of points if special criteria are met
- implement new special tag mkgmap:has-direction=true which tells mkgmap that 
the direction of the way is important and should not be reversed. The routing 
tags oneway=yes or oneway=-1 have the same effect, but they also effect 
routing. Use this tag if you have a TYP file which renders lines different 
(e.g. cycleway on the right or on the left side) to prevent a reverse merge
- implements new experimental option --x-force-reverse-merge 

Merging with reverse produces smaller maps, esp. smaller NET and NOD files, it 
may have an influence on routing.
Reversing of roads is disabled unless mkgmap detects that the style has at 
least one rule which adds mkgmap:has-direction=true in rule file lines or 
option --x-force-reverse-merge is used.
The program checks if any line that was added for a given OSM way has the tag 
mkgmap:has-direction=true.
If one is found the tag is propagated to the road(s) for that OSM way so no 
reversing happens.
Roads with different direction attributes are not merged.

The option --x-force-reverse-merge is meant for those who don't use a TYP file 
or don't render left/right attributes with different types. All others should 
not use the option and adapt the style instead.

http://www.mkgmap.org.uk/websvn/revision.php?repname=mkgmap=4703

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

Re: [mkgmap-dev] Duplicate roads added by default style

[Mike Baggaley]

Hi Gerd,

I had been thinking along those lines, but when I saw the previous posts
thought someone else was looking into the same problem.

Cheers,
Mike


-Original Message-
From: Gerd Petermann [mailto:gpetermann_muenc...@hotmail.com] 
Sent: 11 May 2021 10:19
To: Development list for mkgmap 
Subject: Re: [mkgmap-dev] Duplicate roads added by default style

Hi Mike,

maybe you can use the code for --report-similar-arcs as a base to detect and
possible drop identical arcs?
Didn't try it, I have no idea if that may create incorrect NOD data.

Gerd


Von: mkgmap-dev  im Auftrag von Mike
Baggaley 
Gesendet: Montag, 10. Mai 2021 17:15
An: 'Development list for mkgmap'
Betreff: Re: [mkgmap-dev] Duplicate roads added by default style

Hi Gerd,

I misunderstood the problem you were discussing - I was indeed referring to
overlapping ways from different OSM ways. The multiple ways from the same
OSM way is not a problem for me in the style I use (I think - I haven't
enabled any logging of this so perhaps might not have noticed).

Overlapping ways from different OSM ways is however a problem I have. Mainly
because I include routing around car parks and some car parks have part of
their outline coincident with a road.

Cheers,
Mike
-Original Message-
From: Gerd Petermann [mailto:gpetermann_muenc...@hotmail.com]
Sent: 10 May 2021 16:07
To: Development list for mkgmap 
Subject: Re: [mkgmap-dev] Duplicate roads added by default style

Hi Mike,

Please give an example, I don't understand what you mean. Do you talk about
the situation that two OSM ways are overlapping (sharing segments)? That
would be a completely different problem and requires a different check which
maybe also looks at the layer=* tag.

The issue here is that the style adds multiple identical routable lines for
the same OSM way. Those duplicates would just blows up the road network and
therefore can be safely ignored.

The attached patch is like v5 but contains the additional check in
StyledConverter.

Gerd


Von: mkgmap-dev  im Auftrag von Mike
Baggaley 
Gesendet: Montag, 10. Mai 2021 16:56
An: 'Development list for mkgmap'
Betreff: Re: [mkgmap-dev] Duplicate roads added by default style

HI Gerd,

I would ideally like a new mkgmap tag that if found would remove the
duplicated way or part of a way. This could get tricky when the part to be
deleted is in the middle of the way, as it would need to produce two ways.
Something like:

railway=platform {set mkgmap:removeoverlap=true} [0x16 road_class=0
road_speed=0 resolution 23]

The code would need to check that the access of the overlapping way and
could merge the accesses if necessary. A decision would also have to be made
what to do if two overlapping ways both have the tag set.

Cheers,
Mike


-Original Message-
From: Gerd Petermann [mailto:gpetermann_muenc...@hotmail.com]
Sent: 10 May 2021 10:21
To: Development list for mkgmap 
Subject: Re: [mkgmap-dev] Duplicate roads added by default style


Hi Felix,

sure, I meant roads which RoadMerger would combine. Roadmerger checks a lot
more attributes.
Multiple (different) routable ways for one OSM way are quite normal, esp.
with the --make-opposite-cycleways option.

I think it's worth to log a warning for each.

Gerd


Von: mkgmap-dev  im Auftrag von
Felix Hartmann 
Gesendet: Montag, 10. Mai 2021 11:16
An: Development list for mkgmap
Betreff: Re: [mkgmap-dev] Duplicate roads added by default style

It makes the style very complicated to try to remove any identical copies -
I do this by setting loads of temporary keys, that are checked later for
existing or not existing and based on that add or not add other lines.  I
guess some actual duplicates will still happen.

On Mon, 10 May 2021 at 17:14, Felix Hartmann
mailto:extremecar...@gmail.com>> wrote:
hmm no, please no warning. This can be very beneficial. As long as the type
OR road_speed OR road_class OR oneway plus direction is different. The above
of course makes no sense, as it will set exactly the same road twice.

On Mon, 10 May 2021 at 16:49, Gerd Petermann
mailto:gpetermann_muenc...@hotmail.com>>
wrote:
Hi all,

while double checking patch for the RoadMerger I wondered what might happen
if the style adds two or more identical roads for the same OSM way.
Of course this makes no sense but to my surprise I found out that this
really happens with the default style.
A way with e.g. highway=footway and railway=platform is added twice
...
highway=footway {set tmp:stopMopUp=yes} [0x16 road_class=0 road_speed=0
resolution 23 continue with_actions]
...
railway=platform [0x16 road_class=0 road_speed=0 resolution 23]

Of course the default style should be fixed to avoid that but I think mkgmap
can detect this easily and should print a warning when the style does that?

Gerd
___
mkgmap-dev mailing lis

Re: [mkgmap-dev] Commit r4702: show stacktrace when OutOfMemoryError occurs, helps to decide if maxjobs should be decreased or if one of the combiners is the problem

[Mike Baggaley]

Hi Gerd,

Would it not be better for the code to detect whether it is a combiner and 
adjust the message accordingly?

Cheers,
Mike

-Original Message-
From: svn commit [mailto:s...@mkgmap.org.uk] 
Sent: 11 May 2021 08:33
To: mkgmap-...@lists.mkgmap.org.uk; mkgmap-dev@lists.mkgmap.org.uk
Subject: [mkgmap-dev] Commit r4702: show stacktrace when OutOfMemoryError 
occurs, helps to decide if maxjobs should be decreased or if one of the 
combiners is the problem

Version mkgmap-r4702 was committed by gerd on Tue, 11 May 2021

show stacktrace when OutOfMemoryError occurs, helps to decide if maxjobs should 
be decreased or if one of the combiners is the problem


http://www.mkgmap.org.uk/websvn/revision.php?repname=mkgmap=4702

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

Re: [mkgmap-dev] Duplicate roads added by default style

[Mike Baggaley]

Hi Gerd, 

I misunderstood the problem you were discussing - I was indeed referring to
overlapping ways from different OSM ways. The multiple ways from the same
OSM way is not a problem for me in the style I use (I think - I haven't
enabled any logging of this so perhaps might not have noticed).

Overlapping ways from different OSM ways is however a problem I have. Mainly
because I include routing around car parks and some car parks have part of
their outline coincident with a road.

Cheers,
Mike
-Original Message-
From: Gerd Petermann [mailto:gpetermann_muenc...@hotmail.com] 
Sent: 10 May 2021 16:07
To: Development list for mkgmap 
Subject: Re: [mkgmap-dev] Duplicate roads added by default style

Hi Mike,

Please give an example, I don't understand what you mean. Do you talk about
the situation that two OSM ways are overlapping (sharing segments)? That
would be a completely different problem and requires a different check which
maybe also looks at the layer=* tag.

The issue here is that the style adds multiple identical routable lines for
the same OSM way. Those duplicates would just blows up the road network and
therefore can be safely ignored.

The attached patch is like v5 but contains the additional check in
StyledConverter.

Gerd


Von: mkgmap-dev  im Auftrag von Mike
Baggaley 
Gesendet: Montag, 10. Mai 2021 16:56
An: 'Development list for mkgmap'
Betreff: Re: [mkgmap-dev] Duplicate roads added by default style

HI Gerd,

I would ideally like a new mkgmap tag that if found would remove the
duplicated way or part of a way. This could get tricky when the part to be
deleted is in the middle of the way, as it would need to produce two ways.
Something like:

railway=platform {set mkgmap:removeoverlap=true} [0x16 road_class=0
road_speed=0 resolution 23]

The code would need to check that the access of the overlapping way and
could merge the accesses if necessary. A decision would also have to be made
what to do if two overlapping ways both have the tag set.

Cheers,
Mike


-Original Message-
From: Gerd Petermann [mailto:gpetermann_muenc...@hotmail.com]
Sent: 10 May 2021 10:21
To: Development list for mkgmap 
Subject: Re: [mkgmap-dev] Duplicate roads added by default style


Hi Felix,

sure, I meant roads which RoadMerger would combine. Roadmerger checks a lot
more attributes.
Multiple (different) routable ways for one OSM way are quite normal, esp.
with the --make-opposite-cycleways option.

I think it's worth to log a warning for each.

Gerd


Von: mkgmap-dev  im Auftrag von
Felix Hartmann 
Gesendet: Montag, 10. Mai 2021 11:16
An: Development list for mkgmap
Betreff: Re: [mkgmap-dev] Duplicate roads added by default style

It makes the style very complicated to try to remove any identical copies -
I do this by setting loads of temporary keys, that are checked later for
existing or not existing and based on that add or not add other lines.  I
guess some actual duplicates will still happen.

On Mon, 10 May 2021 at 17:14, Felix Hartmann
mailto:extremecar...@gmail.com>> wrote:
hmm no, please no warning. This can be very beneficial. As long as the type
OR road_speed OR road_class OR oneway plus direction is different. The above
of course makes no sense, as it will set exactly the same road twice.

On Mon, 10 May 2021 at 16:49, Gerd Petermann
mailto:gpetermann_muenc...@hotmail.com>>
wrote:
Hi all,

while double checking patch for the RoadMerger I wondered what might happen
if the style adds two or more identical roads for the same OSM way.
Of course this makes no sense but to my surprise I found out that this
really happens with the default style.
A way with e.g. highway=footway and railway=platform is added twice
...
highway=footway {set tmp:stopMopUp=yes} [0x16 road_class=0 road_speed=0
resolution 23 continue with_actions]
...
railway=platform [0x16 road_class=0 road_speed=0 resolution 23]

Of course the default style should be fixed to avoid that but I think mkgmap
can detect this easily and should print a warning when the style does that?

Gerd
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk>
https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev


--
Felix Hartman - Openmtbmap.org & VeloMap.org



--
Felix Hartman - Openmtbmap.org & VeloMap.org



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

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

Re: [mkgmap-dev] Duplicate roads added by default style

[Mike Baggaley]

HI Gerd,

I would ideally like a new mkgmap tag that if found would remove the
duplicated way or part of a way. This could get tricky when the part to be
deleted is in the middle of the way, as it would need to produce two ways.
Something like:

railway=platform {set mkgmap:removeoverlap=true} [0x16 road_class=0
road_speed=0 resolution 23]

The code would need to check that the access of the overlapping way and
could merge the accesses if necessary. A decision would also have to be made
what to do if two overlapping ways both have the tag set.

Cheers,
Mike


-Original Message-
From: Gerd Petermann [mailto:gpetermann_muenc...@hotmail.com] 
Sent: 10 May 2021 10:21
To: Development list for mkgmap 
Subject: Re: [mkgmap-dev] Duplicate roads added by default style


Hi Felix,

sure, I meant roads which RoadMerger would combine. Roadmerger checks a lot
more attributes.
Multiple (different) routable ways for one OSM way are quite normal, esp.
with the --make-opposite-cycleways option.

I think it's worth to log a warning for each.

Gerd


Von: mkgmap-dev  im Auftrag von
Felix Hartmann 
Gesendet: Montag, 10. Mai 2021 11:16
An: Development list for mkgmap
Betreff: Re: [mkgmap-dev] Duplicate roads added by default style

It makes the style very complicated to try to remove any identical copies -
I do this by setting loads of temporary keys, that are checked later for
existing or not existing and based on that add or not add other lines.  I
guess some actual duplicates will still happen.

On Mon, 10 May 2021 at 17:14, Felix Hartmann
mailto:extremecar...@gmail.com>> wrote:
hmm no, please no warning. This can be very beneficial. As long as the type
OR road_speed OR road_class OR oneway plus direction is different. The above
of course makes no sense, as it will set exactly the same road twice.

On Mon, 10 May 2021 at 16:49, Gerd Petermann
mailto:gpetermann_muenc...@hotmail.com>>
wrote:
Hi all,

while double checking patch for the RoadMerger I wondered what might happen
if the style adds two or more identical roads for the same OSM way.
Of course this makes no sense but to my surprise I found out that this
really happens with the default style.
A way with e.g. highway=footway and railway=platform is added twice
...
highway=footway {set tmp:stopMopUp=yes} [0x16 road_class=0 road_speed=0
resolution 23 continue with_actions]
...
railway=platform [0x16 road_class=0 road_speed=0 resolution 23]

Of course the default style should be fixed to avoid that but I think mkgmap
can detect this easily and should print a warning when the style does that?

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


--
Felix Hartman - Openmtbmap.org & VeloMap.org



--
Felix Hartman - Openmtbmap.org & VeloMap.org



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

[mkgmap-dev] roundabout checks

[Mike Baggaley]

Hi Gerd,

Please find attached the previously discussed patch that splits checking and
fixing roundabouts and flares and provides enhanced flare analysis. I note
that some checks are performed when the style is being processed with others
being performed later. I have not attempted to combine these - is there a
technical reason for the separation, or is it just that the checks were
separately developed?

Thanks,
Mike


roundaboutchecks.patch
Description: Binary data
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

Re: [mkgmap-dev] patch: improve RoadMerger: allow to merge roads with reversed points

[Mike Baggaley]

Hi Gerd, 

I believe this activity is a precursor to reducing zig zags at low
resolutions (though I may be confusing two different activities). I think
the case shown here would be better handled by seeing whether at the low
resolution the two entry points to the A13 can be reduced to a single point.
For each side of the junction we would have two coincident one-way roads
that could be reduced to a single two way road. Merging the two one-way
roads into one would prevent this from taking place. I was under the
impression that mkgmap split ways at junctions anyway, so I'm not sure what
would be gained by joining these together. I do not have a full
understanding of the code, so may have misunderstood this bit. 

Cheers,
Mike

-Original Message-
From: Gerd Petermann [mailto:gpetermann_muenc...@hotmail.com] 
Sent: 07 May 2021 08:55
To: Development list for mkgmap 
Subject: Re: [mkgmap-dev] patch: improve RoadMerger: allow to merge roads
with reversed points

Hi all,

See e.g. the link roads which meat at
https://www.openstreetmap.org/node/606366325
I really wonder how mkgmap should treat roads like that which build a sharp
angle. Current code doesn't merge them. I don't know how it worked in 2014
but today I see no good reason for that. Routing results seem to be the same
and mainly depend on the "avoid u-turn" setting.
Maybe there is a difference when the --ignore-sharp-angles is used, but than
that's probably exactly what the user wants?

I've also seen several places where the two link roads are mapped with a
single OSM way.

The correct mapping probably requires two OSM ways and a turn restriction,
but the Garmin routing algo really doesn't like sharp angles anyway and
prefers large detours to avoid them when "avoid u-turn" is enabled.

I've attached a new patch which ignores sharp angles where only two roads
meet. This gives a few more merges.
If you change the line
private static final double MAX_MERGE_ANGLE = 130.0;
to
private static final double MAX_MERGE_ANGLE = 180.0;
mkgmap will still prefer to merge the roads with the smallest angle but will
also merge those with a sharp angle and thus reduce the NOD/NET size even
more.

I think mkgmap should use always merge if --ignore-sharp-angles  is used,
but that's not implemented yet.

Gerd


Von: mkgmap-dev  im Auftrag von Gerd
Petermann 
Gesendet: Freitag, 7. Mai 2021 07:39
An: Development list for mkgmap
Betreff: Re: [mkgmap-dev] patch: improve RoadMerger: allow to merge roads
with reversed points

Hi Felix,

just noticed that patch v3 still only looked for mkgmap:has-direction=1 in
one place.

Anyway, I am very unsure how to handle the direction flag. It's probably not
a good idea to transfer the flag too ALL lines which are created from one
OSM way.

I also found some cases where roads are not merged because the angle is too
sharp. This was discussed
here:http://www.mkgmap.org.uk/pipermail/mkgmap-dev/2013q3/018649.html
I think it was introduced to avoid bad routing at places like
https://www.osm.org/node/606366325 where we don't want to merge the two link
roads.
I think the angle should be ignored if only two roads with the same
attributes meat. Like here: https://www.osm.org/node/1387136827

Gerd


Von: mkgmap-dev  im Auftrag von
Felix Hartmann 
Gesendet: Donnerstag, 6. Mai 2021 17:55
An: Development list for mkgmap
Betreff: Re: [mkgmap-dev] patch: improve RoadMerger: allow to merge roads
with reversed points

ah okay, no worries I can patch it myself.

On Thu, 6 May 2021 at 23:46, Gerd Petermann
mailto:gpetermann_muenc...@hotmail.com>>
wrote:
Hi Felix,

the patch possibly has an influence on routing, so I don't want to add it to
the low-res-opt branch.
I can provide two binaries if needed.

Gerd


Von: mkgmap-dev
mailto:mkgmap-dev-boun...@lists.mkgm
ap.org.uk>> im Auftrag von Felix Hartmann
mailto:extremecar...@gmail.com>>
Gesendet: Donnerstag, 6. Mai 2021 17:42
An: Development list for mkgmap
Betreff: Re: [mkgmap-dev] patch: improve RoadMerger: allow to merge roads
with reversed points

Could you directly push those patches to the low-res branch? I guess anyone
using it right now would like to try it with the patch..
I will try it out tomorrow.

On Thu, 6 May 2021 at 18:32, Gerd Petermann
mailto:gpetermann_muenc...@hotmail.com>mailto:gpetermann_muenc...@hotmail.com>>
> wrote:
Ahh, sorry, merge-roads-reversed-v2.patch was work-in-progress. v3 works as
described before.

Gerd


Von: mkgmap-dev
mailto:mkgmap-dev-boun...@lists.mkgm
ap.org.uk>>> im Auftrag von Gerd Petermann
mailto:gpetermann_muenc...@hotmail.com>mailto:gpetermann_muenc...@hotmail.com>>
>
Gesendet: Donnerstag, 6. Mai 2021 12:30
An: Development list for mkgmap
Betreff: Re: [mkgmap-dev] patch: improve RoadMerger: allow to merge 

[mkgmap-dev] Check Roundabouts

[Mike Baggaley]

Hi Gerd, I haven't posted it yet. I'm away on holiday at the moment, hence the 
lack of input from me as it is difficult to reply to the digest from a phone. I 
will post the patch when I return home.

Cheers, Mike___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

[mkgmap-dev] logging help patch

[Mike Baggaley]

Hi Gerd,

Attached is a patch that provides additional information about logging.

Cheers,
Mike


logging.txt.patch
Description: Binary data
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

Re: [mkgmap-dev] remainder of logging changes

[Mike Baggaley]

Hi Gerd,

I don't think the text implies that you get rid of console messages if you
use a logging config file. I think the best place for any additional
information about setting up a logging file is logging.txt (which I now
notice incorrectly mentions stdout instead of stderr).

It would probably also be useful if logging.txt included a complete list of
the available loggers, as currently you need to read the source to find out
what they are.

With the update you can't display error messages in stderr, with all other
messages going to the log file. If that is something you think important
then I think the way forward is to change the DIAGNOSTIC and ECHO LogLevel
values to between WARNING and ERROR, rather than being above ERROR.
Unfortunately the logging mechanism doesn't allow a range of log levels to
be reported, only allowing filtering out those below a specified level. So
with the current levels you can output DIAGNOSTIC and ECHO messages to
sdterr and filter out other messages, but not vice-versa. Where would you
prefer the DIAGNOSTIC and ECHO levels to sit?

Cheers,
Mike

-Original Message-
From: Gerd Petermann [mailto:gpetermann_muenc...@hotmail.com] 
Sent: 13 April 2021 07:52
To: Development list for mkgmap 
Subject: Re: [mkgmap-dev] remainder of logging changes

Hi Mike,

reg. diagnosticmessages.patch:
My understanding of the text is that you get rid of the console messages if
you use a logging configuration file. When I try this with my existing
config file I don't see this effect because the configuration tells the
logger to also write those messages to the console.
A similar config can be found in the wiki
https://wiki.openstreetmap.org/wiki/Mkgmap/dev#Enabling_Debugging

So, what I am missing is the hint that the config file should NOT contain a
console handler.

Writing this I wonder if it is now impossible to see only error messages on
stderr when the reporting options are enabled?

Gerd


Von: mkgmap-dev  im Auftrag von Mike
Baggaley 
Gesendet: Montag, 12. April 2021 17:56
An: 'Development list for mkgmap'
Betreff: [mkgmap-dev] remainder of logging changes

Hi Gerd,

Please find attached a patch with the remainder of the logging changes
(apart from CommandArgs).

There are changes to the main program so that the dates and times are only
output if mkgmap is processing one or more files.

The patch includes an update to the unit test. Note that this now takes a
little longer to run, because of having to create new processes to run some
of the tests.

BTW, were you expecting a change to diagnosticmessages.patch, or is it OK as
it stands? (I've attached a copy in case it got lost amongst all the
others.)

Cheers,
Mike


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

[mkgmap-dev] check roundabouts

[Mike Baggaley]

Hi Gerd,

I have a largely completed change that extends the --check-roundabouts
option to become
--check-roundabouts=[all|loop|direction[:fix]|junctions|flares] and had made
fixing reversed roundabouts an optional part of the direction option

loop  - check that roundabouts are formed from a single loop
with no forks or gaps
direction[:fix] - check and optionally fix the direction of travel around
the roundabout
junctions  - check that no more than one connecting highway joins at
each node
flares- check that roundabout flare roads are one-way, are
in the right direction, and don't extend beyond the flare

However, separating the options completely allows for correction without
displaying any message if desired, so I will look at that and I will change
the reporting option name to --report-roundabout-issues as suggested, which
brings it into line with the other diagnostic options.

Also included in the change is code to more accurately try to identify
roundabout flares, as the existing code produces more false results than
wanted ones. It replaces --max-flare-length-ratio=NUM with
--roundabout-flare-rules-config=filename where the config file can contain a
set of rules for identifying flares.

Cheers,
Mike

-Original Message-
From: Gerd Petermann [mailto:gpetermann_muenc...@hotmail.com] 
Sent: 12 April 2021 16:10
To: Development list for mkgmap 
Subject: Re: [mkgmap-dev] logging

Hi Mike,

please have a look at the check-roundabouts and --check-roundabout-flares
code. I think we missed the fact that --check-roundabouts may change the
direction of roundabouts (in StyledConverter).
So, I think we need a new option like report-roundabout-issues=[NUM] and
another one for the reversing?

Gerd


Von: mkgmap-dev  im Auftrag von Mike
Baggaley 
Gesendet: Montag, 12. April 2021 17:02
An: 'Development list for mkgmap'
Betreff: [mkgmap-dev] logging

Hi Gerd,

In the attached patch there are a few improvements to messages as well as
some more use of logging:

In ImgFS, the message from the FileNotWritableException was displaying the
filename twice, so I have fixed that.
In TdbBuilder, I have removed an unnecessary log.error
In StyledConverter, I have added the synchronisation code for the removal of
duplicate messages
In O5mBinHandler, I have changed a thrown exception from IOException to
FormatException so that it gets handled by its callers

Cheers,
Mike





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

[mkgmap-dev] remainder of logging changes

[Mike Baggaley]

Hi Gerd,

Please find attached a patch with the remainder of the logging changes
(apart from CommandArgs).

There are changes to the main program so that the dates and times are only
output if mkgmap is processing one or more files.

The patch includes an update to the unit test. Note that this now takes a
little longer to run, because of having to create new processes to run some
of the tests.

BTW, were you expecting a change to diagnosticmessages.patch, or is it OK as
it stands? (I've attached a copy in case it got lost amongst all the
others.)

Cheers,
Mike


diagnosticmessages.patch
Description: Binary data


mainlogging.patch
Description: Binary data
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

[mkgmap-dev] logging

[Mike Baggaley]

Hi Gerd,

In the attached patch there are a few improvements to messages as well as
some more use of logging:

In ImgFS, the message from the FileNotWritableException was displaying the
filename twice, so I have fixed that.
In TdbBuilder, I have removed an unnecessary log.error
In StyledConverter, I have added the synchronisation code for the removal of
duplicate messages
In O5mBinHandler, I have changed a thrown exception from IOException to
FormatException so that it gets handled by its callers

Cheers,
Mike





stillmorelogging.patch
Description: Binary data
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

Re: [mkgmap-dev] Yet More Logging

[Mike Baggaley]

Hi Gerd,
 
No problems with downgrading the message to info (I'd be happy to remove it
completely, as it does seem a little unnecessary), but stopping if the
directory is not OK will require throwing an ExitException and adding
catches to TypCompiler and MapMaker (I think), so I propose to remove
CommandArgs from the patch (see updated patch attached) and create a new one
for it and its related changes.
 
I assume you would want both the "Unable to create output directory! Using
default directory instead" and "The --output-dir parameter must specify a
directory. The parameter is being ignored, writing to default directory
instead" messages changing so that the default directory is not used and
program execution stops.
 
Cheers,
Mike
 
-Original Message-
From: Gerd Petermann [mailto:gpetermann_muenc...@hotmail.com] 
Sent: 11 April 2021 16:58
To: Development list for mkgmap 
Subject: Re: [mkgmap-dev] Yet More Logging
 
Hi Mike,
 
not sure about the changes in CommandArgs. I'd prefer an info message for
the new directory and exit with error if output-dir is not OK.
For me it's normal to remove the directory and let mkgmap create it. If that
fails for whatever reason mkgmap should just stop.
Rest looks good.
 
Gerd
 

Von: mkgmap-dev < <mailto:mkgmap-dev-boun...@lists.mkgmap.org.uk>
mkgmap-dev-boun...@lists.mkgmap.org.uk> im Auftrag von Mike Baggaley <
<mailto:m...@tvage.co.uk> m...@tvage.co.uk>
Gesendet: Sonntag, 11. April 2021 17:44
An: 'Development list for mkgmap'
Betreff: [mkgmap-dev] Yet More Logging
 
Hi Gerd,
 
Here's the next patch. Hopefully should only need a couple more patches to
package up the remainder of the changes.
 
Cheers,
Mike
 


yetmorelogging.v2.patch
Description: Binary data
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

[mkgmap-dev] Yet More Logging

[Mike Baggaley]

Hi Gerd,

Here's the next patch. Hopefully should only need a couple more patches to
package up the remainder of the changes.

Cheers,
Mike


yetmorelogging.patch
Description: Binary data
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

Re: [mkgmap-dev] More logging

[Mike Baggaley]

Hi Gerd, 

Both changes are fine by me. The "Invalid mapname" message I had put as a
warning only because of the preceding comment "Although its not necessarily
wrong for them to be zero, it probably (is a) sign that something is wrong"
- I have no strong conviction about the severity, and it is probably a
message no-one has ever seen.

Cheers,
Mike

-Original Message-
From: Gerd Petermann [mailto:gpetermann_muenc...@hotmail.com] 
Sent: 11 April 2021 16:08
To: Development list for mkgmap 
Subject: Re: [mkgmap-dev] More logging

Hi Mike,


I think MdxFile should use Logger.defaultLogger.error() and maybe
LblFileReader should use Logger.defaultLogger.warn()
(as in attached patch)..
Just my feeling, can't prove anything.

Gerd


Von: mkgmap-dev  im Auftrag von Mike
Baggaley 
Gesendet: Sonntag, 11. April 2021 16:10
An: 'Development list for mkgmap'
Betreff: [mkgmap-dev] More logging

Hi Gerd,

Here is the next patch. This one moves a number of messages from writing to
stdout/err to using logging. There are several files changed, but most have
only very small changes.

I'd be interested to know what the message "Map has tide prediction, please
implement" in LBLFileReader means...

Cheers,
Mike

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

[mkgmap-dev] More logging

[Mike Baggaley]

Hi Gerd,

Here is the next patch. This one moves a number of messages from writing to
stdout/err to using logging. There are several files changed, but most have
only very small changes.

I'd be interested to know what the message "Map has tide prediction, please
implement" in LBLFileReader means... 

Cheers,
Mike


morelogging.patch
Description: Binary data
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

Re: [mkgmap-dev] Re logging improvements

[Mike Baggaley]

Hi Gerd, 

Attached is the next small patch. This brings echo and echotags under
logging control.

Cheers,
Mike

-Original Message-
From: Mike Baggaley [mailto:m...@tvage.co.uk] 
Sent: 11 April 2021 09:59
To: 'Development list for mkgmap' 
Subject: RE: [mkgmap-dev] Re logging improvements

Hi Gerd, 


The text of diagnostic.messages patch seems to me to accurately reflect what
happens now. If someone is using a logging config file, they should
hopefully know where they are asking the output to go and I don't think the
help should mention changes.

I suggest you ignore the other uncommitted patches I've passed to you and
I'll send some new ones to clarify where we are up to.

I mentioned in the text that the Tests.patch wouldn't work with the existing
code, because of some text that was previously going to stdout going to
stderr under the completed set of patches, so I don't expect that to be
committed yet.

Cheers,
Mike

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

Hi Mike,

I fear I'm lost in patches ;)

Maybe you didn't want me to commit diagnostics.patch?
I've tried Tests.patch with r4649 and 3 unit tests fail.
The text in diagnosticmessages.patch should be adapted to our latest
findings reg. the commit message ("diagnostic messages are now written to
stderr unless using a logging configuration without a ConsoleHandler")

Gerd


Von: mkgmap-dev  im Auftrag von Mike
Baggaley 
Gesendet: Freitag, 9. April 2021 09:30
An: 'Development list for mkgmap'
Betreff: [mkgmap-dev] Re logging improvements

Hi Gerd,

Please find attached the updated version of the patch. It adds
synchronisation of the static variables in StyledConverter and fixes the
unit test.

It includes the not yet committed changes in codepage.patch,
diagnostics.patch and Tests.patch.

Cheers,
Mike



echo.patch
Description: Binary data
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

Re: [mkgmap-dev] Re logging improvements

[Mike Baggaley]

Hi Gerd, 


The text of diagnostic.messages patch seems to me to accurately reflect what
happens now. If someone is using a logging config file, they should
hopefully know where they are asking the output to go and I don't think the
help should mention changes.

I suggest you ignore the other uncommitted patches I've passed to you and
I'll send some new ones to clarify where we are up to.

I mentioned in the text that the Tests.patch wouldn't work with the existing
code, because of some text that was previously going to stdout going to
stderr under the completed set of patches, so I don't expect that to be
committed yet.

Cheers,
Mike

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

Hi Mike,

I fear I'm lost in patches ;)

Maybe you didn't want me to commit diagnostics.patch?
I've tried Tests.patch with r4649 and 3 unit tests fail.
The text in diagnosticmessages.patch should be adapted to our latest
findings reg. the commit message ("diagnostic messages are now written to
stderr unless using a logging configuration without a ConsoleHandler")

Gerd


Von: mkgmap-dev  im Auftrag von Mike
Baggaley 
Gesendet: Freitag, 9. April 2021 09:30
An: 'Development list for mkgmap'
Betreff: [mkgmap-dev] Re logging improvements

Hi Gerd,

Please find attached the updated version of the patch. It adds
synchronisation of the static variables in StyledConverter and fixes the
unit test.

It includes the not yet committed changes in codepage.patch,
diagnostics.patch and Tests.patch.

Cheers,
Mike


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

Re: [mkgmap-dev] diagnostic patch

[Mike Baggaley]

Hi Gerd,

I suggest a couple of minor tweaks to the commit message:

diagnostics.patch by Mike Baggaley
- diagnostic messages are now written to stderr when there is no logging
configuration specified.
- diagnostic messages have the level DIAGNOSTIC when they are logged. Before
some had WARNING, some had INFO.
- deprecate option --check-routing-island-len, replaced by new options
--report-routing-islands and --max-routing-island-len
- change documentation for options --report-similar-arcs and
--report-dead-ends

A good idea to add a note about diagnostic reporting to stderr in the
documentation. Please see the attached patch.

I agree that stderr is better than standard error, as it is the usually used
term.

Cheers,
Miike

-Original Message-
From: Gerd Petermann [mailto:gpetermann_muenc...@hotmail.com] 
Sent: 10 April 2021 10:21
To: Development list for mkgmap 
Subject: Re: [mkgmap-dev] diagnostic patch

Hi Mike,

it seems I sometimes "tested" your patch with the binary in the faster-mp
branch, so of course I got confused about the results. Sorry for that.

Reg. reporting to stderr: Maybe this could be documented similar to the
--version option in a further step?
Also confusing: We use the word stderr for version, but "standard error" in
the style docs. I think stderr is much better.

I plan to commit the patch with the attached commit message. Please suggest
improvements if I missed something important.

Gerd



Von: mkgmap-dev  im Auftrag von Mike
Baggaley 
Gesendet: Samstag, 10. April 2021 00:57
An: 'Development list for mkgmap'
Betreff: Re: [mkgmap-dev] diagnostic patch

Hi Gerd,

The primary reason for this part of the change is to make sure that if you
specify a diagnostic option then you get any messages about it included in
your output. Currently the only way to see any of these messages is if you
use a log.config file to enable a lower level of logging. In one case you
have to go as low as info which causes your wanted messages to be buried in
a lot of other messages that you don't necessarily want. The new levels are
higher than ERROR, so will be output providing the log level is set to ERROR
or lower. Using separate levels also makes it easy to filter the output
should you want to do so, so anything at DIAGNOSTIC level will be a message
from  a requested diagnostic option. In the logging config file you can
choose whether you want the level to be included in the message - I don't
include it and I see yours truncates it to 4 characters.

In the log.config file, if you specify a .level= of 1100, you will get just
DIAGNOSTIC, ECHO and OVERRIDE messages (i.e. no error messages), 1200 will
give you just ECHO and OVERRIDE, 1300 just OVERRIDE. You could therefore set
java.util.logging.ConsoleHandler.level=1300, so it will more or less just
output the version number, start and finish times, total time taken and
number of exceptions (once the rest of the changes are added). Having these
3 levels offers more flexibility than lumping them all together at a single
level.

The ConsoleHandler writes all its output to stderr and we have no control
over that. These messages are currently also output to stderr (if you use a
logging.config file to enable the level required to see them).

If I use the logging.config file you sent me, I can see the messages in both
the console and the log file. Have you got ConsoleHandler enabled as a
handler in the config file you are using?

Cheers,
Mike

-Original Message-
From: Gerd Petermann [mailto:gpetermann_muenc...@hotmail.com]
Sent: 09 April 2021 07:48
To: Development list for mkgmap 
Subject: Re: [mkgmap-dev] diagnostic patch

Hi Mike,

reg. diagnostics.patch:

Please help me with the commit message. What changes are implemented?
What changes in output to logging files or console are intended?
Are the new levels meant to be used by the user in the logging.properties
file? If yes, how exactly?

Without logging.properties I see the diagnostics messages like "Roundabout
1374016 direction is wrong - .." written to stderr now. Why not stdout?
If I use -Dlog.config=logging.properties the diagnostic messages are not
written to the console. Is that intended?

Gerd


Von: mkgmap-dev  im Auftrag von Mike
Baggaley 
Gesendet: Mittwoch, 7. April 2021 11:00
An: 'Development list for mkgmap'
Betreff: [mkgmap-dev] diagnostic patch

Hi Gerd,

Please find attached two patches - one that contains the user interface and
logging changes to provide improved output from the diagnostic options,
along with the other logging interface changes in readiness for replacing
direct writes to stdout/err. The second documents the steps that may be
taken to work around code page problems.

Cheers,
Mike


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


diagnosticmessages.

Re: [mkgmap-dev] diagnostic patch

[Mike Baggaley]

Hi Gerd, 

The primary reason for this part of the change is to make sure that if you
specify a diagnostic option then you get any messages about it included in
your output. Currently the only way to see any of these messages is if you
use a log.config file to enable a lower level of logging. In one case you
have to go as low as info which causes your wanted messages to be buried in
a lot of other messages that you don't necessarily want. The new levels are
higher than ERROR, so will be output providing the log level is set to ERROR
or lower. Using separate levels also makes it easy to filter the output
should you want to do so, so anything at DIAGNOSTIC level will be a message
from  a requested diagnostic option. In the logging config file you can
choose whether you want the level to be included in the message - I don't
include it and I see yours truncates it to 4 characters.

In the log.config file, if you specify a .level= of 1100, you will get just
DIAGNOSTIC, ECHO and OVERRIDE messages (i.e. no error messages), 1200 will
give you just ECHO and OVERRIDE, 1300 just OVERRIDE. You could therefore set
java.util.logging.ConsoleHandler.level=1300, so it will more or less just
output the version number, start and finish times, total time taken and
number of exceptions (once the rest of the changes are added). Having these
3 levels offers more flexibility than lumping them all together at a single
level.

The ConsoleHandler writes all its output to stderr and we have no control
over that. These messages are currently also output to stderr (if you use a
logging.config file to enable the level required to see them).

If I use the logging.config file you sent me, I can see the messages in both
the console and the log file. Have you got ConsoleHandler enabled as a
handler in the config file you are using?

Cheers,
Mike

-Original Message-
From: Gerd Petermann [mailto:gpetermann_muenc...@hotmail.com] 
Sent: 09 April 2021 07:48
To: Development list for mkgmap 
Subject: Re: [mkgmap-dev] diagnostic patch

Hi Mike,

reg. diagnostics.patch:

Please help me with the commit message. What changes are implemented?
What changes in output to logging files or console are intended?
Are the new levels meant to be used by the user in the logging.properties
file? If yes, how exactly?

Without logging.properties I see the diagnostics messages like "Roundabout
1374016 direction is wrong - .." written to stderr now. Why not stdout?
If I use -Dlog.config=logging.properties the diagnostic messages are not
written to the console. Is that intended?

Gerd


Von: mkgmap-dev  im Auftrag von Mike
Baggaley 
Gesendet: Mittwoch, 7. April 2021 11:00
An: 'Development list for mkgmap'
Betreff: [mkgmap-dev] diagnostic patch

Hi Gerd,

Please find attached two patches - one that contains the user interface and
logging changes to provide improved output from the diagnostic options,
along with the other logging interface changes in readiness for replacing
direct writes to stdout/err. The second documents the steps that may be
taken to work around code page problems.

Cheers,
Mike


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

Re: [mkgmap-dev] diagnostic patch

[Mike Baggaley]

Hi Gerd, 

Yes your version is much better.

Cheers,
Mike

-Original Message-
From: Gerd Petermann [mailto:gpetermann_muenc...@hotmail.com] 
Sent: 09 April 2021 07:04
To: Development list for mkgmap 
Subject: Re: [mkgmap-dev] diagnostic patch

Hi Mike,

please review my version of the codepage patch. I've added two words.

Gerd


Von: mkgmap-dev  im Auftrag von Mike
Baggaley 
Gesendet: Mittwoch, 7. April 2021 11:00
An: 'Development list for mkgmap'
Betreff: [mkgmap-dev] diagnostic patch

Hi Gerd,

Please find attached two patches - one that contains the user interface and
logging changes to provide improved output from the diagnostic options,
along with the other logging interface changes in readiness for replacing
direct writes to stdout/err. The second documents the steps that may be
taken to work around code page problems.

Cheers,
Mike

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

[mkgmap-dev] Re logging improvements

[Mike Baggaley]

Hi Gerd,

Please find attached the updated version of the patch. It adds
synchronisation of the static variables in StyledConverter and fixes the
unit test.

It includes the not yet committed changes in codepage.patch,
diagnostics.patch and Tests.patch.

Cheers,
Mike


logging4.patch
Description: Binary data
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

[mkgmap-dev] Unit Tests Patch

[Mike Baggaley]

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


Tests.patch
Description: Binary data
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

[mkgmap-dev] diagnostic patch

[Mike Baggaley]

Hi Gerd,

Please find attached two patches - one that contains the user interface and
logging changes to provide improved output from the diagnostic options,
along with the other logging interface changes in readiness for replacing
direct writes to stdout/err. The second documents the steps that may be
taken to work around code page problems.

Cheers,
Mike


codepage.patch
Description: Binary data


diagnostics.patch
Description: Binary data
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

Re: [mkgmap-dev] logging improvements

[Mike Baggaley]

Hi Gerd,

Please find attached small patches to 3 modules that improve their error
handling, plus the patch to remove commented out System.err.println
statements, which has no code changes.

In GmapiBuilder, the print stack trace calls have been replaced with
throwing ExitExceptions as in the other combiners, so that program execution
correctly stops.

In FileInfo, the thrown ReadFailedException has been replaced with a
MapFailedException, so that it is correctly picked up.

In TypSaver, there is an extra check for an empty file as this was not
handled properly.

Regarding the removal of duplicate messages in StyledConverter, I may be
being naively simplistic, but thought that as the data in the static list of
already logged messages has no effect on the actual generation of a map,
that any race condition would not really matter. If two threads attempt to
update at the same time and only one succeeds, the only impact will be that
it is possible that a duplicate message will later be output (assuming the
two threads are reporting different problems). If they are both reporting
the same message (which is most likely) then there will be no impact at all.
If two threads read that a message has not been displayed and then both
successfully manage to add to the list then the only result will be that
there is a duplicate entry in the list, which should have no impact as the
code is only checking for existence of an entry. Regarding the combinations
of styles and settings, I just need to combine both the  style name and the
option setting before adding to the list. Let me know if you think there is
any other problem I haven’t considered.

I don't at present have a fix for the unit test. Possibly creating a
separate process to run mkgmap when stderr/out needs to be read, rather than
directly calling it might work. Do you have any other suggestions?

Cheers,
Mike

-Original Message-
From: Gerd Petermann [mailto:gpetermann_muenc...@hotmail.com] 
Sent: 06 April 2021 09:21
To: Development list for mkgmap 
Subject: Re: [mkgmap-dev] logging improvements

Hi Mike,

I can live with the codepage problems if we document the workaround (at
least in the svn commit message)

Reg. the changes in StyledConverter: I thought about this as well but found
it too much work to handle the case that a user can use multiple styles or
different combinations of styles and style-option settings. Did you consider
this? Remember that we have multiple instances of StyledConverter, possibly
using different settings regarding these options. I wonder why I see no code
that handles concurrent updates of the static lists.

Yes, I think it would be good to split the patch. I'd start with a patch
that fixes the unit tests (if you have an idea) and the other errors that
you found so far. I prefer to have a few smaller commits with clear commit
messages.

Gerd


Von: mkgmap-dev  im Auftrag von Mike
Baggaley 
Gesendet: Dienstag, 6. April 2021 02:20
An: 'Development list for mkgmap'
Betreff: Re: [mkgmap-dev] logging improvements

Hi Gerd,

I have updated the patch with the following changes:

The --version option now outputs 2 lines, the first containing "mkgmap
version ", the second just .

The log output now starts with " mkgmap version " as its first line
before the start time.

I have replaced the use of logging Level.ALL with 3 custom levels
LogLevel.DIAGNOSTIC, LogLevel.ECHO and LogLevel.OVERRIDE (used by functions
log.diagnostic, log.echo and log.write respectively). The first is used to
display messages from the diagnostic options, the second is used for echo
and echotags and the last is used for general message that are required to
be included, such as the start time. The default output does not display
these prefixes, but if you use a logging.config file, they will be visible
to it.

I have replaced the calls to explicitly write stack traces with calls to
log.error, making sure they all have an error message, and passing the
exception as a  parameter. The default action for these is for the logger to
display a stack trace, which can be disabled in a logging.config file if you
don't want to see it.

In GmapiBuilder, the print stack trace calls have been replaced with
throwing ExitExceptions as in the other combiners, so that program execution
correctly stops.

In FileInfo, the thrown ReadFailedException has been replaced with a
MapFailedException, so that it is correctly picked up.

In TypSaver, I have added a check for an empty file as this was not handled
properly.

In O5mBinHandler a thrown IOException has been replaced with a
FormatException which is better handler.

I have added some code to StyledConvertor to prevent the duplication of
messages about style options.

The "roundabout has reversed way" messages are only displayed if
checkroundabouts is enabled.

I have looked into the code page issue and on Windows, the java environment
defaults to setting its c

Re: [mkgmap-dev] logging improvements

[Mike Baggaley]

Hi Gerd,

I have updated the patch with the following changes:

The --version option now outputs 2 lines, the first containing "mkgmap
version ", the second just .

The log output now starts with " mkgmap version " as its first line
before the start time.

I have replaced the use of logging Level.ALL with 3 custom levels
LogLevel.DIAGNOSTIC, LogLevel.ECHO and LogLevel.OVERRIDE (used by functions
log.diagnostic, log.echo and log.write respectively). The first is used to
display messages from the diagnostic options, the second is used for echo
and echotags and the last is used for general message that are required to
be included, such as the start time. The default output does not display
these prefixes, but if you use a logging.config file, they will be visible
to it.

I have replaced the calls to explicitly write stack traces with calls to
log.error, making sure they all have an error message, and passing the
exception as a  parameter. The default action for these is for the logger to
display a stack trace, which can be disabled in a logging.config file if you
don't want to see it.

In GmapiBuilder, the print stack trace calls have been replaced with
throwing ExitExceptions as in the other combiners, so that program execution
correctly stops.

In FileInfo, the thrown ReadFailedException has been replaced with a
MapFailedException, so that it is correctly picked up.

In TypSaver, I have added a check for an empty file as this was not handled
properly.

In O5mBinHandler a thrown IOException has been replaced with a
FormatException which is better handler.

I have added some code to StyledConvertor to prevent the duplication of
messages about style options.

The "roundabout has reversed way" messages are only displayed if
checkroundabouts is enabled.

I have looked into the code page issue and on Windows, the java environment
defaults to setting its code page to the system default, which on most
Windows machines will be 1252 as used by Windows applications. However, the
command prompt generally has a different code page - it is 850 on my
machine. It appears to be very tricky to change the code page within a Java
application, however, you can specify -Dfile.encoding=850 as a Java argument
or use chcp 1252 before running mkgmap. As 1252 contains more useful
characters than 850, chcp 1252 is likely to be a better solution. It only
seems to be an issue when actually displaying the output in a console
window. When directed to a file it doesn't seem to be a problem, so in
practice it probably isn't much of an issue, as I would think that if people
are displaying messages about road names etc, then there are likely to be
too many to view directly in the console. I'm assuming that the Java
environment doesn't know whether you are running a console program or a
Windows application and hence chooses the code page of the latter.

I have also looked further into the problem in the test suite and it appears
that the redirect of stderr and stdout in the Outputs function does not
capture anything that has gone through ConsoleHandler, even though its
output is directed to stderr. I assume there must be some creation of
separate streams by ConsoleHandler - it can't internally use System.err, as
it is not thread safe, unlike ConsoleHandler. Although only one test is
failing, this actually means a few other tests don't work properly, as they
are checking for an empty stderr output and they will never get anything
else.

I'm now thinking my original suggestion that command line argument errors
should go to stdout was possibly not the best option and these would also be
better going through the logging system. If you have specified a
logging.config file, it would make sense for these messages also to be under
its control. Not all command line argument errors are detected before
processing of input files starts anyway. What is your view?

If you think the patch is getting too big, I could split off the changes
that result in either new or different exceptions being thrown and the
removal of duplicated messages into a separate patch to be introduced first.

Cheers,
Mike

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

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 mes

[mkgmap-dev] rules test

[Mike Baggaley]

Hi Gerd,

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?

Thanks,
Mike


RulesTest.patch
Description: Binary data
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

Re: [mkgmap-dev] logging improvements

[Mike Baggaley]

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 unneeded error message
ImgFS - fix duplicated file name in error message

Utils - write stacktrace to log
FileInfo - write stacktrace to log
HGTReader- write stacktrace to log
CoastlineFileLoader- write stacktrace to log
O5mBinHandler - write stacktrace to log
OsmMapDataSource - write stacktrace to log
SeaGenerator - write stacktrace to log
PrecompSeaGener

Re: [mkgmap-dev] logging improvements

[Mike Baggaley]

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 unneeded error message
ImgFS - fix duplicated file name in error message

Utils - write stacktrace to log
FileInfo - write stacktrace to log
HGTReader- write stacktrace to log
CoastlineFileLoader- write stacktrace to log
O5mBinHandler - write stacktrace to log
OsmMapDataSource - write stacktrace to log
SeaGenerator - write stacktrace to log
PrecompSeaGenerator - write stacktrace to log
PrecompSeaSaver - write stacktrace to log
PrecompSeaMerger - write stacktrace to log (2)
HGTList - write stacktrace to log (2)
GmapiBuilder - write stacktrace to log (2)
NsisBuilder - write stacktrace to log (4)
LocatorConfig - write stacktrace to log + replace System.out.println

These last few have slightly more changes:

RoadNetwork - changes for --check-routing-island-len plus fix spelling
mistakes
RoutreNode - changes for displaying the output of roundabout, flare and
similar arc checks
Logger - changes to logging interface
UsefulFormatter - changes to logging interface
GmapsuppBuilder - several message changes
CommandArgsReader - minor change to facilitate not writing date and time if
not processing a file
Main - various improvements to logging
MapMaker - several replacements of System.err.println and log.err
StyledConverter - change to --report-dead-ends default + several
replacements of System.err.println and log.warn
StyleImpl - several replacements of System.err.println and log.err

Cheers,
Mike




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

Hi Mike,

again: Please separate the changes regarding --check-routing-island-len from
those changes reg. logging.
It's a huge patch and I don't see a reason to mix the two things.

Gerd


Von: mkgmap-dev  im Auftrag von Mike
Baggaley 
Gesendet: Donnerstag, 25. März 2021 11:15
An: 'Development list for mkgmap'
Betreff: Re: [mkgmap-dev] logging improvements

Hi Gerd,

Please find attached an updated patch.
Regarding your points:
1. I have been unable to fix the unit test. The patched version writes the
message to stdout when not using a logging.config file, but changing the
test from checkError to checkOutput does not fix the problem. Running the
test under the debugger, it appears that the test harness has nothing in
either the stdout or stderr stream, though the Eclipse console window
clearly shows output. This will need someone who understands the unit test
system better to fix the test.
2. Message fixed
3. Capitalisation fixed
4. Level.OFF is the correct value. The documentation refers to filtering
messages but does not mention use as a message severity.  Level.OFF is
Integer.MAX_VALUE and level.ALL is Integer.MIN_VALUE. Filtering works by
allowing messages of the filter value or higher. Hence using Level.OFF as a
message severity causes it to be always written, and Level.ALL will never be
written unless the filter level is also Level.All. I have added a comment to
the code to clarify this.
5.I have fixed a couple of SonarLint issues in the logging module, however
most of what it comes up with is of no consequence (there are hundreds of
warnings of dubious value).

I have also rethought the way error and warning messages that are unrelated
to input files are logged. Rather than using a write function using
Level.OFF as in the first version, I have added a global logger so that the
standard logging interface can be used. By default this global logger allows
errors and warnings though, whereas the other loggers only allow errors.
This means that program warnings can be displayed without having to display
OSM data warnings as well.

Cheers,
Mike

-Original Message-----
From: Mike Baggaley [mailto:m...@tvage.co.uk]
Sent: 20 March 2021 12:55
To: 'Development list for mkgmap' 
Subject: RE: [

Re: [mkgmap-dev] logging improvements

[Mike Baggaley]

Hi Gerd, the two things need to be done together otherwise there will be a
loss of backwards compatibility if either is done in isolation. That is why
I have not separated them. I forgot to mention on my previous post.

Regards,
Mike

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

Hi Mike,

again: Please separate the changes regarding --check-routing-island-len from
those changes reg. logging.
It's a huge patch and I don't see a reason to mix the two things.

Gerd


Von: mkgmap-dev  im Auftrag von Mike
Baggaley 
Gesendet: Donnerstag, 25. März 2021 11:15
An: 'Development list for mkgmap'
Betreff: Re: [mkgmap-dev] logging improvements

Hi Gerd,

Please find attached an updated patch.
Regarding your points:
1. I have been unable to fix the unit test. The patched version writes the
message to stdout when not using a logging.config file, but changing the
test from checkError to checkOutput does not fix the problem. Running the
test under the debugger, it appears that the test harness has nothing in
either the stdout or stderr stream, though the Eclipse console window
clearly shows output. This will need someone who understands the unit test
system better to fix the test.
2. Message fixed
3. Capitalisation fixed
4. Level.OFF is the correct value. The documentation refers to filtering
messages but does not mention use as a message severity.  Level.OFF is
Integer.MAX_VALUE and level.ALL is Integer.MIN_VALUE. Filtering works by
allowing messages of the filter value or higher. Hence using Level.OFF as a
message severity causes it to be always written, and Level.ALL will never be
written unless the filter level is also Level.All. I have added a comment to
the code to clarify this.
5.I have fixed a couple of SonarLint issues in the logging module, however
most of what it comes up with is of no consequence (there are hundreds of
warnings of dubious value).

I have also rethought the way error and warning messages that are unrelated
to input files are logged. Rather than using a write function using
Level.OFF as in the first version, I have added a global logger so that the
standard logging interface can be used. By default this global logger allows
errors and warnings though, whereas the other loggers only allow errors.
This means that program warnings can be displayed without having to display
OSM data warnings as well.

Cheers,
Mike

-Original Message-
From: Mike Baggaley [mailto:m...@tvage.co.uk]
Sent: 20 March 2021 12:55
To: 'Development list for mkgmap' 
Subject: RE: [mkgmap-dev] logging improvements

HI Gerd, thanks for the reply

The new static method Logger.Write does not output any input file name and
is designed to output the same text as would have been output by
System.err.println. I may have used log.error rather than Logger.Write as a
replacement for System.err.println in a few places where I couldn't see a
reason why it hadn't been used - I'll have a look at these again.

1) Can you let me know how to run the unit tests?
2) I will change the message to correctly display -- report-routing-islands
(I initially started with --check-reporting-islands but decided report was
better, I must have omitted to change this message).
3) I am used to using capital letters for static functions -  I am happy to
change these to lower case.
4) I will look at using Level.ALL instead.
5) I will look into installing Sonarlint. I do get thirty-odd compiler
warnings, but none of these are related to the patch.

Cheers,
Mike

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

Hi Mike,

I agree in many points.
One reason to use System.err.println() instead of log.error() is that some
messages are not related to a specific input file and thus should not show
any input file name. Typically this is true in the combiners. I did not try
if your changes reflect this, but I think they don't?
The stacktraces help to indentify possible causes when users report
problems. I see no reason to remove them.

Please review,

1) unit test testWarningOnMismatchedCodePages fails.
2) The use of e.g. check-routing-island-len=1 gives message
"The --check-routing-island-len option is deprecated. Please use
--check-routing-islands and/or max-routing-island-len"
but --check-routing-islands is not a valid option. If possible, please
create a separate patch for the changes regarding options.
3) the new method names like Logger.Write or Logger.WriteStackTrace do not
comply with naming conventions, method names should not start with upper
case characters
4) The use of Level.OFF is confusing. My understanding is that the constant
is meant to disable logging?
5) Sonarlint complains about "Preconditio

Re: [mkgmap-dev] logging improvements

[Mike Baggaley]

Hi Gerd,

Please find attached an updated patch.
Regarding your points:
1. I have been unable to fix the unit test. The patched version writes the
message to stdout when not using a logging.config file, but changing the
test from checkError to checkOutput does not fix the problem. Running the
test under the debugger, it appears that the test harness has nothing in
either the stdout or stderr stream, though the Eclipse console window
clearly shows output. This will need someone who understands the unit test
system better to fix the test.
2. Message fixed
3. Capitalisation fixed
4. Level.OFF is the correct value. The documentation refers to filtering
messages but does not mention use as a message severity.  Level.OFF is
Integer.MAX_VALUE and level.ALL is Integer.MIN_VALUE. Filtering works by
allowing messages of the filter value or higher. Hence using Level.OFF as a
message severity causes it to be always written, and Level.ALL will never be
written unless the filter level is also Level.All. I have added a comment to
the code to clarify this.
5.I have fixed a couple of SonarLint issues in the logging module, however
most of what it comes up with is of no consequence (there are hundreds of
warnings of dubious value).

I have also rethought the way error and warning messages that are unrelated
to input files are logged. Rather than using a write function using
Level.OFF as in the first version, I have added a global logger so that the
standard logging interface can be used. By default this global logger allows
errors and warnings though, whereas the other loggers only allow errors.
This means that program warnings can be displayed without having to display
OSM data warnings as well.

Cheers,
Mike

-Original Message-
From: Mike Baggaley [mailto:m...@tvage.co.uk] 
Sent: 20 March 2021 12:55
To: 'Development list for mkgmap' 
Subject: RE: [mkgmap-dev] logging improvements

HI Gerd, thanks for the reply

The new static method Logger.Write does not output any input file name and
is designed to output the same text as would have been output by
System.err.println. I may have used log.error rather than Logger.Write as a
replacement for System.err.println in a few places where I couldn't see a
reason why it hadn't been used - I'll have a look at these again.

1) Can you let me know how to run the unit tests?
2) I will change the message to correctly display -- report-routing-islands
(I initially started with --check-reporting-islands but decided report was
better, I must have omitted to change this message).
3) I am used to using capital letters for static functions -  I am happy to
change these to lower case.
4) I will look at using Level.ALL instead.
5) I will look into installing Sonarlint. I do get thirty-odd compiler
warnings, but none of these are related to the patch.

Cheers,
Mike

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

Hi Mike,

I agree in many points.
One reason to use System.err.println() instead of log.error() is that some
messages are not related to a specific input file and thus should not show
any input file name. Typically this is true in the combiners. I did not try
if your changes reflect this, but I think they don't?
The stacktraces help to indentify possible causes when users report
problems. I see no reason to remove them.

Please review,

1) unit test testWarningOnMismatchedCodePages fails.
2) The use of e.g. check-routing-island-len=1 gives message
"The --check-routing-island-len option is deprecated. Please use
--check-routing-islands and/or max-routing-island-len"
but --check-routing-islands is not a valid option. If possible, please
create a separate patch for the changes regarding options.
3) the new method names like Logger.Write or Logger.WriteStackTrace do not
comply with naming conventions, method names should not start with upper
case characters
4) The use of Level.OFF is confusing. My understanding is that the constant
is meant to disable logging?
5) Sonarlint complains about "Preconditions" and logging arguments should
not require evaluation (java:S2629) but that's not new with your patch.

Gerd








Von: mkgmap-dev  im Auftrag von Mike
Baggaley 
Gesendet: Samstag, 20. März 2021 00:52
An: 'mkgmap development'
Betreff: [mkgmap-dev] logging improvements

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 i

Re: [mkgmap-dev] logging improvements

[Mike Baggaley]

HI Gerd, thanks for the reply

The new static method Logger.Write does not output any input file name and
is designed to output the same text as would have been output by
System.err.println. I may have used log.error rather than Logger.Write as a
replacement for System.err.println in a few places where I couldn't see a
reason why it hadn't been used - I'll have a look at these again.

1) Can you let me know how to run the unit tests?
2) I will change the message to correctly display -- report-routing-islands
(I initially started with --check-reporting-islands but decided report was
better, I must have omitted to change this message).
3) I am used to using capital letters for static functions -  I am happy to
change these to lower case.
4) I will look at using Level.ALL instead.
5) I will look into installing Sonarlint. I do get thirty-odd compiler
warnings, but none of these are related to the patch.

Cheers,
Mike

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

Hi Mike,

I agree in many points.
One reason to use System.err.println() instead of log.error() is that some
messages are not related to a specific input file and thus should not show
any input file name. Typically this is true in the combiners. I did not try
if your changes reflect this, but I think they don't?
The stacktraces help to indentify possible causes when users report
problems. I see no reason to remove them.

Please review,

1) unit test testWarningOnMismatchedCodePages fails.
2) The use of e.g. check-routing-island-len=1 gives message
"The --check-routing-island-len option is deprecated. Please use
--check-routing-islands and/or max-routing-island-len"
but --check-routing-islands is not a valid option. If possible, please
create a separate patch for the changes regarding options.
3) the new method names like Logger.Write or Logger.WriteStackTrace do not
comply with naming conventions, method names should not start with upper
case characters
4) The use of Level.OFF is confusing. My understanding is that the constant
is meant to disable logging?
5) Sonarlint complains about "Preconditions" and logging arguments should
not require evaluation (java:S2629) but that's not new with your patch.

Gerd








Von: mkgmap-dev  im Auftrag von Mike
Baggaley 
Gesendet: Samstag, 20. März 2021 00:52
An: 'mkgmap development'
Betreff: [mkgmap-dev] logging improvements

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 a

[mkgmap-dev] logging improvements

[Mike Baggaley]

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



logging.patch
Description: Binary data
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

Re: [mkgmap-dev] Removal of floodblocker generate-sea option

[Mike Baggaley]

I don't use precomp-sea, but I don't use floodblocker either, so the suggestion 
is fine by me. It may however be worth displaying a warning if a tile appears 
to be flooded.

Cheers,
Mike

-Original Message-
From: Ticker Berkin [mailto:rwb-mkg...@jagit.co.uk] 
Sent: 17 March 2021 09:28
To: mkgmap development 
Subject: [mkgmap-dev] Removal of floodblocker generate-sea option

Hi all

I think it is time that that the floodblocker logic is removed.

I doubt if anyone uses it.

The recommended way to have sea is to use --precomp-sea and
floodblocker is irrelevant to this.

Using the coastline data from the normal OSM input, the common sea
problems are in tiles that extend beyond the extracted region, where
coastline is incomplete (not reaching tile edges, or has gaps where
there are estuaries) and floodblocker is no use in this case.

This could be done as part of the "faster-mp" branch as it removes an
interface into MultiPolygonRelation, reducing the effort to restructure
this.

Ticker


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

Re: [mkgmap-dev] Error in mkgmaps logging class?

[Mike Baggaley]

Hi Gerd, in that case I think the correct fix is:

handler.setLevel(Level.FINE);
l.setLevel(Level.SEVERE);

This would prevent the confusion when changing the handler level to give
more detail appears to have no effect, which took me some time to sort out
when I first started using a logging config file.

Cheers,
Mike

-Original Message-
From: Gerd Petermann [mailto:gpetermann_muenc...@hotmail.com] 
Sent: 15 March 2021 14:29
To: Development list for mkgmap 
Subject: Re: [mkgmap-dev] Error in mkgmaps logging class?

Hi Mike,

not sure if this will help users to use warning level as default. I see +500
warning messages for a single tile in my home area. Most of them are about
problems in the data, many of those data "problems" have no effect on the
map or are caused by incomplete data.

Gerd


Von: mkgmap-dev  im Auftrag von Mike
Baggaley 
Gesendet: Montag, 15. März 2021 14:02
An: 'Development list for mkgmap'
Betreff: Re: [mkgmap-dev] Error in mkgmaps logging class?

HI Gerd/Steve,

The current code with the handler set to SEVERE and logger set to WARNING
doesn't seem to make a lot of sense. Wouldn't it be better if the default
handler level was FINE, so that just logger filters the messages. I think
warnings should be allowed through by default as well, so suggest

handler.setLevel(Level.FINE);
l.setLevel(Level.WARNING);

Cheers,
Mike

-Original Message-
From: Gerd Petermann [mailto:gpetermann_muenc...@hotmail.com]
Sent: 15 March 2021 08:52
To: Steve Ratcliffe ; 'Development list for mkgmap'

Subject: [mkgmap-dev] Error in mkgmaps logging class?

Hi Steve,

Please review:
I've noticed that
log.isLoggable(Level.WARNING)
always returns true when I don't use the -Dconfig.logging option for JRE .
This is unexpected as calls to
log.warn(...)
don't produce any output in this case.

The attached simple patch seems to fix this but I don't really understand
the code.
Maybe you forgot this change in
http://www.mkgmap.org.uk/websvn/revision.php?repname=mkgmap=233 ?

In class MultiPolygonRelation we have quite a lot of methods which is meant
to be skipped if logging is not enabled but because of this bug(?) the code
is executed sometimes, maybe with side effects that I don't yet fully
understand.

Gerd


___
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

Re: [mkgmap-dev] Error in mkgmaps logging class?

[Mike Baggaley]

HI Gerd/Steve,

The current code with the handler set to SEVERE and logger set to WARNING
doesn't seem to make a lot of sense. Wouldn't it be better if the default
handler level was FINE, so that just logger filters the messages. I think
warnings should be allowed through by default as well, so suggest

handler.setLevel(Level.FINE);
l.setLevel(Level.WARNING);

Cheers,
Mike

-Original Message-
From: Gerd Petermann [mailto:gpetermann_muenc...@hotmail.com] 
Sent: 15 March 2021 08:52
To: Steve Ratcliffe ; 'Development list for mkgmap'

Subject: [mkgmap-dev] Error in mkgmaps logging class?

Hi Steve,

Please review: 
I've noticed that 
log.isLoggable(Level.WARNING)
always returns true when I don't use the -Dconfig.logging option for JRE .
This is unexpected as calls to 
log.warn(...)
don't produce any output in this case.

The attached simple patch seems to fix this but I don't really understand
the code.
Maybe you forgot this change in
http://www.mkgmap.org.uk/websvn/revision.php?repname=mkgmap=233 ?

In class MultiPolygonRelation we have quite a lot of methods which is meant
to be skipped if logging is not enabled but because of this bug(?) the code
is executed sometimes, maybe with side effects that I don't yet fully
understand.

Gerd


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

[mkgmap-dev] removal of parallel lines

[Mike Baggaley]

Hi all,

At low resolutions I would like to be able to remove parallel lines so that
(for example) only a single motorway carriageway or railway track is shown
instead of  two or (in the case of the West Coast Main Line) four lines,
which due to different Douglas Peucker line simplifications end up crossing
each other, look messy and add unnecessary lines to the overview.

Has anyone done this before or have any ideas about how I might go about it?

Cheers,
Mike

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

[mkgmap-dev] -c option crash

[Mike Baggaley]

Hi Gerd,

The attached patch fixes a crash if you inadvertently specify a .o5m file
after the -c command line argument.

Cheers,
Mike


CommandArgsReader.patch
Description: Binary data
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

Re: [mkgmap-dev] omit items from overview

[Mike Baggaley]

Hi Ticker,

Yes this does work, but you are right that the test for isOverviewComponent or 
isOverviewCombined only needs to test for isOverviewComponent and it doesn't 
need the change to OverviewMapDataSource.

Please find an updated patch attached.

Cheers,
Mike

-Original Message-
From: Ticker Berkin [mailto:rwb-mkg...@jagit.co.uk] 
Sent: 08 March 2021 08:44
To: Development list for mkgmap 
Subject: Re: [mkgmap-dev] omit items from overview

Hi Mike

Does this work? There is no information about the tagging when the
elements are read back from the ovm_ file.

In MapBuilder I think you have to test for isOverviewComponent rather
than isOverviewCombined and I don't think changes to
OverviewMapDataSource make any difference to anything.

Ticker

On Sun, 2021-03-07 at 21:56 +, Gerd Petermann wrote:
> Hi Mike,
> 
> do you have a use case for that? My approach would be to change the
> resolution/level for the object, so I wonder why we need a special
> variable.
> 
> Gerd
> 
> 
> Von: mkgmap-dev  im Auftrag
> von Mike Baggaley 
> Gesendet: Sonntag, 7. März 2021 22:30
> An: 'Development list for mkgmap'
> Betreff: [mkgmap-dev] omit items from overview
> 
> Hi Gerd,
> 
> Please find attached a patch that causes objects that have
> mkgmap:nooverview=yes to be omitted from the overview map.
> 
> Cheers,
> Mike
> ___
> mkgmap-dev mailing list
> mkgmap-dev@lists.mkgmap.org.uk
> http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev



OverviewContent2.patch
Description: Binary data
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

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

[Mike Baggaley]

Hi Karl,

The first tile is likely to be generated with only a single thread running
whilst memory usage is checked, then the remainder may use both your
processors. If there is something about this tile that causes it to take a
long time, it may be worth moving it back in the list so that it doesn't
hold up starting of parallel processes, resulting in an overall reduction in
processing time.

Cheers,
Mike

-Original Message-
From: Gerd Petermann [mailto:gpetermann_muenc...@hotmail.com] 
Sent: 08 March 2021 06:32
To: Development list for mkgmap 
Subject: Re: [mkgmap-dev] tile takes very long time to generate

Hi Karl,

I don't think that the order of the tiles should make a big difference. It
is quite normal that some tiles take longer than others, but 30 minutes is
far too long.
One well known reason for slow processing are very complex multipolygons
like Lake Huron. Another might be huge areas of sea. So, to find out if the
order or the content is causing the delay you can process the tiles in a
different order.
I often use VisualVM to monitor a running mkgmap, it helps to find out which
routines are called most often.
If you identify a single tile that takes very long (also with the default
style) you can upload that tile to http://files.mkgmap.org.uk/
Best is to add a small file with the options that were used, but you can
also post them here.
Hope that helps.

Gerd



Von: mkgmap-dev  im Auftrag von 7770
<7...@foskan.eu>
Gesendet: Montag, 8. März 2021 06:53
An: mkgmap-dev@lists.mkgmap.org.uk
Betreff: [mkgmap-dev] tile takes very long time to generate

Hi.

I observe a situation that one of the very first tiles (often the first or
the
third) that mkgmap generates takes 20 - 30 minutes to generate, wheres the
others take about 30 seconds each.

The map data produced by splitter is a total of around 700 files with
splitter
option --max-nodes=1275000.

sea and bouds are used for mkgmap.

At first i thought i am running low on memory but changing to max-jobs=1
(instead of the possible max of 2) did not make any change.

Is mkgmap doing something specific in the beginning that can explain this
long
time generating one of the very first tiles?

I can provide more details, let me know how i can best collect those details
in case i need to set some parameters to have mkgmap to say more about what
it
is doing.

Regards
Karl



___
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

Re: [mkgmap-dev] omit items from overview

[Mike Baggaley]

Hi Gerd, yes,

I have overlapping resolutions for the overview and main map.

Cheers,
Mike

-Original Message-
From: Gerd Petermann [mailto:gpetermann_muenc...@hotmail.com] 
Sent: 07 March 2021 21:56
To: Development list for mkgmap 
Subject: Re: [mkgmap-dev] omit items from overview

Hi Mike,

do you have a use case for that? My approach would be to change the
resolution/level for the object, so I wonder why we need a special variable.

Gerd


Von: mkgmap-dev  im Auftrag von Mike
Baggaley 
Gesendet: Sonntag, 7. März 2021 22:30
An: 'Development list for mkgmap'
Betreff: [mkgmap-dev] omit items from overview

Hi Gerd,

Please find attached a patch that causes objects that have
mkgmap:nooverview=yes to be omitted from the overview map.

Cheers,
Mike


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

[mkgmap-dev] omit items from overview

[Mike Baggaley]

Hi Gerd,

Please find attached a patch that causes objects that have
mkgmap:nooverview=yes to be omitted from the overview map.

Cheers,
Mike


OverviewContent.patch
Description: Binary data
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

Re: [mkgmap-dev] Overview Too Big

[Mike Baggaley]

HI Gerd,

Your changes look fine to me. Changing the BufferedImgFileWriter constructor
is a good suggestion, as it only needs half a dozen or so callers to be
changed.

Please see an updated patch attached - I have also improved the DEM error
handling.

Cheers,
Mike

-Original Message-
From: Gerd Petermann [mailto:gpetermann_muenc...@hotmail.com] 
Sent: 02 March 2021 10:51
To: Development list for mkgmap 
Subject: Re: [mkgmap-dev] Overview Too Big

Hi Mike,

I've changed a few things, see attachment.
- more section names which might be too big. Maybe it is possible to have a
NET or NOD section that is bigger than RGN, I really don't know.
- add "bytes" to message
- use as much of the allowed size as possible (not sure what to do with the
GUARD_SIZE. We report e.g. 16777215 bytes (16MB) but in fact we use
something like
16777215 - 1024 = 16776191 bytes.

I think I prefer to change the constructor for BufferedImgFileWriter to pass
the section name instead of extracting it from the stacktrace. Did you
consider this?

Gerd





Von: mkgmap-dev  im Auftrag von Mike
Baggaley 
Gesendet: Sonntag, 28. Februar 2021 17:38
An: 'Development list for mkgmap'
Betreff: Re: [mkgmap-dev] Overview Too Big

Hi Gerd,

Please find attached an updated patch. I'm not sure whether what I've done
is exactly what you intended - it now includes the img file name and the
MDR/RGN/TRE subfile that has exceeded the size limit in the error message. I
couldn't see a clean easy way to get at the subfile without amending every
sub file handler, so have resorted to examining the stack trace. I've also
changed the keep going handling to what works for me and seems more logical.
Let me know if you think it is not quite right.

Cheers,
Mike

-Original Message-----
From: Mike Baggaley [mailto:m...@tvage.co.uk]
Sent: 24 February 2021 13:59
To: 'Development list for mkgmap' 
Subject: RE: [mkgmap-dev] Overview Too Big

Hi Gerd,

I'll have a look at that. The patch catches the low level error and
re-throws in at a higher level in the case of the overview map. It will need
to do the same for the main map.

I notice that when the map is too big, processing does not stop, even though
I have not got --keep-going set. Looking at the code, it seems that the keep
going check is in the Throwable catcher, rather than the MapFailedException
catcher. Is this intended or a mistake? It seems to me that you'd be
unlikely to want to continue from some random error, but might want to if
the problem was known to be related to just one map.

Cheers,
Mike

-Original Message-
From: Gerd Petermann [mailto:gpetermann_muenc...@hotmail.com]
Sent: 24 February 2021 09:30
To: Development list for mkgmap 
Subject: Re: [mkgmap-dev] Overview Too Big

Hi Mike,

I agree that the message should be improved.
In fact I am always unsure what kind of limit this is. I've just created a
working single tile map of Berlin including NOD which has a filesize of >
21MB.
Your patch reports a number which probably counts bytes (I miss that info),
but I  think it is not about tile/map size. I assume it is about max. sub
file size. So, maybe show that sub file name also?

Gerd


Von: mkgmap-dev  im Auftrag von Mike
Baggaley 
Gesendet: Mittwoch, 24. Februar 2021 00:16
An: 'Development list for mkgmap'
Betreff: [mkgmap-dev] Overview Too Big

Hi Gerd,

The error message that mkgmap outputs when the overview map is too big is
not helpful. Please find attached a patch that improves this.

Cheers,
Mike



OverviewTooBig4.patch
Description: Binary data
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

Re: [mkgmap-dev] Error writing overviewmap - continue at failure

[Mike Baggaley]

My mistake - I was assuming you meant the sea area, not a line along the 
coastline. In that case I agree that it is probably unnecessary.

-Original Message-
From: Carlos Dávila [mailto:car...@alternativaslibres.org] 
Sent: 28 February 2021 17:56
To: mkgmap-dev@lists.mkgmap.org.uk
Subject: Re: [mkgmap-dev] Error writing overviewmap - continue at failure

Don't you have sea in your map? If yes, what do you need coastline for?

El 28/2/21 a las 17:47, Mike Baggaley escribió:
> I have coastline in my overview of the UK down to the lowest level. At the 
> lowest level, my overview contains just coastline, country boundaries, major 
> cities and motorways. For an island, I would suggest the coastline is the 
> most important thing to have in the overview.
>
> Cheers,
> Mike
>
> -Original Message-
> From: Ticker Berkin [mailto:rwb-mkg...@jagit.co.uk]
> Sent: 28 February 2021 10:51
> To: Development list for mkgmap 
> Subject: Re: [mkgmap-dev] Error writing overviewmap - continue at failure
>
> Hi
>
> The default style has 5 levels of overview map! This seems excessive.
> I'd have thought 2 or 3 would be acceptable and save a lot of space
>
> The only contents is larger and larger cities, fast trunk roads and
> motorways, some boundaries, sea and, at 3 of the 5 levels, coastline.
>
> I don't think coastline adds anything useful to a typical map,
> certainly not an overview, so dropping this would save space.
>
> Ticker
>
>
>
>
> ___
> 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

Re: [mkgmap-dev] Error writing overviewmap - continue at failure

[Mike Baggaley]

I have coastline in my overview of the UK down to the lowest level. At the 
lowest level, my overview contains just coastline, country boundaries, major 
cities and motorways. For an island, I would suggest the coastline is the most 
important thing to have in the overview.

Cheers,
Mike

-Original Message-
From: Ticker Berkin [mailto:rwb-mkg...@jagit.co.uk] 
Sent: 28 February 2021 10:51
To: Development list for mkgmap 
Subject: Re: [mkgmap-dev] Error writing overviewmap - continue at failure

Hi

The default style has 5 levels of overview map! This seems excessive.
I'd have thought 2 or 3 would be acceptable and save a lot of space

The only contents is larger and larger cities, fast trunk roads and
motorways, some boundaries, sea and, at 3 of the 5 levels, coastline.

I don't think coastline adds anything useful to a typical map,
certainly not an overview, so dropping this would save space.

Ticker




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

Re: [mkgmap-dev] Overview Too Big

[Mike Baggaley]

Hi Gerd,

Please find attached an updated patch. I'm not sure whether what I've done
is exactly what you intended - it now includes the img file name and the
MDR/RGN/TRE subfile that has exceeded the size limit in the error message. I
couldn't see a clean easy way to get at the subfile without amending every
sub file handler, so have resorted to examining the stack trace. I've also
changed the keep going handling to what works for me and seems more logical.
Let me know if you think it is not quite right.

Cheers,
Mike

-Original Message-
From: Mike Baggaley [mailto:m...@tvage.co.uk] 
Sent: 24 February 2021 13:59
To: 'Development list for mkgmap' 
Subject: RE: [mkgmap-dev] Overview Too Big

Hi Gerd,

I'll have a look at that. The patch catches the low level error and
re-throws in at a higher level in the case of the overview map. It will need
to do the same for the main map.

I notice that when the map is too big, processing does not stop, even though
I have not got --keep-going set. Looking at the code, it seems that the keep
going check is in the Throwable catcher, rather than the MapFailedException
catcher. Is this intended or a mistake? It seems to me that you'd be
unlikely to want to continue from some random error, but might want to if
the problem was known to be related to just one map.

Cheers,
Mike

-Original Message-
From: Gerd Petermann [mailto:gpetermann_muenc...@hotmail.com] 
Sent: 24 February 2021 09:30
To: Development list for mkgmap 
Subject: Re: [mkgmap-dev] Overview Too Big

Hi Mike,

I agree that the message should be improved.
In fact I am always unsure what kind of limit this is. I've just created a
working single tile map of Berlin including NOD which has a filesize of >
21MB.
Your patch reports a number which probably counts bytes (I miss that info),
but I  think it is not about tile/map size. I assume it is about max. sub
file size. So, maybe show that sub file name also?

Gerd


Von: mkgmap-dev  im Auftrag von Mike
Baggaley 
Gesendet: Mittwoch, 24. Februar 2021 00:16
An: 'Development list for mkgmap'
Betreff: [mkgmap-dev] Overview Too Big

Hi Gerd,

The error message that mkgmap outputs when the overview map is too big is
not helpful. Please find attached a patch that improves this.

Cheers,
Mike



OverviewTooBig2.patch
Description: Binary data
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

Re: [mkgmap-dev] Error writing overviewmap - continue at failure

[Mike Baggaley]

Hi Joris,
 
I will soon be passing an updated patch to Gerd to improve this, as I had
also been experiencing similar problems. The overview map is not built until
all the tiles have been created (assuming the error is not in an overview
tile), and I don't think it uses the style file at that point, just merges
all the ovm data, so using a new style will not help without restarting your
run. The message produced by the patch when the overview file is too big is
"The overview map is too big. The maximum size is 16777215. Try reducing the
highest overview resolution or reducing the amount of information included
in the overview." If you build your own version of mkgmap, you can use the
version of the patch I posted a few days ago. For the whole world, I expect
the maximum resolution of overview to be pretty low. If I build a single UK
county, I can have an overview at resolution 22, but only 20 for the UK. I
haven't tried anything bigger. You may get some idea how close you are to
the limit by totalling the sizes of the ovm files. The maximum size may not
necessarily be the max for the whole file, it may be the limit of a sub file
though. That is certainly the case for ordinary map tiles, but I'm not sure
on the overview.
 
I also have some code that I'm working on that adds support for a
mkgmap:nooverview tag in the style file, so that if you have overlapping
main and overview resolutions, you can direct your style to omit some of the
information from the overview. Will be passing this patch over shortly as
well.
 
I don't think allowing a continuation after a failure in the final overview
map would be helpful, as there is very little left to do at that point.
There are some issues with the keep going handling and I'm also looking at
that.
 
Cheers,
Mike
 
From: Joris Bo [mailto:jori...@hotmail.com] 
Sent: 27 February 2021 14:49
To: Development list for mkgmap 
Subject: [mkgmap-dev] Error writing overviewmap - continue at failure
 
Hi,
 
I think the below error message is for writing the overview map.
Of which I would not be surprised, it was a test on splitting and building a
full-planet.osm map. So. no worries.
 
But now I'm wondering if there is a way in which I could continue testing
with the already generated 4.426 img-files and 4.426 ovm_work files to
obtain a .tdb file, mdx files, nsis installer etc.
It took 21 hours for mkgmap sofar, so it would be nice if that time spent
was not useless.
I used splitter with maxnodes 1.700.000 which took another 9 hours and did
not give errors when building a single .img file
 
I would like to simplify the style-file run mkgmap again on the previous
output and try the create an overview map only (So without building all the
img files again) and this way iterate until I found the breakpoint.
1) Would that make sense?
2) Could I enable some more error/verbose logging to obtain info about
sizes/counts or whatever indicators that would help to see if my changes
help in my search to a smaller overviewmap.
3) Would It make sense to not generate a MapFailedException but a
warning only? So mkgmap would continue finishing the last millimeters to the
finish (off course without a working overviewmap)
 
Kind regards
Joris
 
SEVERE (MapFailedException): (thrown in BufferedImgFileWriter.ensureSize())
There is not enough room in a single garmin map for all the input data. The
.osm file should be split into smaller pieces first.
uk.me.parabola.imgfmt.MapFailedException: There is not enough room in a
single garmin map for all the input data. The .osm file should be split into
smaller pieces first.
at
uk.me.parabola.imgfmt.app.BufferedImgFileWriter.ensureSize(BufferedImgFileWr
iter.java:275)
at
uk.me.parabola.imgfmt.app.BufferedImgFileWriter.put(BufferedImgFileWriter.ja
va:238)
at
uk.me.parabola.imgfmt.app.trergn.Polyline.write(Polyline.java:142)
at
uk.me.parabola.imgfmt.app.trergn.RGNFile.addMapObject(RGNFile.java:140)
at uk.me.parabola.imgfmt.app.map.Map.addMapObject(Map.java:273)
at
uk.me.parabola.mkgmap.build.MapBuilder$ShapeAddFilter.doFilter(MapBuilder.ja
va:1459)
at
uk.me.parabola.mkgmap.build.LayerFilterChain.doFilter(LayerFilterChain.java:
58)
at
uk.me.parabola.mkgmap.filters.LinePreparerFilter.doFilter(LinePreparerFilter
.java:143)
at
uk.me.parabola.mkgmap.build.LayerFilterChain.doFilter(LayerFilterChain.java:
58)
at
uk.me.parabola.mkgmap.filters.RemoveEmpty.doFilter(RemoveEmpty.java:59)
at
uk.me.parabola.mkgmap.build.LayerFilterChain.doFilter(LayerFilterChain.java:
58)
at
uk.me.parabola.mkgmap.filters.RemoveObsoletePointsFilter.doFilter(RemoveObso
letePointsFilter.java:142)
at
uk.me.parabola.mkgmap.build.LayerFilterChain.doFilter(LayerFilterChain.java:
58)
at
uk.me.parabola.mkgmap.filters.PolygonSplitterFilter.doFilter(PolygonSplitter
Filter.java:81)
at

Re: [mkgmap-dev] Overview Too Big

[Mike Baggaley]

Hi Gerd,

I'll have a look at that. The patch catches the low level error and
re-throws in at a higher level in the case of the overview map. It will need
to do the same for the main map.

I notice that when the map is too big, processing does not stop, even though
I have not got --keep-going set. Looking at the code, it seems that the keep
going check is in the Throwable catcher, rather than the MapFailedException
catcher. Is this intended or a mistake? It seems to me that you'd be
unlikely to want to continue from some random error, but might want to if
the problem was known to be related to just one map.

Cheers,
Mike

-Original Message-
From: Gerd Petermann [mailto:gpetermann_muenc...@hotmail.com] 
Sent: 24 February 2021 09:30
To: Development list for mkgmap 
Subject: Re: [mkgmap-dev] Overview Too Big

Hi Mike,

I agree that the message should be improved.
In fact I am always unsure what kind of limit this is. I've just created a
working single tile map of Berlin including NOD which has a filesize of >
21MB.
Your patch reports a number which probably counts bytes (I miss that info),
but I  think it is not about tile/map size. I assume it is about max. sub
file size. So, maybe show that sub file name also?

Gerd


Von: mkgmap-dev  im Auftrag von Mike
Baggaley 
Gesendet: Mittwoch, 24. Februar 2021 00:16
An: 'Development list for mkgmap'
Betreff: [mkgmap-dev] Overview Too Big

Hi Gerd,

The error message that mkgmap outputs when the overview map is too big is
not helpful. Please find attached a patch that improves this.

Cheers,
Mike


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

Re: [mkgmap-dev] minor documentation improvement

[Mike Baggaley]

Oops, attached the wrong patch. Here's the correct one...

-Original Message-
From: Mike Baggaley [mailto:m...@tvage.co.uk] 
Sent: 24 February 2021 13:43
To: 'Gerd Petermann' ; 'Development list
for mkgmap' 
Subject: RE: [mkgmap-dev] minor documentation improvement

Hi Gerd,

>I think "Error checking options" is too strong. My understanding is that
the options enable additional plausibility checks which may help to explain
>unexpected results in routing. So, maybe "Diagnostic options" is better?
Sounds reasonable - please find an updated patch.

>reg. "POI options":
>I think the option name --link-pois-to-ways is very misleading. I think it
is much more about routing then about "points of interest" like shops or
>restaurants.
Good point, I've moved it back to the miscellaneous options. Do you think
the option should be deprecated with a better named option replacing it?

Cheers,
Mike


docsections2.patch
Description: Binary data
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

Re: [mkgmap-dev] minor documentation improvement

[Mike Baggaley]

Hi Gerd,

>I think "Error checking options" is too strong. My understanding is that
the options enable additional plausibility checks which may help to explain
>unexpected results in routing. So, maybe "Diagnostic options" is better?
Sounds reasonable - please find an updated patch.

>reg. "POI options":
>I think the option name --link-pois-to-ways is very misleading. I think it
is much more about routing then about "points of interest" like shops or
>restaurants.
Good point, I've moved it back to the miscellaneous options. Do you think
the option should be deprecated with a better named option replacing it?

Cheers,
Mike


docsections2.patch
Description: Binary data
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

[mkgmap-dev] minor documentation improvement

[Mike Baggaley]

Hi Gerd,

Please find attached a patch to move some of the miscellaneous options into
new sections Error checking options and POI options. There is no change to
any of the actual wording.

Cheers,
Mike


docsections.patch
Description: Binary data
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

[mkgmap-dev] Overview Too Big

[Mike Baggaley]

Hi Gerd,

The error message that mkgmap outputs when the overview map is too big is
not helpful. Please find attached a patch that improves this.

Cheers,
Mike


OverviewTooBig.patch
Description: Binary data
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

Re: [mkgmap-dev] Documentation improvements for sea processing,

[Mike Baggaley]

Hi Gerd,

I've further edited the documentation in the light of your comments - see
below inline.

>- reg. --add-pois-to-lines (and also add-pois-to-areas)
>I think the texts (and of course the option names) are misleading. The
program doesn't generate "POI", it just generates additional nodes with
special >tags and the point rules decide what to do with those nodes.
>I noticed this because of the new text "An extra point added by mkgmap at
the middle of the line".
>Really, mkgmap adds a new node for all existing nodes of the unclosed way
AND one extra node for the calculated middle of the way. Some of the >added
nodes may be filtered, e.g. when two consecutive "inner" nodes have the same
Garmin position.

I've removed the references to "POIs" and replaced them with "nodes", and
added a mention of the points file being used to produce the POIs.

>I think the most important thing about nodes created by  the
--add-pois-to-lines option is that the user probably has to add rules to
ignore most of >those nodes.

I've added a sentence to cover this.

>- Reg. "=== Sea Processing options ==="
>I don't like the word "either" in this section. This implies that you
cannot use --precomp-sea together with --generate-sea while the text for
-->precomp-sea says you can.

I've removed "either".

>- The --generate-sea option can always be used to overwrite these defaults:
>generate-sea=multipolygon,landtag=natural=land

The documentation indicates that under --precomp-sea.

>The default tag natural=land tag is also used in the precomp-sea data, and
e.g. generate-sea: land-tag=natural=background can be used to change >that.
No idea why, found this option in the "Openfietsmap full" style together
with these polygon rules:
>natural=land [0x27 resolution 20]
>natural=background [0x010100 resolution 12]

>- I don't understand the sentence "Must be used in conjunction with the
--generate-sea option." for --coastlinefile option. I guess this only
applies >when data like that in "gbcoastline-unfixed.zip" is used.

If you use --coastlinefile on its own it has no effect. You have to use
--generate-sea with it.
I have clarified the sentence. Perhaps specifying --coastlinefile should
switch on --generate-sea=multipolygon like --precomp-sea does.
 
>- I think the docu for --precomp-sea should point out that one can download
that data from http://www.mkgmap.org.uk/download/mkgmap.html  and >that it
typically is the best option (I don't know any good alternative)

I have added a reference to the URL (I have not made it a link as the
options builder doesn't support links as far as I remember).

>I see no need for a normal user to compile precomp-sea data, but the needed
steps are shown in
>https://wiki.openstreetmap.org/wiki/Mkgmap/help/options#generating_precompi
led_sea_yourself

I do not think mkgmap documentation should reference the OSM wiki (I don't
think it should be referenced on the index page either, as it gives the
impression that the OSM wiki is the prime place for information). If there
is any useful information about mkgmap on the OSM wiki that is not in the
mkgmap documentation, then this information needs adding to the mkgmap
documentation.

Cheers,
Mike



seadoc2.patch
Description: Binary data
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

Re: [mkgmap-dev] map boundary error

[Mike Baggaley]

Hi Gerd,

The data wasn't cached in BaseCamp (I have just done Ctrl+G twice to make
sure).

However, I had built using --gmapsupp rather than --gmapi, and copied the
gmapsupp.img file to an SD card. I have tried using --gmapi and the results
are correct there. I have also tried installing the registry settings and
that works OK as well, so it looks like a problem specific to gmapsupp.

Regards,
Mike

-Original Message-
From: Gerd Petermann [mailto:gpetermann_muenc...@hotmail.com] 
Sent: 18 February 2021 07:57
To: Development list for mkgmap 
Subject: Re: [mkgmap-dev] map boundary error

Hi Mike,

I cannot reproduce your result with the command
java -jar mkgmap.jar -gmapi test.osm.
I assume you look at cached data. Did you press Ctrl+G 2 times?

Gerd


Von: mkgmap-dev  im Auftrag von Mike
Baggaley 
Gesendet: Donnerstag, 18. Februar 2021 01:03
An: 'Development list for mkgmap'
Betreff: [mkgmap-dev] map boundary error

Hi all,

In creating a small test file I seem to have found an issue. The attached
OSM file has just 3 points and two ways form a right-angled triangle. In the
attached BaseCamp image, the blue line is the boundary of the map. Its
vertical lines contain the ways, but the horizontal lines do not. I can also
see that the road in the underlying base map enters into the blue rectangle,
suggesting that the blue line is not where the map boundary actually is. How
does this boundary line get created

Cheers,
Mike


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

[mkgmap-dev] Documentation improvements for sea processing,

[Mike Baggaley]

Hi Gerd,

Please find attached a patch to improve the documentation of sea processing
plus minor changes to --add-pois-to-lines.

I note that extend-sea-sectors says  "Adds a point so coastline reaches the
nearest tile boundary. This implies no-sea-sectors". But no-sea-sectors
disables the generation of sea sectors when the coastline fails to reach the
tile's boundary, so I would have thought that extend-sea-sectors is an
alternative action and would imply that no-sea-sectors is off.

Cheers,
Mike


seadoc.patch
Description: Binary data
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

Re: [mkgmap-dev] Pending changes

[Mike Baggaley]

HI Ticker,

If you name the typ in the typ file, there should be no need for a default name 
in the style, and as the typ file already allows multiple languages this should 
mostly negate the need for a 'translate' function. Of course, this assumes that 
you don't use a generic typ code for several different objects. Or am I missing 
something?

Regards,
Mike

-Original Message-
From: Ticker Berkin [mailto:rwb-mkg...@jagit.co.uk] 
Sent: 15 February 2021 09:16
To: Development list for mkgmap 
Subject: Re: [mkgmap-dev] Pending changes

Hi Gerd

This has always been a problem with styles, encouraged by
[... default_name ...], eg:

amenity=embassy & country!=*
[0x3003 resolution 24 default_name 'Embassy']
amenity=emergency_phone
[0x2f12 resolution 24 default_name 'Emergency Phone']

I've added to this in an attempt to provide more useful information for
unnamed entities by using constructs like:

tourism=* & name!=* & tourism!=yes & tourism!=no
{set name='${tourism|subst:"_=> "}'}
amenity=restaurant {add name='${cuisine|subst:"_=> "}'}

What is needed is another "substitution filter" - translate, that takes
an optional parameter "context"; context is normally the name of the
tag. The above would read:

amenity=embassy & country!=*
{add name='${amenity|translate:amenity}'}
[0x3003 resolution 24]
amenity=emergency_phone
{add name='${amenity|translate:amenity}'}
   
[0x2f12 resolution 24 default_name 'Emergency Phone']

tourism=* & name!=* & tourism!=yes & tourism!=no
{set name='${tourism|translate:tourism}'}
amenity=restaurant {add name='${cuisine|translate:cuisine}'}

Options would be added to mkmap:
1/ to specify a required language; given as a list, in the same manner as 
browsers, eg --language=en:gb,en

2/ a set of translation files (zip, list, directory or something),
These could be simple lists of {language,context,tag,translation} where an 
empty value takes the previous value, so could have:

en,amenity,parking,Parking
  ,   ,bench,Bench
  ,   ,place_of_worship,Church
  ,   ,restaurant,Restaurant

or, ordered in a different way:

en,barrier,fence,Fence
fr,   , ,french for fence barrier
de,   , ,german ...
en,   ,gate,Gate
fr,   ,,french for gate

There would be a special "common" context that is used if the search for 
language/context/word fails, or if |translate isn't given a context parameter. 
As a final resort, the untranslated string is initcap'd and underscores are 
replaced by spaces.

With a bit of trickery anything can be translated:

{set whatever='${_|def:strToTranslate|translate}'; ...}

Ticker 
  

On Fri, 2021-02-12 at 10:19 +, Gerd Petermann wrote:
> Hi,
> 
> reg. barrier names:
> I don't want those texts in the map at all. I might want to see them
> when I select the icon to look at the details. I expect strings in
> the map to be names of objects (streets, cities), not barrier
> properties. Esp. not in a foreign language. My opinion: If you can't
> find a good way to render them better don't render them at all.
> 
> Gerd
> 
> 
> Von: mkgmap-dev  im Auftrag
> von jan meisters 
> Gesendet: Freitag, 12. Februar 2021 10:52
> An: Development list for mkgmap
> Betreff: Re: [mkgmap-dev] Pending changes
> 
> Hi Ticker,
> 
> in fact 3200 - 3f1f strictly follow their given resolution value -
> other than e.g. 2a-2f, which only appear at kind of 24+, no matter
> what resolution is given.
> Even if both ranges are styled to resolution 24: 2a-2f will always
> appear a bit later.
> I suspect that´s what Gerd found to be confusing.
> 
> Jan
> 
> 
> > Am 12.02.2021 um 09:46 schrieb Ticker Berkin <
> > rwb-mkg...@jagit.co.uk>:
> > 
> > Hi Gerd
> > 
> > The "points" barriers use 0x3200 and I only see these when I
> > "overzoom". I think I configured the device Map Detail levels and
> > Text
> > sizes to get it how I wanted.
> > 
> > I find them useful when walking and sometimes useful for choosing
> > an
> > end-point for car navigation or seeing why a route hasn't been
> > chosen.
> > 
> > "lines" barriers (wall/ditch/etc) again I find useful when walking.
> > 
> > Either of these can commented out by users making their own style
> > starting from default. When I started, the first thing I had to
> > remove
> > were all the low-level administrative boundaries, but I think it
> > right
> > that they are in the default style.
> > 
> > I'd rather not start on other changes until this lot is out of the
> > way.
> > 
> > Ticker
> > 
> > On Thu, 2021-02-11 at 15:27 +, Gerd Petermann wrote:
> > > Hi Ticker,
> > > 
> > > while you are at it: I see lots of rather confusing texts like
> > > "gate"
> > > or "lift_gate" popping up in the map on my Oregon. I think they
> > > might
> > > be useful for mappers but they are not very useful for the normal
> > > user. Maybe it is only on my device but I don't see any need for
> > > this.
> > > 
> > > Gerd
> > > 
> > > 

Re: [mkgmap-dev] Fix Sea Patch

[Mike Baggaley]

Hi Gerd,

In my view it does not make sense to make the option only operate on the new
checks (land within land) leaving sea within sea always checked. I think
that either checks are wanted or they are not, hence the option switches on
and off all the checks. It seems overkill to go for --check=[land|sea].

To me, because the default behaviour statement is on the multipolygon value,
not the generate-sea option, the docs indicate that multipolygon is the
default when --generate-sea is specified without a value, not that
--generate-sea=multipolygon is on by default. If --generate-sea=multipolygon
is the default, how is it switched off if sea processing is not needed?

The minor changes look fine to me. Looks like I had got too used to editing
style files with its & and | rather than the Java && and ||!

Cheers,
Mike

-Original Message-
From: Gerd Petermann [mailto:gpetermann_muenc...@hotmail.com] 
Sent: 10 February 2021 08:47
To: Development list for mkgmap 
Subject: Re: [mkgmap-dev] Fix Sea Patch

Hi Mike,

if I got that right there is no impact on the PrecompSeaGenerator as that
doesn't execute this part of SeaGenerator. There is also no impact on
processing when --precomp-sea is used.
However, now the patched code only performs any check when new parameter
--check is given. Is that intended? Ticker suggested to add an option for
the additional checks.

The doc says that --generate-sea=multipolygon is the default, this is also
true with --precomp-sea. Not sure what is confusing you?

I've made some minor changes to the code to reduce complexity, but didn't
check the details of the new code.

Gerd


Von: mkgmap-dev  im Auftrag von Mike
Baggaley 
Gesendet: Montag, 8. Februar 2021 15:58
An: 'Development list for mkgmap'
Betreff: Re: [mkgmap-dev] Fix Sea Patch

HI Gerd, I don't have a build that includes the PrecompSeaGenerator, but I
would expect the impact to be the same as for in-line sea generation: an
increase in execution time if /check is specified with a reduction if it is
not specified.

I'm not quite clear what happens if you specify --precomp-sea, but don't
specify --generate-sea. The help only says that --precomp-sea can be
combined with --generate-sea but doesn't say what happens if you don't.
(Does it switch on --generate-sea=multipolygon?)

I think the order of the options in the documentation is not ideal either -
I would think --generate-sea should come first, followed by --coastline-file
and that followed by --precomp-sea. Happy to tweak this.

Cheers,
Mike

-Original Message-
From: Gerd Petermann [mailto:gpetermann_muenc...@hotmail.com]
Sent: 07 February 2021 17:36
To: Development list for mkgmap 
Subject: Re: [mkgmap-dev] Fix Sea Patch

Hi Mike and Ticker,

do you expect an impact on the PrecompSeaGenerator?

Gerd


Von: mkgmap-dev  im Auftrag von
Ticker Berkin 
Gesendet: Sonntag, 7. Februar 2021 18:16
An: Development list for mkgmap
Betreff: Re: [mkgmap-dev] Fix Sea Patch

Hi Mike / Gerd

This patch seems fine to me.

Ticker


___
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

Re: [mkgmap-dev] opposite-cycleways option

[Mike Baggaley]

HI Joris,

I do not think we should be hard coding non-standard tags into mkgmap, even
if there are a number of them in some countries.

cycleway:left=opposite, cycleway:left=opposite_lane and
cycleway:left=opposite_track are all non-standard and to me don't make any
sense.

I suggest you add something like
cycleway:left=opposite | cycleway:left=opposite_lane |
cycleway:left=opposite_track | cycleway:right=opposite | cycleway:right
=opposite_lane | cycleway:right =opposite_track { add cycleway=opposite } to
your lines file if you want to use them.

Cheers,
Mike


-Original Message-
From: Joris Bo [mailto:jori...@hotmail.com] 
Sent: 09 February 2021 11:09
To: Development list for mkgmap 
Subject: Re: [mkgmap-dev] opposite-cycleways option

Hi Gerd,

Indeed short way of saying cycleway:left=opposite_lane or
cycleway:left=opposite_track
Like you have 
cycleway=opposite |
cycleway=opposite_lane |
cycleway=opposite_track |

I would also think the others are enough but when I checked taginfo it is
more commonly used then cycleway:left=opposite_track 
So seems valid to me...



Met vriendelijke groeten,

Joris Bo
jori...@hotmail.com

-Oorspronkelijk bericht-
Van: mkgmap-dev  Namens Gerd
Petermann
Verzonden: dinsdag 9 februari 2021 10:37
Aan: Development list for mkgmap 
Onderwerp: Re: [mkgmap-dev] opposite-cycleways option

Hi Joris,

I just wonder what cycleway:left=opposite means. Same with the already
supported cycleway:left=opposite_lane. Do you know a place where this makes
sense?

Gerd


Von: mkgmap-dev  im Auftrag von
Joris Bo 
Gesendet: Dienstag, 9. Februar 2021 10:20
An: Development list for mkgmap
Betreff: Re: [mkgmap-dev] opposite-cycleways option

Hi Gerd,

I came accross tagging
cycleway:left=opposite
cycleway:right=opposite

Overpass says that there are about 3200 ways in France/Belgium for this
situation

These are not mentioned in your e-mail post as possible tagging to create
synthesize roads, if I'am correct Would it be possible to add these options?


Mentioned in your post
oneway:bicycle=no |
bicycle:oneway=no |
cycleway=opposite |
cycleway=opposite_lane |
cycleway=opposite_track |
cycleway:left=opposite_lane |
cycleway:right=opposite_lane |
cycleway:left=opposite_track |
cycleway:right=opposite_track



Met vriendelijke groeten,

Joris Bo
jori...@hotmail.com

-Oorspronkelijk bericht-
Van: mkgmap-dev  Namens Gerd
Petermann
Verzonden: maandag 8 februari 2021 16:17
Aan: Development list for mkgmap 
Onderwerp: Re: [mkgmap-dev] opposite-cycleways option

Hi Joris,

the java code creates a copy of the original way and removes various
possibly existing access tags, it sets access=no,
bicycle=yes,oneway=no,mkgmap:synthesised=yes

I would not add foot=* as the original might have something equivalent to
foot=no.
In fact there should be no need for any special handling in the style unless
you want to assign a special typ.

Gerd


Von: mkgmap-dev  im Auftrag von
Joris Bo 
Gesendet: Montag, 8. Februar 2021 13:30
An: Development list for mkgmap
Betreff: [mkgmap-dev] opposite-cycleways option

Hi,


I'm trying to improve routing for my bicycle and the oneway allowed for
bicycles by using the --make-opposite-cycleway option But I was wondering
what the criteria are for creating such extra cycleways.
I have read some earlier posts an 'll found Gerd's  comments on
http://www.mkgmap.org.uk/pipermail/mkgmap-dev/2014q2/020818.html

But the manual does not state what is actually implemented. Is there some
more documentation somewhere?

As far as I understand now

  *   Only if a highway has oneway=yes AND (some variants of oneway:bicycle
= no) then
  *   Mkgmap will create an extra highway line with (mkgmap:synthesised =
yes)
  *   Within my style file I'll pick up the mkgmap:synthesised=yes and
assign an "invisible overlay routeable highway" line and then
 *   Remove the oneway-tag (which applies to cars)
 *   set mkgmap:bicycle/foot=yes
 *   set mkgmap:car/hgv/bus/delivery=no

Is that correct?
Thx for helping me out


Met vriendelijke groeten,

Joris Bo
jori...@hotmail.com

___
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

Re: [mkgmap-dev] Fix Sea Patch

[Mike Baggaley]

HI Gerd, I don't have a build that includes the PrecompSeaGenerator, but I
would expect the impact to be the same as for in-line sea generation: an
increase in execution time if /check is specified with a reduction if it is
not specified.

I'm not quite clear what happens if you specify --precomp-sea, but don't
specify --generate-sea. The help only says that --precomp-sea can be
combined with --generate-sea but doesn't say what happens if you don't.
(Does it switch on --generate-sea=multipolygon?)

I think the order of the options in the documentation is not ideal either -
I would think --generate-sea should come first, followed by --coastline-file
and that followed by --precomp-sea. Happy to tweak this.

Cheers,
Mike

-Original Message-
From: Gerd Petermann [mailto:gpetermann_muenc...@hotmail.com] 
Sent: 07 February 2021 17:36
To: Development list for mkgmap 
Subject: Re: [mkgmap-dev] Fix Sea Patch

Hi Mike and Ticker,

do you expect an impact on the PrecompSeaGenerator?

Gerd


Von: mkgmap-dev  im Auftrag von
Ticker Berkin 
Gesendet: Sonntag, 7. Februar 2021 18:16
An: Development list for mkgmap
Betreff: Re: [mkgmap-dev] Fix Sea Patch

Hi Mike / Gerd

This patch seems fine to me.

Ticker


___
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

Re: [mkgmap-dev] Fix Sea Patch

[Mike Baggaley]

Hi Gerd/Ticker,

Please find attached an updated patch that adds the --generate-sea=check option 
and fixes the other typo.

Cheers,
Mike

-Original Message-
From: Mike Baggaley [mailto:m...@tvage.co.uk] 
Sent: 31 January 2021 17:31
To: 'Development list for mkgmap' 
Subject: RE: [mkgmap-dev] Fix Sea Patch

Hi Ticker,

The third case (water areas) will be because they are ordered in the wrong 
direction, so they are being picked up as land rather than water - hence the 
error message of land within land. There is no sea showing on the standard OSM 
renderer for way 255902449. This one is presumably seawater that gets refilled 
at extra high tide. My own generated map does show seawater at this point. I 
haven't checked the others.

I'll look at adding an option for checking the sea data (--generate-sea=check) 
and fix the typo you mentioned.

Cheers,
Mike

-Original Message-
From: Ticker Berkin [mailto:rwb-mkg...@jagit.co.uk] 
Sent: 30 January 2021 17:05
To: Development list for mkgmap 
Subject: Re: [mkgmap-dev] Fix Sea Patch

Hi Mike & Gerd

I've just tried running with this on britain-and-ireland.osm.pbf using:
 --generate-sea=multipolygon,extend-sea-sectors,close-gaps=750

I got a few messages from it that I don't get normally - attached.

Looking at some of these, I found:
1/ islands, tagged with coastline, within lakes.
2/ strange inland coastline triangles (didn't check which way round the
coastline went) Source "OS_Opendata_Vectormap_District"
3/ water areas,
close to the sea - maybe salt-water lagoons, tagged with coastline -
I'm not sure why these are flagged if inland seas are allowed.

Some of these could be fixed in OSM.

The run-time has increases from about 35 mins to 44 mins (would need to
run again in a clean environment to be sure of this). I suggest having
an option to enable the extra checking.

I don't have any problem with more detailed logging.

Good to fix the spelling mistake (but should fix loadLandAndSee as
well)

Ticker

On Fri, 2021-01-29 at 11:18 +, Mike Baggaley wrote:
> Hi Gerd, attached is a slightly updated patch, with test data and the
> results from r4600 and the patch. The existing code does not identify
> all
> the problems in the test data and does not provide sufficiently
> detailed
> information on those it does find to enable investigation/correction.
> 
> The test data contains 4 test scenarios:
> land within sea within land, no errors - the existing code is ok here
> sea within land within sea, the outer sea should produce an error -
> the
> existing code is ok here
> land within land within land, the two inner lands should produce an
> error -
> these are not found by the existing code
> sea within sea within sea, all three seas should produce an error -
> the
> existing code finds the errors but does not identify the surrounding
> way for
> the inner two
> 
> Cheers,
> Mike
> 
> -Original Message-
> From: Gerd Petermann [mailto:gpetermann_muenc...@hotmail.com] 
> Sent: 18 January 2021 11:54
> To: Development list for mkgmap 
> Subject: Re: [mkgmap-dev] Fix Sea Patch
> 
> Hi Mike,
> 
> it would be great  to have some unit tests or at least a sample file
> containing the problem cases which are treated by your patch.
> 
> Gerd
> 
> 
> Von: mkgmap-dev  im Auftrag
> von Mike
> Baggaley 
> Gesendet: Montag, 18. Januar 2021 10:06
> An: 'Development list for mkgmap'
> Betreff: Re: [mkgmap-dev] Fix Sea Patch
> 
> Hi Gerd,
> 
> I had too little logging information in the version I sent
> previously. The
> attached remedies that.
> 
> Cheers,
> Mike
> 
> -Original Message-
> From: Mike Baggaley [mailto:m...@tvage.co.uk]
> Sent: 18 January 2021 00:28
> To: 'Development list for mkgmap' 
> Subject: RE: [mkgmap-dev] Fix Sea Patch
> 
> Hi Gerd,
> 
> I'm not sure that mkgmap should be prescriptive about where the input
> data
> comes from. However, I have produced an updated patch that reports on
> errors
> in the input data without providing any functionality to fix the
> problems.
> Please see the attached patch that is able to identify most problems
> in sea
> data.
> 
> Cheers,
> Mike
> 
> -Original Message-
> From: Gerd Petermann [mailto:gpetermann_muenc...@hotmail.com]
> Sent: 05 January 2021 08:40
> To: Development list for mkgmap 
> Subject: Re: [mkgmap-dev] Fix Sea Patch
> 
> Hi Mike & Ticker,
> 
> I would not want to add code to mkgmap to fix problems which only
> occur in
> data that is produced by a 3rd party software. My understanding is
> that the
> "fixing" should happen in that 3rd party software, not in mkgmap.
> 
> Gerd
> 
> 
> Von

Re: [mkgmap-dev] Fix Sea Patch

[Mike Baggaley]

Hi Ticker,

The third case (water areas) will be because they are ordered in the wrong 
direction, so they are being picked up as land rather than water - hence the 
error message of land within land. There is no sea showing on the standard OSM 
renderer for way 255902449. This one is presumably seawater that gets refilled 
at extra high tide. My own generated map does show seawater at this point. I 
haven't checked the others.

I'll look at adding an option for checking the sea data (--generate-sea=check) 
and fix the typo you mentioned.

Cheers,
Mike

-Original Message-
From: Ticker Berkin [mailto:rwb-mkg...@jagit.co.uk] 
Sent: 30 January 2021 17:05
To: Development list for mkgmap 
Subject: Re: [mkgmap-dev] Fix Sea Patch

Hi Mike & Gerd

I've just tried running with this on britain-and-ireland.osm.pbf using:
 --generate-sea=multipolygon,extend-sea-sectors,close-gaps=750

I got a few messages from it that I don't get normally - attached.

Looking at some of these, I found:
1/ islands, tagged with coastline, within lakes.
2/ strange inland coastline triangles (didn't check which way round the
coastline went) Source "OS_Opendata_Vectormap_District"
3/ water areas,
close to the sea - maybe salt-water lagoons, tagged with coastline -
I'm not sure why these are flagged if inland seas are allowed.

Some of these could be fixed in OSM.

The run-time has increases from about 35 mins to 44 mins (would need to
run again in a clean environment to be sure of this). I suggest having
an option to enable the extra checking.

I don't have any problem with more detailed logging.

Good to fix the spelling mistake (but should fix loadLandAndSee as
well)

Ticker

On Fri, 2021-01-29 at 11:18 +, Mike Baggaley wrote:
> Hi Gerd, attached is a slightly updated patch, with test data and the
> results from r4600 and the patch. The existing code does not identify
> all
> the problems in the test data and does not provide sufficiently
> detailed
> information on those it does find to enable investigation/correction.
> 
> The test data contains 4 test scenarios:
> land within sea within land, no errors - the existing code is ok here
> sea within land within sea, the outer sea should produce an error -
> the
> existing code is ok here
> land within land within land, the two inner lands should produce an
> error -
> these are not found by the existing code
> sea within sea within sea, all three seas should produce an error -
> the
> existing code finds the errors but does not identify the surrounding
> way for
> the inner two
> 
> Cheers,
> Mike
> 
> -Original Message-
> From: Gerd Petermann [mailto:gpetermann_muenc...@hotmail.com] 
> Sent: 18 January 2021 11:54
> To: Development list for mkgmap 
> Subject: Re: [mkgmap-dev] Fix Sea Patch
> 
> Hi Mike,
> 
> it would be great  to have some unit tests or at least a sample file
> containing the problem cases which are treated by your patch.
> 
> Gerd
> 
> 
> Von: mkgmap-dev  im Auftrag
> von Mike
> Baggaley 
> Gesendet: Montag, 18. Januar 2021 10:06
> An: 'Development list for mkgmap'
> Betreff: Re: [mkgmap-dev] Fix Sea Patch
> 
> Hi Gerd,
> 
> I had too little logging information in the version I sent
> previously. The
> attached remedies that.
> 
> Cheers,
> Mike
> 
> -Original Message-
> From: Mike Baggaley [mailto:m...@tvage.co.uk]
> Sent: 18 January 2021 00:28
> To: 'Development list for mkgmap' 
> Subject: RE: [mkgmap-dev] Fix Sea Patch
> 
> Hi Gerd,
> 
> I'm not sure that mkgmap should be prescriptive about where the input
> data
> comes from. However, I have produced an updated patch that reports on
> errors
> in the input data without providing any functionality to fix the
> problems.
> Please see the attached patch that is able to identify most problems
> in sea
> data.
> 
> Cheers,
> Mike
> 
> -Original Message-
> From: Gerd Petermann [mailto:gpetermann_muenc...@hotmail.com]
> Sent: 05 January 2021 08:40
> To: Development list for mkgmap 
> Subject: Re: [mkgmap-dev] Fix Sea Patch
> 
> Hi Mike & Ticker,
> 
> I would not want to add code to mkgmap to fix problems which only
> occur in
> data that is produced by a 3rd party software. My understanding is
> that the
> "fixing" should happen in that 3rd party software, not in mkgmap.
> 
> Gerd
> 
> 
> Von: mkgmap-dev  im Auftrag
> von Mike
> Baggaley 
> Gesendet: Montag, 4. Januar 2021 20:40
> An: 'Development list for mkgmap'
> Betreff: Re: [mkgmap-dev] Fix Sea Patch
> 
> Hi Ticker,
> 
> I use coastline data that is generated from just line data and the
> algorithm
> used is not able t

Re: [mkgmap-dev] Fix Sea Patch

[Mike Baggaley]

Hi Gerd, attached is a slightly updated patch, with test data and the
results from r4600 and the patch. The existing code does not identify all
the problems in the test data and does not provide sufficiently detailed
information on those it does find to enable investigation/correction.

The test data contains 4 test scenarios:
land within sea within land, no errors - the existing code is ok here
sea within land within sea, the outer sea should produce an error - the
existing code is ok here
land within land within land, the two inner lands should produce an error -
these are not found by the existing code
sea within sea within sea, all three seas should produce an error - the
existing code finds the errors but does not identify the surrounding way for
the inner two

Cheers,
Mike

-Original Message-
From: Gerd Petermann [mailto:gpetermann_muenc...@hotmail.com] 
Sent: 18 January 2021 11:54
To: Development list for mkgmap 
Subject: Re: [mkgmap-dev] Fix Sea Patch

Hi Mike,

it would be great  to have some unit tests or at least a sample file
containing the problem cases which are treated by your patch.

Gerd


Von: mkgmap-dev  im Auftrag von Mike
Baggaley 
Gesendet: Montag, 18. Januar 2021 10:06
An: 'Development list for mkgmap'
Betreff: Re: [mkgmap-dev] Fix Sea Patch

Hi Gerd,

I had too little logging information in the version I sent previously. The
attached remedies that.

Cheers,
Mike

-Original Message-
From: Mike Baggaley [mailto:m...@tvage.co.uk]
Sent: 18 January 2021 00:28
To: 'Development list for mkgmap' 
Subject: RE: [mkgmap-dev] Fix Sea Patch

Hi Gerd,

I'm not sure that mkgmap should be prescriptive about where the input data
comes from. However, I have produced an updated patch that reports on errors
in the input data without providing any functionality to fix the problems.
Please see the attached patch that is able to identify most problems in sea
data.

Cheers,
Mike

-Original Message-
From: Gerd Petermann [mailto:gpetermann_muenc...@hotmail.com]
Sent: 05 January 2021 08:40
To: Development list for mkgmap 
Subject: Re: [mkgmap-dev] Fix Sea Patch

Hi Mike & Ticker,

I would not want to add code to mkgmap to fix problems which only occur in
data that is produced by a 3rd party software. My understanding is that the
"fixing" should happen in that 3rd party software, not in mkgmap.

Gerd


Von: mkgmap-dev  im Auftrag von Mike
Baggaley 
Gesendet: Montag, 4. Januar 2021 20:40
An: 'Development list for mkgmap'
Betreff: Re: [mkgmap-dev] Fix Sea Patch

Hi Ticker,

I use coastline data that is generated from just line data and the algorithm
used is not able to properly determine whether polygons are islands or
water. It does however make sure polygons are closed, so I don't have
problems with having to join ways together and hence I don't use close-gaps
or extend sea-sectors.

I'm unclear exactly what an anti-island is supposed to be - I have
considered it to be a separate bit of sea, and in my data I have lots of
those that are correct. They are only incorrect if they are within the sea,
rather than the land. For example, if there is a coast road with sea on both
sides of it, I am likely to have a separate sea polygon within the land if
its connection to the sea is under a bridge. The patch checks for sea within
sea and land within land. It doesn't then go back and recursively check for
nested problems - I suspect this would be quite an overhead.

The code is certainly not perfect, but does produce enormously improved
results for me at least. I can still see at least one error in my map, but I
think the remaining errors are tile boundary issues that are resolved
differently on adjacent tiles. I am thinking of a small app to read the
mkgmap log file and the coastline data, reversing whatever mkgmap says is
wrong. By running mkgmap without splitter on just the coastline data I
should be able to avoid any tile boundary problems.

Cheers,
Mike

-Original Message-
From: Ticker Berkin [mailto:rwb-mkg...@jagit.co.uk]
Sent: 04 January 2021 13:58
To: Development list for mkgmap 
Subject: Re: [mkgmap-dev] Fix Sea Patch

Hi Mike & Gerd

I always try to use the coastline data in the downloaded OSM map to
generate the sea with option:
  --generate-sea=multipolygon,extend-sea
-sectors,close-gaps=750
and have only ever had 1 problem with faulty
coastline. In this case it wasn't a reversed section but a lake had
been tagged with coastline, worse, in the wrong direction so it wasn't
treated as an internal sea, rather an island, flipping the rest of the
tile to sea.

I sometimes have problems with the continuation of the downloaded country's
coastlines being cut off and ending up near the middle of tiles, but closer
to the wrong edge or, when extended to the edge, they are in the same
direction as an adjacent coastline, because the un-crossing is outside the
downloaded area.

Re: [mkgmap-dev] Fix Sea Patch

[Mike Baggaley]

Hi Gerd,

I have uploaded /download/498/gbcoastline-unfixed.zip which contains
coastline data that is incorrectly ordered.

Cheers,
Mike


-Original Message-
From: Gerd Petermann [mailto:gpetermann_muenc...@hotmail.com] 
Sent: 18 January 2021 11:54
To: Development list for mkgmap 
Subject: Re: [mkgmap-dev] Fix Sea Patch

Hi Mike,

it would be great  to have some unit tests or at least a sample file
containing the problem cases which are treated by your patch.

Gerd


Von: mkgmap-dev  im Auftrag von Mike
Baggaley 
Gesendet: Montag, 18. Januar 2021 10:06
An: 'Development list for mkgmap'
Betreff: Re: [mkgmap-dev] Fix Sea Patch

Hi Gerd,

I had too little logging information in the version I sent previously. The
attached remedies that.

Cheers,
Mike

-Original Message-
From: Mike Baggaley [mailto:m...@tvage.co.uk]
Sent: 18 January 2021 00:28
To: 'Development list for mkgmap' 
Subject: RE: [mkgmap-dev] Fix Sea Patch

Hi Gerd,

I'm not sure that mkgmap should be prescriptive about where the input data
comes from. However, I have produced an updated patch that reports on errors
in the input data without providing any functionality to fix the problems.
Please see the attached patch that is able to identify most problems in sea
data.

Cheers,
Mike

-Original Message-
From: Gerd Petermann [mailto:gpetermann_muenc...@hotmail.com]
Sent: 05 January 2021 08:40
To: Development list for mkgmap 
Subject: Re: [mkgmap-dev] Fix Sea Patch

Hi Mike & Ticker,

I would not want to add code to mkgmap to fix problems which only occur in
data that is produced by a 3rd party software. My understanding is that the
"fixing" should happen in that 3rd party software, not in mkgmap.

Gerd


Von: mkgmap-dev  im Auftrag von Mike
Baggaley 
Gesendet: Montag, 4. Januar 2021 20:40
An: 'Development list for mkgmap'
Betreff: Re: [mkgmap-dev] Fix Sea Patch

Hi Ticker,

I use coastline data that is generated from just line data and the algorithm
used is not able to properly determine whether polygons are islands or
water. It does however make sure polygons are closed, so I don't have
problems with having to join ways together and hence I don't use close-gaps
or extend sea-sectors.

I'm unclear exactly what an anti-island is supposed to be - I have
considered it to be a separate bit of sea, and in my data I have lots of
those that are correct. They are only incorrect if they are within the sea,
rather than the land. For example, if there is a coast road with sea on both
sides of it, I am likely to have a separate sea polygon within the land if
its connection to the sea is under a bridge. The patch checks for sea within
sea and land within land. It doesn't then go back and recursively check for
nested problems - I suspect this would be quite an overhead.

The code is certainly not perfect, but does produce enormously improved
results for me at least. I can still see at least one error in my map, but I
think the remaining errors are tile boundary issues that are resolved
differently on adjacent tiles. I am thinking of a small app to read the
mkgmap log file and the coastline data, reversing whatever mkgmap says is
wrong. By running mkgmap without splitter on just the coastline data I
should be able to avoid any tile boundary problems.

Cheers,
Mike

-Original Message-
From: Ticker Berkin [mailto:rwb-mkg...@jagit.co.uk]
Sent: 04 January 2021 13:58
To: Development list for mkgmap 
Subject: Re: [mkgmap-dev] Fix Sea Patch

Hi Mike & Gerd

I always try to use the coastline data in the downloaded OSM map to
generate the sea with option:
  --generate-sea=multipolygon,extend-sea
-sectors,close-gaps=750
and have only ever had 1 problem with faulty
coastline. In this case it wasn't a reversed section but a lake had
been tagged with coastline, worse, in the wrong direction so it wasn't
treated as an internal sea, rather an island, flipping the rest of the
tile to sea.

I sometimes have problems with the continuation of the downloaded country's
coastlines being cut off and ending up near the middle of tiles, but closer
to the wrong edge or, when extended to the edge, they are in the same
direction as an adjacent coastline, because the un-crossing is outside the
downloaded area.

@Mike - Do you use --coastlinefile to circumvent this type of problem and is
there an advantage to this over using --precomp-sea? The data seems to need
a lot of correcting!

If arbitrary bits of coastline are in the wrong direction, should you have
another phase, after joining in the same direction and removing
anti/islands. Try to join against their direction and moving closed ways to
an ambiguous closed list and other ways that joined to an ambiguous linear
list. Then see if the ambiguous ones can be resolved, maybe by weighting by
the direction of the majority.

I feel that some of your fixes of land/sea are too late in the flow of code,
ie after genera

Re: [mkgmap-dev] Fix Sea Patch

[Mike Baggaley]

Hi Gerd,

I had too little logging information in the version I sent previously. The
attached remedies that.

Cheers,
Mike

-Original Message-
From: Mike Baggaley [mailto:m...@tvage.co.uk] 
Sent: 18 January 2021 00:28
To: 'Development list for mkgmap' 
Subject: RE: [mkgmap-dev] Fix Sea Patch

Hi Gerd,

I'm not sure that mkgmap should be prescriptive about where the input data
comes from. However, I have produced an updated patch that reports on errors
in the input data without providing any functionality to fix the problems.
Please see the attached patch that is able to identify most problems in sea
data.

Cheers,
Mike

-Original Message-
From: Gerd Petermann [mailto:gpetermann_muenc...@hotmail.com] 
Sent: 05 January 2021 08:40
To: Development list for mkgmap 
Subject: Re: [mkgmap-dev] Fix Sea Patch

Hi Mike & Ticker,

I would not want to add code to mkgmap to fix problems which only occur in
data that is produced by a 3rd party software. My understanding is that the
"fixing" should happen in that 3rd party software, not in mkgmap.

Gerd


Von: mkgmap-dev  im Auftrag von Mike
Baggaley 
Gesendet: Montag, 4. Januar 2021 20:40
An: 'Development list for mkgmap'
Betreff: Re: [mkgmap-dev] Fix Sea Patch

Hi Ticker,

I use coastline data that is generated from just line data and the algorithm
used is not able to properly determine whether polygons are islands or
water. It does however make sure polygons are closed, so I don't have
problems with having to join ways together and hence I don't use close-gaps
or extend sea-sectors.

I'm unclear exactly what an anti-island is supposed to be - I have
considered it to be a separate bit of sea, and in my data I have lots of
those that are correct. They are only incorrect if they are within the sea,
rather than the land. For example, if there is a coast road with sea on both
sides of it, I am likely to have a separate sea polygon within the land if
its connection to the sea is under a bridge. The patch checks for sea within
sea and land within land. It doesn't then go back and recursively check for
nested problems - I suspect this would be quite an overhead.

The code is certainly not perfect, but does produce enormously improved
results for me at least. I can still see at least one error in my map, but I
think the remaining errors are tile boundary issues that are resolved
differently on adjacent tiles. I am thinking of a small app to read the
mkgmap log file and the coastline data, reversing whatever mkgmap says is
wrong. By running mkgmap without splitter on just the coastline data I
should be able to avoid any tile boundary problems.

Cheers,
Mike

-Original Message-
From: Ticker Berkin [mailto:rwb-mkg...@jagit.co.uk]
Sent: 04 January 2021 13:58
To: Development list for mkgmap 
Subject: Re: [mkgmap-dev] Fix Sea Patch

Hi Mike & Gerd

I always try to use the coastline data in the downloaded OSM map to
generate the sea with option:
  --generate-sea=multipolygon,extend-sea
-sectors,close-gaps=750
and have only ever had 1 problem with faulty
coastline. In this case it wasn't a reversed section but a lake had
been tagged with coastline, worse, in the wrong direction so it wasn't
treated as an internal sea, rather an island, flipping the rest of the
tile to sea.

I sometimes have problems with the continuation of the downloaded country's
coastlines being cut off and ending up near the middle of tiles, but closer
to the wrong edge or, when extended to the edge, they are in the same
direction as an adjacent coastline, because the un-crossing is outside the
downloaded area.

@Mike - Do you use --coastlinefile to circumvent this type of problem and is
there an advantage to this over using --precomp-sea? The data seems to need
a lot of correcting!

If arbitrary bits of coastline are in the wrong direction, should you have
another phase, after joining in the same direction and removing
anti/islands. Try to join against their direction and moving closed ways to
an ambiguous closed list and other ways that joined to an ambiguous linear
list. Then see if the ambiguous ones can be resolved, maybe by weighting by
the direction of the majority.

I feel that some of your fixes of land/sea are too late in the flow of code,
ie after generateSeaBackgound has been set.

It seems a reasonably assertion that all anti-islands are a mistake in the
data. I think the only one is the Caspian Sea, which is unlikely to be fully
contained in a tile.

checkIslands(), to do the full job, would need to look at the nesting of
sea/land/sea... so, given above, I don't think it worthwhile.

In verifyHits(), I don't see where any changes that resolves "adjacent hits
in same direction" are applied. The 'fix' could make it totally wrong rather
than partially wrong. Looking for 3 in the same direction and reversing the
middle one might be better.

As I said earlier, I've never had a problem where this type o

Re: [mkgmap-dev] Fix Sea Patch

[Mike Baggaley]

Hi Gerd,

I'm not sure that mkgmap should be prescriptive about where the input data
comes from. However, I have produced an updated patch that reports on errors
in the input data without providing any functionality to fix the problems.
Please see the attached patch that is able to identify most problems in sea
data.

Cheers,
Mike

-Original Message-
From: Gerd Petermann [mailto:gpetermann_muenc...@hotmail.com] 
Sent: 05 January 2021 08:40
To: Development list for mkgmap 
Subject: Re: [mkgmap-dev] Fix Sea Patch

Hi Mike & Ticker,

I would not want to add code to mkgmap to fix problems which only occur in
data that is produced by a 3rd party software. My understanding is that the
"fixing" should happen in that 3rd party software, not in mkgmap.

Gerd


Von: mkgmap-dev  im Auftrag von Mike
Baggaley 
Gesendet: Montag, 4. Januar 2021 20:40
An: 'Development list for mkgmap'
Betreff: Re: [mkgmap-dev] Fix Sea Patch

Hi Ticker,

I use coastline data that is generated from just line data and the algorithm
used is not able to properly determine whether polygons are islands or
water. It does however make sure polygons are closed, so I don't have
problems with having to join ways together and hence I don't use close-gaps
or extend sea-sectors.

I'm unclear exactly what an anti-island is supposed to be - I have
considered it to be a separate bit of sea, and in my data I have lots of
those that are correct. They are only incorrect if they are within the sea,
rather than the land. For example, if there is a coast road with sea on both
sides of it, I am likely to have a separate sea polygon within the land if
its connection to the sea is under a bridge. The patch checks for sea within
sea and land within land. It doesn't then go back and recursively check for
nested problems - I suspect this would be quite an overhead.

The code is certainly not perfect, but does produce enormously improved
results for me at least. I can still see at least one error in my map, but I
think the remaining errors are tile boundary issues that are resolved
differently on adjacent tiles. I am thinking of a small app to read the
mkgmap log file and the coastline data, reversing whatever mkgmap says is
wrong. By running mkgmap without splitter on just the coastline data I
should be able to avoid any tile boundary problems.

Cheers,
Mike

-Original Message-
From: Ticker Berkin [mailto:rwb-mkg...@jagit.co.uk]
Sent: 04 January 2021 13:58
To: Development list for mkgmap 
Subject: Re: [mkgmap-dev] Fix Sea Patch

Hi Mike & Gerd

I always try to use the coastline data in the downloaded OSM map to
generate the sea with option:
  --generate-sea=multipolygon,extend-sea
-sectors,close-gaps=750
and have only ever had 1 problem with faulty
coastline. In this case it wasn't a reversed section but a lake had
been tagged with coastline, worse, in the wrong direction so it wasn't
treated as an internal sea, rather an island, flipping the rest of the
tile to sea.

I sometimes have problems with the continuation of the downloaded country's
coastlines being cut off and ending up near the middle of tiles, but closer
to the wrong edge or, when extended to the edge, they are in the same
direction as an adjacent coastline, because the un-crossing is outside the
downloaded area.

@Mike - Do you use --coastlinefile to circumvent this type of problem and is
there an advantage to this over using --precomp-sea? The data seems to need
a lot of correcting!

If arbitrary bits of coastline are in the wrong direction, should you have
another phase, after joining in the same direction and removing
anti/islands. Try to join against their direction and moving closed ways to
an ambiguous closed list and other ways that joined to an ambiguous linear
list. Then see if the ambiguous ones can be resolved, maybe by weighting by
the direction of the majority.

I feel that some of your fixes of land/sea are too late in the flow of code,
ie after generateSeaBackgound has been set.

It seems a reasonably assertion that all anti-islands are a mistake in the
data. I think the only one is the Caspian Sea, which is unlikely to be fully
contained in a tile.

checkIslands(), to do the full job, would need to look at the nesting of
sea/land/sea... so, given above, I don't think it worthwhile.

In verifyHits(), I don't see where any changes that resolves "adjacent hits
in same direction" are applied. The 'fix' could make it totally wrong rather
than partially wrong. Looking for 3 in the same direction and reversing the
middle one might be better.

As I said earlier, I've never had a problem where this type of fixing would
be of any use.

The swapping between land and sea needs to do more than just re-tagging; the
multi-polygon handling needs to be considered and also the fullArea of sea.

Ticker

On Sat, 2021-01-02 at 10:32 +, Gerd Petermann wrote:
> Hi Mike,
>
> > This was removed some time ago becau

Re: [mkgmap-dev] improved diagnostics patch v2

[Mike Baggaley]

Hi Gerd,

I have made a couple of small changes in the attached version.

Cheers,
Mike

-Original Message-
From: Gerd Petermann [mailto:gpetermann_muenc...@hotmail.com] 
Sent: 15 January 2021 08:26
To: Development list for mkgmap 
Subject: Re: [mkgmap-dev] improved diagnostics patch v2

Hi Mike,

here's the result of my additional changes. Please double check.

Gerd



diagnostics8.patch
Description: Binary data
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

Re: [mkgmap-dev] improved diagnostics patch v2

[Mike Baggaley]

HI Gerd, 

That implementation of toBrowseURL doesn't handle the case where originalId
is also a generated Id (e.g. the background areas generated in SeaGenerator
which do not relate to any OSM way).

How about:
if (FakeIdGenerator.isFakeId(id))
   return getBasicLogInformation();

Cheers,
Mike

-Original Message-
From: Gerd Petermann [mailto:gpetermann_muenc...@hotmail.com] 
Sent: 15 January 2021 07:07
To: Development list for mkgmap 
Subject: Re: [mkgmap-dev] improved diagnostics patch v2

Hi Mike,

didn't help for my case where way.toBrowseURL() is called for a way which
was generated from a multipolygon. (WrongAngleFixer line 688)

I think I can replace toBrowseURL() with getBasicLogInformation() there and
in all other debug.log() messages. I think the urls are not helping anyway
when debugging. There are also some duplicated blanks in log messages.

My current version of toBrowseURL() looks like this:
public String toBrowseURL() {
if (FakeIdGenerator.isFakeId(id))
return "generated from " + getOrigElement() + " " +
originalId;

return "http://www.openstreetmap.org/; + kind() + "/" + id;
}

Gerd

____
Von: mkgmap-dev  im Auftrag von Mike
Baggaley 
Gesendet: Donnerstag, 14. Januar 2021 12:59
An: 'Development list for mkgmap'
Betreff: Re: [mkgmap-dev] improved diagnostics patch v2

HI Gerd,

I spotted a problem in Element.getBasicLogInformation if it is called on an
element that does not have an OSM Id. The attached patch fixes that. The
previous version only fixed it in Element.toBrowseURL.

Cheers,
Mike

-----Original Message-
From: Mike Baggaley [mailto:m...@tvage.co.uk]
Sent: 13 January 2021 20:53
To: 'Development list for mkgmap' 
Subject: RE: [mkgmap-dev] improved diagnostics patch v2

HI Gerd,

The attached updated patch fixes the problem of a URL for a way having a
relation id rather than an way id. It also handles the case where a way is
generated without an original OSM id (as happens in the sea generator), so
there is no valid URL.

Cheers,
Mike

-Original Message-
From: Gerd Petermann [mailto:gpetermann_muenc...@hotmail.com]
Sent: 13 January 2021 09:58
To: Development list for mkgmap 
Subject: Re: [mkgmap-dev] improved diagnostics patch v2

Hi Mike,

I get some messages which are wrong:
FEIN: uk.me.parabola.mkgmap.osmstyle.WrongAngleFixer
f:\osm\wildeshausen.o5m: removing obsolete point on almost straight segment
in way  http://www.openstreetmap.org/way/1187315 at
http://www.openstreetmap.org/?mlat=52.940356=8.340912=17

instead of
FEIN: uk.me.parabola.mkgmap.osmstyle.WrongAngleFixer
f:\osm\wildeshausen.o5m: removing obsolete point on almost straight segment
in way  http://www.openstreetmap.org/way/4611686018427387930 at
http://www.openstreetmap.org/?mlat=52.940356=8.340912=17

The way in question is w78508173 which is a member of relation 1187315. So,
the new code reports the relation id as way id.

I also see unexpected changes in the img files. Don't know yet why. I assume
toString() is used to identify objects somewhere.

Gerd


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

Re: [mkgmap-dev] improved diagnostics patch v2

[Mike Baggaley]

Hi Gerd, the toBrowseURL function just returns an OSM URL currently, unless
the element is not derived from an OSM object, so that is the expected
result. Do you want to me change this so that is does include "generated
from"?

I think that actually most of the calls to toBrowseURL would be better
calling getBasicLogInformation instead, which would make the log files
smaller and more readable. I do find the coordinate URLs useful, but never
use the ones for ways/nodes/relations. Does anyone else use them?

Cheers,
Mike

-Original Message-
From: Gerd Petermann [mailto:gpetermann_muenc...@hotmail.com] 
Sent: 14 January 2021 07:33
To: Development list for mkgmap 
Subject: Re: [mkgmap-dev] improved diagnostics patch v2

Hi Mike,

not sure if this is intended:  (way followed by link to relation without a
"generated from"
FEIN: uk.me.parabola.mkgmap.osmstyle.WrongAngleFixer  f:\osm\work.osm:
removing obsolete point on almost straight segment in way
http://www.openstreetmap.org/relation/1518688 at
http://www.openstreetmap.org/?mlat=53.892259=8.684634=17

Gerd


Von: mkgmap-dev  im Auftrag von Mike
Baggaley 
Gesendet: Mittwoch, 13. Januar 2021 21:53
An: 'Development list for mkgmap'
Betreff: Re: [mkgmap-dev] improved diagnostics patch v2

HI Gerd,

The attached updated patch fixes the problem of a URL for a way having a
relation id rather than an way id. It also handles the case where a way is
generated without an original OSM id (as happens in the sea generator), so
there is no valid URL.

Cheers,
Mike

-Original Message-
From: Gerd Petermann [mailto:gpetermann_muenc...@hotmail.com]
Sent: 13 January 2021 09:58
To: Development list for mkgmap 
Subject: Re: [mkgmap-dev] improved diagnostics patch v2

Hi Mike,

I get some messages which are wrong:
FEIN: uk.me.parabola.mkgmap.osmstyle.WrongAngleFixer
f:\osm\wildeshausen.o5m: removing obsolete point on almost straight segment
in way  http://www.openstreetmap.org/way/1187315 at
http://www.openstreetmap.org/?mlat=52.940356=8.340912=17

instead of
FEIN: uk.me.parabola.mkgmap.osmstyle.WrongAngleFixer
f:\osm\wildeshausen.o5m: removing obsolete point on almost straight segment
in way  http://www.openstreetmap.org/way/4611686018427387930 at
http://www.openstreetmap.org/?mlat=52.940356=8.340912=17

The way in question is w78508173 which is a member of relation 1187315. So,
the new code reports the relation id as way id.

I also see unexpected changes in the img files. Don't know yet why. I assume
toString() is used to identify objects somewhere.

Gerd


Von: mkgmap-dev  im Auftrag von Gerd
Petermann 
Gesendet: Mittwoch, 13. Januar 2021 09:22
An: Development list for mkgmap
Betreff: Re: [mkgmap-dev] improved diagnostics patch v2

Hi Mike,

thanks, I'll have a closer look today.

Gerd


Von: mkgmap-dev  im Auftrag von Mike
Baggaley 
Gesendet: Montag, 11. Januar 2021 10:20
An: 'Development list for mkgmap'
Betreff: Re: [mkgmap-dev] improved diagnostics patch v2

HI Gerd,

Thanks for the updated patch. I have got rid of the repeated definitions of
"generated from" by using getBasicLogInformation as the basis of toString.
This makes them all consistent (although it is not capitalised or have a
colon). It would be more logical for the toString function to contain just
the basic information, the information currently in toString to be in a new
getExtendedLogInformation function and getBasicLoginInformation deleted.
However, this would need a lot of changes elsewhere.

Does RoadDef.toString really need to output a URL? It would improve the
reading of my log files if it was just "(way" + id + ")". For consistency
with above, this should really be "RoadDef + id" / "RoadDef generated",
which would suit me fine. What do you think?

Please find attached an updated version.

Cheers,
Mike

-Original Message-
From: Gerd Petermann [mailto:gpetermann_muenc...@hotmail.com]
Sent: 10 January 2021 08:04
To: Development list for mkgmap 
Subject: Re: [mkgmap-dev] improved diagnostics patch v2

Hi Mike,

sorry, I looked at your first patch but forgot to answer. I always hesitate
to change those debug messages because some users parse them with scripts.
I think Way.toString() should work similar to Node.toString and
Relation.toString and thus return a string starting with "WAY:". See my
modified version.

I don't like the repeated code producing the "generated from" messages.
Isn't it possible to implement that once in classElement?

Gerd




Von: mkgmap-dev  im Auftrag von Mike
Baggaley 
Gesendet: Samstag, 9. Januar 2021 17:18
An: 'Development list for mkgmap'
Betreff: [mkgmap-dev] improved diagnostics patch v2

Hi Gerd,

My previous diagnostic improvements patch seems to have got lost, but since
then I have no

Re: [mkgmap-dev] improved diagnostics patch v2

[Mike Baggaley]

HI Gerd,

I spotted a problem in Element.getBasicLogInformation if it is called on an
element that does not have an OSM Id. The attached patch fixes that. The
previous version only fixed it in Element.toBrowseURL.

Cheers,
Mike

-Original Message-
From: Mike Baggaley [mailto:m...@tvage.co.uk] 
Sent: 13 January 2021 20:53
To: 'Development list for mkgmap' 
Subject: RE: [mkgmap-dev] improved diagnostics patch v2

HI Gerd,

The attached updated patch fixes the problem of a URL for a way having a
relation id rather than an way id. It also handles the case where a way is
generated without an original OSM id (as happens in the sea generator), so
there is no valid URL.

Cheers,
Mike

-Original Message-
From: Gerd Petermann [mailto:gpetermann_muenc...@hotmail.com] 
Sent: 13 January 2021 09:58
To: Development list for mkgmap 
Subject: Re: [mkgmap-dev] improved diagnostics patch v2

Hi Mike,

I get some messages which are wrong:
FEIN: uk.me.parabola.mkgmap.osmstyle.WrongAngleFixer
f:\osm\wildeshausen.o5m: removing obsolete point on almost straight segment
in way  http://www.openstreetmap.org/way/1187315 at
http://www.openstreetmap.org/?mlat=52.940356=8.340912=17

instead of
FEIN: uk.me.parabola.mkgmap.osmstyle.WrongAngleFixer
f:\osm\wildeshausen.o5m: removing obsolete point on almost straight segment
in way  http://www.openstreetmap.org/way/4611686018427387930 at
http://www.openstreetmap.org/?mlat=52.940356=8.340912=17

The way in question is w78508173 which is a member of relation 1187315. So,
the new code reports the relation id as way id.

I also see unexpected changes in the img files. Don't know yet why. I assume
toString() is used to identify objects somewhere.

Gerd


Von: mkgmap-dev  im Auftrag von Gerd
Petermann 
Gesendet: Mittwoch, 13. Januar 2021 09:22
An: Development list for mkgmap
Betreff: Re: [mkgmap-dev] improved diagnostics patch v2

Hi Mike,

thanks, I'll have a closer look today.

Gerd


Von: mkgmap-dev  im Auftrag von Mike
Baggaley 
Gesendet: Montag, 11. Januar 2021 10:20
An: 'Development list for mkgmap'
Betreff: Re: [mkgmap-dev] improved diagnostics patch v2

HI Gerd,

Thanks for the updated patch. I have got rid of the repeated definitions of
"generated from" by using getBasicLogInformation as the basis of toString.
This makes them all consistent (although it is not capitalised or have a
colon). It would be more logical for the toString function to contain just
the basic information, the information currently in toString to be in a new
getExtendedLogInformation function and getBasicLoginInformation deleted.
However, this would need a lot of changes elsewhere.

Does RoadDef.toString really need to output a URL? It would improve the
reading of my log files if it was just "(way" + id + ")". For consistency
with above, this should really be "RoadDef + id" / "RoadDef generated",
which would suit me fine. What do you think?

Please find attached an updated version.

Cheers,
Mike

-Original Message-
From: Gerd Petermann [mailto:gpetermann_muenc...@hotmail.com]
Sent: 10 January 2021 08:04
To: Development list for mkgmap 
Subject: Re: [mkgmap-dev] improved diagnostics patch v2

Hi Mike,

sorry, I looked at your first patch but forgot to answer. I always hesitate
to change those debug messages because some users parse them with scripts.
I think Way.toString() should work similar to Node.toString and
Relation.toString and thus return a string starting with "WAY:". See my
modified version.

I don't like the repeated code producing the "generated from" messages.
Isn't it possible to implement that once in classElement?

Gerd



____
Von: mkgmap-dev  im Auftrag von Mike
Baggaley 
Gesendet: Samstag, 9. Januar 2021 17:18
An: 'Development list for mkgmap'
Betreff: [mkgmap-dev] improved diagnostics patch v2

Hi Gerd,

My previous diagnostic improvements patch seems to have got lost, but since
then I have noticed another couple of items to include, so attached is an
updated version.

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



diagnostics6.patch
Description: Binary data
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev