Roundabouts and Slip-Roads about brouter HOT 17 OPEN

Sure, here's a short working route - obviously Cruiser won't let me export a "non" route, but if I move the Start Point to those bad places, it won't "route". Very odd. I can even "Start" in the field away from the road and BRouter snaps to the road nearby, so it's working up to a point - but just doesn't like roundabouts/slip-roads :(

Cruiser: "Car" Navigation Profile, "Fastest" Route Type, no avoidances
BRouter: "car-fast" and selecting "motocar_fast" Server-Mode in BRouter

It's about as "stock" as I can get - just the update stopped it working. Bizarre, I know!

cruiser-brouter-issue.zip

from brouter.

For now I will make Cruiser reader more flexible in the next update,
so it has no problem reading such responses.

• devemux86/cruiser#150

from brouter.

Update: a further test suggests that it's only the Start point causing a problem. A Route with a Shaping-Point in the same place was able to route correctly.

from brouter.

I've tried to get the fail with your description. And used it with this sample - I always need exact data for producing an error. I have no web server with 1.7.0 lib but in offline generation this is the result.

Seems alright for me. It starts on ramp (near your point). Do I miss something?

PS this also work when I come from the Lidl parking space to bridge.

from brouter.

Just to clarify, I'm using the Cruiser navigation app (Mapsforge maps) with the latest 1.7 "offline" BRouter on my Android device. If I switch to "online" within the app, BRouter performs as expected. "In browser" BRouter is fine :)

I have since tried other roundabouts/slip-roads around the UK and reproduced the same issue.

from brouter.

@MotoUKRider

Can you export a small route example in the (offline) GPX navigation gpx format?

Then I can check the parameters sent to the BRouter app
and @afischerdev can see what's happening in BRouter.

from brouter.

@MotoUKRider
I got that. Anyway on my phone this is Cruiser and BRouter last versions:

Still not see the problem.
May be you can tell us more about your settings? e.g. your profile - I use car-fast in this sample

from brouter.

@MotoUKRider @afischerdev

What routing settings do you use?

• Navigation profile
• Route type
• Avoidance options

So we can see what BRouter profile and extra parameters are called.

from brouter.

Same as mem just as it comes out of the box. Download tiles are from today as this is not my area.

from brouter.

@MotoUKRider thanks for the sample. 👍

The issue is in Cruiser reader of the BRouter responses. The 1st trkpt contains:

<sym>roundabout_e2</sym>
<type>Via</type>

Usually we expect in the 1st trkpt:

<sym>pass_place</sym>
<type>Via</type>

Is the BRouter response correct or we need to adjust the Cruiser reader?

from brouter.

That's it. In my test -0.455417,53.680995;-0.449084,53.695384 I got an unexpected roundabout_e2 at the first point. But when I control the 'old' export with waypoints I get the same result also on first point:

<wpt lat="53.680993" lon="-0.455413"><ele>43</ele><name>Take exit 2</name></wpt>

A beautiful sample.

Who tells us what is the right form?

from brouter.

cc @0709wiwiwi

It should be valid to have a turn instruction at the 1st point (start) of a route.
Mostly it is a simple "straight", but in some cases it can even be a u-turn.

The old format has a different structure.
In the new format we use a limited number of tags, we have to fit everything in them.

from brouter.

1. Surely this is a rare and rather surprising discovery.
2. The snap to street action causes the start to fall on the roundabout.
3. Roundabout indication locations are where the oncoming road connects to the roundabout.
4. So if you only start at the roundabout itself, the condition 3 is not present.
5. You start on a "crooked" road and so the indication should be "pass_place".
   (Compare with the first (rtept) route(way)point but here it is one that snapped to the nearest road).
6. Where you leave that "crooked" road then, a standard L/R directional indication is expected.
   But admittedly that expectation may be a bit too high anyway ;-)

By the last Beta the BRouterAPP 1.6.4l-release this issue did and does not occur.
And also the GH offline router engine in Cruiser handles this fine.
A normal start is so possible at the roundabout. (Confirmed by test).
Start location (before the snap to street action) placed at the parking lot of a pharmacy near a roundabout.

Start_rotonde_gh.gpx.txt

from brouter.

@0709wiwiwi
I also tested the GH router inside Cruiser with our sample above. My result is:

Shows GH also delivers roundabout logic. When I export this to GPX I get a similar result as you in your gpx file. The start point is inside but no turn instruction.
But this is not a fall back from roundabout to 'normal' turn instruction logic.
For me it seems to be the conflict between start point vs. voice hint goes to the start point.
And on a fall back I would expect a right on 1. exit and and a left on 2. exit.

When you export this as a kurviger file you have the 'take exit 2' inside at position index 0.

@devemux86
Yes, we have a different structure now. But the output format changes not the routing logic.
All other export formats accept a turn instruction on the first point.

from brouter.

Anyway, we have a problem in this example:

The result of the roundabout is RNDB2 for right-hand traffic.
It should be RNLB2 on the left side.

from brouter.

Alex,
Surprising was the modified behavior compared to the Beta.

Presenting a theoretical start on a traffic circle optimally ?
See my example: In practice, you probably won't start there.
Unless you want to drive through that private closure.

What is important however is that a routing start up is not blocked.

Leaving the sym "pass_place" can't , as this also used as navtrack "marker".
In Locus import, a sym "pass_place" is the only possible routing point reference.
Cruiser and Locus map handle imports containing type Via_Shaping slightly different.
Cruiser can so even combine every trkpt sym text with a type Via or Shaping.
In Cruiser, the trackpoint can so contain a turn and also be a routing ref point :-))
According to Menion, this combination is not technically possible into Locus.
So in Locus, by a trkpt sym u-turn, you lose the routing point ref marker :-((

from brouter.

For now I will make Cruiser reader more flexible in the next update, so it has no problem reading such responses.

- https://github.com/devemux86/cruiser/discussions/150

It works properly in Cruiser 3.0.19.

from brouter.