Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Before routing, how do I find the correct "PhantomNodes" through the start point? #6234

Closed
GitBenjamin opened this issue Apr 19, 2022 · 10 comments
Labels

Comments

@GitBenjamin
Copy link
Contributor

GitBenjamin commented Apr 19, 2022

When the start point(lat, lon) is in the center of a two-way road, should I choose the left or right side of the road? Maybe the start point is actually on the left side of the road, but the result is to return to the “Phantom node” on the right.

Is there any way to correct these results?

such as:
1
2
3

note:
1、the blue point is the start point of the input's latitude and longitude;
2、the red line is the result of osrm;
3、the green line is the correct result;
4、in the third picture, the red line is the trajectory of the car before the routing;

Is this problem the same as #5073 ?
If i need to modify the code, can i start with "GetPhantomNodes"?
@michael Krasnyk @JackDanger

I hope I can get your help!Thanks!

@GitBenjamin GitBenjamin changed the title Before routing, how do I find the correct "PhantomNodes" through the start_point(lat, lon)? Before routing, how do I find the correct "PhantomNodes" through the start point? Apr 19, 2022
@philipphueber
Copy link

philipphueber commented Apr 28, 2022

i fixed this problem in my display route function by checking if any point on the route is closer than x meters to the destination and if so stop my display routine there...

For your start you can do the same but instead of stopping just removing everything before...

(might not be pretty but functions)

@GitBenjamin
Copy link
Contributor Author

i fixed this problem in my display route function by checking if any point on the route is closer than x meters to the destination and if so stop my display routine there...

For your start you can do the same but instead of stopping just removing everything before...

(might not be pretty but functions)

Thank you for your answer. But, my problem seems to have nothing to do with your method.
My problem is how to more accurately relate the starting point to the correct segment through the input information.

@philipphueber
Copy link

I don't think that tere is any (efficient/ sensical) way to accomplish this as you basically need to know the route to know on wich side of the highway you need to start

(using the heading to the destination might come to mind first but that won't work bc the best route might not head in this direction initially)

So you would need to get an initial wrong route, find the "wrong" u turn (should work with a similar idea to what i described previously) then get the resulting right starting point and calculate that again from there....

And that would be just a stupid idea because u would senselessly do 2 routing calculations for nothing

There might be a way doing this with the osm mapdata and placing the point on the nearest street but that street might also have the wrong heading as u don't know what the router wants to do before you get the route

@philipphueber
Copy link

http://project-osrm.org/docs/v5.24.0/api/?language=cURL#match-service

might potentially work but even then it could snap to the wrong side (i am pretty sure thats what is used inside the router anyway)

@danpat
Copy link
Member

danpat commented Apr 29, 2022

If your origin point is from a vehicle, and you know the approximate direction of travel (and you trust it), then you can use the bearings= parameter to the request to filter out snapping to roads that aren't going the right direction for your vehicle, even if they're closer.

@GitBenjamin
Copy link
Contributor Author

I don't think that tere is any (efficient/ sensical) way to accomplish this as you basically need to know the route to know on wich side of the highway you need to start

(using the heading to the destination might come to mind first but that won't work bc the best route might not head in this direction initially)

So you would need to get an initial wrong route, find the "wrong" u turn (should work with a similar idea to what i described previously) then get the resulting right starting point and calculate that again from there....

And that would be just a stupid idea because u would senselessly do 2 routing calculations for nothing

There might be a way doing this with the osm mapdata and placing the point on the nearest street but that street might also have the wrong heading as u don't know what the router wants to do before you get the route

yeah, i tried using the "bearings=" parameter to correct the starting point binding. i had an idea that i could use the direction of the car to calculate bearing, but i am not sure what is the best way to determine "the range of the bearing".
bearing {value},{range} integer 0 .. 360,integer 0 .. 180
Does range mean smaller is more accurate?

Thank you for your answer, which inspired me a lot.

In addition to, I don't really understand what snap does.

@GitBenjamin
Copy link
Contributor Author

If your origin point is from a vehicle, and you know the approximate direction of travel (and you trust it), then you can use the bearings= parameter to the request to filter out snapping to roads that aren't going the right direction for your vehicle, even if they're closer.

Thank you for your answer.
This method really helped me a lot with my problem.

@danpat
Copy link
Member

danpat commented May 1, 2022

i am not sure what is the best way to determine "the range of the bearing".

The "range" is the plus/minus the routing engine will allow - so if you set the range to "1", then it will filter out roads that are more than +/- 1 degree different to the value you supply.

I would suggest a broad range is usually what you want - like 60 or 90, which gives you lots of wiggle room for inaccuracy in your measurement, but will still filter out roads that generally head in the opposite direction, which is mostly what folks want.

@GitBenjamin
Copy link
Contributor Author

I would suggest a broad range is usually what you want - like 60 or 90, which gives you lots of wiggle room for inaccuracy in your measurement, but will still filter out roads that generally head in the opposite direction, which is mostly what folks want.

Thank you. I can experiment with that logic. It helped me a lot.

Copy link

github-actions bot commented Jul 8, 2024

This issue seems to be stale. It will be closed in 30 days if no further activity occurs.

@github-actions github-actions bot added the Stale label Jul 8, 2024
@github-actions github-actions bot closed this as not planned Won't fix, can't repro, duplicate, stale Aug 8, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

3 participants