Question to the BRouter-Professionals
When I restart my phone,
BRouter resets back to standard profile mode setting like
So to use modified profiles permanently, I have to rename them to car-fast / car-eco etc.
Anyone knows this problem?
BRouter power exists in external profiles, better handled in its app.
BRouter in Kurviger is more meant for offline navigation rerouting.
For route planning should use internet and Kurviger curvy routing.
See also @SchlesiM’s post above with some detailed instructions.
Or change the mapping in BRouter’s
See also its readme in “Routing via the service interface” section.
Hmmm, after proceeding like I described in my post above the content of my “serviceconfig.dat” looks like this, even after restarting the phone (just tested):
Should be enough.
For this example I configured all BRouter profiles to use “Kurviger-smallroads” using BRouters own dialog interface:
Kurviger uses the car fastest profile in offline routing.
With BRouter that should be the “motorcar_fast”.
Maybe the app could provide an internal mapping of Kurviger routing options to BRouter standard profiles (as an option in the settings?).
Something like that:
fastest route -> motorcar_fast
fast and curvy route -> motorcar_short
curvy routes -> bicycle_fast
extra curvy route -> bicycle_short
all curvy route -> foot_fast
This way everyone had the chance to easily use different BRouter profiles for each of the Kurviger options (of course after adding his own brf-mapping in BRouter like described above). Additionally this would provide more transparency how Kurviger integrates the BRouter profiles.
This isn’t right mapping, walking and cycling are completely unrelated meanings to vehicles.
Like mentioned above, BRouter’s power is its custom profiles. Can be one or many and should be handled externally, by users willing to invest time to explore its app and custom profiles.
Yes, that’s clear. But I meant after replacing or remapping the different standard profiles in BRouter to your custom brf-files so that (for example) “foot_fast” in fact isn’t a footwalker profile any longer but uses one of your custom brf-files.
By using this BRouter dialog (several times):
So that it looks somehow like this in the end (I called the BRouter dialog three times to get there):
Advantage: possibility to use different BRouter setting for each of Kurvigers routing options.
Of course the standard mapping in Kurviger still remains this:
fastest route -> motorcar_fast
fast and curvy route -> motorcar_fast
curvy routes -> motorcar_fast
extra curvy route -> motorcar_fast
all curvy route -> motorcar_fast
For users who don’t want to fiddle around with BRouter and its brf-files (as far as I understood this is the way it currently works).
If users wish to customize BRouter, they have to learn how to use it, via its app.
Or they can simply use the sane default profile, which is usable for most cases.
I understand your idea, but to me that looks like an abuse of BRouters profiles.
It feels like a crude hack to map bicycle and foot profiles to some custom motor-vehicle profiles.
Better keep it simple.
Kurzer Einwurf von mir, nicht vergessen das vielleicht einige Anwender BRouter auf Ihrem Handy auch für andere Apps verwenden. Falls Ihr die Profile aber anders, fest, zuordnet passen Sie nicht mehr für die anderen Apps, zB OsmAnd+. Da wäre die manuelle Wahl der Profile, über die BRouter App, vielleicht besser?
Short interjection from me, don’t forget that maybe some users use BRouter on their mobile phones for other apps as well. But if you assign the profiles differently, fixed, they won’t fit for the other apps, e.g. OsmAnd+. Maybe the manual selection of the profiles via the BRouter app would be better?
Kurviger’s road block feature seams not to work with BRouter. Tested with 1.13.1
I don’t know if this would be possible at all.
Roadblock feature definitely works with all 3 routers: Kurviger, GraphHopper, BRouter.
Why it cannot return results in some cases with one of them?
It depends on router’s profile, each one calculates differently.
So there can be several cases where there cannot be results with one of them.
Better to test those cases in their websites, so can check how they work there.
Thank you for your answer.
After some more testing, I can confirm that road block is working with BRouter when blocking 2km and 5km.
Only blocking for 500m is not working in my test scenario.
Maybe I need to learn more about BRouter
In my tests all routers have succeeded or failed with all distances in different scenarios.
Anyway I’ll integrate some roadblock minor improvements and we’ll see if they can help.
EDIT: they are available in Kurviger 1.13.3 (Beta).
Tata, 1.13.3 has arrived.
I am not sure if is the right place, but I have some (minor) issues with BRouter.
How to reproduce:
BRouter is configured straight forward (default).
Routing service is set to BRouter (offline)
Transfer my test route via bar code from website to the app.
- automatic recalculation is off
- rerouting is set to next unvisited waypoint
Here you see the first issue
The distance shown is towards the end, and not towards the next waypoint as I would have expected.
- Recalculate route to the start point.
Now my original waypoint1 is lost and only original start point is left as wp1
schouldn’t the distance field show the distance to the next waypoint (in the image above)?
If you transfer the route while Kurviger routing service is running it is working as expected.
If you switch to BRouter service after the route is transferred successfully then it is working as expected
I started this test, because BRouter’s block road feature sometimes seems to remove waypoints.
I’m not quite sure that I understand the steps to reproduce the report.
You imported a route in what form and with what active routing service(s)?
If not imported it as offline kurviger file, then a route calculation happens.
Here seems a BRouter calculation happens using imported coordinates.
Note that BRouter does not return via points in route instructions.
i.e. BRouter routes know nothing for via points, only start + end.
Also if waypoints exist inside avoided roadblocks, then they’re removed.
Indeed that seems to be the reason.
Note that each router behaves differently and then apps need to process the results.
GraphHopper and Kurviger return 2 instructions per via point. BRouter returns none.
So a post processing must happen, I will see if that’s possible also in BRouter’s case.
Indeed, that was the case.
I imported the route (via bar code from website) while BRouter was set as routing service.
(Step 2 in my description above )
Thank you for your explanation.