[mkgmap-dev] mergeroads branch

Sun Sep 22 12:38:16 BST 2013

> Hi,
>
>
> GerdP wrote
>> Hi WanMil,
>>
>> I have to look at it again. I think you will need only a small part of the
>> patch to
>> solve your problem, and the other part will not work with the latest
>> changes
>> regarding the styles and access.
>
> ok, here is what I remember:
> I created the patch because I observed a lot of problems with
> the --link-pois-to-ways option in combination with the short arc removal.
> This option changes Coord to CoordPOI instances and therefore adds a
> lot of short arcs to rather iunimportant ways, e.g.
> small ways ending on big roads, blocked with bollards or barriers:
> RRRRRRRRR
>     |
>     b
>     |

Bingo! That's exactly what I observed. One example is way 
http://www.openstreetmap.org/browse/way/25344551 (the east end).

>
> As the short-arc-removal algo doesn't care about importance of the road,
> it might move points of the big road towards the bollards to remove
> a short arc in the small "unimportant" way.
> The irony is that many of the small ways are tagged as footways, so
> the bollards or barriers should be IMHO ignored reg. routing.
> So, I tried to filter those CoordPOI which are added to footways.
> While working on the patch I found the errors reg. the maintenance of
> the highway count and also some outaged comments.
> It would have been better to separate them from
> the rest of the patch :-(

I think we should reimplement the --link-pois-to-ways option. Maybe the 
following algorithm would work:
Before the removeShortArcs removal check all POIs and create a list 
which ways need to be changed due to the POIs and at which point (Coord 
and/or distance from start/end point). After the removeShortArcs option 
apply the changes. Due to the information stored in the list before the 
removeShortArcs option it should be possible to ensure that changes are 
applied only to correct ways and not to coord merged ways.

WanMil

>
> Gerd
>
>