[mkgmap-dev] roundabout checks

2021-05-07 Thread Mike Baggaley
Hi Gerd,

Please find attached the previously discussed patch that splits checking and
fixing roundabouts and flares and provides enhanced flare analysis. I note
that some checks are performed when the style is being processed with others
being performed later. I have not attempted to combine these - is there a
technical reason for the separation, or is it just that the checks were
separately developed?

Thanks,
Mike


roundaboutchecks.patch
Description: Binary data
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

Re: [mkgmap-dev] patch: improve RoadMerger: allow to merge roads with reversed points

2021-05-07 Thread Gerd Petermann
Hi all,

I found a few glitches with v4 of the patch. A code block was duplicated (just 
decreased performance) and the calculation of points where only two roads meet 
was wrong.
 Attached are now two different versions, both probably a bit faster:
-v5 corrects the calculation, so probably merges fewer roads than v4
-v6 merges always and produces an info message when sharp angles were merged 
(the reported number can be confusing: 180 means a u-turn, anything > 130 is a 
sharp angle)

If anybody thinks that reversing should not be done yet I can split the patch 
so that only the sharp-angle handling changes.

Gerd


Von: mkgmap-dev  im Auftrag von Felix 
Hartmann 
Gesendet: Freitag, 7. Mai 2021 15:39
An: Development list for mkgmap
Betreff: Re: [mkgmap-dev] patch: improve RoadMerger: allow to merge roads with 
reversed points

I think merging would be fine. Garmin hates sharp angles anyhow and will likely 
not chose them for a car route. And if cycling or walking it doesn't matter too 
much if really an announcement is not given. Anyhow on sharp turns there is 
usually a turn announcement also on the same road - most switchbacks on trails 
are announced. Would be great if the penalty this way could be lowered a bit..

On Fri, 7 May 2021 at 16:35, Mike Baggaley 
mailto:m...@tvage.co.uk>> wrote:
Hi Gerd,

I believe this activity is a precursor to reducing zig zags at low
resolutions (though I may be confusing two different activities). I think
the case shown here would be better handled by seeing whether at the low
resolution the two entry points to the A13 can be reduced to a single point.
For each side of the junction we would have two coincident one-way roads
that could be reduced to a single two way road. Merging the two one-way
roads into one would prevent this from taking place. I was under the
impression that mkgmap split ways at junctions anyway, so I'm not sure what
would be gained by joining these together. I do not have a full
understanding of the code, so may have misunderstood this bit.

Cheers,
Mike

-Original Message-
From: Gerd Petermann 
[mailto:gpetermann_muenc...@hotmail.com]
Sent: 07 May 2021 08:55
To: Development list for mkgmap 
mailto:mkgmap-dev@lists.mkgmap.org.uk>>
Subject: Re: [mkgmap-dev] patch: improve RoadMerger: allow to merge roads
with reversed points

Hi all,

See e.g. the link roads which meat at
https://www.openstreetmap.org/node/606366325
I really wonder how mkgmap should treat roads like that which build a sharp
angle. Current code doesn't merge them. I don't know how it worked in 2014
but today I see no good reason for that. Routing results seem to be the same
and mainly depend on the "avoid u-turn" setting.
Maybe there is a difference when the --ignore-sharp-angles is used, but than
that's probably exactly what the user wants?

I've also seen several places where the two link roads are mapped with a
single OSM way.

The correct mapping probably requires two OSM ways and a turn restriction,
but the Garmin routing algo really doesn't like sharp angles anyway and
prefers large detours to avoid them when "avoid u-turn" is enabled.

I've attached a new patch which ignores sharp angles where only two roads
meet. This gives a few more merges.
If you change the line
private static final double MAX_MERGE_ANGLE = 130.0;
to
private static final double MAX_MERGE_ANGLE = 180.0;
mkgmap will still prefer to merge the roads with the smallest angle but will
also merge those with a sharp angle and thus reduce the NOD/NET size even
more.

I think mkgmap should use always merge if --ignore-sharp-angles  is used,
but that's not implemented yet.

Gerd


Von: mkgmap-dev 
mailto:mkgmap-dev-boun...@lists.mkgmap.org.uk>>
 im Auftrag von Gerd
Petermann 
mailto:gpetermann_muenc...@hotmail.com>>
Gesendet: Freitag, 7. Mai 2021 07:39
An: Development list for mkgmap
Betreff: Re: [mkgmap-dev] patch: improve RoadMerger: allow to merge roads
with reversed points

Hi Felix,

just noticed that patch v3 still only looked for mkgmap:has-direction=1 in
one place.

Anyway, I am very unsure how to handle the direction flag. It's probably not
a good idea to transfer the flag too ALL lines which are created from one
OSM way.

I also found some cases where roads are not merged because the angle is too
sharp. This was discussed
here:http://www.mkgmap.org.uk/pipermail/mkgmap-dev/2013q3/018649.html
I think it was introduced to avoid bad routing at places like
https://www.osm.org/node/606366325 where we don't want to merge the two link
roads.
I think the angle should be ignored if only two roads with the same
attributes meat. Like here: https://www.osm.org/node/1387136827

Gerd


Von: mkgmap-dev 
mailto:mkgmap-dev-boun...@lists.mkgmap.org.uk>>
 im Auftrag von
Felix Hartmann mailto:extremecar...@gmail.com>>
Gesendet: Donnerstag, 6. Mai 2021 17:55
An: De

Re: [mkgmap-dev] patch: improve RoadMerger: allow to merge roads with reversed points

2021-05-07 Thread Felix Hartmann
I think merging would be fine. Garmin hates sharp angles anyhow and will
likely not chose them for a car route. And if cycling or walking it doesn't
matter too much if really an announcement is not given. Anyhow on sharp
turns there is usually a turn announcement also on the same road - most
switchbacks on trails are announced. Would be great if the penalty this way
could be lowered a bit..

On Fri, 7 May 2021 at 16:35, Mike Baggaley  wrote:

> Hi Gerd,
>
> I believe this activity is a precursor to reducing zig zags at low
> resolutions (though I may be confusing two different activities). I think
> the case shown here would be better handled by seeing whether at the low
> resolution the two entry points to the A13 can be reduced to a single
> point.
> For each side of the junction we would have two coincident one-way roads
> that could be reduced to a single two way road. Merging the two one-way
> roads into one would prevent this from taking place. I was under the
> impression that mkgmap split ways at junctions anyway, so I'm not sure what
> would be gained by joining these together. I do not have a full
> understanding of the code, so may have misunderstood this bit.
>
> Cheers,
> Mike
>
> -Original Message-
> From: Gerd Petermann [mailto:gpetermann_muenc...@hotmail.com]
> Sent: 07 May 2021 08:55
> To: Development list for mkgmap 
> Subject: Re: [mkgmap-dev] patch: improve RoadMerger: allow to merge roads
> with reversed points
>
> Hi all,
>
> See e.g. the link roads which meat at
> https://www.openstreetmap.org/node/606366325
> I really wonder how mkgmap should treat roads like that which build a sharp
> angle. Current code doesn't merge them. I don't know how it worked in 2014
> but today I see no good reason for that. Routing results seem to be the
> same
> and mainly depend on the "avoid u-turn" setting.
> Maybe there is a difference when the --ignore-sharp-angles is used, but
> than
> that's probably exactly what the user wants?
>
> I've also seen several places where the two link roads are mapped with a
> single OSM way.
>
> The correct mapping probably requires two OSM ways and a turn restriction,
> but the Garmin routing algo really doesn't like sharp angles anyway and
> prefers large detours to avoid them when "avoid u-turn" is enabled.
>
> I've attached a new patch which ignores sharp angles where only two roads
> meet. This gives a few more merges.
> If you change the line
> private static final double MAX_MERGE_ANGLE = 130.0;
> to
> private static final double MAX_MERGE_ANGLE = 180.0;
> mkgmap will still prefer to merge the roads with the smallest angle but
> will
> also merge those with a sharp angle and thus reduce the NOD/NET size even
> more.
>
> I think mkgmap should use always merge if --ignore-sharp-angles  is used,
> but that's not implemented yet.
>
> Gerd
>
> 
> Von: mkgmap-dev  im Auftrag von
> Gerd
> Petermann 
> Gesendet: Freitag, 7. Mai 2021 07:39
> An: Development list for mkgmap
> Betreff: Re: [mkgmap-dev] patch: improve RoadMerger: allow to merge roads
> with reversed points
>
> Hi Felix,
>
> just noticed that patch v3 still only looked for mkgmap:has-direction=1 in
> one place.
>
> Anyway, I am very unsure how to handle the direction flag. It's probably
> not
> a good idea to transfer the flag too ALL lines which are created from one
> OSM way.
>
> I also found some cases where roads are not merged because the angle is too
> sharp. This was discussed
> here:http://www.mkgmap.org.uk/pipermail/mkgmap-dev/2013q3/018649.html
> I think it was introduced to avoid bad routing at places like
> https://www.osm.org/node/606366325 where we don't want to merge the two
> link
> roads.
> I think the angle should be ignored if only two roads with the same
> attributes meat. Like here: https://www.osm.org/node/1387136827
>
> Gerd
>
> 
> Von: mkgmap-dev  im Auftrag von
> Felix Hartmann 
> Gesendet: Donnerstag, 6. Mai 2021 17:55
> An: Development list for mkgmap
> Betreff: Re: [mkgmap-dev] patch: improve RoadMerger: allow to merge roads
> with reversed points
>
> ah okay, no worries I can patch it myself.
>
> On Thu, 6 May 2021 at 23:46, Gerd Petermann
> mailto:gpetermann_muenc...@hotmail.com>>
> wrote:
> Hi Felix,
>
> the patch possibly has an influence on routing, so I don't want to add it
> to
> the low-res-opt branch.
> I can provide two binaries if needed.
>
> Gerd
>
> 
> Von: mkgmap-dev
>  mkgmap-dev-boun...@lists.mkgm
> ap.org.uk>> im Auftrag von Felix Hartmann
> mailto:extremecar...@gmail.com>>
> Gesendet: Donnerstag, 6. Mai 2021 17:42
> An: Development list for mkgmap
> Betreff: Re: [mkgmap-dev] patch: improve RoadMerger: allow to merge roads
> with reversed points
>
> Could you directly push those patches to the low-res branch? I guess anyone
> using it right now would like to try it with the patch..
> I will try it out tomorrow.
>
> On Thu, 6 May 2021 at

Re: [mkgmap-dev] Divide number in style file

2021-05-07 Thread Felix Hartmann
Ah true, can use other conversion too, so it's doable...

On Fri, 7 May 2021, 18:47 Ticker Berkin  wrote:

> ...|conv:"from=>to" does speed and weight conversions as well as length
>
> This is the table (from mkgmap/osmstyle/eval/UnitConversions.java)
>
>   static {
> Map m = LENGTH_FACTORS;
> m.put("m", 1.0);
> m.put("km", 1000.0);
> m.put("ft", 0.3048);
> m.put("feet", 0.3048);
> m.put("mi", 1_609.344);
> CONVERSIONS.put(UnitType.LENGTH, LENGTH_FACTORS);
>
> m = SPEED_FACTORS;
> m.put("kmh", 1.0);
> m.put("km/h", 1.0);
> m.put("kmph", 1.0);
> m.put("mph", 1.60934);
> m.put("knots", 1.852);
> CONVERSIONS.put(UnitType.SPEED, SPEED_FACTORS);
>
> m = WEIGHT_FACTORS;
> m.put("t", 1.0);
> m.put("kg", 0.001);
> m.put("lb", 0.00045359237);
> m.put("lbs", 0.00045359237);
> CONVERSIONS.put(UnitType.WEIGHT, WEIGHT_FACTORS);
> }
>
> I see no reason why chaining conv| shouldn't work, but haven't tried
> it.
>
> Ticker
>
> On Fri, 2021-05-07 at 17:56 +0800, Felix Hartmann wrote:
> > yes I figured out the only current possible division would be to
> > convert ft to mt - that could be run against population number as
> > well of course.. Dividing the population number to get maps of India
> > or China a bit less cluttered without using a specific style would be
> > quite handy. Though yes - besides improving rules for cities not much
> > else use of a division factor for values that I can think of. So
> > right now only 3.28, 3.28^2, 3.28^3 and so on is possible (i did not
> > actually check if it is possible to convert twice, but think so).
> >
> > On Fri, 7 May 2021 at 16:56, Ticker Berkin 
> > wrote:
> > > Hi Felix
> > >
> > > I don't think there is any way to do maths on tag values.
> > >
> > > It should not be too difficult to implement additional variable
> > > filters
> > > that do a simple maths op with a constant, eg:
> > >   {set population='${population|divide:"7"}'}
> > >
> > > Ticker
> > >
> > > On Wed, 2021-05-05 at 22:58 +0800, Felix Hartmann wrote:
> > > > Is it possible to divide a number by a factor in the style file?
> > > >
> > > > ( mkgmap:country=CHN | mkmgap:countrz=CN | mkgmap:country=IND |
> > >
> > >  ^^
> > > > mkgmap:country=IN ) & ( place=city | place=island | place=town |
> > > > place=village ) & population=* {set population='${population}/7'}
> > > >
> > > > Did not work. I intend to divide the population in cities in
> > > China
> > > > and India because otherwise cities clutter up the map there (also
> > > in
> > > > India they do not use admin level ... which could be an
> > > alternative).
> > > >
> > > > --
> > > > Felix Hartman - Openmtbmap.org & VeloMap.org
> > > >
> > > > ___
> > > > mkgmap-dev mailing list
> > > > mkgmap-dev@lists.mkgmap.org.uk
> > > > https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
> > > ___
> > > mkgmap-dev mailing list
> > > mkgmap-dev@lists.mkgmap.org.uk
> > > https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
> > >
> >
> > --
> > Felix Hartman - Openmtbmap.org & VeloMap.org
> >
> > ___
> > mkgmap-dev mailing list
> > mkgmap-dev@lists.mkgmap.org.uk
> > https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
> ___
> mkgmap-dev mailing list
> mkgmap-dev@lists.mkgmap.org.uk
> https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
>
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

Re: [mkgmap-dev] Divide number in style file

2021-05-07 Thread Ticker Berkin
...|conv:"from=>to" does speed and weight conversions as well as length

This is the table (from mkgmap/osmstyle/eval/UnitConversions.java)

  static {
Map m = LENGTH_FACTORS;
m.put("m", 1.0);
m.put("km", 1000.0);
m.put("ft", 0.3048);
m.put("feet", 0.3048);
m.put("mi", 1_609.344);
CONVERSIONS.put(UnitType.LENGTH, LENGTH_FACTORS);

m = SPEED_FACTORS;
m.put("kmh", 1.0);
m.put("km/h", 1.0);
m.put("kmph", 1.0);
m.put("mph", 1.60934);
m.put("knots", 1.852);
CONVERSIONS.put(UnitType.SPEED, SPEED_FACTORS);

m = WEIGHT_FACTORS;
m.put("t", 1.0);
m.put("kg", 0.001);
m.put("lb", 0.00045359237);
m.put("lbs", 0.00045359237);
CONVERSIONS.put(UnitType.WEIGHT, WEIGHT_FACTORS);
}

I see no reason why chaining conv| shouldn't work, but haven't tried
it.

Ticker

On Fri, 2021-05-07 at 17:56 +0800, Felix Hartmann wrote:
> yes I figured out the only current possible division would be to
> convert ft to mt - that could be run against population number as
> well of course.. Dividing the population number to get maps of India
> or China a bit less cluttered without using a specific style would be
> quite handy. Though yes - besides improving rules for cities not much
> else use of a division factor for values that I can think of. So
> right now only 3.28, 3.28^2, 3.28^3 and so on is possible (i did not
> actually check if it is possible to convert twice, but think so).
> 
> On Fri, 7 May 2021 at 16:56, Ticker Berkin 
> wrote:
> > Hi Felix
> > 
> > I don't think there is any way to do maths on tag values.
> > 
> > It should not be too difficult to implement additional variable
> > filters
> > that do a simple maths op with a constant, eg:
> >   {set population='${population|divide:"7"}'}
> > 
> > Ticker
> > 
> > On Wed, 2021-05-05 at 22:58 +0800, Felix Hartmann wrote:
> > > Is it possible to divide a number by a factor in the style file?
> > > 
> > > ( mkgmap:country=CHN | mkmgap:countrz=CN | mkgmap:country=IND |
> > 
> >  ^^
> > > mkgmap:country=IN ) & ( place=city | place=island | place=town |
> > > place=village ) & population=* {set population='${population}/7'}
> > > 
> > > Did not work. I intend to divide the population in cities in
> > China
> > > and India because otherwise cities clutter up the map there (also
> > in
> > > India they do not use admin level ... which could be an
> > alternative).
> > > 
> > > -- 
> > > Felix Hartman - Openmtbmap.org & VeloMap.org
> > > 
> > > ___
> > > mkgmap-dev mailing list
> > > mkgmap-dev@lists.mkgmap.org.uk
> > > https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
> > ___
> > mkgmap-dev mailing list
> > mkgmap-dev@lists.mkgmap.org.uk
> > https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
> > 
> 
> -- 
> Felix Hartman - Openmtbmap.org & VeloMap.org
> 
> ___
> mkgmap-dev mailing list
> mkgmap-dev@lists.mkgmap.org.uk
> https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev


Re: [mkgmap-dev] Divide number in style file

2021-05-07 Thread Felix Hartmann
yes I figured out the only current possible division would be to convert ft
to mt - that could be run against population number as well of course..
Dividing the population number to get maps of India or China a bit less
cluttered without using a specific style would be quite handy. Though yes -
besides improving rules for cities not much else use of a division factor
for values that I can think of. So right now only 3.28, 3.28^2, 3.28^3 and
so on is possible (i did not actually check if it is possible to convert
twice, but think so).

On Fri, 7 May 2021 at 16:56, Ticker Berkin  wrote:

> Hi Felix
>
> I don't think there is any way to do maths on tag values.
>
> It should not be too difficult to implement additional variable filters
> that do a simple maths op with a constant, eg:
>   {set population='${population|divide:"7"}'}
>
> Ticker
>
> On Wed, 2021-05-05 at 22:58 +0800, Felix Hartmann wrote:
> > Is it possible to divide a number by a factor in the style file?
> >
> > ( mkgmap:country=CHN | mkmgap:countrz=CN | mkgmap:country=IND |
>
>  ^^
> > mkgmap:country=IN ) & ( place=city | place=island | place=town |
> > place=village ) & population=* {set population='${population}/7'}
> >
> > Did not work. I intend to divide the population in cities in China
> > and India because otherwise cities clutter up the map there (also in
> > India they do not use admin level ... which could be an alternative).
> >
> > --
> > Felix Hartman - Openmtbmap.org & VeloMap.org
> >
> > ___
> > mkgmap-dev mailing list
> > mkgmap-dev@lists.mkgmap.org.uk
> > https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
> ___
> mkgmap-dev mailing list
> mkgmap-dev@lists.mkgmap.org.uk
> https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
>


-- 
Felix Hartman - Openmtbmap.org & VeloMap.org
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

Re: [mkgmap-dev] Divide number in style file

2021-05-07 Thread Ticker Berkin
Hi Felix

I don't think there is any way to do maths on tag values.

It should not be too difficult to implement additional variable filters
that do a simple maths op with a constant, eg:
  {set population='${population|divide:"7"}'}

Ticker

On Wed, 2021-05-05 at 22:58 +0800, Felix Hartmann wrote:
> Is it possible to divide a number by a factor in the style file?
> 
> ( mkgmap:country=CHN | mkmgap:countrz=CN | mkgmap:country=IND |

 ^^
> mkgmap:country=IN ) & ( place=city | place=island | place=town |
> place=village ) & population=* {set population='${population}/7'}
> 
> Did not work. I intend to divide the population in cities in China
> and India because otherwise cities clutter up the map there (also in
> India they do not use admin level ... which could be an alternative).
> 
> -- 
> Felix Hartman - Openmtbmap.org & VeloMap.org
> 
> ___
> mkgmap-dev mailing list
> mkgmap-dev@lists.mkgmap.org.uk
> https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev


Re: [mkgmap-dev] patch: improve RoadMerger: allow to merge roads with reversed points

2021-05-07 Thread Mike Baggaley
Hi Gerd, 

I believe this activity is a precursor to reducing zig zags at low
resolutions (though I may be confusing two different activities). I think
the case shown here would be better handled by seeing whether at the low
resolution the two entry points to the A13 can be reduced to a single point.
For each side of the junction we would have two coincident one-way roads
that could be reduced to a single two way road. Merging the two one-way
roads into one would prevent this from taking place. I was under the
impression that mkgmap split ways at junctions anyway, so I'm not sure what
would be gained by joining these together. I do not have a full
understanding of the code, so may have misunderstood this bit. 

Cheers,
Mike

-Original Message-
From: Gerd Petermann [mailto:gpetermann_muenc...@hotmail.com] 
Sent: 07 May 2021 08:55
To: Development list for mkgmap 
Subject: Re: [mkgmap-dev] patch: improve RoadMerger: allow to merge roads
with reversed points

Hi all,

See e.g. the link roads which meat at
https://www.openstreetmap.org/node/606366325
I really wonder how mkgmap should treat roads like that which build a sharp
angle. Current code doesn't merge them. I don't know how it worked in 2014
but today I see no good reason for that. Routing results seem to be the same
and mainly depend on the "avoid u-turn" setting.
Maybe there is a difference when the --ignore-sharp-angles is used, but than
that's probably exactly what the user wants?

I've also seen several places where the two link roads are mapped with a
single OSM way.

The correct mapping probably requires two OSM ways and a turn restriction,
but the Garmin routing algo really doesn't like sharp angles anyway and
prefers large detours to avoid them when "avoid u-turn" is enabled.

I've attached a new patch which ignores sharp angles where only two roads
meet. This gives a few more merges.
If you change the line
private static final double MAX_MERGE_ANGLE = 130.0;
to
private static final double MAX_MERGE_ANGLE = 180.0;
mkgmap will still prefer to merge the roads with the smallest angle but will
also merge those with a sharp angle and thus reduce the NOD/NET size even
more.

I think mkgmap should use always merge if --ignore-sharp-angles  is used,
but that's not implemented yet.

Gerd


Von: mkgmap-dev  im Auftrag von Gerd
Petermann 
Gesendet: Freitag, 7. Mai 2021 07:39
An: Development list for mkgmap
Betreff: Re: [mkgmap-dev] patch: improve RoadMerger: allow to merge roads
with reversed points

Hi Felix,

just noticed that patch v3 still only looked for mkgmap:has-direction=1 in
one place.

Anyway, I am very unsure how to handle the direction flag. It's probably not
a good idea to transfer the flag too ALL lines which are created from one
OSM way.

I also found some cases where roads are not merged because the angle is too
sharp. This was discussed
here:http://www.mkgmap.org.uk/pipermail/mkgmap-dev/2013q3/018649.html
I think it was introduced to avoid bad routing at places like
https://www.osm.org/node/606366325 where we don't want to merge the two link
roads.
I think the angle should be ignored if only two roads with the same
attributes meat. Like here: https://www.osm.org/node/1387136827

Gerd


Von: mkgmap-dev  im Auftrag von
Felix Hartmann 
Gesendet: Donnerstag, 6. Mai 2021 17:55
An: Development list for mkgmap
Betreff: Re: [mkgmap-dev] patch: improve RoadMerger: allow to merge roads
with reversed points

ah okay, no worries I can patch it myself.

On Thu, 6 May 2021 at 23:46, Gerd Petermann
mailto:gpetermann_muenc...@hotmail.com>>
wrote:
Hi Felix,

the patch possibly has an influence on routing, so I don't want to add it to
the low-res-opt branch.
I can provide two binaries if needed.

Gerd


Von: mkgmap-dev
mailto:mkgmap-dev-boun...@lists.mkgm
ap.org.uk>> im Auftrag von Felix Hartmann
mailto:extremecar...@gmail.com>>
Gesendet: Donnerstag, 6. Mai 2021 17:42
An: Development list for mkgmap
Betreff: Re: [mkgmap-dev] patch: improve RoadMerger: allow to merge roads
with reversed points

Could you directly push those patches to the low-res branch? I guess anyone
using it right now would like to try it with the patch..
I will try it out tomorrow.

On Thu, 6 May 2021 at 18:32, Gerd Petermann
mailto:gpetermann_muenc...@hotmail.com>mailto:gpetermann_muenc...@hotmail.com>>
> wrote:
Ahh, sorry, merge-roads-reversed-v2.patch was work-in-progress. v3 works as
described before.

Gerd


Von: mkgmap-dev
mailto:mkgmap-dev-boun...@lists.mkgm
ap.org.uk>>> im Auftrag von Gerd Petermann
mailto:gpetermann_muenc...@hotmail.com>mailto:gpetermann_muenc...@hotmail.com>>
>
Gesendet: Donnerstag, 6. Mai 2021 12:30
An: Development list for mkgmap
Betreff: Re: [mkgmap-dev] patch: improve RoadMerger: allow to merge road

Re: [mkgmap-dev] patch: improve RoadMerger: allow to merge roads with reversed points

2021-05-07 Thread Gerd Petermann
Hi all,

See e.g. the link roads which meat at 
https://www.openstreetmap.org/node/606366325
I really wonder how mkgmap should treat roads like that which build a sharp 
angle. Current code doesn't merge them. I don't know how it worked in 2014 but 
today I see no good reason for that. Routing results seem to be the same and 
mainly depend on the "avoid u-turn" setting.
Maybe there is a difference when the --ignore-sharp-angles is used, but than 
that's probably exactly what the user wants?

I've also seen several places where the two link roads are mapped with a single 
OSM way.

The correct mapping probably requires two OSM ways and a turn restriction, but 
the Garmin routing algo really doesn't like sharp angles anyway and prefers 
large detours to avoid them when "avoid u-turn" is enabled.

I've attached a new patch which ignores sharp angles where only two roads  
meet. This gives a few more merges.
If you change the line
private static final double MAX_MERGE_ANGLE = 130.0;
to
private static final double MAX_MERGE_ANGLE = 180.0;
mkgmap will still prefer to merge the roads with the smallest angle but will 
also merge those with a sharp angle and thus reduce the NOD/NET size even more.

I think mkgmap should use always merge if --ignore-sharp-angles  is used, but 
that's not implemented yet.

Gerd


Von: mkgmap-dev  im Auftrag von Gerd 
Petermann 
Gesendet: Freitag, 7. Mai 2021 07:39
An: Development list for mkgmap
Betreff: Re: [mkgmap-dev] patch: improve RoadMerger: allow to merge roads with 
reversed points

Hi Felix,

just noticed that patch v3 still only looked for mkgmap:has-direction=1 in one 
place.

Anyway, I am very unsure how to handle the direction flag. It's probably not a 
good idea to transfer the flag too ALL lines which are created from one OSM way.

I also found some cases where roads are not merged because the angle is too 
sharp. This was discussed 
here:http://www.mkgmap.org.uk/pipermail/mkgmap-dev/2013q3/018649.html
I think it was introduced to avoid bad routing at places like 
https://www.osm.org/node/606366325 where we don't want to merge the two link 
roads.
I think the angle should be ignored if only two roads with the same attributes 
meat. Like here: https://www.osm.org/node/1387136827

Gerd


Von: mkgmap-dev  im Auftrag von Felix 
Hartmann 
Gesendet: Donnerstag, 6. Mai 2021 17:55
An: Development list for mkgmap
Betreff: Re: [mkgmap-dev] patch: improve RoadMerger: allow to merge roads with 
reversed points

ah okay, no worries I can patch it myself.

On Thu, 6 May 2021 at 23:46, Gerd Petermann 
mailto:gpetermann_muenc...@hotmail.com>> wrote:
Hi Felix,

the patch possibly has an influence on routing, so I don't want to add it to 
the low-res-opt branch.
I can provide two binaries if needed.

Gerd


Von: mkgmap-dev 
mailto:mkgmap-dev-boun...@lists.mkgmap.org.uk>>
 im Auftrag von Felix Hartmann 
mailto:extremecar...@gmail.com>>
Gesendet: Donnerstag, 6. Mai 2021 17:42
An: Development list for mkgmap
Betreff: Re: [mkgmap-dev] patch: improve RoadMerger: allow to merge roads with 
reversed points

Could you directly push those patches to the low-res branch? I guess anyone 
using it right now would like to try it with the patch..
I will try it out tomorrow.

On Thu, 6 May 2021 at 18:32, Gerd Petermann 
mailto:gpetermann_muenc...@hotmail.com>>>
 wrote:
Ahh, sorry, merge-roads-reversed-v2.patch was work-in-progress. v3 works as 
described before.

Gerd


Von: mkgmap-dev 
mailto:mkgmap-dev-boun...@lists.mkgmap.org.uk>>>
 im Auftrag von Gerd Petermann 
mailto:gpetermann_muenc...@hotmail.com>>>
Gesendet: Donnerstag, 6. Mai 2021 12:30
An: Development list for mkgmap
Betreff: Re: [mkgmap-dev] patch: improve RoadMerger: allow to merge roads with 
reversed points

Hi all,

here is the 2nd approach:

RoadMerger can connect more roads if direction of the roads doesn't matter reg. 
routing.  Problem is that mkgmap doesn't know if direction matters unless the 
oneway tag
says so. The patch
- implements new special tag mkgmap:has-direction=true which must be set for 
ways which shoud not be reversed.
I am not yet sure how to use this. My idea was that the style author knows 
which types are direction depended and this should add
mkgmap:has-direction=true for those lines which should not be reversed.
Before road merging all map lines which were created for a given OSM way are 
checked. If any has a direction then all lines for the given OSM way are marked 
to have a direction.
Maybe this needs more thinking.

- The program checks if there is any line rule that uses 
mkgmap:has-direction=true. If