I am working on a project for shortest path finding. I have looked at alot of resources online to come up with a good algorithm.
I am working with openstreetmap data and it's clear to me that I have to use A* algorithm.
While looking for different solutions, I have found that because a way is made of different nodes, one can prune away the intermediate nodes that are not junctions.
How can I do this in a programming language? If anyone has an idea or a further article that can help me, that would be really grateful.
The exact information I found about this pruning that's relevant to osm is this
parse all ways a second time; a way will normally become one edge,
but if any nodes apart from the first and the last have a link counter
greater than one, then split the way into two edges at that point.
Nodes with a link counter of one and which are neither first nor last
can be thrown away unless you need to compute the length of the edge.
Have a look into the GraphHopper project (where I'm the author of) or other routing projects for OSM already doing this. The idea is to count the number of ways one node is member of and mark nodes as junctions if they have a count of three or more (or just one if an endstanding 'junction').
Still the nodes in-between should be accessible as you need to plot the route for the end results after calculating the route. In GraphHopper we call them pillar nodes (nodes between junctions) and tower nodes (junctions). Here is more detailed information.
Another problem is that you have to calculate GPS precise routes and not just routes from junction to junction. Look into this change how we fixed this via virtual nodes and edges.
Related
You've just input a destination address into your navigation software on your phone. It calculates what it believes to be the route that will take the shortest amount of time.
As you are driving you experience some GPS drift and the navigation software thinks you've taken the offramp on the freeway.
I am wondering from an algorithm perspective, how does the navigation software know to correct itself when it estimates a more accurate location a second later? This question may seem simple, but I am looking for a pretty specific answer.
I am guessing that the application has a graph stored in memory of several nodes which depict different road locations (this is also so that it knows how to plot a line in the right direction). When it guesses you exited at the offramp, it realizes your estimated distance from the node it thinks you went to is too far to be accurate, so it backtracks on the graph and goes the other way and finds the correct node. Is this correct? Or is it much simpler? Does it do a DFS back until it finds the node closest to your current position?
There's very many different navigation systems out there, and they use different algorithms, so I doubt there can be a general answer, but:
What is typically the "textbook" approach to fast navigation is a two-sided slightly modified Dijkstra. In other words, you start from your beginning, and mark all directly connected nodes with the time it'll take you to get there and the node you came from.
Then you repeat that with the nodes connected to these nodes. Rinse, repeat. If you encounter a node that has been seen before, you compare the time your "new" path takes to get there with the one already marked there. Only the shorter one survives.
You do that, alternatingly, from both your start and your destination. (You can be a bit smart – for example, you'll rarely go 50km on back roads in the wrong direction). At some point, both trees "meet". You can basically make a graph cut among all the nodes that you find can be reached from both ends, and use that path that goes through the node of the shortest distance.
Now, back to your problem: Your navigation system finds you've taken a road it didn't expect you to take. No problem, that node can only be one that is directly connected to the node it though you were at – other nodes are unlikely, unless you can teleport. Now, since Dijkstra, as explained above, has already calculated how long it takes to get to that node, it's just a matter of pivoting the tree. Really, pretty standard tactic if you're doing route planning.
So, you have interesting questions! I recommend that, if you haven't, you read about Dijkstra's algorithm.
I need an algorithm to find ANY path from point A to point B in a graph.
The problem is that finding out wich nodes can follow a specific one needs a quite lengthy matlab simulation, so i want to access as few nodes as possible.
I know some heuristics about the graph, I.E. every node has some coordinates and follow-up nodes are always "near" the previous one, but there is not always a connection between two close nodes.
I am not searching for an optimal path, or even a short one. I just need any connection.
My first try was some simple greedy algorithm that always picks a follow up node closest to the final node, but this ended in dead ends very often. This wouldn't be a problem, but i have no idea how to efficiently move out of a deadend, currently i simply move through all nodes inside the dead end until i find a better way.
Here is a drawing of an example where i already know the solution:
There are many nodes, so calculating the edges for every node in this small dead end on the top takes about 1h20min. (You can assume every pixel in the picture is a node.)
To put it in short words: how do i find a good way around the obstacle without looking at every node inside a whole area.
Sorry if this a silly question but i'm an engineer and never had a formal education in programming aside from making a LED blink.
Thanks in advance!
I have undirected, unweighed graph. I have a file that contains list of pairs (connected nodes). Each node may have any number of neighbours. I have to find one or all possible ways to traverse from a specified node to another.
I tried the depth first search - it works pretty well but my friends suggest that it may be pretty slowly. What other algorithms would you suggest? Could you please provide example pseudo code for them?
Problem: I have a large collection of points. Each of these points has a list with references to other points with the distance between them already calculated and stored. I need to determine the shortest route that begins from an origin and passes through a specific number of points to any destination.
Ex: I'm on vacation and I'm staying in a specific city. I'm making a ONE WAY trip to see ANY four cities and I want to travel the least distance possible. I cannot visit the same city more than once.
Current solution: Right now I'm just iterating through every possibility manually and storing the shortest path. This works but feels inefficient. Also, this problem will eventually be expanded to include searching from multiple origin points to multiple destination points, so I think that might explode the search space.
What is the better way to search for the shortest route?
Answering to the updated post, your solution of checking every possibility is optimal (at least, noone has discovered better algorithms so far). Yes, that's a travelling salesman, whose essense is not touching every city, but touching every city once. If you don't want to search for best solution possible, you may find it useful to use heuristics that work faster, but allow for limited discrepancy from ideal solution.
For future answerers: Floyd-Warshall algorithm and all Floyd-like variations are inapplicable here.
In generally you should to strict bad variants...
I think you should use some variations of Branch_and_bound method
http://en.wikipedia.org/wiki/Branch_and_bound
Either bredth first search as norheim.se said or Dijkstra's algorithm would be my suggestion as well.
This sounds Travelling Salesman-esque? One solution is to use an optimisation technique such as an evolutionary algorithm. Currently you are doing an exhaustive search, which will get very slow very quickly. But I think this is pretty much a travelling salesman problem and it has been tackled for several decades if not centuries, and such there are several possible ways of attack. Google is your friend.
Perhaps this is what the original poster means by "iterating through each possibility manually and storing the shortest path", but I thought I'd like to make explicit what appears to be a baseline solution.
Assume you already have a two-point shortest path algorithm--this has classical solutions for various kinds of graphs. Assume all distances are nonnegative and d(A->B->C) = d(A->B) + d(B->C).
The essentials are that the path starts at S goes through one of intermediate cities "abcd" and ends with E:
e.g. SabcdE, SacbdE, etc...
With only 4 intermediate cities, you enumerate all 24 permutations. For each permutation use your shortest two-point algorithm to compute the path from head to tail, and its total distance.
Then given the start and ending point, there are 12 possibilities attaching to one of abcd and for each two possibilities for the interior. You've computed these distances already, so you add on the distance from S to the head and the tail to E. Choose minimum. So once you've precomputed the intermediate distances for a fixed set of interior cities you need to do 12 two point shortest path problems for any pair of start and end points.
This obviously scales poorly with increasing number of intermediate cities. It's not clear to me that it could do better unless you impose greater restrictions on the graph structure (is this in a physical Euclidenan space? Triangle inequality?).
My thought example: suppose all intermediate distances between cities are O(1). With no restriction on the graph, then the distance from S to any intermediate city might be 1000 except for one being 1. Same for the tail. So you can force the first city to be visited to be anything. Now, go one layer down, take the first city as the "start point". Apply the same argument: you can make the best path go to any of the following cities by manipulating the distances in the graph.
So it seems that the complexity can't be helped without additional assumptions.
This is the very common and real time situation any one can fall in.Google map user interface gives you the path in the same order, you add in the destination list. it doesn't give you the optimal path though their own Google maps API provide the solution.
Google maps API provides the solution for this. In the request to find out the path you have to provide the flag 'optimizeWaypoints: true,'. The request will seem like this.
var request = {
origin: start,
destination: end,
waypoints: waypts,
optimizeWaypoints: true,
travelMode: google.maps.TravelMode.DRIVING
};
and you can see whole code of the utility in the view source as complete utility is developed in javascript and HTML.
I hope it will help.
It appears that the edges of your graph are bidirectional. In this case, the algorithm you're looking for is Dijkstra's algorithm.
I am attempting to write (or expand on an existing) graph search algorithm that will let me find the path to get closest to destination node considering there is no guarantee that the nodes will be connected.
To provide a realistic application of this, let's say I need to get from Brampton, Ontario to Hamilton, Ontario. I know my possible options at my start point are Local transit, GO bus or Walking. I know that walking is the least desired way to get to my destination so I look at GO bus first. I know I can take GO to a point close to Hamilton, but at that point the GO bus turns and goes another direction at that closest point is at a place where I have no options (other than walk, but the algorithm would only consider walking for short distances otherwise it will consider the route not feasible)
Using this same example, if the algorithm were to find that I can get there a way that is longer but gets me closer to the destination node (or possible at the destination node) that would be a higher weighted path (The weightings don't matter so much while its searching, only when the results are delivered, it would list by which path was closest to the destination in ascending order). For example, one GO Bus may get me 3km from the destination node, while 3 public transit buses would get me 500m away
So my question is two fold:
1) What algorithm should I start with that does something similar
2) How would I programmaticly explain that it's ok if nodes don't connect so that it doesn't just jump from node A to node R. Would starting from the end and working backward accomplish this
Edit: I forgot to ask how to aim for the best approximate solution because especially with a large graph there will be possibly millions of solutions for this problem.
Thanks,
Michael
Read up on the A* algorithm. It is a generalization of Dijkstra's shortest path algorithm, that allows you to specify a heuristic, which provides a lower bound for distances between two verteces. In your case, the heuristic function would simply return the Euclidean distance.
Run the algorithm and keep track of the vertex with the best characteristic value, which you somehow compute from the graph distance from source and Euclidean distance to target. The only tricky part is to determine when to terminate (unless you want to traverse the entire graph).
Why can't you assume that all nodes are connected? In the real world, they normally are, i.e. you can always walk or call a taxi, etc.?
In this case, you could simply change your model the following way: You have one graph for each transportation method. The nodes that are at the same place are connected with edges of weight 0 (i.e. if you are dropped off by car at an airport or train station).
Then, label each vertex and edge with the transportation type and you can simply use existing routing algorithms. Oh, by the way: A* will not scale well to really big networks. To get something that software like Yahoo/Google/Microsoft Maps actually would use, have a look here. The work of this research group includes the winner of the DIMACS shortest path challenge.
Sounds very much like a travelling salesman problem with additional node characteristics. Just be wary that this type of problem is NP Complete and your best bet would be to go with some sort of approximation algorithm.