[mkgmap-dev] Work on is_in branch

Mon Feb 24 13:54:21 GMT 2020

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 +0000, 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 <mkgmap-dev-bounces at lists.mkgmap.org.uk> im Auftrag
> von Ticker Berkin <rwb-mkgmap at jagit.co.uk>
> 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 +0000, 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 +0000, 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
> 