Re: [mkgmap-dev] Work on is_in branch
Hi Ticker,
if you see a way to change the algo just do it.
I've just noticed that I forgot to commit a change in Coord.makeBetweenPoint().
This routine should use Math.round. Will reduce the error by 50%, right?
Gerd
Von: mkgmap-dev im Auftrag von Ticker
Berkin
Gesendet: Donnerstag, 27. Februar 2020 20:24
An: Development list for mkgmap
Betreff: Re: [mkgmap-dev] Work on is_in branch
Hi Gerd
Looking at the distance calculations to compare with EPS (ie very
small), wouldn't it be much simpler and clearer just to calculate it as
highPrecisionSquared units, not bothering with degrees/radians, rhumb
-line, metre conversion etc. Then EPS would be 4.
Then, considering IsInUtil.insidePolgon and can it be changed to have
some tolerance and maybe changing the interface to return IN/ON/OUT, it
looks like it will stop, returning onBoundary, if there is a polygon
segment that 'aims at' the point.
Ticker
On Thu, 2020-02-27 at 16:42 +, Gerd Petermann wrote:
> 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 im Auftrag
> von Ticker Berkin
> 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 +, 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 im Auftrag
> > von Ticker Berkin
> > 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 +, 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
> > >
Re: [mkgmap-dev] Work on is_in branch
Hi Gerd
Looking at the distance calculations to compare with EPS (ie very
small), wouldn't it be much simpler and clearer just to calculate it as
highPrecisionSquared units, not bothering with degrees/radians, rhumb
-line, metre conversion etc. Then EPS would be 4.
Then, considering IsInUtil.insidePolgon and can it be changed to have
some tolerance and maybe changing the interface to return IN/ON/OUT, it
looks like it will stop, returning onBoundary, if there is a polygon
segment that 'aims at' the point.
Ticker
On Thu, 2020-02-27 at 16:42 +, Gerd Petermann wrote:
> 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 im Auftrag
> von Ticker Berkin
> 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 +, 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 im Auftrag
> > von Ticker Berkin
> > 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 +, 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
Re: [mkgmap-dev] Work on is_in branch
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 im Auftrag von Ticker
Berkin
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 +, 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 im Auftrag
> von Ticker Berkin
> 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 +, 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 im Auftrag
> > von Ticker Berkin
> > 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?
> >
>
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 +, 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 im Auftrag
> von Ticker Berkin
> 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 +, 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 im Auftrag
> > von Ticker Berkin
> > 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 +, Ticker Berkin wrote:
> > > Hi Gerd
> > >
> > > Patch attached that:
> > >
> > > - rewords the sentence is the Style Manual and changes the
> > > highlighting; I need to check the
Re: [mkgmap-dev] Work on is_in branch
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 im Auftrag von Ticker
Berkin
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 +, 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 im Auftrag
> von Ticker Berkin
> 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 +, 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
>
>
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 +, 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 im Auftrag
> von Ticker Berkin
> 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 +, 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-devIndex: doc/styles/about.txt
===
--- doc/styles/about.txt (revision 4458)
+++ doc/styles/about.txt (working copy)
@@ -14,9 +14,9 @@
People who have contributed suggestions and corrections to this document
are:
Carlos Dávila,
-Geoff Sherlock
+Geoff Sherlock,
+Ticker Berkin
-
The list of nicknames of everyone that had modified the wiki pages at the time that
this manual was created is as follows:
Brogo,
Index: doc/styles/rules.txt
===
--- doc/styles/rules.txt (revision 4458)
+++ doc/styles/rules.txt (working copy)
@@ -244,9 +244,9 @@
Functions calculate a specific property of an OSM element.
.Style functions
Re: [mkgmap-dev] dead end check patch v2
Hi Mike, I fear I don't understand the problem yet. It seems you don't like the idea that a tag like fixme=* set in the points rules changes the behaviour of the dead-end-check? Gerd Von: mkgmap-dev im Auftrag von Mike Baggaley Gesendet: Donnerstag, 27. Februar 2020 00:17 An: 'Development list for mkgmap' Betreff: [mkgmap-dev] dead end check patch v2 Hi Gerd, Please find attached the alternate patch for improving the dead end check, which is fully backwards compatible. This adds a new command line option -- dead-ends which lists the tags and optional values that are to be considered to be valid dead ends when found on the node at the end of a way. The default is --dead-ends=fixme,FIXME. Regards, Mike ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
