[mkgmap-dev] Work on is_in branch

Mon Feb 24 13:11:46 GMT 2020

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