I really like the feature to find a route around a road block. But I run into an issue as you can see in my test video: https://youtu.be/4DYkSm283Cs?t=1414
Problem is that when you select a distance for the road block, it starts directly at your current position which might produce strange results. Would be cool if you can also pick where the road block starts.
I could imagine doing this with a slider with two handles. One for the start and one for the end with an exponential scaling. And even ++ feature would be to see the blocked area indicated on your route in the map.
2 Likes
I can think for block area improvements and where they can exist, so navigation won’t be overloaded.
Thanks also for the video, community already informed about that. 
1 Like
Can you provide route sample links with details, so we can reproduce those “strange results”?
I think, those unexpected results are specific to roundabouts.
When you hit “road block next 500 m” just before you enter a roundabout then Kurviger considers the roundabout as blocked.
But what the user has intended is to block the road-segment that follows after the roundabout.
The roundabout itself usually isn’t blocked.
Manfred
Computer cannot understand what human means, unless explicitly declared.
Roadblocks are usually in front of driver, when reach one we want to avoid it.
Sometimes it’s even worse: human cannot understand what computer means 
(just kidding)
Let me add some details here.
First of all this is the link to my test route from the video: Kurviger
I added a waypoint 3 that marks the location where I tested the road block feature. My link with the video above includes the timestamp. So if you open that link you are directly at the point in the video where I do this test.
No, I think it will be the same with a regular intersection. See my additional comment below.
Fully agree. And this is actually the intension of my improvement request/wish.
I don’t agree on this point. I think my scenario from the video is quite realistic. When I can see that there is a road block on a roundabout, I don’t drive into the roundabout and stop at the exit that is closed to tell my app that now the road is blocked. And the same thing for a regular intersection. I don’t stop in the middle of an intersection - I will stop a little ahead of the intersection or roundabout and then tell the app that my planned route is blocked.
And as you mentioned above, I want to be able to explicitly declare to kurviger what is blocked.
I mean an easy solution for this would be to just consider a certain threshold like 50 meters. But this might be wrong as well. So the most explicit solution would be to tell not only how long the roadblock is, but also where exactly it starts.
And just to make sure - with “strange results” I just want to express that these might be strange from a user point of view. For the logic of the app - everything was totally fine.
E.g. the example from my video.
(1) I stopped a little bit ahead of the roundabout where I could see already that my exit was blocked.
(2) I told the app that the next 2 km are blocked
(3) and the app did exactly this from my current location, which includes the roundabout and blocked the other two possible exits
(4) the gave my the only possible option which is to turn around and find another way
So from the app and logic point of view everything is fine. The problem is just, that the road block does not always start at my current position. Actually in most of the real life cases I can think of it doesn’t.
And actually in this case it was a strange result, but this is not related to the stuff I mentioned so far.
If you take a closer look at (3) and (4) you can see that the detour is using an “unofficial” road. I think I’m even not allowed to use it. But I think this was caused by the beta offline routing that was active at this moment as I didn’t had a SIMCARD for my Android test device. I guess the offline routing is also using bicycle roads at the moment!?
1 Like
Thanks for the sample route and the additional details, now we can better understand the report.
Roadblocks depend on how flexible is the routing engine.
If (4) is the “user expected” route, it could probably be the result even with current configuration, cannot see from first look why not happen or how extra options will change that.
Regarding offline routing, please see its guide in wiki (they use driving, fastest profile).
So the roadblock rerouting with which router of the 3 had happened?
There are 2 different offline routers available, each one with its own strengths and weaknesses.
You can test them explicitly, if close app internet or select them in settings.
Specially BRouter offers much customization, as discussed in its topic.
Everyone can easily test the routing of all 3 routers (Kurviger, GraphHopper, BRouter) in their websites.
And can search for their avoid area parameter to test also roadblocks, which is what navigation receives and presents to the users.
(4) was not my expected result. And I don’t talk about the not allowed road that was used but the fact that the solution was to turn me around and drive back. And this would have happened with all routing engines I think. As the road block was considered by the app from my current position (A), all routing engines would have turned me around to look for an alternative route.
I think if I would have been able to tell the app that the road block actually starts at (B), the routing would deliver the correct alternative (green line) as it understands that the roundabout is still accessible.
I had GraphHopper activated at this moment.
1 Like
The thing is that sliders are not easily handled in navigation conditions by some users or else it would be better to have the roadblock distances as slider instead of the current buttons limited implementation, because each user has different needs and options.
Would a configurable trash-hold be an option? Having something in the settings of the app where I can adjust where the road block should start relative to my current position.
I mean this is really just an improvement idea. Now that I’m aware of and know how to deal with it, I know how to use it to get the (for me) right results.
True, if you consider the road block function to be handled while riding, then the slider solution is not handy or even not feasible to handle.
My ideas was obviously based on my usual behavior to really have a short stop and deal with the road block.
Indeed, that’s the expected driver’s behavior, so the UI can become more flexible.
We can think how this can be done.
I like the proposal from @Rhoenschrat .
And here a proposal: Current version (left), and a “perhaps” version (right, Fake)
The slider i copied from Minimum GPS accuracy. The range of the slider perhaps could be 0 to 200 m? What do you think?
2 Likes
Sorry, but it even get worse for me now.
I repeated the test at the exact same spot, but now it doesn’t do anything when I add a road block.
Here you can find screen recording of the test:
I use the Beta 1.13.3 with GraphHopper (don’t have a SIM Card for my Android test device), the German map is loaded as well as the DACH routing files.
In my tests the situation was clearly improved, that’s why some improvements were introduced.
I could see for more enhancements in the future. Each router behaves differently in roadblocks.