[mkgmap-dev] Commit r4625: remove dependency on deprecated class javax.xml.bind.DatatypeConverter in unit test
Version mkgmap-r4625 was committed by gerd on Fri, 02 Apr 2021 remove dependency on deprecated class javax.xml.bind.DatatypeConverter in unit test http://www.mkgmap.org.uk/websvn/revision.php?repname=mkgmap&rev=4625 ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] [mkgmap-svn] Commit r4622: - use IsInUtil to do geometry calculations like insideness or outsideness: Allows to remove a lot of complex code but might be slower in some cases.
Hi Ticker, I use JOSM to display the relation and I can see the numbers when debugging in Eclipse. I'd prefer to have a stable and fast algo that works without looking at the roles, but we can always add rather simple code to handle a single outer ring without checking anything. Gerd Von: mkgmap-dev im Auftrag von Ticker Berkin Gesendet: Donnerstag, 1. April 2021 17:26 An: Development list for mkgmap Betreff: Re: [mkgmap-dev] [mkgmap-svn] Commit r4622: - use IsInUtil to do geometry calculations like insideness or outsideness: Allows to remove a lot of complex code but might be slower in some cases. Hi Gerd I can't get to see this relation - it times out. If element roles can be trusted (either OSM or Polish with some appropriate rule) and there is only 1 outer, then no need to test anything - all the inners can be assigned to this and proceed onto the cutting stage. If multiple outers then I agree, each inner needs to be tested against all the outers (but not against each other). isPointInShape will be a lot quicker than isLineInShape or the existing trunk logic. Ticker On Thu, 2021-04-01 at 14:49 +, Gerd Petermann wrote: > Hi Ticker, > > I still see no way how any of this will help reg. throughput. I think > we need something like the BoundaryUtil.rasterArea() method as a > Divide &Conquer approach, at least for monster relations like > r9488835. > The outer ring has +413.000 points and there are +15.000 rings. Even > a single "point in shape" test requires lots of time for such a > complex outer ring, and a single test will not find intersections. > > Have to think about the data structures but I am sure this will be > much faster for most of the really complex MP. > > Gerd > > > > > Von: mkgmap-dev im Auftrag > von Ticker Berkin > Gesendet: Donnerstag, 1. April 2021 14:14 > An: Development list for mkgmap > Betreff: Re: [mkgmap-dev] [mkgmap-svn] Commit r4622: - use IsInUtil > to do geometry calculations like insideness or outsideness: Allows to > remove a lot of complex code but might be slower in some cases. > > Hi Gerd > > 2 more thoughts: > > For elements from Polish input, set a distinct role. This can be > spotted early and either the order rule or direction rule can be > applied (they are closed, so the area/direction can be calculated > immediately). This then allowed OSM data with a blank role to be > handled as suggested earlier. > > The error reporting is not good - it can generate many lines in the > log. An idea would be to have: > Element lists for each way-like problem. > Counts or flags for other problems. > etc > and, for each problem detected, add all the ways in JoinedWays, > increase appropriate count, set the flag etc. At the end, if any of > these are populated, output the Relation and then, if full > diagnostics, > each populated problem type followed by lists of wayIds on same line > etc. > > 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 ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] [mkgmap-svn] Commit r4622: - use IsInUtil to do geometry calculations like insideness or outsideness: Allows to remove a lot of complex code but might be slower in some cases.
Hi Gerd I can't get to see this relation - it times out. If element roles can be trusted (either OSM or Polish with some appropriate rule) and there is only 1 outer, then no need to test anything - all the inners can be assigned to this and proceed onto the cutting stage. If multiple outers then I agree, each inner needs to be tested against all the outers (but not against each other). isPointInShape will be a lot quicker than isLineInShape or the existing trunk logic. Ticker On Thu, 2021-04-01 at 14:49 +, Gerd Petermann wrote: > Hi Ticker, > > I still see no way how any of this will help reg. throughput. I think > we need something like the BoundaryUtil.rasterArea() method as a > Divide &Conquer approach, at least for monster relations like > r9488835. > The outer ring has +413.000 points and there are +15.000 rings. Even > a single "point in shape" test requires lots of time for such a > complex outer ring, and a single test will not find intersections. > > Have to think about the data structures but I am sure this will be > much faster for most of the really complex MP. > > Gerd > > > > > Von: mkgmap-dev im Auftrag > von Ticker Berkin > Gesendet: Donnerstag, 1. April 2021 14:14 > An: Development list for mkgmap > Betreff: Re: [mkgmap-dev] [mkgmap-svn] Commit r4622: - use IsInUtil > to do geometry calculations like insideness or outsideness: Allows to > remove a lot of complex code but might be slower in some cases. > > Hi Gerd > > 2 more thoughts: > > For elements from Polish input, set a distinct role. This can be > spotted early and either the order rule or direction rule can be > applied (they are closed, so the area/direction can be calculated > immediately). This then allowed OSM data with a blank role to be > handled as suggested earlier. > > The error reporting is not good - it can generate many lines in the > log. An idea would be to have: > Element lists for each way-like problem. > Counts or flags for other problems. > etc > and, for each problem detected, add all the ways in JoinedWays, > increase appropriate count, set the flag etc. At the end, if any of > these are populated, output the Relation and then, if full > diagnostics, > each populated problem type followed by lists of wayIds on same line > etc. > > 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] [mkgmap-svn] Commit r4622: - use IsInUtil to do geometry calculations like insideness or outsideness: Allows to remove a lot of complex code but might be slower in some cases.
Hi Ticker, I still see no way how any of this will help reg. throughput. I think we need something like the BoundaryUtil.rasterArea() method as a Divide &Conquer approach, at least for monster relations like r9488835. The outer ring has +413.000 points and there are +15.000 rings. Even a single "point in shape" test requires lots of time for such a complex outer ring, and a single test will not find intersections. Have to think about the data structures but I am sure this will be much faster for most of the really complex MP. Gerd Von: mkgmap-dev im Auftrag von Ticker Berkin Gesendet: Donnerstag, 1. April 2021 14:14 An: Development list for mkgmap Betreff: Re: [mkgmap-dev] [mkgmap-svn] Commit r4622: - use IsInUtil to do geometry calculations like insideness or outsideness: Allows to remove a lot of complex code but might be slower in some cases. Hi Gerd 2 more thoughts: For elements from Polish input, set a distinct role. This can be spotted early and either the order rule or direction rule can be applied (they are closed, so the area/direction can be calculated immediately). This then allowed OSM data with a blank role to be handled as suggested earlier. The error reporting is not good - it can generate many lines in the log. An idea would be to have: Element lists for each way-like problem. Counts or flags for other problems. etc and, for each problem detected, add all the ways in JoinedWays, increase appropriate count, set the flag etc. At the end, if any of these are populated, output the Relation and then, if full diagnostics, each populated problem type followed by lists of wayIds on same line etc. 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] [mkgmap-svn] Commit r4622: - use IsInUtil to do geometry calculations like insideness or outsideness: Allows to remove a lot of complex code but might be slower in some cases.
Hi Gerd 2 more thoughts: For elements from Polish input, set a distinct role. This can be spotted early and either the order rule or direction rule can be applied (they are closed, so the area/direction can be calculated immediately). This then allowed OSM data with a blank role to be handled as suggested earlier. The error reporting is not good - it can generate many lines in the log. An idea would be to have: Element lists for each way-like problem. Counts or flags for other problems. etc and, for each problem detected, add all the ways in JoinedWays, increase appropriate count, set the flag etc. At the end, if any of these are populated, output the Relation and then, if full diagnostics, each populated problem type followed by lists of wayIds on same line etc. Ticker ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] [mkgmap-svn] Commit r4622: - use IsInUtil to do geometry calculations like insideness or outsideness: Allows to remove a lot of complex code but might be slower in some cases.
I meant intersecting polygons
Ticker
On Thu, 2021-04-01 at 12:08 +0100, Ticker Berkin wrote:
> Hi Gerd
>
> I agree that calcContains should be changed as you suggest.
>
> My view otherwise is that the code should be as simple as possible
> for
> "correct" cases and not go to any trouble to detect overlapping
> polygons in this phase, but just allocate them as [outer {inner}]+
> and,
> if the cutting logic has problems during its processing, then it can
> flag errors.
>
> Ticker
>
> On Thu, 2021-04-01 at 09:13 +, Gerd Petermann wrote:
> > Hi Ticker,
> >
> > I think the big question is what the code is expected to do with
> > overlapping polygons. The code in trunk may or may not cut out an
> > inner ring that overlaps the outer. If I got that right it was
> > intended to ignore all rings which are overlapping, but I showed
> > that
> > this doesn't always work.
> >
> > So, probably I should change the logic in the branch from
> > return (x & IsInUtil.IN) != 0;
> > to
> > return (x & IsInUtil.OUT) == 0;
> >
> > Means, calcContains() would return false if at least one point is
> > not
> > contained.
> >
> > Gerd
> >
> >
> > Von: mkgmap-dev im Auftrag
> > von Gerd Petermann
> > Gesendet: Donnerstag, 1. April 2021 10:16
> > An: Development list for mkgmap
> > Betreff: Re: [mkgmap-dev] [mkgmap-svn] Commit r4622: - use IsInUtil
> > to do geometry calculations like insideness or outsideness: Allows
> > to
> > remove a lot of complex code but might be slower in some cases.
> >
> > Hi Ticker,
> >
> > to be more prezise: Looking at the code in runIntersectionCheck()
> > it
> > may change the Bitset unfinishedPolys. Up to now I did not find a
> > case where this happens, so I am tempted to remove the code, but
> > I'd
> > feel better if I would understand why it was coded before removing
> > it.
> >
> > Gerd
> >
> >
> >
> > Von: mkgmap-dev im Auftrag
> > von Gerd Petermann
> > Gesendet: Donnerstag, 1. April 2021 09:29
> > An: Development list for mkgmap
> > Betreff: Re: [mkgmap-dev] [mkgmap-svn] Commit r4622: - use IsInUtil
> > to do geometry calculations like insideness or outsideness: Allows
> > to
> > remove a lot of complex code but might be slower in some cases.
> >
> > Hi Ticker,
> >
> > yes, that's what I plan to do. Right now I try to understand what
> > is
> > done with the data in collection intersectingPolygons.
> >
> > Gerd
> >
> >
> >
> > Von: mkgmap-dev im Auftrag
> > von Ticker Berkin
> > Gesendet: Donnerstag, 1. April 2021 09:25
> > An: mkgmap-dev@lists.mkgmap.org.uk; mkgmap-...@lists.mkgmap.org.uk
> > Betreff: Re: [mkgmap-dev] [mkgmap-svn] Commit r4622: - use IsInUtil
> > to do geometry calculations like insideness or outsideness: Allows
> > to
> > remove a lot of complex code but might be slower in some cases.
> >
> > Hi Gerd
> >
> > Wouldn't it be more efficient to choose a point within a each
> > polygon
> > and then use IsInUtils.isPointInShape and the relative areas to
> > test
> > if
> > this polygon is in others. The point could be the centre of the
> > polygon, after checking isPointInShape == IN on itself, and, if
> > not,
> > make do with the closing point, or some trial and error moving from
> > the
> > closing point.
> >
> > This also bypasses ambiguities cause by overlapping polygons in
> > this
> > phase of the logic.
> >
> > Ticker
> >
> > On Wed, 2021-03-31 at 15:56 +0100, svn commit wrote:
> > > Version mkgmap-r4622 was committed by gerd on Wed, 31 Mar 2021
> > > BRANCH: faster-mp
> > > - use IsInUtil to do geometry calculations like insideness or
> > > outsideness: Allows to remove a lot of complex code but might be
> > > slower in some cases.
> > > - document the poor completeness of collection
> > > intersectingPolygons.
> > > Probably will removed as well.
> > >
> > >
> > > http://www.mkgmap.org.uk/websvn/revision.php?repname=mkgmap&rev=4
> > > 62
> > > 2
> > > ___
> > > mkgmap-svn mailing list
> > > To unsubscribe send an mail to
> > > mkgmap-svn-le...@lists.mkgmap.org.uk
> > > http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-svn
> > ___
> > 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
> ___
> mkgmap-dev mailing li
Re: [mkgmap-dev] [mkgmap-svn] Commit r4622: - use IsInUtil to do geometry calculations like insideness or outsideness: Allows to remove a lot of complex code but might be slower in some cases.
Hi Gerd
I agree that calcContains should be changed as you suggest.
My view otherwise is that the code should be as simple as possible for
"correct" cases and not go to any trouble to detect overlapping
polygons in this phase, but just allocate them as [outer {inner}]+ and,
if the cutting logic has problems during its processing, then it can
flag errors.
Ticker
On Thu, 2021-04-01 at 09:13 +, Gerd Petermann wrote:
> Hi Ticker,
>
> I think the big question is what the code is expected to do with
> overlapping polygons. The code in trunk may or may not cut out an
> inner ring that overlaps the outer. If I got that right it was
> intended to ignore all rings which are overlapping, but I showed that
> this doesn't always work.
>
> So, probably I should change the logic in the branch from
> return (x & IsInUtil.IN) != 0;
> to
> return (x & IsInUtil.OUT) == 0;
>
> Means, calcContains() would return false if at least one point is not
> contained.
>
> Gerd
>
>
> Von: mkgmap-dev im Auftrag
> von Gerd Petermann
> Gesendet: Donnerstag, 1. April 2021 10:16
> An: Development list for mkgmap
> Betreff: Re: [mkgmap-dev] [mkgmap-svn] Commit r4622: - use IsInUtil
> to do geometry calculations like insideness or outsideness: Allows to
> remove a lot of complex code but might be slower in some cases.
>
> Hi Ticker,
>
> to be more prezise: Looking at the code in runIntersectionCheck() it
> may change the Bitset unfinishedPolys. Up to now I did not find a
> case where this happens, so I am tempted to remove the code, but I'd
> feel better if I would understand why it was coded before removing
> it.
>
> Gerd
>
>
>
> Von: mkgmap-dev im Auftrag
> von Gerd Petermann
> Gesendet: Donnerstag, 1. April 2021 09:29
> An: Development list for mkgmap
> Betreff: Re: [mkgmap-dev] [mkgmap-svn] Commit r4622: - use IsInUtil
> to do geometry calculations like insideness or outsideness: Allows to
> remove a lot of complex code but might be slower in some cases.
>
> Hi Ticker,
>
> yes, that's what I plan to do. Right now I try to understand what is
> done with the data in collection intersectingPolygons.
>
> Gerd
>
>
>
> Von: mkgmap-dev im Auftrag
> von Ticker Berkin
> Gesendet: Donnerstag, 1. April 2021 09:25
> An: mkgmap-dev@lists.mkgmap.org.uk; mkgmap-...@lists.mkgmap.org.uk
> Betreff: Re: [mkgmap-dev] [mkgmap-svn] Commit r4622: - use IsInUtil
> to do geometry calculations like insideness or outsideness: Allows to
> remove a lot of complex code but might be slower in some cases.
>
> Hi Gerd
>
> Wouldn't it be more efficient to choose a point within a each polygon
> and then use IsInUtils.isPointInShape and the relative areas to test
> if
> this polygon is in others. The point could be the centre of the
> polygon, after checking isPointInShape == IN on itself, and, if not,
> make do with the closing point, or some trial and error moving from
> the
> closing point.
>
> This also bypasses ambiguities cause by overlapping polygons in this
> phase of the logic.
>
> Ticker
>
> On Wed, 2021-03-31 at 15:56 +0100, svn commit wrote:
> > Version mkgmap-r4622 was committed by gerd on Wed, 31 Mar 2021
> > BRANCH: faster-mp
> > - use IsInUtil to do geometry calculations like insideness or
> > outsideness: Allows to remove a lot of complex code but might be
> > slower in some cases.
> > - document the poor completeness of collection
> > intersectingPolygons.
> > Probably will removed as well.
> >
> >
> > http://www.mkgmap.org.uk/websvn/revision.php?repname=mkgmap&rev=462
> > 2
> > ___
> > mkgmap-svn mailing list
> > To unsubscribe send an mail to mkgmap-svn-le...@lists.mkgmap.org.uk
> > http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-svn
> ___
> 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
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] [mkgmap-svn] Commit r4622: - use IsInUtil to do geometry calculations like insideness or outsideness: Allows to remove a lot of complex code but might be slower in some cases.
Hi Ticker, I think the big question is what the code is expected to do with overlapping polygons. The code in trunk may or may not cut out an inner ring that overlaps the outer. If I got that right it was intended to ignore all rings which are overlapping, but I showed that this doesn't always work. So, probably I should change the logic in the branch from return (x & IsInUtil.IN) != 0; to return (x & IsInUtil.OUT) == 0; Means, calcContains() would return false if at least one point is not contained. Gerd Von: mkgmap-dev im Auftrag von Gerd Petermann Gesendet: Donnerstag, 1. April 2021 10:16 An: Development list for mkgmap Betreff: Re: [mkgmap-dev] [mkgmap-svn] Commit r4622: - use IsInUtil to do geometry calculations like insideness or outsideness: Allows to remove a lot of complex code but might be slower in some cases. Hi Ticker, to be more prezise: Looking at the code in runIntersectionCheck() it may change the Bitset unfinishedPolys. Up to now I did not find a case where this happens, so I am tempted to remove the code, but I'd feel better if I would understand why it was coded before removing it. Gerd Von: mkgmap-dev im Auftrag von Gerd Petermann Gesendet: Donnerstag, 1. April 2021 09:29 An: Development list for mkgmap Betreff: Re: [mkgmap-dev] [mkgmap-svn] Commit r4622: - use IsInUtil to do geometry calculations like insideness or outsideness: Allows to remove a lot of complex code but might be slower in some cases. Hi Ticker, yes, that's what I plan to do. Right now I try to understand what is done with the data in collection intersectingPolygons. Gerd Von: mkgmap-dev im Auftrag von Ticker Berkin Gesendet: Donnerstag, 1. April 2021 09:25 An: mkgmap-dev@lists.mkgmap.org.uk; mkgmap-...@lists.mkgmap.org.uk Betreff: Re: [mkgmap-dev] [mkgmap-svn] Commit r4622: - use IsInUtil to do geometry calculations like insideness or outsideness: Allows to remove a lot of complex code but might be slower in some cases. Hi Gerd Wouldn't it be more efficient to choose a point within a each polygon and then use IsInUtils.isPointInShape and the relative areas to test if this polygon is in others. The point could be the centre of the polygon, after checking isPointInShape == IN on itself, and, if not, make do with the closing point, or some trial and error moving from the closing point. This also bypasses ambiguities cause by overlapping polygons in this phase of the logic. Ticker On Wed, 2021-03-31 at 15:56 +0100, svn commit wrote: > Version mkgmap-r4622 was committed by gerd on Wed, 31 Mar 2021 > BRANCH: faster-mp > - use IsInUtil to do geometry calculations like insideness or > outsideness: Allows to remove a lot of complex code but might be > slower in some cases. > - document the poor completeness of collection intersectingPolygons. > Probably will removed as well. > > > http://www.mkgmap.org.uk/websvn/revision.php?repname=mkgmap&rev=4622 > ___ > mkgmap-svn mailing list > To unsubscribe send an mail to mkgmap-svn-le...@lists.mkgmap.org.uk > http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-svn ___ 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] [mkgmap-svn] Commit r4622: - use IsInUtil to do geometry calculations like insideness or outsideness: Allows to remove a lot of complex code but might be slower in some cases.
Hi Ticker, to be more prezise: Looking at the code in runIntersectionCheck() it may change the Bitset unfinishedPolys. Up to now I did not find a case where this happens, so I am tempted to remove the code, but I'd feel better if I would understand why it was coded before removing it. Gerd Von: mkgmap-dev im Auftrag von Gerd Petermann Gesendet: Donnerstag, 1. April 2021 09:29 An: Development list for mkgmap Betreff: Re: [mkgmap-dev] [mkgmap-svn] Commit r4622: - use IsInUtil to do geometry calculations like insideness or outsideness: Allows to remove a lot of complex code but might be slower in some cases. Hi Ticker, yes, that's what I plan to do. Right now I try to understand what is done with the data in collection intersectingPolygons. Gerd Von: mkgmap-dev im Auftrag von Ticker Berkin Gesendet: Donnerstag, 1. April 2021 09:25 An: mkgmap-dev@lists.mkgmap.org.uk; mkgmap-...@lists.mkgmap.org.uk Betreff: Re: [mkgmap-dev] [mkgmap-svn] Commit r4622: - use IsInUtil to do geometry calculations like insideness or outsideness: Allows to remove a lot of complex code but might be slower in some cases. Hi Gerd Wouldn't it be more efficient to choose a point within a each polygon and then use IsInUtils.isPointInShape and the relative areas to test if this polygon is in others. The point could be the centre of the polygon, after checking isPointInShape == IN on itself, and, if not, make do with the closing point, or some trial and error moving from the closing point. This also bypasses ambiguities cause by overlapping polygons in this phase of the logic. Ticker On Wed, 2021-03-31 at 15:56 +0100, svn commit wrote: > Version mkgmap-r4622 was committed by gerd on Wed, 31 Mar 2021 > BRANCH: faster-mp > - use IsInUtil to do geometry calculations like insideness or > outsideness: Allows to remove a lot of complex code but might be > slower in some cases. > - document the poor completeness of collection intersectingPolygons. > Probably will removed as well. > > > http://www.mkgmap.org.uk/websvn/revision.php?repname=mkgmap&rev=4622 > ___ > mkgmap-svn mailing list > To unsubscribe send an mail to mkgmap-svn-le...@lists.mkgmap.org.uk > http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-svn ___ 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] [mkgmap-svn] Commit r4622: - use IsInUtil to do geometry calculations like insideness or outsideness: Allows to remove a lot of complex code but might be slower in some cases.
Hi Ticker, yes, that's what I plan to do. Right now I try to understand what is done with the data in collection intersectingPolygons. Gerd Von: mkgmap-dev im Auftrag von Ticker Berkin Gesendet: Donnerstag, 1. April 2021 09:25 An: mkgmap-dev@lists.mkgmap.org.uk; mkgmap-...@lists.mkgmap.org.uk Betreff: Re: [mkgmap-dev] [mkgmap-svn] Commit r4622: - use IsInUtil to do geometry calculations like insideness or outsideness: Allows to remove a lot of complex code but might be slower in some cases. Hi Gerd Wouldn't it be more efficient to choose a point within a each polygon and then use IsInUtils.isPointInShape and the relative areas to test if this polygon is in others. The point could be the centre of the polygon, after checking isPointInShape == IN on itself, and, if not, make do with the closing point, or some trial and error moving from the closing point. This also bypasses ambiguities cause by overlapping polygons in this phase of the logic. Ticker On Wed, 2021-03-31 at 15:56 +0100, svn commit wrote: > Version mkgmap-r4622 was committed by gerd on Wed, 31 Mar 2021 > BRANCH: faster-mp > - use IsInUtil to do geometry calculations like insideness or > outsideness: Allows to remove a lot of complex code but might be > slower in some cases. > - document the poor completeness of collection intersectingPolygons. > Probably will removed as well. > > > http://www.mkgmap.org.uk/websvn/revision.php?repname=mkgmap&rev=4622 > ___ > mkgmap-svn mailing list > To unsubscribe send an mail to mkgmap-svn-le...@lists.mkgmap.org.uk > http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-svn ___ 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] [mkgmap-svn] Commit r4622: - use IsInUtil to do geometry calculations like insideness or outsideness: Allows to remove a lot of complex code but might be slower in some cases.
Hi Gerd Wouldn't it be more efficient to choose a point within a each polygon and then use IsInUtils.isPointInShape and the relative areas to test if this polygon is in others. The point could be the centre of the polygon, after checking isPointInShape == IN on itself, and, if not, make do with the closing point, or some trial and error moving from the closing point. This also bypasses ambiguities cause by overlapping polygons in this phase of the logic. Ticker On Wed, 2021-03-31 at 15:56 +0100, svn commit wrote: > Version mkgmap-r4622 was committed by gerd on Wed, 31 Mar 2021 > BRANCH: faster-mp > - use IsInUtil to do geometry calculations like insideness or > outsideness: Allows to remove a lot of complex code but might be > slower in some cases. > - document the poor completeness of collection intersectingPolygons. > Probably will removed as well. > > > http://www.mkgmap.org.uk/websvn/revision.php?repname=mkgmap&rev=4622 > ___ > mkgmap-svn mailing list > To unsubscribe send an mail to mkgmap-svn-le...@lists.mkgmap.org.uk > http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-svn ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
