[mkgmap-dev] Work on is_in branch

Thu Feb 27 16:42:54 GMT 2020

Hi Ticker,

yes, probably the value is still too small, and I assume nobody would mind to use a halo of 0.08 m width.
Small problem is that we don't use this halo with the point in shape tests.

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 17:23
An: Development list for mkgmap
Betreff: Re: [mkgmap-dev] Work on is_in branch

Hi Gerd

Yes, I think I see where it goes in with josm at maximum zoom.

Shouldn't EPS be a bit bigger? My understanding was that a high
-precision unit was ~37mm at the equator (40,075*1000/2^24/2^6)*1000.

With your change from 10mm to 20mm all the tests pass, but wouldn't
    private static final double EPS = 0.080;
be safer, to allow for 2 hp roundings away from each other.

Ticker

On Thu, 2020-02-27 at 14:42 +0000, Gerd Petermann wrote:
> 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
_______________________________________________
mkgmap-dev mailing list
mkgmap-dev at lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev