Re: [mkgmap-dev] Problems with sea in overview map

[Gerd Petermann]

Hi Ticker,

that's an interesting idea. Did you try that? My results are even worse, but 
maybe I changed the wrong places.
For sure the ovm* files are much larger. I guess there will also be problems 
with memory when you try to combine many tiles.

Gerd


Von: mkgmap-dev  im Auftrag von Ticker 
Berkin 
Gesendet: Montag, 24. Mai 2021 18:00
An: Development list for mkgmap
Betreff: Re: [mkgmap-dev] Problems with sea in overview map

Hi Gerd

This seems to be false when combining the ovm_, rather than when
generating them!

It suppresses RoundCoords but maybe shouldn't. Not sure why RoundCoords
should ever be suppressed when res < 24?

It doesn't suppress removeObsolete, which removes points in any
straight line.

I suppose the simpler way to view this is that unique points per
element on the tile boundary should be kept; making the job of the
overview combiner mergeShape possible.

Ticker

On Mon, 2021-05-24 at 15:35 +, Gerd Petermann wrote:
> Hi Ticker,
>
> yes, it is. See usage of enableLineCleanFilters
>
> Gerd
>
> 
> Von: mkgmap-dev  im Auftrag
> von Ticker Berkin 
> Gesendet: Montag, 24. Mai 2021 17:33
> An: Development list for mkgmap
> Betreff: Re: [mkgmap-dev] Problems with sea in overview map
>
> Hi Gerd
>
> Not quite related, but if merging the shapes from all ovm_ imgs, then
> maybe some types of filtering should be turned off when the contents
> for these is being generated; esp DP, and probably straigh-line
> removal
> in removeObsolete
>
> Ticker
>
> On Mon, 2021-05-24 at 15:21 +, Gerd Petermann wrote:
> > Hi Ticker,
> >
> > sorry, I can't follow. The old code only preserved points on the
> > boundary of the merged shape, but the outer ring can be far from
> > rectangular.
> > This way some important points on outer ring were not preserved.
> >
> > There's still a possible problem with large white area in sea which
> > seems to depend on the order in which shapes are merged. Sill
> > trying
> > to understand what goes, but at least I can reproduce it...
> >
> > Gerd
> >
> >
> > 
> > Von: mkgmap-dev  im Auftrag
> > von Ticker Berkin 
> > Gesendet: Montag, 24. Mai 2021 17:11
> > An: Development list for mkgmap
> > Betreff: Re: [mkgmap-dev] Problems with sea in overview map
> >
> > Hi Gerd
> >
> > Re. last commit: preserve all horizontal and vertical lines in
> > shapes.
> >
> > Do the cut lines go right across the outer polygon or just in from
> > one
> > side to the hole? If all the way across, might this change inhibit
> > the
> > merging to one side of the hole, or, if divided for some other
> > reason
> > in the other direction, merging across the now unneeded cut line.
> >
> > Ticker
> >
> > ___
> > 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
> ___
> 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] Problems with sea in overview map

[Ticker Berkin]

Hi Gerd

This seems to be false when combining the ovm_, rather than when
generating them!

It suppresses RoundCoords but maybe shouldn't. Not sure why RoundCoords
should ever be suppressed when res < 24?

It doesn't suppress removeObsolete, which removes points in any
straight line. 

I suppose the simpler way to view this is that unique points per
element on the tile boundary should be kept; making the job of the
overview combiner mergeShape possible.

Ticker

On Mon, 2021-05-24 at 15:35 +, Gerd Petermann wrote:
> Hi Ticker,
> 
> yes, it is. See usage of enableLineCleanFilters
> 
> Gerd
> 
> 
> Von: mkgmap-dev  im Auftrag
> von Ticker Berkin 
> Gesendet: Montag, 24. Mai 2021 17:33
> An: Development list for mkgmap
> Betreff: Re: [mkgmap-dev] Problems with sea in overview map
> 
> Hi Gerd
> 
> Not quite related, but if merging the shapes from all ovm_ imgs, then
> maybe some types of filtering should be turned off when the contents
> for these is being generated; esp DP, and probably straigh-line
> removal
> in removeObsolete
> 
> Ticker
> 
> On Mon, 2021-05-24 at 15:21 +, Gerd Petermann wrote:
> > Hi Ticker,
> > 
> > sorry, I can't follow. The old code only preserved points on the
> > boundary of the merged shape, but the outer ring can be far from
> > rectangular.
> > This way some important points on outer ring were not preserved.
> > 
> > There's still a possible problem with large white area in sea which
> > seems to depend on the order in which shapes are merged. Sill
> > trying
> > to understand what goes, but at least I can reproduce it...
> > 
> > Gerd
> > 
> > 
> > 
> > Von: mkgmap-dev  im Auftrag
> > von Ticker Berkin 
> > Gesendet: Montag, 24. Mai 2021 17:11
> > An: Development list for mkgmap
> > Betreff: Re: [mkgmap-dev] Problems with sea in overview map
> > 
> > Hi Gerd
> > 
> > Re. last commit: preserve all horizontal and vertical lines in
> > shapes.
> > 
> > Do the cut lines go right across the outer polygon or just in from
> > one
> > side to the hole? If all the way across, might this change inhibit
> > the
> > merging to one side of the hole, or, if divided for some other
> > reason
> > in the other direction, merging across the now unneeded cut line.
> > 
> > Ticker
> > 
> > ___
> > 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
> ___
> 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] logging improvement

[Gerd Petermann]

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-
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

Re: [mkgmap-dev] Problems with sea in overview map

[Gerd Petermann]

Hi Ticker,

yes, it is. See usage of enableLineCleanFilters

Gerd


Von: mkgmap-dev  im Auftrag von Ticker 
Berkin 
Gesendet: Montag, 24. Mai 2021 17:33
An: Development list for mkgmap
Betreff: Re: [mkgmap-dev] Problems with sea in overview map

Hi Gerd

Not quite related, but if merging the shapes from all ovm_ imgs, then
maybe some types of filtering should be turned off when the contents
for these is being generated; esp DP, and probably straigh-line removal
in removeObsolete

Ticker

On Mon, 2021-05-24 at 15:21 +, Gerd Petermann wrote:
> Hi Ticker,
>
> sorry, I can't follow. The old code only preserved points on the
> boundary of the merged shape, but the outer ring can be far from
> rectangular.
> This way some important points on outer ring were not preserved.
>
> There's still a possible problem with large white area in sea which
> seems to depend on the order in which shapes are merged. Sill trying
> to understand what goes, but at least I can reproduce it...
>
> Gerd
>
>
> 
> Von: mkgmap-dev  im Auftrag
> von Ticker Berkin 
> Gesendet: Montag, 24. Mai 2021 17:11
> An: Development list for mkgmap
> Betreff: Re: [mkgmap-dev] Problems with sea in overview map
>
> Hi Gerd
>
> Re. last commit: preserve all horizontal and vertical lines in
> shapes.
>
> Do the cut lines go right across the outer polygon or just in from
> one
> side to the hole? If all the way across, might this change inhibit
> the
> merging to one side of the hole, or, if divided for some other reason
> in the other direction, merging across the now unneeded cut line.
>
> Ticker
>
> ___
> 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
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

Re: [mkgmap-dev] Problems with sea in overview map

[Ticker Berkin]

Hi Gerd

Not quite related, but if merging the shapes from all ovm_ imgs, then
maybe some types of filtering should be turned off when the contents
for these is being generated; esp DP, and probably straigh-line removal
in removeObsolete

Ticker

On Mon, 2021-05-24 at 15:21 +, Gerd Petermann wrote:
> Hi Ticker,
> 
> sorry, I can't follow. The old code only preserved points on the
> boundary of the merged shape, but the outer ring can be far from
> rectangular.
> This way some important points on outer ring were not preserved.
> 
> There's still a possible problem with large white area in sea which
> seems to depend on the order in which shapes are merged. Sill trying
> to understand what goes, but at least I can reproduce it...
> 
> Gerd
> 
> 
> 
> Von: mkgmap-dev  im Auftrag
> von Ticker Berkin 
> Gesendet: Montag, 24. Mai 2021 17:11
> An: Development list for mkgmap
> Betreff: Re: [mkgmap-dev] Problems with sea in overview map
> 
> Hi Gerd
> 
> Re. last commit: preserve all horizontal and vertical lines in
> shapes.
> 
> Do the cut lines go right across the outer polygon or just in from
> one
> side to the hole? If all the way across, might this change inhibit
> the
> merging to one side of the hole, or, if divided for some other reason
> in the other direction, merging across the now unneeded cut line.
> 
> Ticker
> 
> ___
> 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] Problems with sea in overview map

[Gerd Petermann]

Hi Ticker,

sorry, I can't follow. The old code only preserved points on the boundary of 
the merged shape, but the outer ring can be far from rectangular.
This way some important points on outer ring were not preserved.

There's still a possible problem with large white area in sea which seems to 
depend on the order in which shapes are merged. Sill trying to understand what 
goes, but at least I can reproduce it...

Gerd



Von: mkgmap-dev  im Auftrag von Ticker 
Berkin 
Gesendet: Montag, 24. Mai 2021 17:11
An: Development list for mkgmap
Betreff: Re: [mkgmap-dev] Problems with sea in overview map

Hi Gerd

Re. last commit: preserve all horizontal and vertical lines in shapes.

Do the cut lines go right across the outer polygon or just in from one
side to the hole? If all the way across, might this change inhibit the
merging to one side of the hole, or, if divided for some other reason
in the other direction, merging across the now unneeded cut line.

Ticker

___
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] Problems with sea in overview map

[Ticker Berkin]

Hi Gerd

Re. last commit: preserve all horizontal and vertical lines in shapes.
 
Do the cut lines go right across the outer polygon or just in from one
side to the hole? If all the way across, might this change inhibit the
merging to one side of the hole, or, if divided for some other reason
in the other direction, merging across the now unneeded cut line.

Ticker

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

Re: [mkgmap-dev] Problems with sea in overview map

[Ticker Berkin]

Ah

When I scanned this area a while ago I guessed, without looking
carefully or thinking, that mergeShapesFirst took all the shapes from
all the ovm_ imgs and attempted to merge them. I see now that it
doesn't. I don't know what problem it can solve better than the
standard subdivision merge. It might have been there because, a long
time ago, outer zoom subdivs (esp. overview) were far too small when
there was anything (sea/coastline) because the content #points was
calculated at res24. 

So, yes, I'd try without.

Ticker

On Mon, 2021-05-24 at 14:19 +, Gerd Petermann wrote:
> Oops, I meant
>  should I remove mergeShapesFirst() completely?
> 
> Gerd
> 
> 
> Von: mkgmap-dev  im Auftrag
> von Gerd Petermann 
> Gesendet: Montag, 24. Mai 2021 16:07
> An: Development list for mkgmap
> Betreff: Re: [mkgmap-dev] Problems with sea in overview map
> 
> Hi Ticker,
> 
> you mean I should mergeShapesFirst() completely?
> 
> Gerd
> 
> 
> Von: mkgmap-dev  im Auftrag
> von Ticker Berkin 
> Gesendet: Montag, 24. Mai 2021 15:57
> An: Development list for mkgmap
> Betreff: Re: [mkgmap-dev] Problems with sea in overview map
> 
> Hi Gerd
> 
> Not sure about this. It is a very drastic change and might break a
> lot
> of the element>subdiv code (esp --order-by). Many element well be too
> big and have to be split again.
> 
> It ends up as a merge attempt at all lines/shapes in the tile, so it
> might as well be resolution independent!
> 
> Ticker
> On Mon, 2021-05-24 at 13:33 +, Gerd Petermann wrote:
> > Hi Ticker,
> > 
> > I think I found my mistake. The code to re-calc the preserved
> > points
> > was executed for each sub division instead of once per level.
> > 
> > The attached patch might already solve this.
> > 
> > Gerd
> 
> ___
> 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
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

Re: [mkgmap-dev] Problems with sea in overview map

[Ticker Berkin]

Hi Gerd

That would be the conclusion - but I don't think you should do it.

I don't see that making the problem bigger will help!

Ticker

On Mon, 2021-05-24 at 14:07 +, Gerd Petermann wrote:
> Hi Ticker,
> 
> you mean I should mergeShapesFirst() completely?
> 
> Gerd
> 
> 
> Von: mkgmap-dev  im Auftrag
> von Ticker Berkin 
> Gesendet: Montag, 24. Mai 2021 15:57
> An: Development list for mkgmap
> Betreff: Re: [mkgmap-dev] Problems with sea in overview map
> 
> Hi Gerd
> 
> Not sure about this. It is a very drastic change and might break a
> lot
> of the element>subdiv code (esp --order-by). Many element well be too
> big and have to be split again.
> 
> It ends up as a merge attempt at all lines/shapes in the tile, so it
> might as well be resolution independent!
> 
> Ticker
> On Mon, 2021-05-24 at 13:33 +, Gerd Petermann wrote:
> > Hi Ticker,
> > 
> > I think I found my mistake. The code to re-calc the preserved
> > points
> > was executed for each sub division instead of once per level.
> > 
> > The attached patch might already solve this.
> > 
> > Gerd
> 
> ___
> 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] Problems with sea in overview map

[Gerd Petermann]

Oops, I meant
 should I remove mergeShapesFirst() completely?

Gerd


Von: mkgmap-dev  im Auftrag von Gerd 
Petermann 
Gesendet: Montag, 24. Mai 2021 16:07
An: Development list for mkgmap
Betreff: Re: [mkgmap-dev] Problems with sea in overview map

Hi Ticker,

you mean I should mergeShapesFirst() completely?

Gerd


Von: mkgmap-dev  im Auftrag von Ticker 
Berkin 
Gesendet: Montag, 24. Mai 2021 15:57
An: Development list for mkgmap
Betreff: Re: [mkgmap-dev] Problems with sea in overview map

Hi Gerd

Not sure about this. It is a very drastic change and might break a lot
of the element>subdiv code (esp --order-by). Many element well be too
big and have to be split again.

It ends up as a merge attempt at all lines/shapes in the tile, so it
might as well be resolution independent!

Ticker
On Mon, 2021-05-24 at 13:33 +, Gerd Petermann wrote:
> Hi Ticker,
>
> I think I found my mistake. The code to re-calc the preserved points
> was executed for each sub division instead of once per level.
>
> The attached patch might already solve this.
>
> Gerd

___
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] Problems with sea in overview map

[Gerd Petermann]

Hi Ticker,

you mean I should mergeShapesFirst() completely?

Gerd


Von: mkgmap-dev  im Auftrag von Ticker 
Berkin 
Gesendet: Montag, 24. Mai 2021 15:57
An: Development list for mkgmap
Betreff: Re: [mkgmap-dev] Problems with sea in overview map

Hi Gerd

Not sure about this. It is a very drastic change and might break a lot
of the element>subdiv code (esp --order-by). Many element well be too
big and have to be split again.

It ends up as a merge attempt at all lines/shapes in the tile, so it
might as well be resolution independent!

Ticker
On Mon, 2021-05-24 at 13:33 +, Gerd Petermann wrote:
> Hi Ticker,
>
> I think I found my mistake. The code to re-calc the preserved points
> was executed for each sub division instead of once per level.
>
> The attached patch might already solve this.
>
> Gerd

___
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] Problems with sea in overview map

[Ticker Berkin]

Hi Gerd

Not sure about this. It is a very drastic change and might break a lot
of the element>subdiv code (esp --order-by). Many element well be too
big and have to be split again.

It ends up as a merge attempt at all lines/shapes in the tile, so it
might as well be resolution independent!

Ticker
On Mon, 2021-05-24 at 13:33 +, Gerd Petermann wrote:
> Hi Ticker,
> 
> I think I found my mistake. The code to re-calc the preserved points
> was executed for each sub division instead of once per level.
> 
> The attached patch might already solve this.
> 
> Gerd

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

Re: [mkgmap-dev] Problems with sea in overview map

[Gerd Petermann]

Hi Ticker,

I think I found my mistake. The code to re-calc the preserved points was 
executed for each sub division instead of once per level.

The attached patch might already solve this.

Gerd


Von: mkgmap-dev  im Auftrag von Ticker 
Berkin 
Gesendet: Montag, 24. Mai 2021 15:03
An: Development list for mkgmap
Betreff: Re: [mkgmap-dev] Problems with sea in overview map

Hi Gerd

See other thread about DP / removeObsolete ordering. RemoveObsolete
tidies up the remains after DP has done things it shouldn't

For non-road lines re. first and last - I don't think any filters will
cause there not to be a point at the res-coord of the start or end, so
I don't see that there would be a gap for different types.

ShapeSplitter will notice if the dividing line has inconsistent (non
-alternating) direction crossings (probably caused by self
-intersection). It can't deal with this, just issues a warning. It
won't notice self-intersection elsewhere and allocates "outside" before
the first line crossing, "inside" next and alternates. I think it is
possible to come up with shapes where this is the opposite what you'd
expect.

Maybe we need a proper intersecting segments checker. I've investigated
some algos. Not sure what to do with self-intersection when we find it.
Lots are simply output in RGN and devices might have some defined way
of rendering. It's only the cutting and the overview merging that don't
really have a solution.

Ticker

On Mon, 2021-05-24 at 12:20 +, Gerd Petermann wrote:
> Hi Ticker,
>
> the removeObsolete filter sometimes ignores the preserved status, and
> probably it doesn't make sure to keep or copy that status. Maybe that
> explains why a following DP gives other results? I think in the
> current order there is no problem with this but I'll double check
> because I think somewhere mkgmap removes points which should be
> preserved.
>
> The first/last point of lines is preserved to avoid gaps between
> connected lines of different types, e.g. when a stream gets a river.
>
> The shape merger produces self intersecting shapes. I think this is
> not a problem as long as ShapeSplitter can handle this. Can it?
>
> Gerd
>
> 
> Von: mkgmap-dev  im Auftrag
> von Ticker Berkin 
> Gesendet: Montag, 24. Mai 2021 12:54
> An: Development list for mkgmap
> Betreff: Re: [mkgmap-dev] Problems with sea in overview map
>
> Hi Gerd
>
> The meaning of the preserved flag + handling of road/line/polygon etc
> to different filters seem to be getting a bit mixed up.
>
> I'm currently seeing some problems because of first/last points in
> line
> being preserved (which some filters respect and others don't). I can
> understand this for Roads, but not other lines. Is there a reason for
> this.
>
> preserveHorizonalAndVertical preserving multiple use points might be
> good initially but could hinder removeObsolete spike removal from
> removing the cuts to a collapsed hole.
>
> Still haven't got to grips with shapeMergeFilter, but the main tile /
> ovm_ generation is producing self-intersecting polygons.
>
> Ticker
>
> On Mon, 2021-05-24 at 06:52 +, Gerd Petermann wrote:
> > Hi Ticker / all,
> >
> > it seems I've looked at the wrong test files. I've tested with a
> > few
> > more input files and now I see large white triangles with the
> > branch
> > version 4736 while trunk 4735 doesn't show them.
> > Looks like a problem with preserving points or maybe special cases
> > with ShapeSplitter...
> >
> > Gerd
> >
> >
> >
> > 
> > Von: mkgmap-dev  im Auftrag
> > von Ticker Berkin 
> > Gesendet: Samstag, 22. Mai 2021 13:30
> > An: Development list for mkgmap
> > Betreff: Re: [mkgmap-dev] Problems with sea in overview map
> >
> > Hi Gerd
> >
> > I've been doing experiments on tiles with much more sea and islands
> > (tests before only had a bit of sea and lots of city).
> >
> > With my re-ordering I get a very slightly smaller main tile (4096
> > bytes
> > in 5614K) and larger osmmap.img (34304 vs. 25088)
> >
> > In both cases I'm getting quite a few shapeSplitter messages where
> > it
> > finds inconsistencies in the line directions across the split-line;
> > normally due to self-intersection. These are happening in both the
> > main
> > tile generation and the overview combining.
> >
> > Once shapeSplitter has generated this type of warning it is
> > indeterminate which is shape and which is hole, so I'd expect gaps
> > in
> > the rendering.
> >
> > I think trunk had eradicated split/self-intersection problems in
> > the
> > tile processing, including the ovm_ file generation.
> >
> > I'm not sure about the overview combiner as, in my standard map
> > -build,
> > I don't merge shapes.
> >
> > Ticker
> >
> > On Fri, 2021-05-21 at 16:41 +, Gerd Petermann wrote:
> > > Hi Ticker,
> > >
> > > I tried this patch with r4734 and I see no improvements. Maps are
> > > larger, more white rectangles in sea.
> >

Re: [mkgmap-dev] Similar Arcs

[Felix Hartmann]

I thought that patch could be used to remove the dual highways at low
resolutions. Does not seem to work for that with a value of 4... So it is
only about routing, right? I will not work on lines but only roads?

On Sun, 23 May 2021 at 20:02, Gerd Petermann <
gpetermann_muenc...@hotmail.com> wrote:

> Hi Mike,
>
> the NodCheck (and NodDisplay is part of the display utility, see
> https://svn.mkgmap.org.uk/svn/display
> NodCheck reports lots of errors about angles and lengths of arcs which
> probably are not critical and mostly caused by rounding.
>
> There are some pdf docs about the IMG format and also the wiki
> https://wiki.openstreetmap.org/wiki/OSM_Map_On_Garmin/NOD_Subfile_Format
> Some details are probably not documented, esp. the last findings about
> encoding of bearings.
>
> I think it is possible to suppress some duplicate arcs, e.g. if two roads
> have the same first arc it should be possible to truncate one of the roads.
> It might be needed to remove all the data in RGN and NET as well, so that
> you simulate the removal of data in OSM. I don't see a need for this, the
> effect should be very small for styles which don't try to make objects like
> amenity=parking routable.
>
> Gerd
>
> 
> Von: mkgmap-dev  im Auftrag von
> Mike Baggaley 
> Gesendet: Sonntag, 23. Mai 2021 19:27
> An: 'Development list for mkgmap'
> Betreff: Re: [mkgmap-dev] Similar Arcs
>
> 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_se

Re: [mkgmap-dev] Problems with sea in overview map

[Ticker Berkin]

Hi Gerd

See other thread about DP / removeObsolete ordering. RemoveObsolete
tidies up the remains after DP has done things it shouldn't

For non-road lines re. first and last - I don't think any filters will
cause there not to be a point at the res-coord of the start or end, so
I don't see that there would be a gap for different types. 

ShapeSplitter will notice if the dividing line has inconsistent (non
-alternating) direction crossings (probably caused by self
-intersection). It can't deal with this, just issues a warning. It
won't notice self-intersection elsewhere and allocates "outside" before
the first line crossing, "inside" next and alternates. I think it is
possible to come up with shapes where this is the opposite what you'd
expect.

Maybe we need a proper intersecting segments checker. I've investigated
some algos. Not sure what to do with self-intersection when we find it.
Lots are simply output in RGN and devices might have some defined way
of rendering. It's only the cutting and the overview merging that don't
really have a solution.

Ticker

On Mon, 2021-05-24 at 12:20 +, Gerd Petermann wrote:
> Hi Ticker,
> 
> the removeObsolete filter sometimes ignores the preserved status, and
> probably it doesn't make sure to keep or copy that status. Maybe that
> explains why a following DP gives other results? I think in the
> current order there is no problem with this but I'll double check
> because I think somewhere mkgmap removes points which should be
> preserved.
> 
> The first/last point of lines is preserved to avoid gaps between
> connected lines of different types, e.g. when a stream gets a river.
> 
> The shape merger produces self intersecting shapes. I think this is
> not a problem as long as ShapeSplitter can handle this. Can it?
> 
> Gerd
> 
> 
> Von: mkgmap-dev  im Auftrag
> von Ticker Berkin 
> Gesendet: Montag, 24. Mai 2021 12:54
> An: Development list for mkgmap
> Betreff: Re: [mkgmap-dev] Problems with sea in overview map
> 
> Hi Gerd
> 
> The meaning of the preserved flag + handling of road/line/polygon etc
> to different filters seem to be getting a bit mixed up.
> 
> I'm currently seeing some problems because of first/last points in
> line
> being preserved (which some filters respect and others don't). I can
> understand this for Roads, but not other lines. Is there a reason for
> this.
> 
> preserveHorizonalAndVertical preserving multiple use points might be
> good initially but could hinder removeObsolete spike removal from
> removing the cuts to a collapsed hole.
> 
> Still haven't got to grips with shapeMergeFilter, but the main tile /
> ovm_ generation is producing self-intersecting polygons.
> 
> Ticker
> 
> On Mon, 2021-05-24 at 06:52 +, Gerd Petermann wrote:
> > Hi Ticker / all,
> > 
> > it seems I've looked at the wrong test files. I've tested with a
> > few
> > more input files and now I see large white triangles with the
> > branch
> > version 4736 while trunk 4735 doesn't show them.
> > Looks like a problem with preserving points or maybe special cases
> > with ShapeSplitter...
> > 
> > Gerd
> > 
> > 
> > 
> > 
> > Von: mkgmap-dev  im Auftrag
> > von Ticker Berkin 
> > Gesendet: Samstag, 22. Mai 2021 13:30
> > An: Development list for mkgmap
> > Betreff: Re: [mkgmap-dev] Problems with sea in overview map
> > 
> > Hi Gerd
> > 
> > I've been doing experiments on tiles with much more sea and islands
> > (tests before only had a bit of sea and lots of city).
> > 
> > With my re-ordering I get a very slightly smaller main tile (4096
> > bytes
> > in 5614K) and larger osmmap.img (34304 vs. 25088)
> > 
> > In both cases I'm getting quite a few shapeSplitter messages where
> > it
> > finds inconsistencies in the line directions across the split-line;
> > normally due to self-intersection. These are happening in both the
> > main
> > tile generation and the overview combining.
> > 
> > Once shapeSplitter has generated this type of warning it is
> > indeterminate which is shape and which is hole, so I'd expect gaps
> > in
> > the rendering.
> > 
> > I think trunk had eradicated split/self-intersection problems in
> > the
> > tile processing, including the ovm_ file generation.
> > 
> > I'm not sure about the overview combiner as, in my standard map
> > -build,
> > I don't merge shapes.
> > 
> > Ticker
> > 
> > On Fri, 2021-05-21 at 16:41 +, Gerd Petermann wrote:
> > > Hi Ticker,
> > > 
> > > I tried this patch with r4734 and I see no improvements. Maps are
> > > larger, more white rectangles in sea.
> > > 
> > > Maybe my recent changes don't work well with yours? Do you have
> > > an
> > > example where it improves something with r4734?
> > > 
> > > Gerd
> > > 
> > > 
> > > Von: mkgmap-dev  im
> > > Auftrag
> > > von Ticker Berkin 
> > > Gesendet: Freitag, 21. Mai 2021 18:10
> > > An: Development list for mkgmap
> > > Betreff: Re: [mkgmap-dev] 

Re: [mkgmap-dev] Problems with sea in overview map

[Gerd Petermann]

Hi Ticker,

the removeObsolete filter sometimes ignores the preserved status, and probably 
it doesn't make sure to keep or copy that status. Maybe that explains why a 
following DP gives other results? I think in the current order there is no 
problem with this but I'll double check because I think somewhere mkgmap 
removes points which should be preserved.

The first/last point of lines is preserved to avoid gaps between connected 
lines of different types, e.g. when a stream gets a river.

The shape merger produces self intersecting shapes. I think this is not a 
problem as long as ShapeSplitter can handle this. Can it?

Gerd


Von: mkgmap-dev  im Auftrag von Ticker 
Berkin 
Gesendet: Montag, 24. Mai 2021 12:54
An: Development list for mkgmap
Betreff: Re: [mkgmap-dev] Problems with sea in overview map

Hi Gerd

The meaning of the preserved flag + handling of road/line/polygon etc
to different filters seem to be getting a bit mixed up.

I'm currently seeing some problems because of first/last points in line
being preserved (which some filters respect and others don't). I can
understand this for Roads, but not other lines. Is there a reason for
this.

preserveHorizonalAndVertical preserving multiple use points might be
good initially but could hinder removeObsolete spike removal from
removing the cuts to a collapsed hole.

Still haven't got to grips with shapeMergeFilter, but the main tile /
ovm_ generation is producing self-intersecting polygons.

Ticker

On Mon, 2021-05-24 at 06:52 +, Gerd Petermann wrote:
> Hi Ticker / all,
>
> it seems I've looked at the wrong test files. I've tested with a few
> more input files and now I see large white triangles with the branch
> version 4736 while trunk 4735 doesn't show them.
> Looks like a problem with preserving points or maybe special cases
> with ShapeSplitter...
>
> Gerd
>
>
>
> 
> Von: mkgmap-dev  im Auftrag
> von Ticker Berkin 
> Gesendet: Samstag, 22. Mai 2021 13:30
> An: Development list for mkgmap
> Betreff: Re: [mkgmap-dev] Problems with sea in overview map
>
> Hi Gerd
>
> I've been doing experiments on tiles with much more sea and islands
> (tests before only had a bit of sea and lots of city).
>
> With my re-ordering I get a very slightly smaller main tile (4096
> bytes
> in 5614K) and larger osmmap.img (34304 vs. 25088)
>
> In both cases I'm getting quite a few shapeSplitter messages where it
> finds inconsistencies in the line directions across the split-line;
> normally due to self-intersection. These are happening in both the
> main
> tile generation and the overview combining.
>
> Once shapeSplitter has generated this type of warning it is
> indeterminate which is shape and which is hole, so I'd expect gaps in
> the rendering.
>
> I think trunk had eradicated split/self-intersection problems in the
> tile processing, including the ovm_ file generation.
>
> I'm not sure about the overview combiner as, in my standard map
> -build,
> I don't merge shapes.
>
> Ticker
>
> On Fri, 2021-05-21 at 16:41 +, Gerd Petermann wrote:
> > Hi Ticker,
> >
> > I tried this patch with r4734 and I see no improvements. Maps are
> > larger, more white rectangles in sea.
> >
> > Maybe my recent changes don't work well with yours? Do you have an
> > example where it improves something with r4734?
> >
> > Gerd
> >
> > 
> > Von: mkgmap-dev  im Auftrag
> > von Ticker Berkin 
> > Gesendet: Freitag, 21. Mai 2021 18:10
> > An: Development list for mkgmap
> > Betreff: Re: [mkgmap-dev] Problems with sea in overview map
> >
> > Hi Gerd
> >
> > I'd been doing some investigation of filters ordering (based on
> > trunk).
> > I'd also done the pre-filtering of lines & shapes by minRes.
> >
> > My conclusions are:
> >
> > Shapes:
> > It is better to run SizeFilter after RemoveObsoleteFilter.
> > It is more efficient to run DP filter after both of these.
> >
> > Lines:
> > LineSplitterFilter should be run after everything that can remove
> > points.
> > It is more efficient to run DP after RemoveObsoleteFilter.
> >
> > I've adapted my changes into a patch for the low-res-opt branch,
> > along
> > with removal of some resolution tests that are now redundant.
> >
> > For the contourFilters, I've left DP as the first filter but moved
> > LineSplitter as for the normalFilters
> >
> > Ticker
> >
> >
> > ___
> > 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
___
mkgmap-dev mailing list

Re: [mkgmap-dev] Problems with sea in overview map

[Ticker Berkin]

Hi Gerd

The meaning of the preserved flag + handling of road/line/polygon etc
to different filters seem to be getting a bit mixed up.

I'm currently seeing some problems because of first/last points in line
being preserved (which some filters respect and others don't). I can
understand this for Roads, but not other lines. Is there a reason for
this.

preserveHorizonalAndVertical preserving multiple use points might be
good initially but could hinder removeObsolete spike removal from
removing the cuts to a collapsed hole.

Still haven't got to grips with shapeMergeFilter, but the main tile /
ovm_ generation is producing self-intersecting polygons.

Ticker

On Mon, 2021-05-24 at 06:52 +, Gerd Petermann wrote:
> Hi Ticker / all,
> 
> it seems I've looked at the wrong test files. I've tested with a few
> more input files and now I see large white triangles with the branch
> version 4736 while trunk 4735 doesn't show them.
> Looks like a problem with preserving points or maybe special cases
> with ShapeSplitter...
> 
> Gerd
> 
> 
> 
> 
> Von: mkgmap-dev  im Auftrag
> von Ticker Berkin 
> Gesendet: Samstag, 22. Mai 2021 13:30
> An: Development list for mkgmap
> Betreff: Re: [mkgmap-dev] Problems with sea in overview map
> 
> Hi Gerd
> 
> I've been doing experiments on tiles with much more sea and islands
> (tests before only had a bit of sea and lots of city).
> 
> With my re-ordering I get a very slightly smaller main tile (4096
> bytes
> in 5614K) and larger osmmap.img (34304 vs. 25088)
> 
> In both cases I'm getting quite a few shapeSplitter messages where it
> finds inconsistencies in the line directions across the split-line;
> normally due to self-intersection. These are happening in both the
> main
> tile generation and the overview combining.
> 
> Once shapeSplitter has generated this type of warning it is
> indeterminate which is shape and which is hole, so I'd expect gaps in
> the rendering.
> 
> I think trunk had eradicated split/self-intersection problems in the
> tile processing, including the ovm_ file generation.
> 
> I'm not sure about the overview combiner as, in my standard map
> -build,
> I don't merge shapes.
> 
> Ticker
> 
> On Fri, 2021-05-21 at 16:41 +, Gerd Petermann wrote:
> > Hi Ticker,
> > 
> > I tried this patch with r4734 and I see no improvements. Maps are
> > larger, more white rectangles in sea.
> > 
> > Maybe my recent changes don't work well with yours? Do you have an
> > example where it improves something with r4734?
> > 
> > Gerd
> > 
> > 
> > Von: mkgmap-dev  im Auftrag
> > von Ticker Berkin 
> > Gesendet: Freitag, 21. Mai 2021 18:10
> > An: Development list for mkgmap
> > Betreff: Re: [mkgmap-dev] Problems with sea in overview map
> > 
> > Hi Gerd
> > 
> > I'd been doing some investigation of filters ordering (based on
> > trunk).
> > I'd also done the pre-filtering of lines & shapes by minRes.
> > 
> > My conclusions are:
> > 
> > Shapes:
> > It is better to run SizeFilter after RemoveObsoleteFilter.
> > It is more efficient to run DP filter after both of these.
> > 
> > Lines:
> > LineSplitterFilter should be run after everything that can remove
> > points.
> > It is more efficient to run DP after RemoveObsoleteFilter.
> > 
> > I've adapted my changes into a patch for the low-res-opt branch,
> > along
> > with removal of some resolution tests that are now redundant.
> > 
> > For the contourFilters, I've left DP as the first filter but moved
> > LineSplitter as for the normalFilters
> > 
> > Ticker
> > 
> > 
> > ___
> > 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
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

[mkgmap-dev] Douglas Peucker Filter and short lines

[Ticker Berkin]

Hi Gerd / anyone else

Attempting to improve filtering by considering their optimal order, I
got much worse results at very low resolutions. The excess was lots of
1-res-unit lines (these came from the coastlines of lots of small
islands)

These lines start off sufficiently large to make it through the
sizeFilter.

Running the DP filter next, if intermediate points are less than -
-reduce-point-density (default 2.6) res-units from the line between
first and last point, they are dropped. This can result in a single
point if the first and last points are equal, or a line shorter than at
least 2 of the sub-lines that no longer exist.

I'm not sure of the best approach to deal with this. I considered
inhibiting DP if the distance between start&end (either overall or for
the internal sub-processing) is less than the error distance, but this
is wrong for polygons or lines that loop back towards their starting
point. Maybe the DP error size must be less than sizeFilter size; For
lines this is MIN_LINE_SIZE = 1 and not configurable, For polygons it
is --min-size-polygon (default 8) or --polygon-size-limits.

Running RemoveObsoleteFilter before or after DP effects the final
result. Considering the functions of the filters, I think
RemoveObsolete should be before DP; DP shouldn't produce obsolete
points and there is no point in DP considering obsolete points.

Ticker

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

Re: [mkgmap-dev] Problems with sea in overview map

[Felix Hartmann]

yes I know - some version last week or so was horrible in this regard. I
thought this happened because of trying to make the overview map smaller -
so I just wanted to note that the size here is less important.

On Mon, 24 May 2021 at 11:29, Gerd Petermann <
gpetermann_muenc...@hotmail.com> wrote:

> Hi Felix,
>
> white triangles in the sea are obvious errors and therefore I want to fix
> this. The number of points is not the interesting point, it is about
> keeping the important points and removing unnecessary ones. This doesn't
> work well. The same problem occurs with other complex multipolygons that
> have many inners, but you don't see them often in the alps ;)
>
> Gerd
>
> 
> Von: mkgmap-dev  im Auftrag von
> Felix Hartmann 
> Gesendet: Montag, 24. Mai 2021 11:07
> An: Development list for mkgmap
> Betreff: Re: [mkgmap-dev] Problems with sea in overview map
>
> I feel that there is not too much need to get the size of the overview map
> down. Even for Asia continent map there is enough room. So it is better to
> make sure it looks nice - than smallest size.
> Also for resolution higher than overview map - it is usually not too
> important. Most people are navigating on land - so sea does not have to be
> rendered as often on your GPS device compared to land and roads. Meaning
> for >90% of Garmin mkgmap created map users it is not too often that you
> have a complex sea in your map. Even if you live on a mid sized island -
> say Cyprus or so - most of the time you do not have much sea on your GPS
> device.
> The recent work on reducing road complexity was much more important in
> real world use than what can be achieved by reducing sea complexity. Just
> my opinion. Of course nice if there is an improvement - but compared to
> land features for most users for sea it is not too important to reduce the
> points. The changes recently made did make quite a big difference in speed
> when zooming out / panning the map on my Oregon or etrex devices. For sea
> there is much less to be gained. Of course it is never bad to see some
> improvements - but it is less important. On PC / notebook - usually the
> processor should be plenty fast for drawing the map (plus the cache of
> Basecamp)..
>
> On Mon, 24 May 2021 at 08:52, Gerd Petermann <
> gpetermann_muenc...@hotmail.com>
> wrote:
> Hi Ticker / all,
>
> it seems I've looked at the wrong test files. I've tested with a few more
> input files and now I see large white triangles with the branch version
> 4736 while trunk 4735 doesn't show them.
> Looks like a problem with preserving points or maybe special cases with
> ShapeSplitter...
>
> Gerd
>
>
>
> 
> Von: mkgmap-dev  mkgmap-dev-boun...@lists.mkgmap.org.uk>> im Auftrag von Ticker Berkin <
> rwb-mkg...@jagit.co.uk>
> Gesendet: Samstag, 22. Mai 2021 13:30
> An: Development list for mkgmap
> Betreff: Re: [mkgmap-dev] Problems with sea in overview map
>
> Hi Gerd
>
> I've been doing experiments on tiles with much more sea and islands
> (tests before only had a bit of sea and lots of city).
>
> With my re-ordering I get a very slightly smaller main tile (4096 bytes
> in 5614K) and larger osmmap.img (34304 vs. 25088)
>
> In both cases I'm getting quite a few shapeSplitter messages where it
> finds inconsistencies in the line directions across the split-line;
> normally due to self-intersection. These are happening in both the main
> tile generation and the overview combining.
>
> Once shapeSplitter has generated this type of warning it is
> indeterminate which is shape and which is hole, so I'd expect gaps in
> the rendering.
>
> I think trunk had eradicated split/self-intersection problems in the
> tile processing, including the ovm_ file generation.
>
> I'm not sure about the overview combiner as, in my standard map-build,
> I don't merge shapes.
>
> Ticker
>
> On Fri, 2021-05-21 at 16:41 +, Gerd Petermann wrote:
> > Hi Ticker,
> >
> > I tried this patch with r4734 and I see no improvements. Maps are
> > larger, more white rectangles in sea.
> >
> > Maybe my recent changes don't work well with yours? Do you have an
> > example where it improves something with r4734?
> >
> > Gerd
> >
> > 
> > Von: mkgmap-dev  mkgmap-dev-boun...@lists.mkgmap.org.uk>> im Auftrag
> > von Ticker Berkin mailto:rwb-mkg...@jagit.co.uk
> >>
> > Gesendet: Freitag, 21. Mai 2021 18:10
> > An: Development list for mkgmap
> > Betreff: Re: [mkgmap-dev] Problems with sea in overview map
> >
> > Hi Gerd
> >
> > I'd been doing some investigation of filters ordering (based on
> > trunk).
> > I'd also done the pre-filtering of lines & shapes by minRes.
> >
> > My conclusions are:
> >
> > Shapes:
> > It is better to run SizeFilter after RemoveObsoleteFilter.
> > It is more efficient to run DP filter after both of these.
> >
> > Lines:
> > LineSplitterFilter 

Re: [mkgmap-dev] Problems with sea in overview map

[Gerd Petermann]

Hi Felix,

white triangles in the sea are obvious errors and therefore I want to fix this. 
The number of points is not the interesting point, it is about keeping the 
important points and removing unnecessary ones. This doesn't work well. The 
same problem occurs with other complex multipolygons that have many inners, but 
you don't see them often in the alps ;)

Gerd


Von: mkgmap-dev  im Auftrag von Felix 
Hartmann 
Gesendet: Montag, 24. Mai 2021 11:07
An: Development list for mkgmap
Betreff: Re: [mkgmap-dev] Problems with sea in overview map

I feel that there is not too much need to get the size of the overview map 
down. Even for Asia continent map there is enough room. So it is better to make 
sure it looks nice - than smallest size.
Also for resolution higher than overview map - it is usually not too important. 
Most people are navigating on land - so sea does not have to be rendered as 
often on your GPS device compared to land and roads. Meaning for >90% of Garmin 
mkgmap created map users it is not too often that you have a complex sea in 
your map. Even if you live on a mid sized island - say Cyprus or so - most of 
the time you do not have much sea on your GPS device.
The recent work on reducing road complexity was much more important in real 
world use than what can be achieved by reducing sea complexity. Just my 
opinion. Of course nice if there is an improvement - but compared to land 
features for most users for sea it is not too important to reduce the points. 
The changes recently made did make quite a big difference in speed when zooming 
out / panning the map on my Oregon or etrex devices. For sea there is much less 
to be gained. Of course it is never bad to see some improvements - but it is 
less important. On PC / notebook - usually the processor should be plenty fast 
for drawing the map (plus the cache of Basecamp)..

On Mon, 24 May 2021 at 08:52, Gerd Petermann 
mailto:gpetermann_muenc...@hotmail.com>> wrote:
Hi Ticker / all,

it seems I've looked at the wrong test files. I've tested with a few more input 
files and now I see large white triangles with the branch version 4736 while 
trunk 4735 doesn't show them.
Looks like a problem with preserving points or maybe special cases with 
ShapeSplitter...

Gerd




Von: mkgmap-dev 
mailto:mkgmap-dev-boun...@lists.mkgmap.org.uk>>
 im Auftrag von Ticker Berkin 
mailto:rwb-mkg...@jagit.co.uk>>
Gesendet: Samstag, 22. Mai 2021 13:30
An: Development list for mkgmap
Betreff: Re: [mkgmap-dev] Problems with sea in overview map

Hi Gerd

I've been doing experiments on tiles with much more sea and islands
(tests before only had a bit of sea and lots of city).

With my re-ordering I get a very slightly smaller main tile (4096 bytes
in 5614K) and larger osmmap.img (34304 vs. 25088)

In both cases I'm getting quite a few shapeSplitter messages where it
finds inconsistencies in the line directions across the split-line;
normally due to self-intersection. These are happening in both the main
tile generation and the overview combining.

Once shapeSplitter has generated this type of warning it is
indeterminate which is shape and which is hole, so I'd expect gaps in
the rendering.

I think trunk had eradicated split/self-intersection problems in the
tile processing, including the ovm_ file generation.

I'm not sure about the overview combiner as, in my standard map-build,
I don't merge shapes.

Ticker

On Fri, 2021-05-21 at 16:41 +, Gerd Petermann wrote:
> Hi Ticker,
>
> I tried this patch with r4734 and I see no improvements. Maps are
> larger, more white rectangles in sea.
>
> Maybe my recent changes don't work well with yours? Do you have an
> example where it improves something with r4734?
>
> Gerd
>
> 
> Von: mkgmap-dev 
> mailto:mkgmap-dev-boun...@lists.mkgmap.org.uk>>
>  im Auftrag
> von Ticker Berkin mailto:rwb-mkg...@jagit.co.uk>>
> Gesendet: Freitag, 21. Mai 2021 18:10
> An: Development list for mkgmap
> Betreff: Re: [mkgmap-dev] Problems with sea in overview map
>
> Hi Gerd
>
> I'd been doing some investigation of filters ordering (based on
> trunk).
> I'd also done the pre-filtering of lines & shapes by minRes.
>
> My conclusions are:
>
> Shapes:
> It is better to run SizeFilter after RemoveObsoleteFilter.
> It is more efficient to run DP filter after both of these.
>
> Lines:
> LineSplitterFilter should be run after everything that can remove
> points.
> It is more efficient to run DP after RemoveObsoleteFilter.
>
> I've adapted my changes into a patch for the low-res-opt branch,
> along
> with removal of some resolution tests that are now redundant.
>
> For the contourFilters, I've left DP as the first filter but moved
> LineSplitter as for the normalFilters
>
> Ticker
>
>
> ___
> mkgmap-dev mailing list
> mkgmap-dev@lists.mkgmap.org.uk

Re: [mkgmap-dev] Problems with sea in overview map

[Felix Hartmann]

I feel that there is not too much need to get the size of the overview map
down. Even for Asia continent map there is enough room. So it is better to
make sure it looks nice - than smallest size.
Also for resolution higher than overview map - it is usually not too
important. Most people are navigating on land - so sea does not have to be
rendered as often on your GPS device compared to land and roads. Meaning
for >90% of Garmin mkgmap created map users it is not too often that you
have a complex sea in your map. Even if you live on a mid sized island -
say Cyprus or so - most of the time you do not have much sea on your GPS
device.
The recent work on reducing road complexity was much more important in real
world use than what can be achieved by reducing sea complexity. Just my
opinion. Of course nice if there is an improvement - but compared to land
features for most users for sea it is not too important to reduce the
points. The changes recently made did make quite a big difference in speed
when zooming out / panning the map on my Oregon or etrex devices. For sea
there is much less to be gained. Of course it is never bad to see some
improvements - but it is less important. On PC / notebook - usually the
processor should be plenty fast for drawing the map (plus the cache of
Basecamp)..

On Mon, 24 May 2021 at 08:52, Gerd Petermann <
gpetermann_muenc...@hotmail.com> wrote:

> Hi Ticker / all,
>
> it seems I've looked at the wrong test files. I've tested with a few more
> input files and now I see large white triangles with the branch version
> 4736 while trunk 4735 doesn't show them.
> Looks like a problem with preserving points or maybe special cases with
> ShapeSplitter...
>
> Gerd
>
>
>
> 
> Von: mkgmap-dev  im Auftrag von
> Ticker Berkin 
> Gesendet: Samstag, 22. Mai 2021 13:30
> An: Development list for mkgmap
> Betreff: Re: [mkgmap-dev] Problems with sea in overview map
>
> Hi Gerd
>
> I've been doing experiments on tiles with much more sea and islands
> (tests before only had a bit of sea and lots of city).
>
> With my re-ordering I get a very slightly smaller main tile (4096 bytes
> in 5614K) and larger osmmap.img (34304 vs. 25088)
>
> In both cases I'm getting quite a few shapeSplitter messages where it
> finds inconsistencies in the line directions across the split-line;
> normally due to self-intersection. These are happening in both the main
> tile generation and the overview combining.
>
> Once shapeSplitter has generated this type of warning it is
> indeterminate which is shape and which is hole, so I'd expect gaps in
> the rendering.
>
> I think trunk had eradicated split/self-intersection problems in the
> tile processing, including the ovm_ file generation.
>
> I'm not sure about the overview combiner as, in my standard map-build,
> I don't merge shapes.
>
> Ticker
>
> On Fri, 2021-05-21 at 16:41 +, Gerd Petermann wrote:
> > Hi Ticker,
> >
> > I tried this patch with r4734 and I see no improvements. Maps are
> > larger, more white rectangles in sea.
> >
> > Maybe my recent changes don't work well with yours? Do you have an
> > example where it improves something with r4734?
> >
> > Gerd
> >
> > 
> > Von: mkgmap-dev  im Auftrag
> > von Ticker Berkin 
> > Gesendet: Freitag, 21. Mai 2021 18:10
> > An: Development list for mkgmap
> > Betreff: Re: [mkgmap-dev] Problems with sea in overview map
> >
> > Hi Gerd
> >
> > I'd been doing some investigation of filters ordering (based on
> > trunk).
> > I'd also done the pre-filtering of lines & shapes by minRes.
> >
> > My conclusions are:
> >
> > Shapes:
> > It is better to run SizeFilter after RemoveObsoleteFilter.
> > It is more efficient to run DP filter after both of these.
> >
> > Lines:
> > LineSplitterFilter should be run after everything that can remove
> > points.
> > It is more efficient to run DP after RemoveObsoleteFilter.
> >
> > I've adapted my changes into a patch for the low-res-opt branch,
> > along
> > with removal of some resolution tests that are now redundant.
> >
> > For the contourFilters, I've left DP as the first filter but moved
> > LineSplitter as for the normalFilters
> >
> > Ticker
> >
> >
> > ___
> > 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
>


-- 
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

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 
Gesendet: Donnerstag, 20.