Re: [mkgmap-dev] Work on is_in branch
Hi Gerd Nothing else I want to change. I keep thinking there must be other ways to do the lineInShape logic, but I think it has taken enough time already. Ticker On Fri, 2020-03-06 at 08:16 +, Gerd Petermann wrote: > Hi Ticker, > > My concerns regarding a merge to trunk are resolved. Anything else > you want to change? > > Gerd > > > > Von: mkgmap-dev im Auftrag > von Gerd Petermann > Gesendet: Dienstag, 3. März 2020 15:22 > An: Ticker Berkin; Development list for mkgmap > Betreff: Re: [mkgmap-dev] Work on is_in branch > > Hi Ticker, > > nice :) > Committed with r4461, with small changes. > > This even allows to change the test case for lamp4 from expected="?" > to expected="2" (ON). > > reg. the distance calculations: I don't remember the details and > maybe all is wrong. > > See svn log for r : > http://www.mkgmap.org.uk/websvn/revision.php?repname=mkgmap= > and search the archives for "Great Britain National Grid". > > The math behind projections and distance formulas is too complex for > me. > > Gerd > > > Von: mkgmap-dev im Auftrag > von Ticker Berkin > Gesendet: Dienstag, 3. März 2020 14:24 > An: Development list for mkgmap > Betreff: Re: [mkgmap-dev] Work on is_in branch > > Hi Gerd > > Patch attached: > > - inherits your is_in-function_v14.patch > > - adds Math.round to Coord.makeBetweenPoint(); Is this how you > indented? > > - removes IsInUtil.insidePolygon() and changes callers to use > isPointInShape() > > - adds ON tolerance to isPointInShape() - I couldn't work out how to > do > this with the winding algo, so changed it to crossing-point, which is > fine for mkgmap polygons. > > - add some more tolerances to isLineInShape > > - isLineInShape had comment: > > // it is unlikely but not impossible that pTest is on boundary :( > > and it returned the wrong result if it was. This contributed to the > difficulties with b14 (and b19). I've fixed it and, I think, improved > and simplified the running status setting > > - fix spelling of rhumLine to rhumbLine > > There are still a couple of places that have complicated distance > calculation and point insertion using, bearings, rhumbline, meter > conversion but I don't think it is worth re-implementing them for > this. > > I'm slightly surprised how much use there is of > bearing/rhumbLine/Mercator projection calculations. I think real > distance/metre calcs should be "great circle" and internal poly/line > chopping, testing etc should be high-precision polar coords. > > Ticker > > On Thu, 2020-02-27 at 19:36 +, Gerd Petermann wrote: > > Hi Ticker, > > > > if you see a way to change the algo just do it. > > I've just noticed that I forgot to commit a change in > > Coord.makeBetweenPoint(). > > This routine should use Math.round. Will reduce the error by 50%, > > right? > > > > Gerd > > > > > > Von: mkgmap-dev im Auftrag > > von Ticker Berkin > > Gesendet: Donnerstag, 27. Februar 2020 20:24 > > An: Development list for mkgmap > > Betreff: Re: [mkgmap-dev] Work on is_in branch > > > > Hi Gerd > > > > Looking at the distance calculations to compare with EPS (ie very > > small), wouldn't it be much simpler and clearer just to calculate > > it > > as > > highPrecisionSquared units, not bothering with degrees/radians, > > rhumb > > -line, metre conversion etc. Then EPS would be 4. > > > > Then, considering IsInUtil.insidePolgon and can it be changed to > > have > > some tolerance and maybe changing the interface to return > > IN/ON/OUT, > > it > > looks like it will stop, returning onBoundary, if there is a > > polygon > > segment that 'aims at' the point. > > > > 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] Work on is_in branch
Hi Ticker, My concerns regarding a merge to trunk are resolved. Anything else you want to change? Gerd Von: mkgmap-dev im Auftrag von Gerd Petermann Gesendet: Dienstag, 3. März 2020 15:22 An: Ticker Berkin; Development list for mkgmap Betreff: Re: [mkgmap-dev] Work on is_in branch Hi Ticker, nice :) Committed with r4461, with small changes. This even allows to change the test case for lamp4 from expected="?" to expected="2" (ON). reg. the distance calculations: I don't remember the details and maybe all is wrong. See svn log for r : http://www.mkgmap.org.uk/websvn/revision.php?repname=mkgmap= and search the archives for "Great Britain National Grid". The math behind projections and distance formulas is too complex for me. Gerd Von: mkgmap-dev im Auftrag von Ticker Berkin Gesendet: Dienstag, 3. März 2020 14:24 An: Development list for mkgmap Betreff: Re: [mkgmap-dev] Work on is_in branch Hi Gerd Patch attached: - inherits your is_in-function_v14.patch - adds Math.round to Coord.makeBetweenPoint(); Is this how you indented? - removes IsInUtil.insidePolygon() and changes callers to use isPointInShape() - adds ON tolerance to isPointInShape() - I couldn't work out how to do this with the winding algo, so changed it to crossing-point, which is fine for mkgmap polygons. - add some more tolerances to isLineInShape - isLineInShape had comment: // it is unlikely but not impossible that pTest is on boundary :( and it returned the wrong result if it was. This contributed to the difficulties with b14 (and b19). I've fixed it and, I think, improved and simplified the running status setting - fix spelling of rhumLine to rhumbLine There are still a couple of places that have complicated distance calculation and point insertion using, bearings, rhumbline, meter conversion but I don't think it is worth re-implementing them for this. I'm slightly surprised how much use there is of bearing/rhumbLine/Mercator projection calculations. I think real distance/metre calcs should be "great circle" and internal poly/line chopping, testing etc should be high-precision polar coords. Ticker On Thu, 2020-02-27 at 19:36 +, Gerd Petermann wrote: > Hi Ticker, > > if you see a way to change the algo just do it. > I've just noticed that I forgot to commit a change in > Coord.makeBetweenPoint(). > This routine should use Math.round. Will reduce the error by 50%, > right? > > Gerd > > > Von: mkgmap-dev im Auftrag > von Ticker Berkin > Gesendet: Donnerstag, 27. Februar 2020 20:24 > An: Development list for mkgmap > Betreff: Re: [mkgmap-dev] Work on is_in branch > > Hi Gerd > > Looking at the distance calculations to compare with EPS (ie very > small), wouldn't it be much simpler and clearer just to calculate it > as > highPrecisionSquared units, not bothering with degrees/radians, rhumb > -line, metre conversion etc. Then EPS would be 4. > > Then, considering IsInUtil.insidePolgon and can it be changed to have > some tolerance and maybe changing the interface to return IN/ON/OUT, > it > looks like it will stop, returning onBoundary, if there is a polygon > segment that 'aims at' the point. > > 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] Work on is_in branch
Hi Ticker, nice :) Committed with r4461, with small changes. This even allows to change the test case for lamp4 from expected="?" to expected="2" (ON). reg. the distance calculations: I don't remember the details and maybe all is wrong. See svn log for r : http://www.mkgmap.org.uk/websvn/revision.php?repname=mkgmap= and search the archives for "Great Britain National Grid". The math behind projections and distance formulas is too complex for me. Gerd Von: mkgmap-dev im Auftrag von Ticker Berkin Gesendet: Dienstag, 3. März 2020 14:24 An: Development list for mkgmap Betreff: Re: [mkgmap-dev] Work on is_in branch Hi Gerd Patch attached: - inherits your is_in-function_v14.patch - adds Math.round to Coord.makeBetweenPoint(); Is this how you indented? - removes IsInUtil.insidePolygon() and changes callers to use isPointInShape() - adds ON tolerance to isPointInShape() - I couldn't work out how to do this with the winding algo, so changed it to crossing-point, which is fine for mkgmap polygons. - add some more tolerances to isLineInShape - isLineInShape had comment: // it is unlikely but not impossible that pTest is on boundary :( and it returned the wrong result if it was. This contributed to the difficulties with b14 (and b19). I've fixed it and, I think, improved and simplified the running status setting - fix spelling of rhumLine to rhumbLine There are still a couple of places that have complicated distance calculation and point insertion using, bearings, rhumbline, meter conversion but I don't think it is worth re-implementing them for this. I'm slightly surprised how much use there is of bearing/rhumbLine/Mercator projection calculations. I think real distance/metre calcs should be "great circle" and internal poly/line chopping, testing etc should be high-precision polar coords. Ticker On Thu, 2020-02-27 at 19:36 +, Gerd Petermann wrote: > Hi Ticker, > > if you see a way to change the algo just do it. > I've just noticed that I forgot to commit a change in > Coord.makeBetweenPoint(). > This routine should use Math.round. Will reduce the error by 50%, > right? > > Gerd > > > Von: mkgmap-dev im Auftrag > von Ticker Berkin > Gesendet: Donnerstag, 27. Februar 2020 20:24 > An: Development list for mkgmap > Betreff: Re: [mkgmap-dev] Work on is_in branch > > Hi Gerd > > Looking at the distance calculations to compare with EPS (ie very > small), wouldn't it be much simpler and clearer just to calculate it > as > highPrecisionSquared units, not bothering with degrees/radians, rhumb > -line, metre conversion etc. Then EPS would be 4. > > Then, considering IsInUtil.insidePolgon and can it be changed to have > some tolerance and maybe changing the interface to return IN/ON/OUT, > it > looks like it will stop, returning onBoundary, if there is a polygon > segment that 'aims at' the point. > > Ticker ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Work on is_in branch
Hi Gerd
Patch attached:
- inherits your is_in-function_v14.patch
- adds Math.round to Coord.makeBetweenPoint(); Is this how you
indented?
- removes IsInUtil.insidePolygon() and changes callers to use
isPointInShape()
- adds ON tolerance to isPointInShape() - I couldn't work out how to do
this with the winding algo, so changed it to crossing-point, which is
fine for mkgmap polygons.
- add some more tolerances to isLineInShape
- isLineInShape had comment:
// it is unlikely but not impossible that pTest is on boundary :(
and it returned the wrong result if it was. This contributed to the
difficulties with b14 (and b19). I've fixed it and, I think, improved
and simplified the running status setting
- fix spelling of rhumLine to rhumbLine
There are still a couple of places that have complicated distance
calculation and point insertion using, bearings, rhumbline, meter
conversion but I don't think it is worth re-implementing them for this.
I'm slightly surprised how much use there is of
bearing/rhumbLine/Mercator projection calculations. I think real
distance/metre calcs should be "great circle" and internal poly/line
chopping, testing etc should be high-precision polar coords.
Ticker
On Thu, 2020-02-27 at 19:36 +, Gerd Petermann wrote:
> Hi Ticker,
>
> if you see a way to change the algo just do it.
> I've just noticed that I forgot to commit a change in
> Coord.makeBetweenPoint().
> This routine should use Math.round. Will reduce the error by 50%,
> right?
>
> Gerd
>
>
> Von: mkgmap-dev im Auftrag
> von Ticker Berkin
> Gesendet: Donnerstag, 27. Februar 2020 20:24
> An: Development list for mkgmap
> Betreff: Re: [mkgmap-dev] Work on is_in branch
>
> Hi Gerd
>
> Looking at the distance calculations to compare with EPS (ie very
> small), wouldn't it be much simpler and clearer just to calculate it
> as
> highPrecisionSquared units, not bothering with degrees/radians, rhumb
> -line, metre conversion etc. Then EPS would be 4.
>
> Then, considering IsInUtil.insidePolgon and can it be changed to have
> some tolerance and maybe changing the interface to return IN/ON/OUT,
> it
> looks like it will stop, returning onBoundary, if there is a polygon
> segment that 'aims at' the point.
>
> Ticker
Index: src/uk/me/parabola/imgfmt/app/Coord.java
===
--- src/uk/me/parabola/imgfmt/app/Coord.java (revision 4460)
+++ src/uk/me/parabola/imgfmt/app/Coord.java (working copy)
@@ -56,6 +56,7 @@
public static final int DELTA_SHIFT = HIGH_PREC_BITS - 24;
private static final int MAX_DELTA = 1 << (DELTA_SHIFT - 2); // max delta abs value that is considered okay
private static final long FACTOR_HP = 1L << HIGH_PREC_BITS;
+ private static final int HIGH_PREC_UNUSED_BITS = Integer.SIZE - HIGH_PREC_BITS;
public static final double R = 6378137.0; // Radius of earth at equator as defined by WGS84
public static final double U = R * 2 * Math.PI; // circumference of earth at equator (WGS84)
@@ -516,6 +517,16 @@
}
/**
+ * Distance to other point in high precision squared units
+ */
+ public long distanceInHighPrecSquared(Coord other) {
+ int dLatHp = other.getHighPrecLat() - getHighPrecLat();
+ int dLonHp = other.getHighPrecLon() - getHighPrecLon();
+ dLonHp = (dLonHp << HIGH_PREC_UNUSED_BITS) >> HIGH_PREC_UNUSED_BITS; // fix wrap-around earth
+ return (long)dLatHp * dLatHp + (long)dLonHp * dLonHp;
+ }
+
+ /**
* Calculate point on the line this->other. If d is the distance between this and other,
* the point is {@code fraction * d} metres from this.
* For small distances between this and other we use a flat earth approximation,
@@ -525,15 +536,15 @@
public Coord makeBetweenPoint(Coord other, double fraction) {
int dlatHp = other.getHighPrecLat() - getHighPrecLat();
int dlonHp = other.getHighPrecLon() - getHighPrecLon();
- if (dlonHp == 0 || Math.abs(dlatHp) < 100 && Math.abs(dlonHp) < 100 ){
+ if (dlonHp == 0 || Math.abs(dlatHp) < 100 && Math.abs(dlonHp) < 100) {
// distances are rather small, we can use flat earth approximation
- int latHighPrec = (int) (getHighPrecLat() + dlatHp * fraction);
- int lonHighPrec = (int) (getHighPrecLon() + dlonHp * fraction);
+ int latHighPrec = (int)Math.round(getHighPrecLat() + dlatHp * fraction);
+ int lonHighPrec = (int)Math.round(getHighPrecLon() + dlonHp * fraction);
return makeHighPrecCoord(latHighPrec, lonHighPrec);
}
double brng = this.bearingToOnRhumbLine(other, true);
double dist = this.distance(other) * fraction;
- return this.destOnRhumLine(dist, brng);
+ return this.destOnRhumbLine(dist, brng);
}
@@ -763,7 +774,7 @@
* @param brng bearing in degrees
* @return a new Coord instance
*/
- public Coord
Re: [mkgmap-dev] Work on is_in branch
Hi Ticker,
if you see a way to change the algo just do it.
I've just noticed that I forgot to commit a change in Coord.makeBetweenPoint().
This routine should use Math.round. Will reduce the error by 50%, right?
Gerd
Von: mkgmap-dev im Auftrag von Ticker
Berkin
Gesendet: Donnerstag, 27. Februar 2020 20:24
An: Development list for mkgmap
Betreff: Re: [mkgmap-dev] Work on is_in branch
Hi Gerd
Looking at the distance calculations to compare with EPS (ie very
small), wouldn't it be much simpler and clearer just to calculate it as
highPrecisionSquared units, not bothering with degrees/radians, rhumb
-line, metre conversion etc. Then EPS would be 4.
Then, considering IsInUtil.insidePolgon and can it be changed to have
some tolerance and maybe changing the interface to return IN/ON/OUT, it
looks like it will stop, returning onBoundary, if there is a polygon
segment that 'aims at' the point.
Ticker
On Thu, 2020-02-27 at 16:42 +, Gerd Petermann wrote:
> Hi Ticker,
>
> yes, probably the value is still too small, and I assume nobody would
> mind to use a halo of 0.08 m width.
> Small problem is that we don't use this halo with the point in shape
> tests.
>
> Gerd
>
>
> Von: mkgmap-dev im Auftrag
> von Ticker Berkin
> Gesendet: Donnerstag, 27. Februar 2020 17:23
> An: Development list for mkgmap
> Betreff: Re: [mkgmap-dev] Work on is_in branch
>
> Hi Gerd
>
> Yes, I think I see where it goes in with josm at maximum zoom.
>
> Shouldn't EPS be a bit bigger? My understanding was that a high
> -precision unit was ~37mm at the equator (40,075*1000/2^24/2^6)*1000.
>
> With your change from 10mm to 20mm all the tests pass, but wouldn't
> private static final double EPS = 0.080;
> be safer, to allow for 2 hp roundings away from each other.
>
> Ticker
>
> On Thu, 2020-02-27 at 14:42 +, Gerd Petermann wrote:
> > Hi Ticker,
> >
> > I've looked at b14 again. The mp-cutting produces a point which is
> > a
> > small bit inside the real hole (~1.6 mm). I've attached the gpx
> > files.
> > e_hp is the tested segmet of the element b14, s_hp is the tested
> > segment created by cutting, shape_hp is the complete shape produced
> > by the mp-cutter.
> > The southern end crosses e_hp. This small overlap is ignored when
> > the
> > merged shape is analyzed. Responsible for this is the method
> > isOnOrCloseToEdgeOfShape(), I think I wrote it exactly for this
> > problem but it is just a work-around for the problems produced by
> > the
> > polygon cutting.
> >
> > Attached is a patch which might solve the problem, didn't test it
> > much. It increases the allowed distance for "ON" from 1 to 2 mm and
> > handles this special case.
> >
> > Gerd
> >
> >
> > Von: mkgmap-dev im Auftrag
> > von Ticker Berkin
> > Gesendet: Donnerstag, 27. Februar 2020 14:01
> > An: Development list for mkgmap
> > Betreff: Re: [mkgmap-dev] Work on is_in branch
> >
> > Hi Gerd
> >
> > Changes:
> >
> > - Added comment in style-manual.txt about tools needed and how to
> > generate the pdf. These are asciidoc, fop, python-pygments and
> > mkgmap
> > -pygments.
> >
> > - Adjusted the layout of "Table 4.2. Style functions" so that
> > is_in(...) doesn't run into the flags and and slightly changed the
> > highlighting again.
> >
> > - Changed log.info to log.debug.
> >
> > - Added default: throw... to a couple of switch statements. I
> > disagree
> > with SonarLint that this is always good practice; here it is just
> > pointless clutter.
> >
> > I'm not sure what the problem is with commented code blocks. I left
> > @override value() {...} in as commented because it clarifies what
> > needs
> > to change between a CachedFunction and a StyleFunction.
> >
> > doc/styles/main.txt should be deleted from svn; it has been
> > superseded
> > by style-manual.txt.
> >
> > Reg. b14. It might be slight rounding errors, but the hole
> > generated
> > from the merge of the 2 halves of the outer retains the 2 cut
> > -points
> > and this does match the inner polygon, whereas, for the inner
> > polygon, isLineInShape gives IN/ON/OUT against one of the halves of
> > the outer. I'd have expected the problems to be the other way
> > around.
> >
> > Ticker
> >
> > On Wed, 2020-02-26 at 08:46 +, Gerd Petermann wrote:
> > > Hi Ticker,
> > >
> > > no idea how the tool chain for t
Re: [mkgmap-dev] Work on is_in branch
Hi Gerd
Looking at the distance calculations to compare with EPS (ie very
small), wouldn't it be much simpler and clearer just to calculate it as
highPrecisionSquared units, not bothering with degrees/radians, rhumb
-line, metre conversion etc. Then EPS would be 4.
Then, considering IsInUtil.insidePolgon and can it be changed to have
some tolerance and maybe changing the interface to return IN/ON/OUT, it
looks like it will stop, returning onBoundary, if there is a polygon
segment that 'aims at' the point.
Ticker
On Thu, 2020-02-27 at 16:42 +, Gerd Petermann wrote:
> Hi Ticker,
>
> yes, probably the value is still too small, and I assume nobody would
> mind to use a halo of 0.08 m width.
> Small problem is that we don't use this halo with the point in shape
> tests.
>
> Gerd
>
>
> Von: mkgmap-dev im Auftrag
> von Ticker Berkin
> Gesendet: Donnerstag, 27. Februar 2020 17:23
> An: Development list for mkgmap
> Betreff: Re: [mkgmap-dev] Work on is_in branch
>
> Hi Gerd
>
> Yes, I think I see where it goes in with josm at maximum zoom.
>
> Shouldn't EPS be a bit bigger? My understanding was that a high
> -precision unit was ~37mm at the equator (40,075*1000/2^24/2^6)*1000.
>
> With your change from 10mm to 20mm all the tests pass, but wouldn't
> private static final double EPS = 0.080;
> be safer, to allow for 2 hp roundings away from each other.
>
> Ticker
>
> On Thu, 2020-02-27 at 14:42 +, Gerd Petermann wrote:
> > Hi Ticker,
> >
> > I've looked at b14 again. The mp-cutting produces a point which is
> > a
> > small bit inside the real hole (~1.6 mm). I've attached the gpx
> > files.
> > e_hp is the tested segmet of the element b14, s_hp is the tested
> > segment created by cutting, shape_hp is the complete shape produced
> > by the mp-cutter.
> > The southern end crosses e_hp. This small overlap is ignored when
> > the
> > merged shape is analyzed. Responsible for this is the method
> > isOnOrCloseToEdgeOfShape(), I think I wrote it exactly for this
> > problem but it is just a work-around for the problems produced by
> > the
> > polygon cutting.
> >
> > Attached is a patch which might solve the problem, didn't test it
> > much. It increases the allowed distance for "ON" from 1 to 2 mm and
> > handles this special case.
> >
> > Gerd
> >
> >
> > Von: mkgmap-dev im Auftrag
> > von Ticker Berkin
> > Gesendet: Donnerstag, 27. Februar 2020 14:01
> > An: Development list for mkgmap
> > Betreff: Re: [mkgmap-dev] Work on is_in branch
> >
> > Hi Gerd
> >
> > Changes:
> >
> > - Added comment in style-manual.txt about tools needed and how to
> > generate the pdf. These are asciidoc, fop, python-pygments and
> > mkgmap
> > -pygments.
> >
> > - Adjusted the layout of "Table 4.2. Style functions" so that
> > is_in(...) doesn't run into the flags and and slightly changed the
> > highlighting again.
> >
> > - Changed log.info to log.debug.
> >
> > - Added default: throw... to a couple of switch statements. I
> > disagree
> > with SonarLint that this is always good practice; here it is just
> > pointless clutter.
> >
> > I'm not sure what the problem is with commented code blocks. I left
> > @override value() {...} in as commented because it clarifies what
> > needs
> > to change between a CachedFunction and a StyleFunction.
> >
> > doc/styles/main.txt should be deleted from svn; it has been
> > superseded
> > by style-manual.txt.
> >
> > Reg. b14. It might be slight rounding errors, but the hole
> > generated
> > from the merge of the 2 halves of the outer retains the 2 cut
> > -points
> > and this does match the inner polygon, whereas, for the inner
> > polygon, isLineInShape gives IN/ON/OUT against one of the halves of
> > the outer. I'd have expected the problems to be the other way
> > around.
> >
> > Ticker
> >
> > On Wed, 2020-02-26 at 08:46 +, Gerd Petermann wrote:
> > > Hi Ticker,
> > >
> > > no idea how the tool chain for the pdf works.
> > >
> > > There are some commented code blocks and Eclipse and SonarLint
> > > warn
> > > about several missing default statements, e.g.
> > > Complete cases by adding the missing enum constants or add a
> > > default
> > > case to this switch. IsInFunction.java
> > > mkgmap/src/uk/me/parabola/mkgmap/osmstyle/functio
Re: [mkgmap-dev] Work on is_in branch
Hi Ticker,
yes, probably the value is still too small, and I assume nobody would mind to
use a halo of 0.08 m width.
Small problem is that we don't use this halo with the point in shape tests.
Gerd
Von: mkgmap-dev im Auftrag von Ticker
Berkin
Gesendet: Donnerstag, 27. Februar 2020 17:23
An: Development list for mkgmap
Betreff: Re: [mkgmap-dev] Work on is_in branch
Hi Gerd
Yes, I think I see where it goes in with josm at maximum zoom.
Shouldn't EPS be a bit bigger? My understanding was that a high
-precision unit was ~37mm at the equator (40,075*1000/2^24/2^6)*1000.
With your change from 10mm to 20mm all the tests pass, but wouldn't
private static final double EPS = 0.080;
be safer, to allow for 2 hp roundings away from each other.
Ticker
On Thu, 2020-02-27 at 14:42 +, Gerd Petermann wrote:
> Hi Ticker,
>
> I've looked at b14 again. The mp-cutting produces a point which is a
> small bit inside the real hole (~1.6 mm). I've attached the gpx
> files.
> e_hp is the tested segmet of the element b14, s_hp is the tested
> segment created by cutting, shape_hp is the complete shape produced
> by the mp-cutter.
> The southern end crosses e_hp. This small overlap is ignored when the
> merged shape is analyzed. Responsible for this is the method
> isOnOrCloseToEdgeOfShape(), I think I wrote it exactly for this
> problem but it is just a work-around for the problems produced by the
> polygon cutting.
>
> Attached is a patch which might solve the problem, didn't test it
> much. It increases the allowed distance for "ON" from 1 to 2 mm and
> handles this special case.
>
> Gerd
>
>
> Von: mkgmap-dev im Auftrag
> von Ticker Berkin
> Gesendet: Donnerstag, 27. Februar 2020 14:01
> An: Development list for mkgmap
> Betreff: Re: [mkgmap-dev] Work on is_in branch
>
> Hi Gerd
>
> Changes:
>
> - Added comment in style-manual.txt about tools needed and how to
> generate the pdf. These are asciidoc, fop, python-pygments and mkgmap
> -pygments.
>
> - Adjusted the layout of "Table 4.2. Style functions" so that
> is_in(...) doesn't run into the flags and and slightly changed the
> highlighting again.
>
> - Changed log.info to log.debug.
>
> - Added default: throw... to a couple of switch statements. I
> disagree
> with SonarLint that this is always good practice; here it is just
> pointless clutter.
>
> I'm not sure what the problem is with commented code blocks. I left
> @override value() {...} in as commented because it clarifies what
> needs
> to change between a CachedFunction and a StyleFunction.
>
> doc/styles/main.txt should be deleted from svn; it has been
> superseded
> by style-manual.txt.
>
> Reg. b14. It might be slight rounding errors, but the hole generated
> from the merge of the 2 halves of the outer retains the 2 cut-points
> and this does match the inner polygon, whereas, for the inner
> polygon, isLineInShape gives IN/ON/OUT against one of the halves of
> the outer. I'd have expected the problems to be the other way around.
>
> Ticker
>
> On Wed, 2020-02-26 at 08:46 +, Gerd Petermann wrote:
> > Hi Ticker,
> >
> > no idea how the tool chain for the pdf works.
> >
> > There are some commented code blocks and Eclipse and SonarLint warn
> > about several missing default statements, e.g.
> > Complete cases by adding the missing enum constants or add a
> > default
> > case to this switch. IsInFunction.java
> > mkgmap/src/uk/me/parabola/mkgmap/osmstyle/function line 164
> > SonarLint On-The-Fly Issue
> >
> > Reg. the TODO comment
> > // problem with test b14 on the cut polygons and isLineInShape that
> > goes away when merged. TODO: investigate sometime
> > Maybe the reason is that we create a Coord instance at the place
> > where the polygon is split. Due to the rounding errors this point
> > can
> > be a 1-2 mm inside or outside the original inner polygon. Merging
> > should not change the result unless the added point is removed by
> > the
> > merge. In that case I would assume that there were no rounding
> > errors.
> >
> > Some log statements might be removed or changed to debug level?
> > log.info("done", System.identityHashCode(this), hasIn, hasOn,
> > hasOut);
> >
> > Gerd
> >
> >
> > Von: mkgmap-dev im Auftrag
> > von Ticker Berkin
> > Gesendet: Dienstag, 25. Februar 2020 10:27
> > An: Development list for mkgmap
> > Betreff: Re: [mkgmap-dev] Work on is_in branch
> >
> > Hi Gerd
> >
> >
Re: [mkgmap-dev] Work on is_in branch
Hi Gerd
Yes, I think I see where it goes in with josm at maximum zoom.
Shouldn't EPS be a bit bigger? My understanding was that a high
-precision unit was ~37mm at the equator (40,075*1000/2^24/2^6)*1000.
With your change from 10mm to 20mm all the tests pass, but wouldn't
private static final double EPS = 0.080;
be safer, to allow for 2 hp roundings away from each other.
Ticker
On Thu, 2020-02-27 at 14:42 +, Gerd Petermann wrote:
> Hi Ticker,
>
> I've looked at b14 again. The mp-cutting produces a point which is a
> small bit inside the real hole (~1.6 mm). I've attached the gpx
> files.
> e_hp is the tested segmet of the element b14, s_hp is the tested
> segment created by cutting, shape_hp is the complete shape produced
> by the mp-cutter.
> The southern end crosses e_hp. This small overlap is ignored when the
> merged shape is analyzed. Responsible for this is the method
> isOnOrCloseToEdgeOfShape(), I think I wrote it exactly for this
> problem but it is just a work-around for the problems produced by the
> polygon cutting.
>
> Attached is a patch which might solve the problem, didn't test it
> much. It increases the allowed distance for "ON" from 1 to 2 mm and
> handles this special case.
>
> Gerd
>
>
> Von: mkgmap-dev im Auftrag
> von Ticker Berkin
> Gesendet: Donnerstag, 27. Februar 2020 14:01
> An: Development list for mkgmap
> Betreff: Re: [mkgmap-dev] Work on is_in branch
>
> Hi Gerd
>
> Changes:
>
> - Added comment in style-manual.txt about tools needed and how to
> generate the pdf. These are asciidoc, fop, python-pygments and mkgmap
> -pygments.
>
> - Adjusted the layout of "Table 4.2. Style functions" so that
> is_in(...) doesn't run into the flags and and slightly changed the
> highlighting again.
>
> - Changed log.info to log.debug.
>
> - Added default: throw... to a couple of switch statements. I
> disagree
> with SonarLint that this is always good practice; here it is just
> pointless clutter.
>
> I'm not sure what the problem is with commented code blocks. I left
> @override value() {...} in as commented because it clarifies what
> needs
> to change between a CachedFunction and a StyleFunction.
>
> doc/styles/main.txt should be deleted from svn; it has been
> superseded
> by style-manual.txt.
>
> Reg. b14. It might be slight rounding errors, but the hole generated
> from the merge of the 2 halves of the outer retains the 2 cut-points
> and this does match the inner polygon, whereas, for the inner
> polygon, isLineInShape gives IN/ON/OUT against one of the halves of
> the outer. I'd have expected the problems to be the other way around.
>
> Ticker
>
> On Wed, 2020-02-26 at 08:46 +, Gerd Petermann wrote:
> > Hi Ticker,
> >
> > no idea how the tool chain for the pdf works.
> >
> > There are some commented code blocks and Eclipse and SonarLint warn
> > about several missing default statements, e.g.
> > Complete cases by adding the missing enum constants or add a
> > default
> > case to this switch. IsInFunction.java
> > mkgmap/src/uk/me/parabola/mkgmap/osmstyle/function line 164
> > SonarLint On-The-Fly Issue
> >
> > Reg. the TODO comment
> > // problem with test b14 on the cut polygons and isLineInShape that
> > goes away when merged. TODO: investigate sometime
> > Maybe the reason is that we create a Coord instance at the place
> > where the polygon is split. Due to the rounding errors this point
> > can
> > be a 1-2 mm inside or outside the original inner polygon. Merging
> > should not change the result unless the added point is removed by
> > the
> > merge. In that case I would assume that there were no rounding
> > errors.
> >
> > Some log statements might be removed or changed to debug level?
> > log.info("done", System.identityHashCode(this), hasIn, hasOn,
> > hasOut);
> >
> > Gerd
> >
> >
> > Von: mkgmap-dev im Auftrag
> > von Ticker Berkin
> > Gesendet: Dienstag, 25. Februar 2020 10:27
> > An: Development list for mkgmap
> > Betreff: Re: [mkgmap-dev] Work on is_in branch
> >
> > Hi Gerd
> >
> > I think this is about ready for release.
> >
> > There is a slight problem with the layout in the Style Manual in
> > that
> > the width of "is_in(tag,value,method)" causes it to run into the
> > Node/Way/Relation flags. If there was a way to put the function
> > args
> > down the first column it would fix it, but I have no idea of the
>
Re: [mkgmap-dev] Work on is_in branch
Hi Ticker,
I've looked at b14 again. The mp-cutting produces a point which is a small bit
inside the real hole (~1.6 mm). I've attached the gpx files.
e_hp is the tested segmet of the element b14, s_hp is the tested segment
created by cutting, shape_hp is the complete shape produced by the mp-cutter.
The southern end crosses e_hp. This small overlap is ignored when the merged
shape is analyzed. Responsible for this is the method
isOnOrCloseToEdgeOfShape(), I think I wrote it exactly for this problem but it
is just a work-around for the problems produced by the polygon cutting.
Attached is a patch which might solve the problem, didn't test it much. It
increases the allowed distance for "ON" from 1 to 2 mm and handles this special
case.
Gerd
Von: mkgmap-dev im Auftrag von Ticker
Berkin
Gesendet: Donnerstag, 27. Februar 2020 14:01
An: Development list for mkgmap
Betreff: Re: [mkgmap-dev] Work on is_in branch
Hi Gerd
Changes:
- Added comment in style-manual.txt about tools needed and how to
generate the pdf. These are asciidoc, fop, python-pygments and mkgmap
-pygments.
- Adjusted the layout of "Table 4.2. Style functions" so that
is_in(...) doesn't run into the flags and and slightly changed the
highlighting again.
- Changed log.info to log.debug.
- Added default: throw... to a couple of switch statements. I disagree
with SonarLint that this is always good practice; here it is just
pointless clutter.
I'm not sure what the problem is with commented code blocks. I left
@override value() {...} in as commented because it clarifies what needs
to change between a CachedFunction and a StyleFunction.
doc/styles/main.txt should be deleted from svn; it has been superseded
by style-manual.txt.
Reg. b14. It might be slight rounding errors, but the hole generated from the
merge of the 2 halves of the outer retains the 2 cut-points and this does match
the inner polygon, whereas, for the inner polygon, isLineInShape gives
IN/ON/OUT against one of the halves of the outer. I'd have expected the
problems to be the other way around.
Ticker
On Wed, 2020-02-26 at 08:46 +, Gerd Petermann wrote:
> Hi Ticker,
>
> no idea how the tool chain for the pdf works.
>
> There are some commented code blocks and Eclipse and SonarLint warn
> about several missing default statements, e.g.
> Complete cases by adding the missing enum constants or add a default
> case to this switch. IsInFunction.java
> mkgmap/src/uk/me/parabola/mkgmap/osmstyle/function line 164
> SonarLint On-The-Fly Issue
>
> Reg. the TODO comment
> // problem with test b14 on the cut polygons and isLineInShape that
> goes away when merged. TODO: investigate sometime
> Maybe the reason is that we create a Coord instance at the place
> where the polygon is split. Due to the rounding errors this point can
> be a 1-2 mm inside or outside the original inner polygon. Merging
> should not change the result unless the added point is removed by the
> merge. In that case I would assume that there were no rounding
> errors.
>
> Some log statements might be removed or changed to debug level?
> log.info("done", System.identityHashCode(this), hasIn, hasOn,
> hasOut);
>
> Gerd
>
>
> Von: mkgmap-dev im Auftrag
> von Ticker Berkin
> Gesendet: Dienstag, 25. Februar 2020 10:27
> An: Development list for mkgmap
> Betreff: Re: [mkgmap-dev] Work on is_in branch
>
> Hi Gerd
>
> I think this is about ready for release.
>
> There is a slight problem with the layout in the Style Manual in that
> the width of "is_in(tag,value,method)" causes it to run into the
> Node/Way/Relation flags. If there was a way to put the function args
> down the first column it would fix it, but I have no idea of the
> rules
> of the formatting language. What are the tools used to transform
> doc/styles/*.txt to the style-manual.pdf?
>
> I'm not going to be able to do any complex line->polygon in/on/out
> debugging in the next few days and it seems to work well for most
> cases.
>
> Ticker
>
> On Mon, 2020-02-24 at 12:50 +, Ticker Berkin wrote:
> > Hi Gerd
> >
> > Patch attached that:
> >
> > - rewords the sentence is the Style Manual and changes the
> > highlighting; I need to check the next build/download to see if
> > this
> > is clearer.
> >
> > - fixes polygon 'any' method to also return true if exactly ON.
> >
> > - merge polygons for 'any' so that line on shared boundary is "in"
> > rather than "on".
> >
> > - change the test driver to try all methods relevant to the
> > element,
> > checking they return true/false as appropriate. I decided that,
&
Re: [mkgmap-dev] Work on is_in branch
Hi Gerd
Changes:
- Added comment in style-manual.txt about tools needed and how to
generate the pdf. These are asciidoc, fop, python-pygments and mkgmap
-pygments.
- Adjusted the layout of "Table 4.2. Style functions" so that
is_in(...) doesn't run into the flags and and slightly changed the
highlighting again.
- Changed log.info to log.debug.
- Added default: throw... to a couple of switch statements. I disagree
with SonarLint that this is always good practice; here it is just
pointless clutter.
I'm not sure what the problem is with commented code blocks. I left
@override value() {...} in as commented because it clarifies what needs
to change between a CachedFunction and a StyleFunction.
doc/styles/main.txt should be deleted from svn; it has been superseded
by style-manual.txt.
Reg. b14. It might be slight rounding errors, but the hole generated from the
merge of the 2 halves of the outer retains the 2 cut-points and this does match
the inner polygon, whereas, for the inner polygon, isLineInShape gives
IN/ON/OUT against one of the halves of the outer. I'd have expected the
problems to be the other way around.
Ticker
On Wed, 2020-02-26 at 08:46 +, Gerd Petermann wrote:
> Hi Ticker,
>
> no idea how the tool chain for the pdf works.
>
> There are some commented code blocks and Eclipse and SonarLint warn
> about several missing default statements, e.g.
> Complete cases by adding the missing enum constants or add a default
> case to this switch. IsInFunction.java
> mkgmap/src/uk/me/parabola/mkgmap/osmstyle/function line 164
> SonarLint On-The-Fly Issue
>
> Reg. the TODO comment
> // problem with test b14 on the cut polygons and isLineInShape that
> goes away when merged. TODO: investigate sometime
> Maybe the reason is that we create a Coord instance at the place
> where the polygon is split. Due to the rounding errors this point can
> be a 1-2 mm inside or outside the original inner polygon. Merging
> should not change the result unless the added point is removed by the
> merge. In that case I would assume that there were no rounding
> errors.
>
> Some log statements might be removed or changed to debug level?
> log.info("done", System.identityHashCode(this), hasIn, hasOn,
> hasOut);
>
> Gerd
>
>
> Von: mkgmap-dev im Auftrag
> von Ticker Berkin
> Gesendet: Dienstag, 25. Februar 2020 10:27
> An: Development list for mkgmap
> Betreff: Re: [mkgmap-dev] Work on is_in branch
>
> Hi Gerd
>
> I think this is about ready for release.
>
> There is a slight problem with the layout in the Style Manual in that
> the width of "is_in(tag,value,method)" causes it to run into the
> Node/Way/Relation flags. If there was a way to put the function args
> down the first column it would fix it, but I have no idea of the
> rules
> of the formatting language. What are the tools used to transform
> doc/styles/*.txt to the style-manual.pdf?
>
> I'm not going to be able to do any complex line->polygon in/on/out
> debugging in the next few days and it seems to work well for most
> cases.
>
> Ticker
>
> On Mon, 2020-02-24 at 12:50 +, Ticker Berkin wrote:
> > Hi Gerd
> >
> > Patch attached that:
> >
> > - rewords the sentence is the Style Manual and changes the
> > highlighting; I need to check the next build/download to see if
> > this
> > is clearer.
> >
> > - fixes polygon 'any' method to also return true if exactly ON.
> >
> > - merge polygons for 'any' so that line on shared boundary is "in"
> > rather than "on".
> >
> > - change the test driver to try all methods relevant to the
> > element,
> > checking they return true/false as appropriate. I decided that,
> > rather than introducing a new tag saying which methods should
> > match,
> > it was clearer to use the 'expected' tag value as a description of
> > how the element interacted with the polygons and generate the
> > methods
> > that should match from this and the non-matching from a list if all
> > methods.
> >
> > Ticker
>
> ___
> mkgmap-dev mailing list
> mkgmap-dev@lists.mkgmap.org.uk
> http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-devIndex: doc/styles/about.txt
===
--- doc/styles/about.txt (revision 4458)
+++ doc/styles/about.txt (working copy)
@@ -14,9 +14,9 @@
People who have contributed suggestions and corrections to this document
are:
Carlos Dávila,
-Geoff Sherlock
+Geoff Sherlock,
+Ticker Berkin
-
The list of nicknames of everyone that had modified the wiki page
Re: [mkgmap-dev] Work on is_in branch
Hi Ticker,
no idea how the tool chain for the pdf works.
There are some commented code blocks and Eclipse and SonarLint warn about
several missing default statements, e.g.
Complete cases by adding the missing enum constants or add a default case to
this switch. IsInFunction.java
mkgmap/src/uk/me/parabola/mkgmap/osmstyle/function line 164
SonarLint On-The-Fly Issue
Reg. the TODO comment
// problem with test b14 on the cut polygons and isLineInShape that goes away
when merged. TODO: investigate sometime
Maybe the reason is that we create a Coord instance at the place where the
polygon is split. Due to the rounding errors this point can be a 1-2 mm inside
or outside the original inner polygon. Merging should not change the result
unless the added point is removed by the merge. In that case I would assume
that there were no rounding errors.
Some log statements might be removed or changed to debug level?
log.info("done", System.identityHashCode(this), hasIn, hasOn, hasOut);
Gerd
Von: mkgmap-dev im Auftrag von Ticker
Berkin
Gesendet: Dienstag, 25. Februar 2020 10:27
An: Development list for mkgmap
Betreff: Re: [mkgmap-dev] Work on is_in branch
Hi Gerd
I think this is about ready for release.
There is a slight problem with the layout in the Style Manual in that
the width of "is_in(tag,value,method)" causes it to run into the
Node/Way/Relation flags. If there was a way to put the function args
down the first column it would fix it, but I have no idea of the rules
of the formatting language. What are the tools used to transform
doc/styles/*.txt to the style-manual.pdf?
I'm not going to be able to do any complex line->polygon in/on/out
debugging in the next few days and it seems to work well for most
cases.
Ticker
On Mon, 2020-02-24 at 12:50 +, Ticker Berkin wrote:
> Hi Gerd
>
> Patch attached that:
>
> - rewords the sentence is the Style Manual and changes the
> highlighting; I need to check the next build/download to see if this
> is clearer.
>
> - fixes polygon 'any' method to also return true if exactly ON.
>
> - merge polygons for 'any' so that line on shared boundary is "in"
> rather than "on".
>
> - change the test driver to try all methods relevant to the element,
> checking they return true/false as appropriate. I decided that,
> rather than introducing a new tag saying which methods should match,
> it was clearer to use the 'expected' tag value as a description of
> how the element interacted with the polygons and generate the methods
> that should match from this and the non-matching from a list if all
> methods.
>
> 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] Work on is_in branch
Hi Gerd I think this is about ready for release. There is a slight problem with the layout in the Style Manual in that the width of "is_in(tag,value,method)" causes it to run into the Node/Way/Relation flags. If there was a way to put the function args down the first column it would fix it, but I have no idea of the rules of the formatting language. What are the tools used to transform doc/styles/*.txt to the style-manual.pdf? I'm not going to be able to do any complex line->polygon in/on/out debugging in the next few days and it seems to work well for most cases. Ticker On Mon, 2020-02-24 at 12:50 +, Ticker Berkin wrote: > Hi Gerd > > Patch attached that: > > - rewords the sentence is the Style Manual and changes the > highlighting; I need to check the next build/download to see if this > is clearer. > > - fixes polygon 'any' method to also return true if exactly ON. > > - merge polygons for 'any' so that line on shared boundary is "in" > rather than "on". > > - change the test driver to try all methods relevant to the element, > checking they return true/false as appropriate. I decided that, > rather than introducing a new tag saying which methods should match, > it was clearer to use the 'expected' tag value as a description of > how the element interacted with the polygons and generate the methods > that should match from this and the non-matching from a list if all > methods. > > Ticker ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Work on is_in branch
Hi Ticker, I think what I tried to point out is that we have lost some precision reg. the unit tests. On the other hand you are probably right that it doesn't matter for the mkgmap user. Gerd Von: mkgmap-dev im Auftrag von Ticker Berkin Gesendet: Montag, 24. Februar 2020 14:54 An: Development list for mkgmap Betreff: Re: [mkgmap-dev] Work on is_in branch Hi Gerd It isn't really a problem of the test driver; it is a consequence of not having a method that distinguishes between an inner line that touches the edge and one that doesn't, ditto for outer lines. If there is a strong case for methods that do distinguish these cases and they get implemented, then the new methods just needed to be added to the allLineMethods list and expected #1 and #4 maps. Then the tests will fail if you swap 1 & 3 or 4 & 6. Ticker On Mon, 2020-02-24 at 13:11 +, Gerd Petermann wrote: > Hi Ticker, > > see r4457. > > I see one potential problem with your test driver: > It does not always find a problem when the expected value in the test > data is wrong. E.g. when I change the expected value for w2 from 1 to > the wrong value 3 the test doesn't fail. > > Gerd > > > Von: mkgmap-dev im Auftrag > von Ticker Berkin > Gesendet: Montag, 24. Februar 2020 13:50 > An: Development list for mkgmap > Betreff: Re: [mkgmap-dev] Work on is_in branch > > Hi Gerd > > Patch attached that: > > - rewords the sentence is the Style Manual and changes the > highlighting; I need to check the next build/download to see if this > is clearer. > > - fixes polygon 'any' method to also return true if exactly ON. > > - merge polygons for 'any' so that line on shared boundary is "in" > rather than "on". > > - change the test driver to try all methods relevant to the element, > checking they return true/false as appropriate. I decided that, > rather than introducing a new tag saying which methods should match, > it was clearer to use the 'expected' tag value as a description of > how the element interacted with the polygons and generate the methods > that should match from this and the non-matching from a list if all > methods. > > Ticker > > On Thu, 2020-02-20 at 16:45 +, Ticker Berkin wrote: > Hi Gerd > > I don't think the test data 'expected' values are wrong, it is just > that they are more specific than the 'method' mechanism allows to be > differentiated; eg a polygon can only be tested for ALL in or ANY in. > > At the moment I feel you have a reluctance about the whole concept of > the methods. Once the principle is accepted, I'll go through the test > data and add, as another tag, the list of methods that should match > the > element, then change the test driver to check that these match and > the > other applicable methods don't. > > Reg. b14: It isn't the stop-early code that causes the problems, > isLineInShape is not giving the correct answer for a simple polygon > produced by the MP cutter. > > It would be quite easy to introduce some POLYGON 'on' methods, that > match the outer, inner or either edge of a polygon, but maybe this > could wait until there is a call for it. > > Next mail: > I'll change the sentence as you suggest. > > Please can you commit the patch as it stands; it has a lot of good > stuff in it. Then I can do the IsInUtilTest and test data changes as > the next stage. It's also handy to see how the Style Manual looks > after > each build into the download area, because I don't know how to > generate > it and am just guessing at the formatting. > > Thank you > Ticker > > On Thu, 2020-02-20 at 15:41 +, Gerd Petermann wrote: > Hi Ticker, > > I see that you overwrite the expected value stored in the test data > in the unit test. Please don't do this. If you think that the > expected value in is-in-samples.osm > is wrong we should discuss the test data. > In my eyes b14 clearly has points on the edge (as it is part of the > edge) and is out. > > If you think the expected results are correct but your new code > doesn't allow to test them because of the early stop code please add > a new tag to each object or maybe create a new file. The unit test > file is meant to document what the code does. > > Gerd > ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Work on is_in branch
Hi Gerd It isn't really a problem of the test driver; it is a consequence of not having a method that distinguishes between an inner line that touches the edge and one that doesn't, ditto for outer lines. If there is a strong case for methods that do distinguish these cases and they get implemented, then the new methods just needed to be added to the allLineMethods list and expected #1 and #4 maps. Then the tests will fail if you swap 1 & 3 or 4 & 6. Ticker On Mon, 2020-02-24 at 13:11 +, Gerd Petermann wrote: > Hi Ticker, > > see r4457. > > I see one potential problem with your test driver: > It does not always find a problem when the expected value in the test > data is wrong. E.g. when I change the expected value for w2 from 1 to > the wrong value 3 the test doesn't fail. > > Gerd > > > Von: mkgmap-dev im Auftrag > von Ticker Berkin > Gesendet: Montag, 24. Februar 2020 13:50 > An: Development list for mkgmap > Betreff: Re: [mkgmap-dev] Work on is_in branch > > Hi Gerd > > Patch attached that: > > - rewords the sentence is the Style Manual and changes the > highlighting; I need to check the next build/download to see if this > is clearer. > > - fixes polygon 'any' method to also return true if exactly ON. > > - merge polygons for 'any' so that line on shared boundary is "in" > rather than "on". > > - change the test driver to try all methods relevant to the element, > checking they return true/false as appropriate. I decided that, > rather than introducing a new tag saying which methods should match, > it was clearer to use the 'expected' tag value as a description of > how the element interacted with the polygons and generate the methods > that should match from this and the non-matching from a list if all > methods. > > Ticker > > On Thu, 2020-02-20 at 16:45 +, Ticker Berkin wrote: > Hi Gerd > > I don't think the test data 'expected' values are wrong, it is just > that they are more specific than the 'method' mechanism allows to be > differentiated; eg a polygon can only be tested for ALL in or ANY in. > > At the moment I feel you have a reluctance about the whole concept of > the methods. Once the principle is accepted, I'll go through the test > data and add, as another tag, the list of methods that should match > the > element, then change the test driver to check that these match and > the > other applicable methods don't. > > Reg. b14: It isn't the stop-early code that causes the problems, > isLineInShape is not giving the correct answer for a simple polygon > produced by the MP cutter. > > It would be quite easy to introduce some POLYGON 'on' methods, that > match the outer, inner or either edge of a polygon, but maybe this > could wait until there is a call for it. > > Next mail: > I'll change the sentence as you suggest. > > Please can you commit the patch as it stands; it has a lot of good > stuff in it. Then I can do the IsInUtilTest and test data changes as > the next stage. It's also handy to see how the Style Manual looks > after > each build into the download area, because I don't know how to > generate > it and am just guessing at the formatting. > > Thank you > Ticker > > On Thu, 2020-02-20 at 15:41 +, Gerd Petermann wrote: > Hi Ticker, > > I see that you overwrite the expected value stored in the test data > in the unit test. Please don't do this. If you think that the > expected value in is-in-samples.osm > is wrong we should discuss the test data. > In my eyes b14 clearly has points on the edge (as it is part of the > edge) and is out. > > If you think the expected results are correct but your new code > doesn't allow to test them because of the early stop code please add > a new tag to each object or maybe create a new file. The unit test > file is meant to document what the code does. > > Gerd > ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Work on is_in branch
Hi Ticker, see r4457. I see one potential problem with your test driver: It does not always find a problem when the expected value in the test data is wrong. E.g. when I change the expected value for w2 from 1 to the wrong value 3 the test doesn't fail. Gerd Von: mkgmap-dev im Auftrag von Ticker Berkin Gesendet: Montag, 24. Februar 2020 13:50 An: Development list for mkgmap Betreff: Re: [mkgmap-dev] Work on is_in branch Hi Gerd Patch attached that: - rewords the sentence is the Style Manual and changes the highlighting; I need to check the next build/download to see if this is clearer. - fixes polygon 'any' method to also return true if exactly ON. - merge polygons for 'any' so that line on shared boundary is "in" rather than "on". - change the test driver to try all methods relevant to the element, checking they return true/false as appropriate. I decided that, rather than introducing a new tag saying which methods should match, it was clearer to use the 'expected' tag value as a description of how the element interacted with the polygons and generate the methods that should match from this and the non-matching from a list if all methods. Ticker On Thu, 2020-02-20 at 16:45 +, Ticker Berkin wrote: Hi Gerd I don't think the test data 'expected' values are wrong, it is just that they are more specific than the 'method' mechanism allows to be differentiated; eg a polygon can only be tested for ALL in or ANY in. At the moment I feel you have a reluctance about the whole concept of the methods. Once the principle is accepted, I'll go through the test data and add, as another tag, the list of methods that should match the element, then change the test driver to check that these match and the other applicable methods don't. Reg. b14: It isn't the stop-early code that causes the problems, isLineInShape is not giving the correct answer for a simple polygon produced by the MP cutter. It would be quite easy to introduce some POLYGON 'on' methods, that match the outer, inner or either edge of a polygon, but maybe this could wait until there is a call for it. Next mail: I'll change the sentence as you suggest. Please can you commit the patch as it stands; it has a lot of good stuff in it. Then I can do the IsInUtilTest and test data changes as the next stage. It's also handy to see how the Style Manual looks after each build into the download area, because I don't know how to generate it and am just guessing at the formatting. Thank you Ticker On Thu, 2020-02-20 at 15:41 +, Gerd Petermann wrote: Hi Ticker, I see that you overwrite the expected value stored in the test data in the unit test. Please don't do this. If you think that the expected value in is-in-samples.osm is wrong we should discuss the test data. In my eyes b14 clearly has points on the edge (as it is part of the edge) and is out. If you think the expected results are correct but your new code doesn't allow to test them because of the early stop code please add a new tag to each object or maybe create a new file. The unit test file is meant to document what the code does. Gerd ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Work on is_in branch
Hi Gerd Patch attached that: - rewords the sentence is the Style Manual and changes the highlighting; I need to check the next build/download to see if this is clearer. - fixes polygon 'any' method to also return true if exactly ON. - merge polygons for 'any' so that line on shared boundary is "in" rather than "on". - change the test driver to try all methods relevant to the element, checking they return true/false as appropriate. I decided that, rather than introducing a new tag saying which methods should match, it was clearer to use the 'expected' tag value as a description of how the element interacted with the polygons and generate the methods that should match from this and the non-matching from a list if all methods. Ticker On Thu, 2020-02-20 at 16:45 +, Ticker Berkin wrote: > Hi Gerd > > I don't think the test data 'expected' values are wrong, it is just > that they are more specific than the 'method' mechanism allows to be > differentiated; eg a polygon can only be tested for ALL in or ANY in. > > At the moment I feel you have a reluctance about the whole concept of > the methods. Once the principle is accepted, I'll go through the test > data and add, as another tag, the list of methods that should match > the > element, then change the test driver to check that these match and > the > other applicable methods don't. > > Reg. b14: It isn't the stop-early code that causes the problems, > isLineInShape is not giving the correct answer for a simple polygon > produced by the MP cutter. > > It would be quite easy to introduce some POLYGON 'on' methods, that > match the outer, inner or either edge of a polygon, but maybe this > could wait until there is a call for it. > > Next mail: > I'll change the sentence as you suggest. > > Please can you commit the patch as it stands; it has a lot of good > stuff in it. Then I can do the IsInUtilTest and test data changes as > the next stage. It's also handy to see how the Style Manual looks > after > each build into the download area, because I don't know how to > generate > it and am just guessing at the formatting. > > Thank you > Ticker > > On Thu, 2020-02-20 at 15:41 +, Gerd Petermann wrote: > > Hi Ticker, > > > > I see that you overwrite the expected value stored in the test data > > in the unit test. Please don't do this. If you think that the > > expected value in is-in-samples.osm > > is wrong we should discuss the test data. > > In my eyes b14 clearly has points on the edge (as it is part of the > > edge) and is out. > > > > If you think the expected results are correct but your new code > > doesn't allow to test them because of the early stop code please > > add > > a new tag to each object or maybe create a new file. The unit test > > file is meant to document what the code does. > > > > Gerd Index: doc/styles/rules.txt === --- doc/styles/rules.txt (revision 4456) +++ doc/styles/rules.txt (working copy) @@ -283,29 +283,29 @@ some element ids are changed and some have a faked id > 4611686018427387904. |is_in(tag,value,method) | x | x | | -+true+ if the element is in polygon(s) having the specified +tag+=+value+ according to the +method+, +false+ otherwise. ++true+ if the element is in polygon(s) having the specified *tag=value* according to the *method*, +false+ otherwise. The methods available depend on the Style section: -. polygons: - +all+ - all of the closed Way is within the polygon(s). - +any+ - some is within. +polygons: + *all* - all of the closed 'way' is within the polygon(s). + *any* - some is within. -. points: - +in+ - the Node is within a polygon. - +in_or_on+ - it is within or on the edge. - +on+ - it is on the edge. +points: + *in* - the 'node' is within a polygon. + *in_or_on* - it is within or on the edge. + *on* - it is on the edge. -. lines: - +all+ - part of the Way is within the polygon(s), none is outside; it might touch an edge. - +all_in_or_on+ - none is outside. - +on+ - it runs along the edge. - +any+ - part is within. - +none+ - part is outside, none is inside +lines: + *all* - part of the 'way' is within the polygon(s), none is outside; it might touch an edge. + *all_in_or_on* - none is outside. + *on* - it runs along the edge. + *any* - part is within. + *none* - part is outside, none is inside. A common case is a line outside the polygon that runs to the edge, joining a line that is inside. -The method to match an outside line (+none+) allows part to be on the edge, -likewise, the method to match an inside line (+all+) allows part to be on the edge. -The method +all_in_or_on+ additionally matches lines are only on the edge of the polygon. +The method to match an outside line (*none*) allows part to be on the edge, +likewise, the method to match an inside line (*all*) allows part to be on the edge. +Compared to *all*, the method *all_in_or_on* additionally matches lines which are only on the edge of the polygon.
Re: [mkgmap-dev] Work on is_in branch
Hi Ticker, I use GpxCreator class for debugging. It produces output pairs of files with garmin 24 bit precision as well as the highprec 30 bits. Helps a lot to understand how OSM values are rounded and were calculated points are placed when you load them in JOSM. Gerd Von: Ticker Berkin Gesendet: Donnerstag, 20. Februar 2020 18:37 An: Gerd Petermann; Development list for mkgmap Betreff: Re: AW: [mkgmap-dev] Work on is_in branch Hi Gerd Attached is a quick patch that cause b14 to give the correct answer for the 'any' method and hence pass the test; merge the 2 polygons and then it processes 1 outer, 1 hole with the expected results When my mind is up to it, I'll try and work out what happens during the isLineInShape processing. The hole after merging appears to retain the same upper and lower mid-points from the cutting and matches the line, with the values as output like (not sure what the precision is here): line [2492250/449714, 2492167/450038, 2492073/449970, 2492155/449646, 2492250/449714] ie the inner b14 polygon [2491978/449872, 2492086/449391, 2492384/449581, 2492319/449872, 2492209/449872, 2492250/449714, 2492155/449646, 2492097/449872, 2491978/449872] ie 1/2 of the MP from cutting. this gives IN|ON|OUT, should be ON|OUT hole [2492073/449970, 2492167/450038, 2492209/449872, 2492250/449714, 2492155/449646, 2492097/449872, 2492073/449970] after the java2d merging - this gives ON Ticker On Thu, 2020-02-20 at 17:04 +, Gerd Petermann wrote: > Hi Ticker, > > patch is commited. It is a bit difficult for me because you change a > lot of things and the unit test fails. > I just want to make sure that we have something testable in the end. > It is already difficult enough to understand what is documented. > > I think the tests are not always working because the result of > Coord.makeBetweenPoint is rounded. That means a point calculated with > it is typically not ON the line between the given points. A possible > solution would be to change all the code in IsInUtil to use double > values and rewrite e.g. makeBetweenPoint and the other used methods > to keep the double precision. Still, it might fail when java area > code comes in because that always uses a flat earth calculation. > When I understood that I felt indeed a bit relunctant. > > Gerd > > > Von: mkgmap-dev im Auftrag > von Ticker Berkin > Gesendet: Donnerstag, 20. Februar 2020 17:45 > An: Development list for mkgmap > Betreff: Re: [mkgmap-dev] Work on is_in branch > > Hi Gerd > > I don't think the test data 'expected' values are wrong, it is just > that they are more specific than the 'method' mechanism allows to be > differentiated; eg a polygon can only be tested for ALL in or ANY in. > > At the moment I feel you have a reluctance about the whole concept of > the methods. Once the principle is accepted, I'll go through the test > data and add, as another tag, the list of methods that should match > the > element, then change the test driver to check that these match and > the > other applicable methods don't. > > Reg. b14: It isn't the stop-early code that causes the problems, > isLineInShape is not giving the correct answer for a simple polygon > produced by the MP cutter. > > It would be quite easy to introduce some POLYGON 'on' methods, that > match the outer, inner or either edge of a polygon, but maybe this > could wait until there is a call for it. > > Next mail: > I'll change the sentence as you suggest. > > Please can you commit the patch as it stands; it has a lot of good > stuff in it. Then I can do the IsInUtilTest and test data changes as > the next stage. It's also handy to see how the Style Manual looks > after > each build into the download area, because I don't know how to > generate > it and am just guessing at the formatting. > > Thank you > Ticker ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Work on is_in branch
Hi Gerd
Attached is a quick patch that cause b14 to give the correct answer for
the 'any' method and hence pass the test; merge the 2 polygons and then
it processes 1 outer, 1 hole with the expected results
When my mind is up to it, I'll try and work out what happens during the
isLineInShape processing. The hole after merging appears to retain the
same upper and lower mid-points from the cutting and matches the line,
with the values as output like (not sure what the precision is here):
line [2492250/449714, 2492167/450038, 2492073/449970, 2492155/449646,
2492250/449714]
ie the inner b14
polygon [2491978/449872, 2492086/449391, 2492384/449581,
2492319/449872, 2492209/449872, 2492250/449714, 2492155/449646,
2492097/449872, 2491978/449872]
ie 1/2 of the MP from cutting. this gives IN|ON|OUT, should be ON|OUT
hole [2492073/449970, 2492167/450038, 2492209/449872, 2492250/449714,
2492155/449646, 2492097/449872, 2492073/449970]
after the java2d merging - this gives ON
Ticker
On Thu, 2020-02-20 at 17:04 +, Gerd Petermann wrote:
> Hi Ticker,
>
> patch is commited. It is a bit difficult for me because you change a
> lot of things and the unit test fails.
> I just want to make sure that we have something testable in the end.
> It is already difficult enough to understand what is documented.
>
> I think the tests are not always working because the result of
> Coord.makeBetweenPoint is rounded. That means a point calculated with
> it is typically not ON the line between the given points. A possible
> solution would be to change all the code in IsInUtil to use double
> values and rewrite e.g. makeBetweenPoint and the other used methods
> to keep the double precision. Still, it might fail when java area
> code comes in because that always uses a flat earth calculation.
> When I understood that I felt indeed a bit relunctant.
>
> Gerd
>
>
> Von: mkgmap-dev im Auftrag
> von Ticker Berkin
> Gesendet: Donnerstag, 20. Februar 2020 17:45
> An: Development list for mkgmap
> Betreff: Re: [mkgmap-dev] Work on is_in branch
>
> Hi Gerd
>
> I don't think the test data 'expected' values are wrong, it is just
> that they are more specific than the 'method' mechanism allows to be
> differentiated; eg a polygon can only be tested for ALL in or ANY in.
>
> At the moment I feel you have a reluctance about the whole concept of
> the methods. Once the principle is accepted, I'll go through the test
> data and add, as another tag, the list of methods that should match
> the
> element, then change the test driver to check that these match and
> the
> other applicable methods don't.
>
> Reg. b14: It isn't the stop-early code that causes the problems,
> isLineInShape is not giving the correct answer for a simple polygon
> produced by the MP cutter.
>
> It would be quite easy to introduce some POLYGON 'on' methods, that
> match the outer, inner or either edge of a polygon, but maybe this
> could wait until there is a call for it.
>
> Next mail:
> I'll change the sentence as you suggest.
>
> Please can you commit the patch as it stands; it has a lot of good
> stuff in it. Then I can do the IsInUtilTest and test data changes as
> the next stage. It's also handy to see how the Style Manual looks
> after
> each build into the download area, because I don't know how to
> generate
> it and am just guessing at the formatting.
>
> Thank you
> Ticker
Index: src/uk/me/parabola/mkgmap/osmstyle/function/IsInFunction.java
===
--- src/uk/me/parabola/mkgmap/osmstyle/function/IsInFunction.java (revision 4455)
+++ src/uk/me/parabola/mkgmap/osmstyle/function/IsInFunction.java (working copy)
@@ -66,7 +66,9 @@
POLYGON_ALL("all",FeatureKind.POLYGON, false, false, true, true)
{ @Override public boolean mapFlags(boolean hasIn, boolean hasOn, boolean hasOut) {return !hasOut;} },
- POLYGON_ANY("any",FeatureKind.POLYGON, true, false, false, false)
+// POLYGON_ANY("any",FeatureKind.POLYGON, true, false, false, false)
+// problem with test b14 on the cut polygons and isLineInShape that goes away when merged. TODO: investigate sometime
+ POLYGON_ANY("any",FeatureKind.POLYGON, true, false, false, true)
{ @Override public boolean mapFlags(boolean hasIn, boolean hasOn, boolean hasOut) {return hasIn;} };
public abstract boolean mapFlags(boolean hasIn, boolean hasOn, boolean hasOut);
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Work on is_in branch
Hi Ticker, patch is commited. It is a bit difficult for me because you change a lot of things and the unit test fails. I just want to make sure that we have something testable in the end. It is already difficult enough to understand what is documented. I think the tests are not always working because the result of Coord.makeBetweenPoint is rounded. That means a point calculated with it is typically not ON the line between the given points. A possible solution would be to change all the code in IsInUtil to use double values and rewrite e.g. makeBetweenPoint and the other used methods to keep the double precision. Still, it might fail when java area code comes in because that always uses a flat earth calculation. When I understood that I felt indeed a bit relunctant. Gerd Von: mkgmap-dev im Auftrag von Ticker Berkin Gesendet: Donnerstag, 20. Februar 2020 17:45 An: Development list for mkgmap Betreff: Re: [mkgmap-dev] Work on is_in branch Hi Gerd I don't think the test data 'expected' values are wrong, it is just that they are more specific than the 'method' mechanism allows to be differentiated; eg a polygon can only be tested for ALL in or ANY in. At the moment I feel you have a reluctance about the whole concept of the methods. Once the principle is accepted, I'll go through the test data and add, as another tag, the list of methods that should match the element, then change the test driver to check that these match and the other applicable methods don't. Reg. b14: It isn't the stop-early code that causes the problems, isLineInShape is not giving the correct answer for a simple polygon produced by the MP cutter. It would be quite easy to introduce some POLYGON 'on' methods, that match the outer, inner or either edge of a polygon, but maybe this could wait until there is a call for it. Next mail: I'll change the sentence as you suggest. Please can you commit the patch as it stands; it has a lot of good stuff in it. Then I can do the IsInUtilTest and test data changes as the next stage. It's also handy to see how the Style Manual looks after each build into the download area, because I don't know how to generate it and am just guessing at the formatting. Thank you Ticker On Thu, 2020-02-20 at 15:41 +, Gerd Petermann wrote: > Hi Ticker, > > I see that you overwrite the expected value stored in the test data > in the unit test. Please don't do this. If you think that the > expected value in is-in-samples.osm > is wrong we should discuss the test data. > In my eyes b14 clearly has points on the edge (as it is part of the > edge) and is out. > > If you think the expected results are correct but your new code > doesn't allow to test them because of the early stop code please add > a new tag to each object or maybe create a new file. The unit test > file is meant to document what the code does. > > Gerd > > > Von: mkgmap-dev im Auftrag > von Ticker Berkin > Gesendet: Donnerstag, 20. Februar 2020 14:11 > An: Development list for mkgmap > Betreff: Re: [mkgmap-dev] Work on is_in branch > > Hi Gerd > > Here is a replacement for is_in-function_v10.patch with the > additions: > > - method ..,none)=true to replace ..,any_in_or_on)=false. > > - revised documentation. > > - detection of holes within the rule.polygon. Will set OUT, ie stop > 'all' being true, and, if exactly ON, not set IN, ie stop 'any' being > true. > > - removal the kind parameters and related logic from IsInUtil; the > IsInFunction driver has better understanding of how POLYGON > processing > should differ from POLYLINE. > > - restructure the MethodArg enum to include all the method dependent > logic. > > Test case b14 (rule.polygon being the hole in the multiPolygon) > should be OUT, or maybe OUT|ON but the test driver only understands > ALL > or ANY for polygons. It still fails because isLineInShape returns > IN|ON|OUT for the rule.polygon against one of the cut simple > polygons, > where it should be ON|OUT > > Ticker > > On Tue, 2020-02-18 at 00:23 -0700, Gerd Petermann wrote: > > Ticker Berkin wrote > > > I suggest replacing ANY_IN_OR_ON with SOME_OUT_NONE_IN, giving it > > > the > > > method string "none", like SOME_IN_NONE_OUT is referenced as > > > "all". > > > > Yes, much better. > > > > Gerd > > > > > > > > > > -- > > Sent from: > > http://gis.19327.n8.nabble.com/Mkgmap-Development-f5324443.html > > ___ > > 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] Work on is_in branch
Hi Gerd I don't think the test data 'expected' values are wrong, it is just that they are more specific than the 'method' mechanism allows to be differentiated; eg a polygon can only be tested for ALL in or ANY in. At the moment I feel you have a reluctance about the whole concept of the methods. Once the principle is accepted, I'll go through the test data and add, as another tag, the list of methods that should match the element, then change the test driver to check that these match and the other applicable methods don't. Reg. b14: It isn't the stop-early code that causes the problems, isLineInShape is not giving the correct answer for a simple polygon produced by the MP cutter. It would be quite easy to introduce some POLYGON 'on' methods, that match the outer, inner or either edge of a polygon, but maybe this could wait until there is a call for it. Next mail: I'll change the sentence as you suggest. Please can you commit the patch as it stands; it has a lot of good stuff in it. Then I can do the IsInUtilTest and test data changes as the next stage. It's also handy to see how the Style Manual looks after each build into the download area, because I don't know how to generate it and am just guessing at the formatting. Thank you Ticker On Thu, 2020-02-20 at 15:41 +, Gerd Petermann wrote: > Hi Ticker, > > I see that you overwrite the expected value stored in the test data > in the unit test. Please don't do this. If you think that the > expected value in is-in-samples.osm > is wrong we should discuss the test data. > In my eyes b14 clearly has points on the edge (as it is part of the > edge) and is out. > > If you think the expected results are correct but your new code > doesn't allow to test them because of the early stop code please add > a new tag to each object or maybe create a new file. The unit test > file is meant to document what the code does. > > Gerd > > > Von: mkgmap-dev im Auftrag > von Ticker Berkin > Gesendet: Donnerstag, 20. Februar 2020 14:11 > An: Development list for mkgmap > Betreff: Re: [mkgmap-dev] Work on is_in branch > > Hi Gerd > > Here is a replacement for is_in-function_v10.patch with the > additions: > > - method ..,none)=true to replace ..,any_in_or_on)=false. > > - revised documentation. > > - detection of holes within the rule.polygon. Will set OUT, ie stop > 'all' being true, and, if exactly ON, not set IN, ie stop 'any' being > true. > > - removal the kind parameters and related logic from IsInUtil; the > IsInFunction driver has better understanding of how POLYGON > processing > should differ from POLYLINE. > > - restructure the MethodArg enum to include all the method dependent > logic. > > Test case b14 (rule.polygon being the hole in the multiPolygon) > should be OUT, or maybe OUT|ON but the test driver only understands > ALL > or ANY for polygons. It still fails because isLineInShape returns > IN|ON|OUT for the rule.polygon against one of the cut simple > polygons, > where it should be ON|OUT > > Ticker > > On Tue, 2020-02-18 at 00:23 -0700, Gerd Petermann wrote: > > Ticker Berkin wrote > > > I suggest replacing ANY_IN_OR_ON with SOME_OUT_NONE_IN, giving it > > > the > > > method string "none", like SOME_IN_NONE_OUT is referenced as > > > "all". > > > > Yes, much better. > > > > Gerd > > > > > > > > > > -- > > Sent from: > > http://gis.19327.n8.nabble.com/Mkgmap-Development-f5324443.html > > ___ > > 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] Work on is_in branch
Hi Ticker, sorry, presssed send too early. Reg. documentation: I think it is logically correct now :) I think the sentence "The method +all_in_or_on+ additionally matches lines are only on the edge of the polygon." should be changed to "Compared to +all+ the method +all_in_or_on+ additionally matches lines which are only on the edge of the polygon." Gerd Von: mkgmap-dev im Auftrag von Gerd Petermann Gesendet: Donnerstag, 20. Februar 2020 16:41 An: Ticker Berkin; Development list for mkgmap Betreff: Re: [mkgmap-dev] Work on is_in branch Hi Ticker, I see that you overwrite the expected value stored in the test data in the unit test. Please don't do this. If you think that the expected value in is-in-samples.osm is wrong we should discuss the test data. In my eyes b14 clearly has points on the edge (as it is part of the edge) and is out. If you think the expected results are correct but your new code doesn't allow to test them because of the early stop code please add a new tag to each object or maybe create a new file. The unit test file is meant to document what the code does. Gerd Von: mkgmap-dev im Auftrag von Ticker Berkin Gesendet: Donnerstag, 20. Februar 2020 14:11 An: Development list for mkgmap Betreff: Re: [mkgmap-dev] Work on is_in branch Hi Gerd Here is a replacement for is_in-function_v10.patch with the additions: - method ..,none)=true to replace ..,any_in_or_on)=false. - revised documentation. - detection of holes within the rule.polygon. Will set OUT, ie stop 'all' being true, and, if exactly ON, not set IN, ie stop 'any' being true. - removal the kind parameters and related logic from IsInUtil; the IsInFunction driver has better understanding of how POLYGON processing should differ from POLYLINE. - restructure the MethodArg enum to include all the method dependent logic. Test case b14 (rule.polygon being the hole in the multiPolygon) should be OUT, or maybe OUT|ON but the test driver only understands ALL or ANY for polygons. It still fails because isLineInShape returns IN|ON|OUT for the rule.polygon against one of the cut simple polygons, where it should be ON|OUT Ticker On Tue, 2020-02-18 at 00:23 -0700, Gerd Petermann wrote: > Ticker Berkin wrote > > I suggest replacing ANY_IN_OR_ON with SOME_OUT_NONE_IN, giving it > > the > > method string "none", like SOME_IN_NONE_OUT is referenced as "all". > > Yes, much better. > > Gerd > > > > > -- > Sent from: > http://gis.19327.n8.nabble.com/Mkgmap-Development-f5324443.html > ___ > 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] Work on is_in branch
Hi Ticker, I see that you overwrite the expected value stored in the test data in the unit test. Please don't do this. If you think that the expected value in is-in-samples.osm is wrong we should discuss the test data. In my eyes b14 clearly has points on the edge (as it is part of the edge) and is out. If you think the expected results are correct but your new code doesn't allow to test them because of the early stop code please add a new tag to each object or maybe create a new file. The unit test file is meant to document what the code does. Gerd Von: mkgmap-dev im Auftrag von Ticker Berkin Gesendet: Donnerstag, 20. Februar 2020 14:11 An: Development list for mkgmap Betreff: Re: [mkgmap-dev] Work on is_in branch Hi Gerd Here is a replacement for is_in-function_v10.patch with the additions: - method ..,none)=true to replace ..,any_in_or_on)=false. - revised documentation. - detection of holes within the rule.polygon. Will set OUT, ie stop 'all' being true, and, if exactly ON, not set IN, ie stop 'any' being true. - removal the kind parameters and related logic from IsInUtil; the IsInFunction driver has better understanding of how POLYGON processing should differ from POLYLINE. - restructure the MethodArg enum to include all the method dependent logic. Test case b14 (rule.polygon being the hole in the multiPolygon) should be OUT, or maybe OUT|ON but the test driver only understands ALL or ANY for polygons. It still fails because isLineInShape returns IN|ON|OUT for the rule.polygon against one of the cut simple polygons, where it should be ON|OUT Ticker On Tue, 2020-02-18 at 00:23 -0700, Gerd Petermann wrote: > Ticker Berkin wrote > > I suggest replacing ANY_IN_OR_ON with SOME_OUT_NONE_IN, giving it > > the > > method string "none", like SOME_IN_NONE_OUT is referenced as "all". > > Yes, much better. > > Gerd > > > > > -- > Sent from: > http://gis.19327.n8.nabble.com/Mkgmap-Development-f5324443.html > ___ > 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] Work on is_in branch
Hi Gerd
Here is a replacement for is_in-function_v10.patch with the additions:
- method ..,none)=true to replace ..,any_in_or_on)=false.
- revised documentation.
- detection of holes within the rule.polygon. Will set OUT, ie stop
'all' being true, and, if exactly ON, not set IN, ie stop 'any' being
true.
- removal the kind parameters and related logic from IsInUtil; the
IsInFunction driver has better understanding of how POLYGON processing
should differ from POLYLINE.
- restructure the MethodArg enum to include all the method dependent
logic.
Test case b14 (rule.polygon being the hole in the multiPolygon)
should be OUT, or maybe OUT|ON but the test driver only understands ALL
or ANY for polygons. It still fails because isLineInShape returns
IN|ON|OUT for the rule.polygon against one of the cut simple polygons,
where it should be ON|OUT
Ticker
On Tue, 2020-02-18 at 00:23 -0700, Gerd Petermann wrote:
> Ticker Berkin wrote
> > I suggest replacing ANY_IN_OR_ON with SOME_OUT_NONE_IN, giving it
> > the
> > method string "none", like SOME_IN_NONE_OUT is referenced as "all".
>
> Yes, much better.
>
> Gerd
>
>
>
>
> --
> Sent from:
> http://gis.19327.n8.nabble.com/Mkgmap-Development-f5324443.html
> ___
> mkgmap-dev mailing list
> mkgmap-dev@lists.mkgmap.org.uk
> http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-devIndex: doc/styles/rules.txt
===
--- doc/styles/rules.txt (revision 4453)
+++ doc/styles/rules.txt (working copy)
@@ -286,21 +286,26 @@
+true+ if the element is in polygon(s) having the specified +tag+=+value+ according to the +method+, +false+ otherwise.
The methods available depend on the Style section:
-* points:
+. polygons:
+ +all+ - all of the closed Way is within the polygon(s).
+ +any+ - some is within.
+
+. points:
+in+ - the Node is within a polygon.
+in_or_on+ - it is within or on the edge.
+on+ - it is on the edge.
-* lines:
+. lines:
+all+ - part of the Way is within the polygon(s), none is outside; it might touch an edge.
- +all_in_or_on+ - none is outside. This is useful for the negative - is_in(...,all_in_or_on)=false - for processing a line that is outside the polgon(s).
+ +all_in_or_on+ - none is outside.
+on+ - it runs along the edge.
+any+ - part is within.
- +any_in_or_on+ - part is within or in the edge.
+ +none+ - part is outside, none is inside
-* polygons:
- +all+ - all of the closed Way is within the polygon(s).
- +any+ - some is within.
+A common case is a line outside the polygon that runs to the edge, joining a line that is inside.
+The method to match an outside line (+none+) allows part to be on the edge,
+likewise, the method to match an inside line (+all+) allows part to be on the edge.
+The method +all_in_or_on+ additionally matches lines are only on the edge of the polygon.
|
Index: src/uk/me/parabola/mkgmap/osmstyle/function/IsInFunction.java
===
--- src/uk/me/parabola/mkgmap/osmstyle/function/IsInFunction.java (revision 4453)
+++ src/uk/me/parabola/mkgmap/osmstyle/function/IsInFunction.java (working copy)
@@ -43,19 +43,33 @@
private enum MethodArg {
- // can stop when: IN ON OUT
- POINT_IN("in",FeatureKind.POINT,true, false, false),
- POINT_IN_OR_ON("in_or_on",FeatureKind.POINT,true, true, false),
- POINT_ON("on",FeatureKind.POINT,false, true, false),
+ // can stop when: IN ON OUTMERGE
+ POINT_IN("in",FeatureKind.POINT,true, false, false, true)
+ { @Override public boolean mapFlags(boolean hasIn, boolean hasOn, boolean hasOut) {return hasIn;} },
+ POINT_IN_OR_ON("in_or_on",FeatureKind.POINT,true, true, false, false)
+ { @Override public boolean mapFlags(boolean hasIn, boolean hasOn, boolean hasOut) {return hasIn || hasOn;} },
+ POINT_ON("on",FeatureKind.POINT,false, true, false, true)
+ { @Override public boolean mapFlags(boolean hasIn, boolean hasOn, boolean hasOut) {return hasOn;} },
- LINE_SOME_IN_NONE_OUT("all", FeatureKind.POLYLINE, false, false, true),
- LINE_ALL_IN_OR_ON("all_in_or_on", FeatureKind.POLYLINE, false, false, true),
- LINE_ALL_ON("on", FeatureKind.POLYLINE, true, false, true),
- LINE_ANY_IN("any",FeatureKind.POLYLINE, true, false, false),
- LINE_ANY_IN_OR_ON("any_in_or_on", FeatureKind.POLYLINE, true, true, false),
+ LINE_SOME_IN_NONE_OUT("all", FeatureKind.POLYLINE, false, false, true, true)
+ { @Override public boolean mapFlags(boolean hasIn, boolean hasOn, boolean hasOut) {return hasIn && !hasOut;} },
+ LINE_ALL_IN_OR_ON("all_in_or_on", FeatureKind.POLYLINE, false, false, true, true)
+ { @Override public boolean mapFlags(boolean
Re: [mkgmap-dev] Work on is_in branch
Hi Gerd Part of the reason for the methods is to group the IN/ON/OUT cases together in various combinations for meaningful usability. In IsInUtilTest.java is the table (for the sake of brevity, using 'camel' notation rather than underscores as in the actual method keyword): /* all=someInNoneOut, any=anyIn, none=someOutNoneIn a) INall allInOrOnany b) IN ON all allInOrOnany c) IN ON OUT any d)ON allInOrOn on e)ON OUT none f) OUT none */ So the difference between ..,all)=true and ..,none)=false is what happens to cases c) and d). The methods "any", "on" and "allInOrOn" include these cases. Obvious and sensible for the meaning of "any" and "on", "allInOrOn" is a bit arbritary, but the idea is that a perimeter line can be picked up along with the inside lines in one test if that is what is wanted. I didn't think there was a need to pick up a perimeter line with the outside lines, but this could be added easily. Ticker On Tue, 2020-02-18 at 00:28 -0700, Gerd Petermann wrote: > Gerd Petermann wrote > > Ticker Berkin wrote > > > I suggest replacing ANY_IN_OR_ON with SOME_OUT_NONE_IN, giving it > > > the > > > method string "none", like SOME_IN_NONE_OUT is referenced as > > > "all". > > > > Yes, much better. > > Thinking again about it. What would be the difference between > is_in(..all)=true and is_in(..none)=false? > > My understanding is that we want to distinguish 5 or 6 cases. Three > methods > returning true or false should be enough for that. > > Gerd > > > > -- > Sent from: > http://gis.19327.n8.nabble.com/Mkgmap-Development-f5324443.html > ___ > 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] Work on is_in branch
Gerd Petermann wrote > Ticker Berkin wrote >> I suggest replacing ANY_IN_OR_ON with SOME_OUT_NONE_IN, giving it the >> method string "none", like SOME_IN_NONE_OUT is referenced as "all". > > Yes, much better. Thinking again about it. What would be the difference between is_in(..all)=true and is_in(..none)=false? My understanding is that we want to distinguish 5 or 6 cases. Three methods returning true or false should be enough for that. Gerd -- Sent from: http://gis.19327.n8.nabble.com/Mkgmap-Development-f5324443.html ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Work on is_in branch
Ticker Berkin wrote > I suggest replacing ANY_IN_OR_ON with SOME_OUT_NONE_IN, giving it the > method string "none", like SOME_IN_NONE_OUT is referenced as "all". Yes, much better. Gerd -- Sent from: http://gis.19327.n8.nabble.com/Mkgmap-Development-f5324443.html ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Work on is_in branch
Hi Gerd The two most common cases that I imagine users will want to match are lines inside the polygon(s) and lines outside. Inside lines will frequently meet the edge, and I don't think these should fail the inside test. Outside lines will, less frequently, meet the edge, and I don't think these should fail the outside test. Often there will be 2 lines, joining at edge of the polygon, that make a continuous highway that is the entrance to the polygon. Both of these will have an ON component. So, the flag test for inside lines should be "hasIn && !hasOut" and for outside lines should be "hasOut && !hasIn". Expressing the outside test as the negative, in keeping with the is_in() methods expressing in-ness, it becomes "hasIn || !hasOut". I had expressed this as "hasIn || !(hasIn || hasOut)", because "!(hasIn || hasOut)" is all_ON, and this matches the method being called, ambiguously, ANY_IN_OR_ON (ON_OR_ANY_IN would have been better) but they are logically equivalent. This expressing as in-ness seems to be the cause of these problems we are discussing and maybe now is the time to abandon it. I suggest replacing ANY_IN_OR_ON with SOME_OUT_NONE_IN, giving it the method string "none", like SOME_IN_NONE_OUT is referenced as "all". Ticker On Mon, 2020-02-17 at 19:16 +, Gerd Petermann wrote: > Hi Ticker, > > I would except > +any_in_or_on+ - if is_in(...,any_in_or_on)=false, all is outside, > none is in or on the edge. > > Or name it > +all_out+ - if is_in(...,all_out)=true, all is outside, none is in or > on the edge. > > A method that returns true when all is either out or on the edge > could be called > +out-or-on+ > > Gerd ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Work on is_in branch
Hi Ticker, I would except +any_in_or_on+ - if is_in(...,any_in_or_on)=false, all is outside, none is in or on the edge. Or name it +all_out+ - if is_in(...,all_out)=true, all is outside, none is in or on the edge. A method that returns true when all is either out or on the edge could be called +out-or-on+ Gerd Von: mkgmap-dev im Auftrag von Ticker Berkin Gesendet: Montag, 17. Februar 2020 19:11 An: Development list for mkgmap Betreff: Re: [mkgmap-dev] Work on is_in branch Hi Gerd A simpler way of expressing it in the Style Manual would be: +any_in_or_on+ - if is_in(...,any_in_or_on)=false, part is outside, none is inside. What do you think? An alternative would be to re-phrase the keyword as something like 'some-out-none-in', testing for =true instead. But, with the function being called 'is_in', I wanted to have the methods expressing IN'ness as far as possible. Rec. early-stop. It has ~4% improvement for 'any' in my scenario, ~2.5% for 'on' and ~1% for all. It just seems easy and sensible to stop when, if asking for 'any', a part is found IN, or, if asking for 'all', a part is found OUT, etc Ticker On Mon, 2020-02-17 at 17:13 +, Gerd Petermann wrote: > Hi Ticker, > > reg. result: > Please find a better explanation for this: > "This is useful for the negative - is_in(...,any_in_or_on)=false - > for processing a line that is outside the polgon(s) but might touch > an edge." > For me this sounds plain wrong. It would be okay without "but might > touch an edge". > > reg. performance: > I did not mean to remove early stop completely, I just don't believe > that it is worth to distinguish the different methods. > My original code also stops early when result is 7 (IN+ON+OUT). > > reg. special case b14: one reason why I don't like my code. It's > frustrating. OTOH nobody seems to care about the results for > polygons. > > Gerd ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Work on is_in branch
Hi Gerd A simpler way of expressing it in the Style Manual would be: +any_in_or_on+ - if is_in(...,any_in_or_on)=false, part is outside, none is inside. What do you think? An alternative would be to re-phrase the keyword as something like 'some-out-none-in', testing for =true instead. But, with the function being called 'is_in', I wanted to have the methods expressing IN'ness as far as possible. Rec. early-stop. It has ~4% improvement for 'any' in my scenario, ~2.5% for 'on' and ~1% for all. It just seems easy and sensible to stop when, if asking for 'any', a part is found IN, or, if asking for 'all', a part is found OUT, etc Ticker On Mon, 2020-02-17 at 17:13 +, Gerd Petermann wrote: > Hi Ticker, > > reg. result: > Please find a better explanation for this: > "This is useful for the negative - is_in(...,any_in_or_on)=false - > for processing a line that is outside the polgon(s) but might touch > an edge." > For me this sounds plain wrong. It would be okay without "but might > touch an edge". > > reg. performance: > I did not mean to remove early stop completely, I just don't believe > that it is worth to distinguish the different methods. > My original code also stops early when result is 7 (IN+ON+OUT). > > reg. special case b14: one reason why I don't like my code. It's > frustrating. OTOH nobody seems to care about the results for > polygons. > > Gerd ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Work on is_in branch
Hi Ticker,
reg. result:
Please find a better explanation for this:
"This is useful for the negative - is_in(...,any_in_or_on)=false - for
processing a line that is outside the polgon(s) but might touch an edge."
For me this sounds plain wrong. It would be okay without "but might touch an
edge".
reg. performance:
I did not mean to remove early stop completely, I just don't believe that it is
worth to distinguish the different methods.
My original code also stops early when result is 7 (IN+ON+OUT).
reg. special case b14: one reason why I don't like my code. It's frustrating.
OTOH nobody seems to care about the results for polygons.
Gerd
Von: mkgmap-dev im Auftrag von Ticker
Berkin
Gesendet: Montag, 17. Februar 2020 15:57
An: Development list for mkgmap
Betreff: Re: [mkgmap-dev] Work on is_in branch
Hi Gerd
The new meaning of any_in_or_on is for handing a line where some is
OUT, none is IN and touching the edge is irrelevant and is tested as
()=false, with the +ve logic being "some-IN or all-ON". Can't stop on
ON because need to have IN component.
This was the the meaning I had originally intended, but at some point
forgot. It is the reciprocal of the method for a line where some is IN
and touching the edge makes no difference.
Various timing tests on a 2 tile area with max-jobs=1, my normal
options and a function invocation in lines.
These are with my latest code:
highway=* & length()<200 {add maxspeed="20 mph"}
Total time taken: 1 minute 12 seconds
highway=* & is_in(landuse,residential,any)=true {add maxspeed="20 mph"}
Total time taken: 1 minute 14 seconds
..., all)...
Total time taken: 1 minute 23 seconds
..., on)...
Total time taken: 1 minute 21 seconds
Taking out the automatic "stop early" code, timings are:
highway=* & is_in(landuse,residential,any)=true {add maxspeed="20 mph"}
Total time taken: 1 minute 17 seconds
..., all)...
Total time taken: 1 minute 24 seconds
..., on)...
Total time taken: 1 minute 23 seconds
ie the "stop-early" gives a slight improvement for "all"/"on" and a bigger
improvement for "any"
I feel the "stop-early" mechanism is well hidden from the much more complex
coding of isLineInShape() and how the results of this should be interpreted
with multiple shapes and holes, etc, and so it is worth-while.
I'm getting strange results for b14 just from the 2 parts of the outer after MP
cutting, without the Java2D logic in mergePolygons being invoked. I'll
investigate.
Ticker
On Mon, 2020-02-17 at 11:33 +, Gerd Petermann wrote:
> Hi Ticker,
>
> I don't understand the new meaning of any_in_or_on. Why can't you
> stop early when ON was found?
>
> I still think that the "stop early" code is just adding complexity.
> Do you have a sample that shows how this improves performance?
>
> Reg. unexpected results when joining shapes: Welcome to the club!
> Some not so obvious things:
> - The java area code sometimes removes points which are on straight
> lines.
> - a node calculated with e.g. makeBetweenPoint is only very close to
> the place where it should be
>
> Gerd
>
> ________
> Von: mkgmap-dev im Auftrag
> von Ticker Berkin
> Gesendet: Montag, 17. Februar 2020 11:31
> An: Development list for mkgmap
> Betreff: Re: [mkgmap-dev] Work on is_in branch
>
> Hi Gerd
>
> Here is patch with:
> - IsInUtilTest driver using the is_in function with methods.
> - a slight re-formulation to the 'any_in_or_in' method.
> - updates to style manual for above.
> - some fixes and improvements relating to holes, ON etc.
>
> There is one more bit of logic that is needed for polygons: after the
> polygon has been found to be fully within a shape, and it isn't in a
> hole, check that a hole isn't within it. I'll so this in the next day
> or so.
>
> I'm having trouble with b14 (building is inner to a multi-polygon):
> Without merging the cut outer, isLineInShape for the b14 polygon
> returns IN/ON/OUT for the first component - I was expecting ON/OUT.
> With merging, it returns IN for the merged shape (good), but IN/ON
> for
> the hole - I was expecting ON.
>
> Ticker
>
> On Wed, 2020-02-12 at 15:55 +, Gerd Petermann wrote:
> > Hi Ticker,
> >
> > I found it difficult to test the real style function, that's why I
> > moved all the logic out of it.
> > I am looking forward to your solution.
> >
> > Gerd
> >
> >
> > Von: mkgmap-dev im Auftrag
> > von Ticker Berkin
> > Gesendet: Mittwoch, 12. Februar 2020 16:47
> > An: Development list for mkgmap
> > Betreff: Re: [mkgmap-dev] Work on is_in branch
Re: [mkgmap-dev] Work on is_in branch
Hi Gerd
The new meaning of any_in_or_on is for handing a line where some is
OUT, none is IN and touching the edge is irrelevant and is tested as
()=false, with the +ve logic being "some-IN or all-ON". Can't stop on
ON because need to have IN component.
This was the the meaning I had originally intended, but at some point
forgot. It is the reciprocal of the method for a line where some is IN
and touching the edge makes no difference.
Various timing tests on a 2 tile area with max-jobs=1, my normal
options and a function invocation in lines.
These are with my latest code:
highway=* & length()<200 {add maxspeed="20 mph"}
Total time taken: 1 minute 12 seconds
highway=* & is_in(landuse,residential,any)=true {add maxspeed="20 mph"}
Total time taken: 1 minute 14 seconds
..., all)...
Total time taken: 1 minute 23 seconds
..., on)...
Total time taken: 1 minute 21 seconds
Taking out the automatic "stop early" code, timings are:
highway=* & is_in(landuse,residential,any)=true {add maxspeed="20 mph"}
Total time taken: 1 minute 17 seconds
..., all)...
Total time taken: 1 minute 24 seconds
..., on)...
Total time taken: 1 minute 23 seconds
ie the "stop-early" gives a slight improvement for "all"/"on" and a bigger
improvement for "any"
I feel the "stop-early" mechanism is well hidden from the much more complex
coding of isLineInShape() and how the results of this should be interpreted
with multiple shapes and holes, etc, and so it is worth-while.
I'm getting strange results for b14 just from the 2 parts of the outer after MP
cutting, without the Java2D logic in mergePolygons being invoked. I'll
investigate.
Ticker
On Mon, 2020-02-17 at 11:33 +, Gerd Petermann wrote:
> Hi Ticker,
>
> I don't understand the new meaning of any_in_or_on. Why can't you
> stop early when ON was found?
>
> I still think that the "stop early" code is just adding complexity.
> Do you have a sample that shows how this improves performance?
>
> Reg. unexpected results when joining shapes: Welcome to the club!
> Some not so obvious things:
> - The java area code sometimes removes points which are on straight
> lines.
> - a node calculated with e.g. makeBetweenPoint is only very close to
> the place where it should be
>
> Gerd
>
> ____________________
> Von: mkgmap-dev im Auftrag
> von Ticker Berkin
> Gesendet: Montag, 17. Februar 2020 11:31
> An: Development list for mkgmap
> Betreff: Re: [mkgmap-dev] Work on is_in branch
>
> Hi Gerd
>
> Here is patch with:
> - IsInUtilTest driver using the is_in function with methods.
> - a slight re-formulation to the 'any_in_or_in' method.
> - updates to style manual for above.
> - some fixes and improvements relating to holes, ON etc.
>
> There is one more bit of logic that is needed for polygons: after the
> polygon has been found to be fully within a shape, and it isn't in a
> hole, check that a hole isn't within it. I'll so this in the next day
> or so.
>
> I'm having trouble with b14 (building is inner to a multi-polygon):
> Without merging the cut outer, isLineInShape for the b14 polygon
> returns IN/ON/OUT for the first component - I was expecting ON/OUT.
> With merging, it returns IN for the merged shape (good), but IN/ON
> for
> the hole - I was expecting ON.
>
> Ticker
>
> On Wed, 2020-02-12 at 15:55 +, Gerd Petermann wrote:
> > Hi Ticker,
> >
> > I found it difficult to test the real style function, that's why I
> > moved all the logic out of it.
> > I am looking forward to your solution.
> >
> > Gerd
> >
> >
> > Von: mkgmap-dev im Auftrag
> > von Ticker Berkin
> > Gesendet: Mittwoch, 12. Februar 2020 16:47
> > An: Development list for mkgmap
> > Betreff: Re: [mkgmap-dev] Work on is_in branch
> >
> > Hi Gerd
> >
> > The re-structuring makes this difficult.
> >
> > I propose a function in IsInUtilTest with the same interface as
> > calcInsideness from IsInUtil that somehow drives the real function
> > IsIn
> > Function to collect and build the IN/ON/OUT intflag.
> >
> > Ticker
> >
> > On Wed, 2020-02-12 at 15:28 +, Gerd Petermann wrote:
> > > Hi Ticker,
> > >
> > > did you run the unit tests? This should download a newer version
> > > of
> > > the samples.
> > >
> > > Gerd
> > >
> > >
> > > Von: mkgmap-dev im
> > > Auftrag
> > > von Ticker Berkin
> > > Gesendet: Mittwoch, 12. Februar 2020 16:23
> >
Re: [mkgmap-dev] Work on is_in branch
Hi Ticker, I don't understand the new meaning of any_in_or_on. Why can't you stop early when ON was found? I still think that the "stop early" code is just adding complexity. Do you have a sample that shows how this improves performance? Reg. unexpected results when joining shapes: Welcome to the club! Some not so obvious things: - The java area code sometimes removes points which are on straight lines. - a node calculated with e.g. makeBetweenPoint is only very close to the place where it should be Gerd Von: mkgmap-dev im Auftrag von Ticker Berkin Gesendet: Montag, 17. Februar 2020 11:31 An: Development list for mkgmap Betreff: Re: [mkgmap-dev] Work on is_in branch Hi Gerd Here is patch with: - IsInUtilTest driver using the is_in function with methods. - a slight re-formulation to the 'any_in_or_in' method. - updates to style manual for above. - some fixes and improvements relating to holes, ON etc. There is one more bit of logic that is needed for polygons: after the polygon has been found to be fully within a shape, and it isn't in a hole, check that a hole isn't within it. I'll so this in the next day or so. I'm having trouble with b14 (building is inner to a multi-polygon): Without merging the cut outer, isLineInShape for the b14 polygon returns IN/ON/OUT for the first component - I was expecting ON/OUT. With merging, it returns IN for the merged shape (good), but IN/ON for the hole - I was expecting ON. Ticker On Wed, 2020-02-12 at 15:55 +, Gerd Petermann wrote: > Hi Ticker, > > I found it difficult to test the real style function, that's why I > moved all the logic out of it. > I am looking forward to your solution. > > Gerd > > > Von: mkgmap-dev im Auftrag > von Ticker Berkin > Gesendet: Mittwoch, 12. Februar 2020 16:47 > An: Development list for mkgmap > Betreff: Re: [mkgmap-dev] Work on is_in branch > > Hi Gerd > > The re-structuring makes this difficult. > > I propose a function in IsInUtilTest with the same interface as > calcInsideness from IsInUtil that somehow drives the real function > IsIn > Function to collect and build the IN/ON/OUT intflag. > > Ticker > > On Wed, 2020-02-12 at 15:28 +, Gerd Petermann wrote: > > Hi Ticker, > > > > did you run the unit tests? This should download a newer version of > > the samples. > > > > Gerd > > > > > > Von: mkgmap-dev im Auftrag > > von Ticker Berkin > > Gesendet: Mittwoch, 12. Februar 2020 16:23 > > An: Development list for mkgmap > > Betreff: Re: [mkgmap-dev] Work on is_in branch > > > > Hi Gerd > > > > Here it is - changes are: > > > > - Some restructuring with early stopping where possible. > > > > - Merging polygons for POINT IN/ON test so a point on shared > > boundary > > becomes IN rather than ON. > > > > - Not merging polygons when no need. > > > > - Make the function cacheable, so that there is negligible cost to > > the > > second call: > > highway=path & is_in(landuse, residential, all)=true [0xAA] > > highway=path & is_in(landuse, residential, all)=false [0xBB] > > > > - Improved the layout of documentation in the Style Manual. > > > > - Fixed quite a few problems. > > > > I've left quite a lot of debug in for the moment, I think there > > will > > still be work to do. > > > > It gives correct answers to 'point-on.osm'. I haven't worked > > through > > is > > -in-hook-sample-v3.osm yet because I wanted to get this revision > > out > > to > > replace faults in the previous versions. > > > > Ticker > > > > On Tue, 2020-02-11 at 15:49 +, Gerd Petermann wrote: > > > Hi Ticker, > > > > > > whatever you plan to do. I moved the code to the lib because it > > > is > > > easier to write a unit test. > > > I would not invest much time to avoid a few tests which only > > > happen > > > in very rare cases. Makes testing more complicated and code less > > > readable. > > > > > > Gerd > ___ > mkgmap-dev mailing list > mkgmap-dev@lists.mkgmap.org.uk > http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Work on is_in branch
Hi Gerd Here is patch with: - IsInUtilTest driver using the is_in function with methods. - a slight re-formulation to the 'any_in_or_in' method. - updates to style manual for above. - some fixes and improvements relating to holes, ON etc. There is one more bit of logic that is needed for polygons: after the polygon has been found to be fully within a shape, and it isn't in a hole, check that a hole isn't within it. I'll so this in the next day or so. I'm having trouble with b14 (building is inner to a multi-polygon): Without merging the cut outer, isLineInShape for the b14 polygon returns IN/ON/OUT for the first component - I was expecting ON/OUT. With merging, it returns IN for the merged shape (good), but IN/ON for the hole - I was expecting ON. Ticker On Wed, 2020-02-12 at 15:55 +, Gerd Petermann wrote: > Hi Ticker, > > I found it difficult to test the real style function, that's why I > moved all the logic out of it. > I am looking forward to your solution. > > Gerd > > > Von: mkgmap-dev im Auftrag > von Ticker Berkin > Gesendet: Mittwoch, 12. Februar 2020 16:47 > An: Development list for mkgmap > Betreff: Re: [mkgmap-dev] Work on is_in branch > > Hi Gerd > > The re-structuring makes this difficult. > > I propose a function in IsInUtilTest with the same interface as > calcInsideness from IsInUtil that somehow drives the real function > IsIn > Function to collect and build the IN/ON/OUT intflag. > > Ticker > > On Wed, 2020-02-12 at 15:28 +, Gerd Petermann wrote: > > Hi Ticker, > > > > did you run the unit tests? This should download a newer version of > > the samples. > > > > Gerd > > > > > > Von: mkgmap-dev im Auftrag > > von Ticker Berkin > > Gesendet: Mittwoch, 12. Februar 2020 16:23 > > An: Development list for mkgmap > > Betreff: Re: [mkgmap-dev] Work on is_in branch > > > > Hi Gerd > > > > Here it is - changes are: > > > > - Some restructuring with early stopping where possible. > > > > - Merging polygons for POINT IN/ON test so a point on shared > > boundary > > becomes IN rather than ON. > > > > - Not merging polygons when no need. > > > > - Make the function cacheable, so that there is negligible cost to > > the > > second call: > > highway=path & is_in(landuse, residential, all)=true [0xAA] > > highway=path & is_in(landuse, residential, all)=false [0xBB] > > > > - Improved the layout of documentation in the Style Manual. > > > > - Fixed quite a few problems. > > > > I've left quite a lot of debug in for the moment, I think there > > will > > still be work to do. > > > > It gives correct answers to 'point-on.osm'. I haven't worked > > through > > is > > -in-hook-sample-v3.osm yet because I wanted to get this revision > > out > > to > > replace faults in the previous versions. > > > > Ticker > > > > On Tue, 2020-02-11 at 15:49 +, Gerd Petermann wrote: > > > Hi Ticker, > > > > > > whatever you plan to do. I moved the code to the lib because it > > > is > > > easier to write a unit test. > > > I would not invest much time to avoid a few tests which only > > > happen > > > in very rare cases. Makes testing more complicated and code less > > > readable. > > > > > > Gerd > ___ > mkgmap-dev mailing list > mkgmap-dev@lists.mkgmap.org.uk > http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-devIndex: doc/styles/rules.txt === --- doc/styles/rules.txt (revision 4453) +++ doc/styles/rules.txt (working copy) @@ -286,19 +286,19 @@ +true+ if the element is in polygon(s) having the specified +tag+=+value+ according to the +method+, +false+ otherwise. The methods available depend on the Style section: -* points: +. points: +in+ - the Node is within a polygon. +in_or_on+ - it is within or on the edge. +on+ - it is on the edge. -* lines: +. lines: +all+ - part of the Way is within the polygon(s), none is outside; it might touch an edge. - +all_in_or_on+ - none is outside. This is useful for the negative - is_in(...,all_in_or_on)=false - for processing a line that is outside the polgon(s). + +all_in_or_on+ - none is outside. +on+ - it runs along the edge. +any+ - part is within. - +any_in_or_on+ - part is within or in the edge. + +any_in_or_on+ - part is within or all is on the edge. This is useful for the negative - is_in(...,any_in_or_on)=false -
Re: [mkgmap-dev] Work on is_in branch
Hi Gerd Here is the start of it + a couple of changes to the interface of IsInFunction to make life easier. I won't be able to finish this tonight so I've fixed the IsInUnitTest to run using a copied version of calcInsideness, but the start of the 'reverse' version is there, called dev_calcInsideness. Attached patch supersedes is_in-function_v8b.patch and it would be good if it can be applied soon so that, for instance, Arndt, could see if it fixes his problem with context and parameters. Ticker On Wed, 2020-02-12 at 15:55 +, Gerd Petermann wrote: > Hi Ticker, > > I found it difficult to test the real style function, that's why I > moved all the logic out of it. > I am looking forward to your solution. > > Gerd > > > Von: mkgmap-dev im Auftrag > von Ticker Berkin > Gesendet: Mittwoch, 12. Februar 2020 16:47 > An: Development list for mkgmap > Betreff: Re: [mkgmap-dev] Work on is_in branch > > Hi Gerd > > The re-structuring makes this difficult. > > I propose a function in IsInUtilTest with the same interface as > calcInsideness from IsInUtil that somehow drives the real function > IsIn > Function to collect and build the IN/ON/OUT intflag. > > Ticker > > On Wed, 2020-02-12 at 15:28 +, Gerd Petermann wrote: > > Hi Ticker, > > > > did you run the unit tests? This should download a newer version of > > the samples. > > > > Gerd > > > > > > Von: mkgmap-dev im Auftrag > > von Ticker Berkin > > Gesendet: Mittwoch, 12. Februar 2020 16:23 > > An: Development list for mkgmap > > Betreff: Re: [mkgmap-dev] Work on is_in branch > > > > Hi Gerd > > > > Here it is - changes are: > > > > - Some restructuring with early stopping where possible. > > > > - Merging polygons for POINT IN/ON test so a point on shared > > boundary > > becomes IN rather than ON. > > > > - Not merging polygons when no need. > > > > - Make the function cacheable, so that there is negligible cost to > > the > > second call: > > highway=path & is_in(landuse, residential, all)=true [0xAA] > > highway=path & is_in(landuse, residential, all)=false [0xBB] > > > > - Improved the layout of documentation in the Style Manual. > > > > - Fixed quite a few problems. > > > > I've left quite a lot of debug in for the moment, I think there > > will > > still be work to do. > > > > It gives correct answers to 'point-on.osm'. I haven't worked > > through > > is > > -in-hook-sample-v3.osm yet because I wanted to get this revision > > out > > to > > replace faults in the previous versions. > > > > Ticker > > > > On Tue, 2020-02-11 at 15:49 +, Gerd Petermann wrote: > > > Hi Ticker, > > > > > > whatever you plan to do. I moved the code to the lib because it > > > is > > > easier to write a unit test. > > > I would not invest much time to avoid a few tests which only > > > happen > > > in very rare cases. Makes testing more complicated and code less > > > readable. > > > > > > Gerd > ___ > mkgmap-dev mailing list > mkgmap-dev@lists.mkgmap.org.uk > http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-devIndex: doc/styles/rules.txt === --- doc/styles/rules.txt (revision 4445) +++ doc/styles/rules.txt (working copy) @@ -285,19 +285,22 @@ |is_in(tag,value,method) | x | x | | +true+ if the element is in polygon(s) having the specified +tag+=+value+ according to the +method+, +false+ otherwise. The methods available depend on the Style section: -"points": + +* points: +in+ - the Node is within a polygon. +in_or_on+ - it is within or on the edge. +on+ - it is on the edge. -"lines": - +all+ - part of the Way is within the polygon(s), none is outside; it might touch an edge. + +* lines: + +all+ - part of the Way is within the polygon(s), none is outside; it might touch an edge. +all_in_or_on+ - none is outside. This is useful for the negative - is_in(...,all_in_or_on)=false - for processing a line that is outside the polgon(s). +on+ - it runs along the edge. +any+ - part is within. +any_in_or_on+ - part is within or in the edge. -"polygons": + +* polygons: +all+ - all of the closed Way is within the polygon(s). - +any" - some is within. + +any+ - some is within. | Index: src/uk/me/parabola/mkgmap/osmstyle/function/IsInFunction.java ===
Re: [mkgmap-dev] Work on is_in branch
Hi Ticker, I found it difficult to test the real style function, that's why I moved all the logic out of it. I am looking forward to your solution. Gerd Von: mkgmap-dev im Auftrag von Ticker Berkin Gesendet: Mittwoch, 12. Februar 2020 16:47 An: Development list for mkgmap Betreff: Re: [mkgmap-dev] Work on is_in branch Hi Gerd The re-structuring makes this difficult. I propose a function in IsInUtilTest with the same interface as calcInsideness from IsInUtil that somehow drives the real function IsIn Function to collect and build the IN/ON/OUT intflag. Ticker On Wed, 2020-02-12 at 15:28 +, Gerd Petermann wrote: > Hi Ticker, > > did you run the unit tests? This should download a newer version of > the samples. > > Gerd > > > Von: mkgmap-dev im Auftrag > von Ticker Berkin > Gesendet: Mittwoch, 12. Februar 2020 16:23 > An: Development list for mkgmap > Betreff: Re: [mkgmap-dev] Work on is_in branch > > Hi Gerd > > Here it is - changes are: > > - Some restructuring with early stopping where possible. > > - Merging polygons for POINT IN/ON test so a point on shared boundary > becomes IN rather than ON. > > - Not merging polygons when no need. > > - Make the function cacheable, so that there is negligible cost to > the > second call: > highway=path & is_in(landuse, residential, all)=true [0xAA] > highway=path & is_in(landuse, residential, all)=false [0xBB] > > - Improved the layout of documentation in the Style Manual. > > - Fixed quite a few problems. > > I've left quite a lot of debug in for the moment, I think there will > still be work to do. > > It gives correct answers to 'point-on.osm'. I haven't worked through > is > -in-hook-sample-v3.osm yet because I wanted to get this revision out > to > replace faults in the previous versions. > > Ticker > > On Tue, 2020-02-11 at 15:49 +, Gerd Petermann wrote: > > Hi Ticker, > > > > whatever you plan to do. I moved the code to the lib because it is > > easier to write a unit test. > > I would not invest much time to avoid a few tests which only happen > > in very rare cases. Makes testing more complicated and code less > > readable. > > > > Gerd ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Work on is_in branch
Hi Gerd The re-structuring makes this difficult. I propose a function in IsInUtilTest with the same interface as calcInsideness from IsInUtil that somehow drives the real function IsIn Function to collect and build the IN/ON/OUT intflag. Ticker On Wed, 2020-02-12 at 15:28 +, Gerd Petermann wrote: > Hi Ticker, > > did you run the unit tests? This should download a newer version of > the samples. > > Gerd > > > Von: mkgmap-dev im Auftrag > von Ticker Berkin > Gesendet: Mittwoch, 12. Februar 2020 16:23 > An: Development list for mkgmap > Betreff: Re: [mkgmap-dev] Work on is_in branch > > Hi Gerd > > Here it is - changes are: > > - Some restructuring with early stopping where possible. > > - Merging polygons for POINT IN/ON test so a point on shared boundary > becomes IN rather than ON. > > - Not merging polygons when no need. > > - Make the function cacheable, so that there is negligible cost to > the > second call: > highway=path & is_in(landuse, residential, all)=true [0xAA] > highway=path & is_in(landuse, residential, all)=false [0xBB] > > - Improved the layout of documentation in the Style Manual. > > - Fixed quite a few problems. > > I've left quite a lot of debug in for the moment, I think there will > still be work to do. > > It gives correct answers to 'point-on.osm'. I haven't worked through > is > -in-hook-sample-v3.osm yet because I wanted to get this revision out > to > replace faults in the previous versions. > > Ticker > > On Tue, 2020-02-11 at 15:49 +, Gerd Petermann wrote: > > Hi Ticker, > > > > whatever you plan to do. I moved the code to the lib because it is > > easier to write a unit test. > > I would not invest much time to avoid a few tests which only happen > > in very rare cases. Makes testing more complicated and code less > > readable. > > > > Gerd ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Work on is_in branch
Hi Ticker, did you run the unit tests? This should download a newer version of the samples. Gerd Von: mkgmap-dev im Auftrag von Ticker Berkin Gesendet: Mittwoch, 12. Februar 2020 16:23 An: Development list for mkgmap Betreff: Re: [mkgmap-dev] Work on is_in branch Hi Gerd Here it is - changes are: - Some restructuring with early stopping where possible. - Merging polygons for POINT IN/ON test so a point on shared boundary becomes IN rather than ON. - Not merging polygons when no need. - Make the function cacheable, so that there is negligible cost to the second call: highway=path & is_in(landuse, residential, all)=true [0xAA] highway=path & is_in(landuse, residential, all)=false [0xBB] - Improved the layout of documentation in the Style Manual. - Fixed quite a few problems. I've left quite a lot of debug in for the moment, I think there will still be work to do. It gives correct answers to 'point-on.osm'. I haven't worked through is -in-hook-sample-v3.osm yet because I wanted to get this revision out to replace faults in the previous versions. Ticker On Tue, 2020-02-11 at 15:49 +, Gerd Petermann wrote: > Hi Ticker, > > whatever you plan to do. I moved the code to the lib because it is easier to > write a unit test. > I would not invest much time to avoid a few tests which only happen in very > rare cases. Makes testing more complicated and code less readable. > > Gerd ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Work on is_in branch
Hi Gerd
Here it is - changes are:
- Some restructuring with early stopping where possible.
- Merging polygons for POINT IN/ON test so a point on shared boundary
becomes IN rather than ON.
- Not merging polygons when no need.
- Make the function cacheable, so that there is negligible cost to the
second call:
highway=path & is_in(landuse, residential, all)=true [0xAA]
highway=path & is_in(landuse, residential, all)=false [0xBB]
- Improved the layout of documentation in the Style Manual.
- Fixed quite a few problems.
I've left quite a lot of debug in for the moment, I think there will
still be work to do.
It gives correct answers to 'point-on.osm'. I haven't worked through is
-in-hook-sample-v3.osm yet because I wanted to get this revision out to
replace faults in the previous versions.
Ticker
On Tue, 2020-02-11 at 15:49 +, Gerd Petermann wrote:
> Hi Ticker,
>
> whatever you plan to do. I moved the code to the lib because it is easier to
> write a unit test.
> I would not invest much time to avoid a few tests which only happen in very
> rare cases. Makes testing more complicated and code less readable.
>
> Gerd
Index: doc/styles/rules.txt
===
--- doc/styles/rules.txt (revision 4445)
+++ doc/styles/rules.txt (working copy)
@@ -285,19 +285,22 @@
|is_in(tag,value,method) | x | x | |
+true+ if the element is in polygon(s) having the specified +tag+=+value+ according to the +method+, +false+ otherwise.
The methods available depend on the Style section:
-"points":
+
+* points:
+in+ - the Node is within a polygon.
+in_or_on+ - it is within or on the edge.
+on+ - it is on the edge.
-"lines":
- +all+ - part of the Way is within the polygon(s), none is outside; it might touch an edge.
+
+* lines:
+ +all+ - part of the Way is within the polygon(s), none is outside; it might touch an edge.
+all_in_or_on+ - none is outside. This is useful for the negative - is_in(...,all_in_or_on)=false - for processing a line that is outside the polgon(s).
+on+ - it runs along the edge.
+any+ - part is within.
+any_in_or_on+ - part is within or in the edge.
-"polygons":
+
+* polygons:
+all+ - all of the closed Way is within the polygon(s).
- +any" - some is within.
+ +any+ - some is within.
|
Index: src/uk/me/parabola/mkgmap/osmstyle/function/IsInFunction.java
===
--- src/uk/me/parabola/mkgmap/osmstyle/function/IsInFunction.java (revision 4445)
+++ src/uk/me/parabola/mkgmap/osmstyle/function/IsInFunction.java (working copy)
@@ -22,6 +22,7 @@
import uk.me.parabola.imgfmt.app.Area;
import uk.me.parabola.imgfmt.app.Coord;
+import uk.me.parabola.log.Logger;
import uk.me.parabola.mkgmap.reader.osm.Element;
import uk.me.parabola.mkgmap.reader.osm.ElementSaver;
import uk.me.parabola.mkgmap.reader.osm.FeatureKind;
@@ -37,7 +38,8 @@
* @author Ticker Berkin
*
*/
-public class IsInFunction extends StyleFunction {
+public class IsInFunction extends CachedFunction { // StyleFunction
+ private static final Logger log = Logger.getLogger(IsInFunction.class);
private enum MethodArg {
@@ -91,10 +93,10 @@
private class CanStopProcessing extends RuntimeException {};
private MethodArg method;
- private boolean hasIn = false;
- private boolean hasOn = false;
- private boolean hasOut = false;
- private ElementQuadTree qt;
+ private boolean hasIn;
+ private boolean hasOn;
+ private boolean hasOut;
+ private ElementQuadTree qt = null;
public IsInFunction() {
super(null);
@@ -102,10 +104,22 @@
// 1: polygon tagName
// 2: value for above tag
// 3: method keyword, see above
+ log.info("isInFunction", System.identityHashCode(this));
}
+ private void resetHasFlags() {
+ // the instance is per unique call in rules, then applied repeatedly to each point/line/polygon
+ hasIn = false;
+ hasOn = false;
+ hasOut = false;
+ }
+
protected String calcImpl(Element el) {
- if (qt == null || qt.isEmpty())
+ log.info("calcImpl", System.identityHashCode(this), kind, params, el);
+ assert qt != null : "invoked the non-augmented instance";
+ resetHasFlags();
+
+ if (qt.isEmpty())
return String.valueOf(false);
try {
switch (kind) {
@@ -120,17 +134,21 @@
break;
}
} catch (CanStopProcessing e) {}
+ log.info("done", hasIn, hasOn, hasOut);
return String.valueOf(mapHasFlagsAnswer());
}
+/* don't have this for CachedFunction
@Override
public String value(Element el) {
return calcImpl(el);
}
-
+*/
+
@Override
public void setParams(List params, FeatureKind kind) {
super.setParams(params, kind);
+ log.info("setParams", System.identityHashCode(this), kind, params);
String methodStr = params.get(2);
boolean knownMethod = false;
List methodsForKind = new ArrayList<>();
@@ -150,22 +168,34 @@
}
private void setIn() {
+ log.info("setIn", hasIn, hasOn, hasOut);
hasIn = true;
- if
Re: [mkgmap-dev] Work on is_in branch
Hi Ticker, whatever you plan to do. I moved the code to the lib because it is easier to write a unit test. I would not invest much time to avoid a few tests which only happen in very rare cases. Makes testing more complicated and code less readable. Gerd Von: mkgmap-dev im Auftrag von Ticker Berkin Gesendet: Dienstag, 11. Februar 2020 16:43 An: Development list for mkgmap Betreff: Re: [mkgmap-dev] Work on is_in branch Hi Gerd I assume you mean towards moving some logic from IsInUtil to IsInFunction. Ticker On Tue, 2020-02-11 at 15:41 +, Gerd Petermann wrote: > Hi Ticker, > > okay, let's see where this goes... > > Gerd > > > Von: mkgmap-dev im Auftrag > von Ticker Berkin > Gesendet: Dienstag, 11. Februar 2020 16:36 > An: Development list for mkgmap > Betreff: Re: [mkgmap-dev] Work on is_in branch > > Hi Gerd > > To take advantage of efficiency gains based on knowing what is being > asked for, ie: > > - do the polygons need to be merged or can we do one-by-one. > - can we answer correctly even of !W.isComplete(). > - can we stop early, eg ANY as soon as part is IN, ALL as soon as > part > is OUT, etc > > the top layers of code need to be with the method and its associated > knowledge. I don't see any point in simply moving this into IsInUtil. > > I was going to take calcInsideness next and divide it into some > library > bits remaining in IsInUtil, and logic equivalent to the rest in > IsInFunction. > > If you consider this is not the way to proceed, then I'd still like > patch applied anyway, firstly because it contains other changes > unrelated to this, secondly so that the code exists in SVN. I'll then > immediately do another patch that removes the canStop logic etc and > the > POINT code that migrated here and restore it to just testing the > composite flags. > > Ticker > > On Tue, 2020-02-11 at 14:11 +, Gerd Petermann wrote: > > Hi all, > > > > sorry, something is broken in the mail system. > > The latest posts don't appear on nabble (1) and my answers to > > existing threads are rejected. > > > > @Ticker: I'd prefer to do the merge and I think it should be done > > in > > IsInUtil. Your patch is_in-function_v7.patch goes in the opposite > > direction. > > Not sure what you plan to do now? > > > > Gerd > > > > (1) http://gis.19327.n8.nabble.com/Mkgmap-Development-f5324443.html > > ___ > > 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] Work on is_in branch
Hi Gerd I assume you mean towards moving some logic from IsInUtil to IsInFunction. Ticker On Tue, 2020-02-11 at 15:41 +, Gerd Petermann wrote: > Hi Ticker, > > okay, let's see where this goes... > > Gerd > > > Von: mkgmap-dev im Auftrag > von Ticker Berkin > Gesendet: Dienstag, 11. Februar 2020 16:36 > An: Development list for mkgmap > Betreff: Re: [mkgmap-dev] Work on is_in branch > > Hi Gerd > > To take advantage of efficiency gains based on knowing what is being > asked for, ie: > > - do the polygons need to be merged or can we do one-by-one. > - can we answer correctly even of !W.isComplete(). > - can we stop early, eg ANY as soon as part is IN, ALL as soon as > part > is OUT, etc > > the top layers of code need to be with the method and its associated > knowledge. I don't see any point in simply moving this into IsInUtil. > > I was going to take calcInsideness next and divide it into some > library > bits remaining in IsInUtil, and logic equivalent to the rest in > IsInFunction. > > If you consider this is not the way to proceed, then I'd still like > patch applied anyway, firstly because it contains other changes > unrelated to this, secondly so that the code exists in SVN. I'll then > immediately do another patch that removes the canStop logic etc and > the > POINT code that migrated here and restore it to just testing the > composite flags. > > Ticker > > On Tue, 2020-02-11 at 14:11 +, Gerd Petermann wrote: > > Hi all, > > > > sorry, something is broken in the mail system. > > The latest posts don't appear on nabble (1) and my answers to > > existing threads are rejected. > > > > @Ticker: I'd prefer to do the merge and I think it should be done > > in > > IsInUtil. Your patch is_in-function_v7.patch goes in the opposite > > direction. > > Not sure what you plan to do now? > > > > Gerd > > > > (1) http://gis.19327.n8.nabble.com/Mkgmap-Development-f5324443.html > > ___ > > 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] Work on is_in branch
Hi Ticker, okay, let's see where this goes... Gerd Von: mkgmap-dev im Auftrag von Ticker Berkin Gesendet: Dienstag, 11. Februar 2020 16:36 An: Development list for mkgmap Betreff: Re: [mkgmap-dev] Work on is_in branch Hi Gerd To take advantage of efficiency gains based on knowing what is being asked for, ie: - do the polygons need to be merged or can we do one-by-one. - can we answer correctly even of !W.isComplete(). - can we stop early, eg ANY as soon as part is IN, ALL as soon as part is OUT, etc the top layers of code need to be with the method and its associated knowledge. I don't see any point in simply moving this into IsInUtil. I was going to take calcInsideness next and divide it into some library bits remaining in IsInUtil, and logic equivalent to the rest in IsInFunction. If you consider this is not the way to proceed, then I'd still like patch applied anyway, firstly because it contains other changes unrelated to this, secondly so that the code exists in SVN. I'll then immediately do another patch that removes the canStop logic etc and the POINT code that migrated here and restore it to just testing the composite flags. Ticker On Tue, 2020-02-11 at 14:11 +, Gerd Petermann wrote: > Hi all, > > sorry, something is broken in the mail system. > The latest posts don't appear on nabble (1) and my answers to > existing threads are rejected. > > @Ticker: I'd prefer to do the merge and I think it should be done in > IsInUtil. Your patch is_in-function_v7.patch goes in the opposite > direction. > Not sure what you plan to do now? > > Gerd > > (1) http://gis.19327.n8.nabble.com/Mkgmap-Development-f5324443.html > ___ > 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] Work on is_in branch
Hi Gerd To take advantage of efficiency gains based on knowing what is being asked for, ie: - do the polygons need to be merged or can we do one-by-one. - can we answer correctly even of !W.isComplete(). - can we stop early, eg ANY as soon as part is IN, ALL as soon as part is OUT, etc the top layers of code need to be with the method and its associated knowledge. I don't see any point in simply moving this into IsInUtil. I was going to take calcInsideness next and divide it into some library bits remaining in IsInUtil, and logic equivalent to the rest in IsInFunction. If you consider this is not the way to proceed, then I'd still like patch applied anyway, firstly because it contains other changes unrelated to this, secondly so that the code exists in SVN. I'll then immediately do another patch that removes the canStop logic etc and the POINT code that migrated here and restore it to just testing the composite flags. Ticker On Tue, 2020-02-11 at 14:11 +, Gerd Petermann wrote: > Hi all, > > sorry, something is broken in the mail system. > The latest posts don't appear on nabble (1) and my answers to > existing threads are rejected. > > @Ticker: I'd prefer to do the merge and I think it should be done in > IsInUtil. Your patch is_in-function_v7.patch goes in the opposite > direction. > Not sure what you plan to do now? > > Gerd > > (1) http://gis.19327.n8.nabble.com/Mkgmap-Development-f5324443.html > ___ > 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
