I am working on a project where I have been asked to provide the least amount of distance, and its duration as an estimate based up a journey between two or more postcodes in the uk.
e.g. http://maps.googleapis.com/maps/api/distancematrix/xml?mode=driving&TrafficModel=optimistic&sensor=false&language=en-EN&units=imperial&origins=mk109hs, uk&destinations=WC1N 1LE, uk
As part of the google distance api call I am choosing mode=driving.
In terms of the Traffic Model I am choosing optimistic.
Google developer documentation says;
"optimistic indicates that the returned duration_in_traffic should be shorter than the actual travel time on most days, though occasional days with particularly good traffic conditions may be faster than this value."
https://developers.google.com/maps/documentation/distance-matrix/intro
Does this mean;
a.) I should receive the least distance to the destination?
b.) I should receive the least duration to the destination?
The reason I ask is that there could be more miles to travel but does not take as long due to the speed you able to travel at.
For Google Distance Matrix API, the distance it returns is not the shortest distance but it is shortest time. These responses are not calculated taking the traffic into consideration. If there is a path with only 2 miles distance and takes 10 minutes to get there and another path with 3 miles and 8 minutes, distance matrix will return the second path as it gets you to the destination sooner. There is no exact documentation which specifies this in the documentation they have but I use Distance Matrix on a regular basis for a very big application and this is the behavior from the beginning. Hope this helps.
Note: Having the traffic model set to optimal will only return time shorter than the expected but has no impact on the distance.
Related
I am developing an mobile application for recording user trips. A trip is made by sequences of user positions (with longitude and latitude values).
Now my problem is how to determine a trip has been traveled so far? On the other words, how to determine duplicated paths between trips?
(I know that we could not have 2 trips with the exact same data points, hence, I don't know how to begin with, I am looking for an algorithm could approximately address this problem).
Thank for your help!
There are a couple of trajectory distance measures that could help: Euclidean Distance, Dynamic Time Wraping, Edit Distance with Real Penalty, LCSS, ... Which one to pick depends on how you want to define similarity.
In this paper the authors describe all distance measures and evaluate them.
As far as I understand your scenario an LCSS or ERP based similarity measure might fit. A quick search brought me to this Github Repository
If you wanted to know the shortest distance/path between two household addresses, which data structure(s) would you use to return the answer efficiently?
Say you are considering the set of all households in the United States (~100 million).
I am struggling to come up with a practical data structure considering the input size is so big. Dijkstra's seems too inefficient, but I'm guessing there is a way to preprocess the paths to make such a query possible. I'm just not sure where to start.
Dijkstra's algorithm or something very similar it probably is the basis, although you can expect that it's highly optimized. If you put high weights on residential streets and reduce the weight as the roads' capacities increase, you narrow the search space pretty quickly.
You can also expect that there are pre-computed routes between major cities. So if you're in Miami and you want to get to Los Angeles, most of the route is pre-computed. You just need to figure out how to get from the house in Miami to the nearest highway interchange, and from the highway in Los Angeles to the destination.
Consider that the number of ZIP codes is less than 100,000, so it's not unthinkable to have a table that has pre-computed routes from every ZIP code to every other ZIP code. We're only talking 10 billion routes. Stored naively, that'd be a fair amount of data, but it's highly compressible. Consider, for example, if your ZIP code database just contained the route to the nearest major highway. Once you're on the major highways, the amount of data just isn't that large.
Although all of the roads are connected, it's not like you'd treat it as one huge graph. Rather, you have a bunch of smaller graphs--clusters--and you compute the routes between clusters. You'd also have clusters within clusters until the data gets to a manageable size.
At least, that's how I'd go about solving the problem.
The A* algorithm may be used here.
It's essentially an extension of Dijkstra's algorithm, where you add a 'heuristic' to each node's value, which is the estimated distance to the destination.
In this specific case, assuming you have access to the coordinates of each house, you can determine the straight-line distance to the destination as the heuristic.
Visualization:
Beyond this, Jim's suggestions are also good.
I have a quadcopter with some sensors and I want to measure values in set of points on the map (2d problem).
Every measurement takes 30 seconds and I assume copter has constant speed of 60km/h.
It can fly constantly 20 minutes and then it needs to land to charge for an hour.
I would like to write an algorithm, that automatically computes flight paths and minimizes time to take all the samples.
I can represent the points as a full graph (I assume I am flying so high, that there are no obstacles). Then time to reach the point is cost on the edge, but I have also cost of visiting the vertex and limited "fuel". It is some generalization of TSP or VRP, but I am not sure which one.
There are also problems with gas stations, but they usually find path between two points.
Can you name an algorithm that could solve this or come up with something similar. It is NP hard, but there could be some nice approximate solutions.
The problem isn't easy to solve because there is also the fuel constraints and you need to find groups of pods. You can use a combination of a brute force algorithm and a heuristic. For example a quad tree or a spatial index (hilbert curve) can reduce the dimensions and the search space. It looks similar to the capacitated vehicle routing problem.
I'm making this repost after the earlier one here with more details.
PROBLEM :
The problem consists of a marauder who has to travel to different cities spread over a map. The starting location is known. Each city has a fixed loot associated with it. The aim of marauder is to travel across various nature of terrain. By nature of terrain, I mean there is a varied cost of travel between each pair of cities. He has to maximize the booty gained.
What we have done:
We have generated an adjacancy matrix (booty-path cost in place for each node) and then employed a heuristic analysis. It gave some output which is reasonable.
Now, the problem now is that each city has few or more vehicles in them, which can be bought (by paying) and can be used to travel. What vehicle does in actual is that it reduces the path cost. Once a vehicle is bought, it remains upto the time when next vehicle is bought. It is to upto to decide whether to buy the vehicle or not and how.
I need help at this point. How to integrate the idea of vehicle into what we already have? Plus, any further ideas which may help us to maximize the profit. I can post the code, if required. Thanks!
One way to do it would be to have a directed edge bearing the cost of the vehicle towards a duplicate graph with the reduced costs. You can even make it so that the reduction is finer than just a percentage if you want to.
The downside is that this will probably increase the size of the graph a lot (as many copies as you have different vehicles, plus the links between them), and if your heuristic is not optimal, you may have to modify it so that it considers the new edge positively.
It sounds as though beam search would suit this problem. Beam search uses a heuristic function H and a parameter k and works like this:
Initialize the set S to the initial game position.
Set T to the empty set.
For each game position in S, generate all possible successor positions to S after one move by the marauder. (A move being to loot, to purchase a vehicle, to move to an adjacent city, or whatever else a marauder can do.) Add each such successor position to the set T.
For each position p in T, evaluate H(p) for a heuristic function H. (The heuristic function can take into account the amount of loot, the possession of a vehicle, the number of remaining unlooted cities, and whatever else you think is relevant and easy to compute.)
If you've run out of search time, return the best-scoring position in T.
Otherwise, set S to the best-scoring k positions in T and go back to step 2.
The algorithm works well if you store T in the form of a heap with k elements.
In my app, the GPS picks the location of the vehicle. It is then supposed to put markers at all points where the vehicle could be if it drives for 1 KM in any direction (note that the roads may fork many times within his 1KM reach).
Can someone suggest me how to do this? Thanks in advance.
This is a very tricky problem to solve with the Google Maps API. The following is one method that you may want to consider:
You can easily calculate a bounding circle of 1km around your GPS point, and it is also easy to calculate points that fall on the circumference of this circle, for any angle. This distance will be "as the crow files" and not the actual road distance, but you may want to check out the following Stack Overflow post for a concrete implementation of this:
How to calculate the latlng of a point a certain distance away from another?
Screenshot with markers at 20 degree intervals on a bounding circle with a 1km radius:
removed dead ImageShack link - How to calculate the latlng of a point a certain distance away from another?
There is also a trick to snap these points to the nearest street. You can check out Mike Williams' Snap point to street examples for a good implementation of this.
Calculating the road distance from your GPS point to each snapped road point could be done with the directions service of the Google Maps API. Note that this will only work in countries that support directions in Google Maps, but more importantly, the road distance will almost always be greater than 1km, because our bounding circle has a 1km radius "as the crow flies". However if you can work with approximate information, this may already be one possible solution.
You can also consider starting with the above solution (1km bounding circle, calculate x points on the circumference, and snap them to the closest road), then calculate the road distance of each path (from your GPS point to each snapped point), and then you can repeat this this recursively for each path, each time using a smaller bounding circle, until you reach a road distance close to 1km. You can decrease the bounding circle in each recursion, in proportion to the error margin, to make your algorithm more efficient.
UPDATE:
I found a very neat implementation which appears to be using a similar method to the one I described above:
Driving Radius (Multiple destinations)
Note how you can change the interval of degrees from the top. With a wide interval you'll get fast results, but you could easily miss a few routes.
Screenshot:
removed dead ImageShack link - Driving Radius
Natural brute force algorithm is to build a list of all possible nodes taking into account each possible decision on every crossroad.
I doubt that within 1km you would get more then 10 crossroads on average and assuming avg of 3 choices on a crossroad you would end up with 3^10 - around 59,049 end nodes (notice that you need to have 10 crossroads on every branch of the road to reach the full number).
In reality the number would go down and I would assume getting to the same node by different route would not be uncommon, especially in cities.
This approach would give you an exact answer (providing you have good street map as input). It is potential time, but the n does not seem to be that high, so it might be practical.
Further improvements and optimizations might be possible depending on what do you need these nodes for (or which kind of scenarios you would consider similar enough to prune them).
Elaborating a bit on Daniel's approach above, you want to first find all the point within a straight line radius from your origin. That's your starting set of nodes. Now include ALL edges incident to those nodes and other nodes in your starting set. Now check that the nodes are connected and that there aren't any nodes out there floating around that you can't reach. Now create a "shortest path tree" starting from your vehicle node.
The tree will give you the shortest paths from your starting node to all other nodes. Note that if you start by creating paths at the furthest nodes, any sub-paths are also shortest paths to those nodes along the way. Make sure to label those nodes on sub-paths as you continue so you don't need to compute them. Worst case scenario, you need to develop a shortest path for all nodes, but in practice this should take much less time.
List all possible nodes taking into account each possible decision on every crossroad
(But how to do it automatically?
Use Dijkstra`s algorithm to find closes route to all points.
Visualize data.
(That is a little bit tricky, because there can be an unreachable areas inside reachable area.