[mkgmap-dev] Work on is_in branch

Thu Feb 27 14:42:20 GMT 2020

Hi Ticker,

I've looked at b14 again. The mp-cutting produces a point which is a small bit inside the real hole (~1.6 mm). I've attached the gpx files.
e_hp is the tested segmet of the element b14, s_hp is the tested segment created by cutting, shape_hp is the complete shape produced by the mp-cutter.
The southern end crosses e_hp. This small overlap is ignored when the merged shape is analyzed. Responsible for this is the method isOnOrCloseToEdgeOfShape(), I think I wrote it exactly for this problem but it is just a work-around for the problems produced by the polygon cutting.

Attached is a patch which might solve the problem, didn't test it much. It increases the allowed distance for "ON" from 1 to 2 mm and handles this special case.

Gerd

________________________________________
Von: mkgmap-dev <mkgmap-dev-bounces at lists.mkgmap.org.uk> im Auftrag von Ticker Berkin <rwb-mkgmap at jagit.co.uk>
Gesendet: Donnerstag, 27. Februar 2020 14:01
An: Development list for mkgmap
Betreff: Re: [mkgmap-dev] Work on is_in branch

Hi Gerd

Changes:

- Added comment in style-manual.txt about tools needed and how to
generate the pdf. These are asciidoc, fop, python-pygments and mkgmap
-pygments.

- Adjusted the layout of "Table 4.2. Style functions" so that
is_in(...) doesn't run into the flags and and slightly changed the
highlighting again.

- Changed log.info to log.debug.

- Added default: throw...  to a couple of switch statements. I disagree
with SonarLint that this is always good practice; here it is just
pointless clutter.

I'm not sure what the problem is with commented code blocks. I left
@override value() {...} in as commented because it clarifies what needs
to change between a CachedFunction and a StyleFunction.

doc/styles/main.txt should be deleted from svn; it has been superseded
by style-manual.txt.

Reg. b14. It might be slight rounding errors, but the hole generated from the merge of the 2 halves of the outer retains the 2 cut-points and this does match the inner polygon, whereas, for the inner polygon, isLineInShape gives IN/ON/OUT against one of the halves of the outer. I'd have expected the problems to be the other way around.

Ticker

On Wed, 2020-02-26 at 08:46 +0000, Gerd Petermann wrote:
> 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-bounces at lists.mkgmap.org.uk> im Auftrag
> von Ticker Berkin <rwb-mkgmap at 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 at lists.mkgmap.org.uk
> http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
-------------- next part --------------
A non-text attachment was scrubbed...
Name: no-merge-gpx.zip
Type: application/x-zip-compressed
Size: 1250 bytes
Desc: no-merge-gpx.zip
URL: <http://www.mkgmap.org.uk/pipermail/mkgmap-dev/attachments/20200227/5aa04aaa/attachment-0001.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: is_in-function_v14.patch
Type: application/octet-stream
Size: 3870 bytes
Desc: is_in-function_v14.patch
URL: <http://www.mkgmap.org.uk/pipermail/mkgmap-dev/attachments/20200227/5aa04aaa/attachment-0001.obj>