Hi Ticker,
no idea how the tool chain for the pdf works.
There are some commented code blocks and Eclipse and SonarLint warn about
several missing default statements, e.g.
Complete cases by adding the missing enum constants or add a default case to
this switch. IsInFunction.java
mkgmap/src/uk/me/parabola/mkgmap/osmstyle/function line 164
SonarLint On-The-Fly Issue
Reg. the TODO comment
// problem with test b14 on the cut polygons and isLineInShape that goes away
when merged. TODO: investigate sometime
Maybe the reason is that we create a Coord instance at the place where the
polygon is split. Due to the rounding errors this point can be a 1-2 mm inside
or outside the original inner polygon. Merging should not change the result
unless the added point is removed by the merge. In that case I would assume
that there were no rounding errors.
Some log statements might be removed or changed to debug level?
log.info("done", System.identityHashCode(this), hasIn, hasOn, hasOut);
Gerd
________________________________________
Von: mkgmap-dev <mkgmap-dev-boun...@lists.mkgmap.org.uk> im Auftrag von Ticker
Berkin <rwb-mkg...@jagit.co.uk>
Gesendet: Dienstag, 25. Februar 2020 10:27
An: Development list for mkgmap
Betreff: Re: [mkgmap-dev] Work on is_in branch
Hi Gerd
I think this is about ready for release.
There is a slight problem with the layout in the Style Manual in that
the width of "is_in(tag,value,method)" causes it to run into the
Node/Way/Relation flags. If there was a way to put the function args
down the first column it would fix it, but I have no idea of the rules
of the formatting language. What are the tools used to transform
doc/styles/*.txt to the style-manual.pdf?
I'm not going to be able to do any complex line->polygon in/on/out
debugging in the next few days and it seems to work well for most
cases.
Ticker
On Mon, 2020-02-24 at 12:50 +0000, Ticker Berkin wrote:
> 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
_______________________________________________
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
