[mkgmap-dev] Work on is_in branch

Mon Feb 24 12:50:47 GMT 2020

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.mkgmap.org.uk/pipermail/mkgmap-dev/attachments/20200224/2a5cda14/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: is_in-function_v12.patch
Type: text/x-patch
Size: 13995 bytes
Desc: not available
URL: <http://www.mkgmap.org.uk/pipermail/mkgmap-dev/attachments/20200224/2a5cda14/attachment.bin>