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
[mkgmap-dev] Commit r4454: Correct WrongAngleFixer: Avoid to disconnect end points of routable lines from non-routable lines even when the end point causes a distortion of the non-routable line.
Version mkgmap-r4454 was committed by gerd on Thu, 20 Feb 2020 Correct WrongAngleFixer: Avoid to disconnect end points of routable lines from non-routable lines even when the end point causes a distortion of the non-routable line. http://www.mkgmap.org.uk/websvn/revision.php?repname=mkgmap=4454 ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
