<html><head></head><body style="font-family: Monospace;"><div>Hi Gerd</div><div><br></div><div>Patch attached that:</div><div><br></div><div>- 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.</div><div><br></div><div>- fixes polygon 'any' method to also return true if exactly ON.</div><div><br></div><div>- merge polygons for 'any' so that line on shared boundary is "in" rather than "on".</div><div><br></div><div>- 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.</div><div><br></div><div>Ticker</div><div><br></div><div>On Thu, 2020-02-20 at 16:45 +0000, Ticker Berkin wrote:</div><blockquote type="cite"><div>Hi Gerd</div><div><br></div><div>I don't think the test data 'expected' values are wrong, it is just</div><div>that they are more specific than the 'method' mechanism allows to be</div><div>differentiated; eg a polygon can only be tested for ALL in or ANY in.</div><div><br></div><div>At the moment I feel you have a reluctance about the whole concept of</div><div>the methods. Once the principle is accepted, I'll go through the test</div><div>data and add, as another tag, the list of methods that should match the</div><div>element, then change the test driver to check that these match and the</div><div>other applicable methods don't.</div><div><br></div><div>Reg. b14: It isn't the stop-early code that causes the problems,</div><div>isLineInShape is not giving the correct answer for a simple polygon</div><div>produced by the MP cutter.</div><div><br></div><div>It would be quite easy to introduce some POLYGON 'on' methods, that</div><div>match the outer, inner or either edge of a polygon, but maybe this</div><div>could wait until there is a call for it.</div><div><br></div><div>Next mail:</div><div>I'll change the sentence as you suggest.</div><div><br></div><div>Please can you commit the patch as it stands; it has a lot of good</div><div>stuff in it. Then I can do the IsInUtilTest and test data changes as</div><div>the next stage. It's also handy to see how the Style Manual looks after</div><div>each build into the download area, because I don't know how to generate</div><div>it and am just guessing at the formatting.</div><div><br></div><div>Thank you</div><div>Ticker</div><div><br></div><div>On Thu, 2020-02-20 at 15:41 +0000, Gerd Petermann wrote:</div><blockquote type="cite"><div>Hi Ticker,</div><div><br></div><div>I see that you overwrite the expected value stored in the test data</div><div>in the unit test. Please don't do this. If you think that the</div><div>expected value in is-in-samples.osm</div><div>is wrong we should discuss the test data.</div><div>In my eyes b14 clearly has points on the edge (as it is part of the</div><div>edge) and is out.</div><div><br></div><div>If you think the expected results are correct but your new code</div><div>doesn't allow to test them because of the early stop code please add</div><div>a new tag to each object or maybe create a new file. The unit test</div><div>file is meant to document what the code does.</div><div><br></div><div>Gerd</div></blockquote></blockquote><div><br></div></body></html>