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] wrong result from is_in style function
Hi Gerd I thought of this case the other day and the fix for it is done and will be in the next patch, which is mainly related to the test driver. Ticker On Mon, 2020-02-24 at 10:57 +, Gerd Petermann wrote: > Hi Ticker, > > please try attached sample file with the two rules in polygons. > With r4456 I see > Way -101782 all OK > but not > Way -101782 any OK > > 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
[mkgmap-dev] wrong result from is_in style function
Hi Ticker, please try attached sample file with the two rules in polygons. With r4456 I see Way -101782 all OK but not Way -101782 any OK Gerd inside.osm Description: inside.osm polygons Description: polygons ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
