Closed MotoUKRider closed 1 year ago
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.
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.
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.
@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.
@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
@MotoUKRider @afischerdev
What routing settings do you use?
So we can see what BRouter profile and extra parameters are called.
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!
Same as mem just as it comes out of the box. Download tiles are from today as this is not my area.
@MotoUKRider thanks for the sample. :+1:
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?
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?
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.
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
For now I will make Cruiser reader more flexible in the next update, so it has no problem reading such responses.
@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.
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.
Alex, Surprising was the modified behavior compared to the Beta. What is important is that a routing start up is not blocked.
Cruiser and Locus handle imports of trkpt sym with type Via_Shaping slightly different. In Cruiser any trkpt sym turn with a type Via or Shaping is accepted as routing reference. In Locus only the sym pass-place is usefully to be used as via point routing reference.
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.
@devemux86, is there anything left to do, or can we close this?
@quaelnix thanks for asking, I have already updated the reader in Cruiser.
So we can close this issue, as a turn instruction in the first trkpt is valid.
Hello - Cruiser user here.
I've just updated to v1.7 and found that a Route didn't load - further investigation reveals it boils down to roundabouts and slip-roads as starting points - replicated in several places on a map using duplicate "preferences" on 2 devices, the other using the previous BRouter from GooglePlay Store.
If you attempt to start from a roundabout (ie: a place where fuel/services may be) then it won't "route". The on/off-ramp/slip-road does not route, either. You have to start the Route on the main carriageway or a little back from the roundabout.
See example below: It will "route" on the main A15 towards the Humber Bridge, but not on the entry-ramp, so you have to find a "clear" piece of road.![cruiser-brouter-issue](https://user-images.githubusercontent.com/125696109/235622691-7a45a1b1-ff3b-4f85-be23-fbf5e0146e22.jpg)