[mkgmap-dev] line/polygon filters fix

Mon Mar 29 09:49:01 BST 2021

Ah, it may return STRAIGHT_SPIKE if all three points are equal. Have to test this again.

Gerd

________________________________________
Von: mkgmap-dev <mkgmap-dev-bounces at lists.mkgmap.org.uk> im Auftrag von Gerd Petermann <gpetermann_muenchen at hotmail.com>
Gesendet: Montag, 29. März 2021 10:45
An: Development list for mkgmap
Betreff: Re: [mkgmap-dev] line/polygon filters fix

Hi Ticker,

can you give me an example where the isStraight test doesn't return STRICTLY_STRAIGHT if c2 and c3 are equal?

Gerd

________________________________________
Von: mkgmap-dev <mkgmap-dev-bounces at lists.mkgmap.org.uk> im Auftrag von Ticker Berkin <rwb-mkgmap at jagit.co.uk>
Gesendet: Montag, 29. März 2021 10:38
An: Development list for mkgmap
Betreff: Re: [mkgmap-dev] line/polygon filters fix

Hi Gerd

On a road, if there is a normal Coord, immediately followed CoordNode
(junction) or HouseNumber node and they are in the same Garmin-square
for level0/maxRes then the CoordNode got duplicated. The isStraight
test won't remove it again because it might not be straight (depends on
another point) and, regardless, both points are 'preserved'.

I haven't followed the logic through the all app/net and app/trergn to
see what happens if road had duplicate CoordNodes or CoordNodes with
duplicate Ids.

Ticker

On Sun, 2021-03-28 at 09:12 +0000, Gerd Petermann wrote:
> Hi Ticker,
>
> I tried to find a case where the bug in RemoveObsoletePointsFilter
> would really add the same point twice but failed. I tried with --x-no
> -force-end-nodes-routing-nodes so that the 1st point is not a
> CoordNode but still the first (and last) point of a MapLine is always
> preserved.
> So, we always get into the Utils.isStraight() test which contains the
> needed continue.
> So, in the end the bug has no effect on output, it just produced
> useless Utils.isStraight calls and possibly debug messages ""found
> three consecutive points on strictly straight line""
>
> I commited only parts of your patch, I think the stuff regarding
> closed shapes is too confusing and the changed loop logic really
> doesn't improve robustness or readability.
> See r4619 and r4620.
>
> Gerd
>
> ________________________________________
> Von: mkgmap-dev <mkgmap-dev-bounces at lists.mkgmap.org.uk> im Auftrag
> von Ticker Berkin <rwb-mkgmap at jagit.co.uk>
> Gesendet: Donnerstag, 25. März 2021 11:14
> An: Development list for mkgmap
> Betreff: Re: [mkgmap-dev] line/polygon filters fix
>
> Hi Gerd
>
> I doubt if forced close is needed - a mix of identical and equal
> endPoint polygons has been fed through the filters and RGN polyline
> processing for a long time without *noticeable* problems.
>
> But I was trying to diagnose a problem that could have been caused by
> the point duplication or the not-properly-closed polygons and it
> seemed
> better to fix and make consistent on my way to finding where the
> problem lay.
>
> Ticker
>
> On Thu, 2021-03-25 at 09:59 +0000, Gerd Petermann wrote:
> > Hi Ticker,
> >
> > why do you think that this forced closing is needed? Do we have
> > code
> > that relies on this?
> >
> > Gerd
> >
> > ________________________________________
> > Von: mkgmap-dev <mkgmap-dev-bounces at lists.mkgmap.org.uk> im Auftrag
> > von Ticker Berkin <rwb-mkgmap at jagit.co.uk>
> > Gesendet: Donnerstag, 25. März 2021 10:47
> > An: Development list for mkgmap
> > Betreff: Re: [mkgmap-dev] line/polygon filters fix
> >
> > Hi Gerd
> >
> > Yes, you're right.
> >
> > I've changed it so it only keeps polygons correctly closed.
> >
> > Ticker
> >
> > On Wed, 2021-03-24 at 18:54 +0000, Gerd Petermann wrote:
> > > Hi Ticker,
> > >
> > > I don't understand the last changes in RoundCoordsFilter.java.
> > > What
> > > if the replaced 1st point is preserved?
> > >
> > > Gerd
> > >
> > > ________________________________________
> > > Von: mkgmap-dev <mkgmap-dev-bounces at lists.mkgmap.org.uk> im
> > > Auftrag
> > > von Ticker Berkin <rwb-mkgmap at jagit.co.uk>
> > > Gesendet: Dienstag, 23. März 2021 14:17
> > > An: Development list for mkgmap
> > > Betreff: Re: [mkgmap-dev] line/polygon filters fix
> > >
> > > Hi Gerd
> > >
> > > I don't get any detectable failures, but this might cause
> > > difficulties
> > > with adjacent junctions and/or housenumbers.
> > >
> > > If there are two adjacent equal points, with the first not
> > > preserved
> > > and the second preserved, the existing RemoveObsoleteFilter will
> > > replace the first with the second and leave the second in as
> > > well.
> > > The
> > > code clearly intended not to duplicate the preserved point, and,
> > > if
> > > they were the other way around, doesn't.
> > >
> > > Ticker
> > >
> > > On Tue, 2021-03-23 at 12:38 +0000, Gerd Petermann wrote:
> > > > Hi Ticker,
> > > >
> > > > please add a unit test that shows where the old code fails.
> > > >
> > > > Gerd
> > > >
> > > > ________________________________________
> > > > Von: mkgmap-dev <mkgmap-dev-bounces at lists.mkgmap.org.uk> im
> > > > Auftrag
> > > > von Ticker Berkin <rwb-mkgmap at jagit.co.uk>
> > > > Gesendet: Dienstag, 23. März 2021 13:10
> > > > An: mkgmap development
> > > > Betreff: [mkgmap-dev] line/polygon filters fix
> > > >
> > > > Hi Gerd
> > > >
> > > > I was trying to diagnose a problem with a repeating points in
> > > > polylines
> > > > as reported by GPSMapEdit and found a problem in
> > > > RemoveObsoletePointsFilter where it duplicates a point.
> > > >
> > > > Also in this and/or RoundCoordsFilter I've made some changes:
> > > > 1/ stop the chain when polygons get too small
> > > > 2/ keep polygons closed with the same first/last point
> > > > 3/ slight logic tidy-up
> > > > 4/ add a couple of debug lines to be consistent
> > > >
> > > > Patch attached.
> > > >
> > > > Actually these didn't make any difference to the repeating
> > > > points
> > > > problem. This happens when there are enough unused bits in the
> > > > last
> > > > byte of the polyline bitsteam to represent an extra point. I
> > > > can't
> > > > see
> > > > any good way of stopping this.
> > > >
> > > > Ticker
> > > > _______________________________________________
> > > > mkgmap-dev mailing list
> > > > mkgmap-dev at lists.mkgmap.org.uk
> > > > http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
> > > _______________________________________________
> > > mkgmap-dev mailing list
> > > mkgmap-dev at lists.mkgmap.org.uk
> > > http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
> > > _______________________________________________
> > > mkgmap-dev mailing list
> > > mkgmap-dev at lists.mkgmap.org.uk
> > > http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
> > _______________________________________________
> > mkgmap-dev mailing list
> > mkgmap-dev at lists.mkgmap.org.uk
> > http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
> _______________________________________________
> mkgmap-dev mailing list
> mkgmap-dev at lists.mkgmap.org.uk
> http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
> _______________________________________________
> mkgmap-dev mailing list
> mkgmap-dev at lists.mkgmap.org.uk
> http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
_______________________________________________
mkgmap-dev mailing list
mkgmap-dev at lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
_______________________________________________
mkgmap-dev mailing list
mkgmap-dev at lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev