I use the Google Maps Matrix API, to estimate the distance between 2 points, the point is that it uses traffic as a parameter to suggest a route which ends up giving a distance greater than the average. And since my application is mainly present in smaller cities, drivers end up following other routes of their own, etc.
So in the Matrix API call I would just like to return the distance from the nearest route.
This is not possible in Google Maps API. I can see that the feature request has already been filed, but unfortunately rejected by Google:
https://issuetracker.google.com/issues/35826943
Here is the answer of Google rep:
The Google Maps API team has reviewed the request for returning the shortest routes for driving directions, as opposed to the fastest routes. After much consideration, we have decided to keep the existing behavior and not implement shortest routes.
We understand there is demand for this feature; however, we believe that using the shortest route rather than the fastest route is not a good idea in practice. When the shortest route is not the fastest, it is likely to be a lower quality route in terms of time, fuel efficiency and sometimes even personal safety. We think these factors are more important to the majority of drivers on the road.
Our primary goal with driving directions is to save time for drivers. Therefore, we do not plan to offer the shortest routes in Google Maps or the Directions API.
There are a few workarounds that could potentially yield shorter routes, but we have found that they have significant drawbacks. We explain these below to clarify why we recommend against them.
Request routes in both directions.
Directions from A to B may not yield a feasible route from B to A due to situations like one-way streets, turn restrictions and different locations of highway exits. Requesting routes in both directions and taking the shortest route may yield a route that is not usable in the one direction.
Request alternative routes.
Adding alternatives=true to the request and picking the shortest route can yield a shorter route than that returned by default.
However, these alternative routes are not generally stable (may change over time as short-term road conditions change) nor guaranteed to include the shortest route. This means that the shortest route may still not be available, and also the shortest route found by this approach may change over time, giving an impression of instability.
Related
I am well aware that this question was asked many times and i've spent days looking through stackoverflow answers but couldn't find anything that goes behind workarounds.
The problem is pretty simple: we need to show exact routes passed by the car (so, from GPS long/lat history data) on google maps and the routes are hundreds or even thousands kms long. What that mean is that we will always exceed waypoints limits by at least an order of magnitude (8 for free or 25 for premium). My gut is telling me that batching GPS locations to batches of 8/25, sending many requests that way and then snap all of those to roads and at the end merge all together into a single route is a bit wild solution.
If we are on a highway then its not that big problem since snap and expected/calculated route will work but if some long route is a combination of highway but also in-town drive through small streets with alot of turning, then i can imagine huge discrepancy between an actual (from raw GPS data) and shown route.
I am wondering if i am missing something? Is there some 'more proper' way to approach this problem?
PS.
I don't need any code at the moment, just a proper way to architecture the idea.
Thanks
[UPDATE]
To put a few numbers into the mix:
1) average route distance is about 1800kms
2) number of raw GPS points generated is about 15000-18000 (every 100-150 meters)
3) number of points that the route must go through (waypoints) is in at least in hundreds and sometimes in thousands (when most of the route is in urban areas)
One possible solution is the Roads API.
Related questions:
draw a path from GEO locations from GPS snapped to road
Google Map Road API not interpolating path and not giving smooth route
Issues
The Roads API doesn't seem ready for prime time (reports of inconsistent results in the issue tracker)
Issue 9436: Roads-API - Snapping point defects
has a limit of 100 points at a time with a (not documented) recommended maximum separation of 400m (reference a comment under the answer to Google Map Road API not interpolating path and not giving smooth route).
You could render the routes as images yourself and load them as an overlay layer on top of google maps.
For example in my website we render weather forecast layers and add them as layers on top of the base map:
http://www.weather.gr/en/maps.aspx
I am developing an application that can show the shortest route using public transport methods (currently only buses). It should include the sections where one can walk some distance to the next stop rather than taking another bus (if its more shorter).
What should be the data structure for the map? I thought of graphical structure with nodes for bus stops. and vertices with distance as weight.
Even if I have found the shortest path using an algorithm (dijkstra) how to implement that walking sections in to the logic.
Without a lot of extra information, it's difficult to give you a great answer to this question, but let me hit some basics. This should be enough to get you going, but then you're going to need to do additional work to develop your solution.
In general, your data structure is going to be something like nodes that represent destinations or waypoints (like a bus stop, or an address). Your relationships will be modes of transportation with associated costs. For example, you can get from point/node A to point/node B via walking, or the bus. Those are two different relationships, with different "costs" in terms of time and money.
In general, you'll want to use a "weighted shortest path" algorithm to find the best way from point A to point B. Neo4j gives you a shortest path function, but in your case you'll need to assign weights to your relationships, and then calculate the shortest path not based on the number of "hops" through the graph, but based on some overall cost metric (time, money, whatever).
Ian Robinson wrote a great post on how to do weighted shortest paths in neo4j. So you should follow a template like that as a starting point.
You have a bunch of design questions to answer though. Do you want the shortest path in terms of time, money, effort, or some combination? The answer to that will affect your graph design, and your query strategy.
I have been working recently with the geocoding API and had a few questions regarding the accuracy of geocoding requests. If I geocode an address using the API and then reverse geocode the coordinates generated from the initial result the two street addresses usually do not match (usually by two houses or so).
Is this an issue with geocoding accuracy or reverse? Is there anything I can do to combat this or is this merely inherent within the API. If so is there any way that I can provide a margin of error when performing these actions, i.e is this inaccuracy documented anywhere?
Obviously it is to be expected that the geocoding API cannot be completely accurate 100% of the time, but I would like to able to see some numbers or documentation on the subject is anyone has any suggestions?
Thanks in advance,
Best,
Chris.
Edit I realise this is an old question but it was never answered and if recently come across the issue again, and have been questioned on this by clients paying for business licences before.
The level of detail in the data that Google has/provides varies from location to location.
The GeocoderLocationType in the GeocoderGeometry you receive indicate how precise the geocoding is:
APPROXIMATE
The returned result is approximate.
GEOMETRIC_CENTER
The returned result is the geometric center of a result such a line (e.g. street) or polygon (region).
RANGE_INTERPOLATEDThe returned result reflects an approximation (usually on a road) interpolated between two precise points (such as intersections). Interpolated results are generally returned when rooftop geocodes are unavailable for a street address.
ROOFTOPThe returned result reflects a precise geocode.
I have written a website that uses the DirectionsService of Google Maps API v3 to find the driving distance between two user-defined locations.
I have found that it produces different results at different times of day or different days of the week.
For example, I have run a journey between Coatbridge and Grangemouth on two separate occasions the first time it told me the distance was 41.8km, the second time it said it was 39.9km.
I suspect it could be influenced by current traffic conditions, perhaps. I have found no clues within the Google documentation.
Has anyone else come across this problem? More importantly, does anyone have a solution?
Edit:
It seems that the influence of current traffic conditions is a known 'function' of the Google Maps DirectionsService (thanks for your input #vitors), but, as yet, no one has come forward with a method to 'turn off' this functionality.
How can I prevent the results being influenced by current traffic conditions? Can anyone help, please?
Edit:
It seems Google have finally added a durationInTraffic parameter (thanks for the info #Ron). Shame it's nearly 2 years too late for me! Hope this is useful for someone else.
You could try setting durationInTraffic as false.
Your suspicion is correct, the result is influenced by traffic conditions.
I think that this post can explain http://searchengineland.com/traffic-estimates-return-to-google-maps-116862.
If you want to provide only one point to the user and it should be the shortest distance, what you can do is, specify the optimizeWaypoints (optional) parameter while calling distance service for Google. After using this option, the first result in the array that you will get will hold your shortest distance and will always be the same:
For more information you can follow this link:
https://developers.google.com/maps/documentation/javascript/directions
and search for optimizeWaypoints
Happy Coding.
Is there a way using the Google Maps API to get back an "optimized" route given a set of waypoints (in other words, a "good-enough" solution to the traveling salesman problem), or does it always return the route with the points in the specified order?
There is an option in Google Maps API DirectionsRequest called optimizeWaypoints, which should do what you want. This can only handle up to 8 waypoints, though.
Alternatively, there is an open source (MIT license) library that you can use with the Google Maps API to get an optimal (up to 15 locations) or pretty close to optimal (up to 100 locations) route.
See http://code.google.com/p/google-maps-tsp-solver/
You can see the library in action at www.optimap.net
It always gives them in order.
So I think you'd have to find the distance (or time) between each pair of points, one at a time, then solve the traveling salesman problem yourself. Maybe you could convince Google Maps to add that feature though. I guess what constitutes a "good enough" solution depends on what you're doing and how fast it needs to be.
Google has a ready solution for Travel Salesman Problem. It is OR-Tools (Google's Operations Research tools) that you can find here: https://developers.google.com/optimization/routing/tsp
What you need to do basically is 2 things:
Get the distances between each two points using Google Maps API: https://developers.google.com/maps/documentation/distance-matrix/start
Then you will feed the distances in an array to the OR-Tools and it will find a very-good solution for you (For certain instances with millions of nodes, solutions have been found guaranteed to be within 1% of an optimal tour).
You can also note that:
In addition to finding solutions to the classical Traveling Salesman
Problem, OR-Tools also provides methods for more general types of
TSPs, including the following:
Asymmetric cost problems — The traditional TSP is symmetric: the distance from point A to point B equals the distance from point B to
point A. However, the cost of shipping items from point A to point B
might not equal the cost of shipping them from point B to point A.
OR-Tools can also handle problems that have asymmetric costs.
Prize-collecting TSPs, where benefits accrue from visiting nodes
TSP with time windows
Additional links:
OR-tools at Github: https://github.com/google/or-tools
Get Started: https://developers.google.com/optimization/introduction/get_started
In a typical TSP problem, the assumption is one can travel directly between any two points. For surface roads, this is never the case. When Google calculates a route between two points, it does a heuristic spanning tree optimization, and usually comes up with a fairly close to optimal path.
To calculate a TSP route, one would first have to ask Google to calculate the pair-wise distance between every node in the graph. I think this requires n*(n-1) / 2 calcs. One could then take those distances and perform a TSP optimization on them.
OpenStreetMaps.org has a Java WebStart application which may do what you want. Of course the calculations are being run client side. The project is open source, and may be worth a look.
Are you trying to find an optimal straight line path between locations, or the optimal driving route? If you just want to order the points, if you can get the GPS coordinates, it becomes a very easy problem.
Just found http://gebweb.net/optimap/ It looks nice and easy. Online version using google maps.