[mkgmap-dev] highway=track with no road_class and road_speed set breaks routing ## was ## "No roads near target" bug in Schwabmünchen

Sat Apr 13 11:51:05 BST 2013

Hi Franco,

I don't think that the problem with Robert-Bosch-Str. 14 is caused by that.
Here are my findings with the small extract posted here:
http://gis.19327.n5.nabble.com/No-roads-near-target-bug-in-Schwabmunchen-tp5753364p5756716.html

The housenumber generator sees 3 parts of the road.
1: from node 37507846 to 37507848
2: from node 37507848 to 59608285
3: the roundabout from 59608285 to 59608285

The first part gets housenumber 3 on the left (Schönwetter Automobile) and  numbers 2..6 on the right
The 2nd part gets no numbers on the left and 8..12 on the right
The 3rd parts gets no numbers on the left and 14 and 5 (Aldi) on the right (in this order)
So I think the roundabout triggeres a bit flag that says: numbers are mixed (odd and even numbers on one side)
As a final result the Oregon displays only two possible numbers: 3 and 5. 

@Wanmil: Maybe the result would be better  when the numbers are sorted in a different way?

Gerd

Date: Fri, 12 Apr 2013 22:30:47 +0200
From: franco.bez at web.de
To: mkgmap-dev at lists.mkgmap.org.uk
Subject: Re: [mkgmap-dev] highway=track with no road_class and road_speed set breaks routing ## was ## "No roads near target" bug in Schwabmünchen

    Hi Gerd,

    An idea just crossed my mind that could lead to a solution of the
    routing problem.

    To make sure I understood the problem correctly I summarize the
    facts:

    1. to make the Garmin device announce a "roundabout" it is
    neccessary that the type of the road is 0x0c

    2. we want to have different looks for different kinds of
    roundabouts, so we need another type for the displayed road.

    3. overlays create two roads, one (road1) that is routable and has
    the type 0x0c (a roundabout), and a second one (road2) that is not
    routable but drawn on top of the other so it's responsible for the
    looks on the map.

    4. If we choose a type for road2 that is not in the range of
    "routable" types the optics of the map is not good. Bernd tested
    this many times.

    5. if we use a "routable" type for road2 we might get broken routing
    because a "routable" type without road_class and road_speed is
    entered into the map

    My idea is as follows.

    Why don't we just assign the lowest possible road_class and
    road_speed to the overlayed road2 when it has routable type ?

    Wouldn't there be no more routable types without road_speed and
    road_class ?

    Wouldn't the Garmin Firmware be "happy" ?

    Wouldn't the "better" and "faster" road1 be picked by the firmware
    for actual routing, as the road2 has the lowest possible class and
    speed and is therefore discarded ? 

    What do you think ?

    Would this be possible ?

    Or is this just a crazy idea ?

    Ciao,

      Franco

_______________________________________________
mkgmap-dev mailing list
mkgmap-dev at lists.mkgmap.org.uk
http://lists.mkgmap.org.uk/mailman/listinfo/mkgmap-dev 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.mkgmap.org.uk/pipermail/mkgmap-dev/attachments/20130413/105c1790/attachment.html 