car routing then direct line

[abdullahO2]

Thank you for your efforts in this software, and I tried it and found it useful and wonderful, but in my country (Saudi Arabia) there are large desert areas without roads and sometimes we need to go to a place inside that desert, and BRouter does not support routing for places where there are no roads, so I have a suggestion to put a profile that supports A route to the nearest nearby road and then puts a direct line to the specified waypoint, and this solution is found in many applications such as Navitel and Osmand (example):

If this solution is possible, please guide me on how to do it, thank you

[abrensch]

No, in BRouter-(Web), Waypoints are always matched to the routable-network.

There's a hidden feature for some sort of "beeline-routing", by putting a nogo-circle over 2 Waypoints ( see here for details: https://www.marcusjaschen.de/blog/2021/brouter-direkte-verbindung-zwischen-zwei-wegpunkten/ )

that's good if you need a connection within your route where there's no mapped way. But it doesn't help you for off-road start- or detination-points.

[abdullahO2]

Thank you, I was hoping to find this solution for applications that depend on BRouter, like Orux, Locus and others, Regards

[polyscias]

It is not that if Brouter would add support for direct lines, Apps like Orux, Locus and OsmAnd would directly support direct lines, these Apps have to communicate their desires to BRouter and such new functionality will need code changes in these Apps.

In the link @abrensch posted you can see BRouter has already a way to do this using No-Go-Area's the problem is on the App side to support this. Note that Apps might also support this but just calling Brouter multiple times, only for the pieces so the route where the user wants routing.

Adding this functionality to the Apps, see also Allow straight lines #68 seems to be the hard problem, especially the user interface. So if you want this, you better check these Apps, see if there is already a "direct line" request and if not add one.

[abdullahO2]

Thank you very much for explaining that, regards

[abdullahO2]

Related discussion:
devemux86/cruiser#204

[abdullahO2]

@afischerdev @abrensch Does the current state of development allow for the development of something for this proposal? This is a video to understand the intended proposal:
straight line - normal routing - straight line
and here are clips demonstrating this feature in other applications and drawing a direct line without user interaction:
https://youtu.be/yvXSpP_dkdQ
https://youtu.be/1dD6SDb0Z6Q
https://youtu.be/3Gu9WlyYLRc
This feature is especially crucial for us in our country, where many places are not accessible by roads, but it is still possible to drive a car through them. Incorporating this feature into the application would make a significant difference to users, and we hope you will consider our suggestion.

Thank you for your attention to this matter.
Best regards,
Abdullah Abdulrahman

[devemux86]

@abdullahO2

Do you ask BRouter to automatically generate straight lines when waypoints are far from the road?
Start and end waypoints or also via points?

All of these seem more suitable for implementation in applications than on the router.

I know I said to implement it in Cruiser. 🙂

[abdullahO2]

@devemux86 Thank you so much for explaining that! I understand it makes more sense to handle the "straight line" feature on the app side, given what you've said about complexity and user experience. My knowledge of the development side is limited, so I really appreciate you shedding light on this approach. I'll keep an eye out for updates in Cruiser!

[afischerdev]

Sorry for the delay. I had to reactivate my code for this feature.
I have solution that works almost as expected.

But this is in a developer state and need more action.
Example with other context - boat should not go across the shore:

And I had some miraculous results - endpoints are very near to each other:

I'll go on with this, but my time is very rare, so it will take a while.

[devemux86]

@afischerdev

How does it work, is it optional?
Because there will be users who don't like routes outside the road network.

Does it generate straight line instructions at start / end?

[afischerdev]

@devemux86

How does it work, is it optional?

Yes, the plan is a switch for the profiles, something like enableDynamicDistance .

Does it generate straight line instructions at start / end?

Yes, when distance between waypoint and crosspoint greater then x then a beeline is created.
May be you like to have a look at this export.
testtrack0.gpx

[devemux86]

@afischerdev

Thanks, it already looks good!

Will it also be available in other export formats, such as geojson?

[afischerdev]

@devemux86
Yes, all export formats

[abdullahO2]

@afischerdev and @devemux86

I am absolutely thrilled to see this progress! Thank you both so much for your hard work and dedication to this feature. It's incredibly encouraging to see it coming to life. Knowing that it will be optional and available in multiple export formats is fantastic.

This functionality will be a game-changer for users in areas with limited road networks, like where I live. Your efforts are truly appreciated and will make a significant difference.

Thank you again for considering this proposal and for all the progress you've made. I'm eagerly looking forward to seeing the final implementation!

Best regards,

Abdullah Abdulrahman

[devemux86]

@afischerdev Thanks for this implementation!

I started testing the API and the received routes from BRouter (GeoJSON format).
(tested with assign use_dynamic_range = true)

The voice hints seem to be missing at the start of beelines?

• Route 1: there are not any voice hints.
• Route 2: there is only 1 beeline voice hint at the start of 1st beeline.

[afischerdev]

@devemux86
Thanks for the nice samples

Route 1: I can follow this and get same result - no voicehints in json. But I have two in Locus export (gpx, timode02)
I'll take a look.

Route 2: looks alright for me. First point has a beeline voicehint, a second voicehint at junction. The last point does not meet the generate beeline rule - it is less then 250m away from street. Please see this

[afischerdev]

I think I found the reason:
When we have no detours we don't generate voicehints.
Please see
I'll prepare a PR later on.

[devemux86]

@afischerdev Thanks, now it seems to work ok. 👍

I included it into the latest Cruiser for more user testing:

• BRouter (offline) use distant waypoints for off-road routes devemux86/cruiser#204 (comment)

[abdullahO2]

@afischerdev @devemux86
I would like to report a performance issue I noticed after enabling the "Use distant waypoints" feature along with routing on roads tagged with highway=track. The application lags significantly when calculating the route in this case.

Could you please try this on roads with the same tag (highway=track) to verify the issue? I hope there is a solution to improve performance in this case.

Thank you very much.

[devemux86]

@abdullahO2 Can you provide a route example as BRouter website link?

Also please mention what profile you use and what routing options.

[abdullahO2]

I used this profile:
Car profile.txt

Maybe there was a mistake in my editing of the profile that caused this problem, or maybe there was a problem with the map data.

[abdullahO2]

@abdullahO2 Can you provide a route example as BRouter website link?

Also please mention what profile you use and what routing options.

https://brouter.de/brouter-test/#map=7/24.431/49.015/standard&lonlats=47.21911,25.997484;51.294883,21.534438

[devemux86]

@afischerdev This profile is the car-fast with use_dynamic_range enabled and new lines 62-63:

switch highway=track	                    1
switch highway=road	                    1

[devemux86]

This route does not seem to work even with the default car-fast profile and use_dynamic_range.
It reports the error "target island detected for section 1".

[afischerdev]

With the car profile I got the same error message. With the trekking profile I got a route.
I'll look after this.

[afischerdev]

As I said the trekking profile delivers a route.
I didn't control all roads, but a road near to target has a highway=track and that is not defined in variable caraccess.
When you add a line like

switch and highway=track use_dynamic_range 1

You will get a route.
So I think an offroad profile should enable that.

[devemux86]

@afischerdev The mentioned profile above contains the use_dynamic_range.

[afischerdev]

@devemux86
Ok, I only had a look at the standard profile.
But with this custom profile I get the same route. For me it works.

[devemux86]

@afischerdev Do these changes also affect the correctMisplacedViaPoints?

There was a report that it no longer works, unfortunately without more details or a route example:

• Cruiser 5.1.0 (Beta) devemux86/cruiser#671 (comment)

[afischerdev]

@devemux86
That was not the plan. I'll test it.

[afischerdev]

@devemux86
Here are my results for the parameter profile:correctMisplacedViaPoints=1
Example

Note: this only works in the library. The web client collects data segment by segment.

[devemux86]

@afischerdev Thanks very much for checking this! 👍

The web client collects data segment by segment.

I forgot this part. 🙂

[devemux86]

@afischerdev

Can you check if alternative routes work with the latest code?
I always receive the same route regardless the alternativeidx.

While alternatives exist and I can get them with the 1.7.7 code.

We had a report here:

• Cruiser 5.1.0 (Beta) devemux86/cruiser#671 (comment)

[afischerdev]

@devemux86
Thanks for the hint. It seems so. On a short test brouter web against brouter test it doesn't work.
I'll have a deeper look.

[devemux86]

@afischerdev The problem seems to be from commit 504f819.
Without this change the alternative routes work again.

[afischerdev]

@devemux86
Yes, I think so. I've found it as well.
But I'm fighting against some other things of current version. I can't say if I find that today - have to leave soon.

[afischerdev]

@devemux86
Alternative routes and END point calculation should run in a better way now. Please see #742.
Available also on test server

[devemux86]

@afischerdev Thanks, now it seems to work properly. 👍