Hi I am creating an android app that will generate a cycling route for users using a route finder.
I am trying to allow the user to either prefer distance or routes with cyclelanes present.
I have a slider from 0 to 10, where 0 means the user wants the shortest route, and 10 where the user wants roads with cyclelanes (if available).
The roads are represented as a graph and I have a function that calculate the shortest path from one point to another.
Given the output of this function: if there is a cyclelane present on the road I want to weight the result so that the higher the number the user chose, the lower the cost of the road and vice versa.
I am not really sure how weighted functions work.
if you calculate the route with dijkstra-like algorithm, in case of a cyclelane-edge, you should simply decrease the distance between two point by some value according to the slider-value
Related
I have a number of locations between which I want to know the travel time and distance.
The locations have been correctly geocoded. However, the problem I am experiencing is that some of the locations lie between a regular road and a motorway. In fact, they lie closest to the motorway.
In this case, the travel time and distance I receive consider the location to lie on the motorway (the closest road), which leads to an incorrect estimation of the actual travel time and distance.
Given that I cannot manually adapt each geocode to lie closest to the regular road, I need a different solution.
I included 'street!!' in my call as indicated on https://developer.here.com/api-explorer/rest/routing/route-to-location-near-motorway but to no avail.
My call looks like this "https://matrix.route.api.here.com/routing/7.2/calculatematrix.json?start0=x.x,y.y&destination0=street!!x1.x1,y1.y1&mode=fastest;car;traffic:disabled&summaryattributes=traveltime,distance&app_id=...&app_code=...".
Is there another way to avoid that Here puts the destination on the motorway?
Your help would be greatly appreciated. Thank you in advance!
Below you find one example
Geocodes of departure: 51.090995,4.018793
Geocodes of destination: 51.017960,3.694040 (close to E40/A10 in Belgium)
When I use the matrix routing API, I get a distance of 29799 meters and a travel time of 1317 seconds.
My call:
"https://matrix.route.api.here.com/routing/7.2/calculatematrix.json?start0=51.090995,4.018793&destination0=street!!51.017960,3.694040&mode=fastest;car;traffic:disabled&summaryattributes=traveltime,distance&app_id=...&app_code=..."
When I use the routing API to get the directions, I can see that my destination is updated to 51.0187054,3.6935735, which is on the E40/A10. This gives me a distance of 29827 meters and a travel time of 1335 seconds.
I used the call below:
"https://route.api.here.com/routing/7.2/calculateroute.json?app_id=...&app_code=...&waypoint0=51.090995,4.018793&waypoint1=street!!51.017960,3.694040&mode=fastest;car;traffic:disabled"
Given that the distance and travel time differs, I executed my matrix routing API call again with the updated destination geocodes (51.0187054,3.6935735). This provided me with the same distance and travel time as my initial matrix routing request, i.e. 29799 meters and 1317 seconds.
I used this call:
"https://matrix.route.api.here.com/routing/7.2/calculatematrix.json?start0=51.090995,4.018793&destination0=street!!51.0187054,3.6935735&mode=fastest;car;traffic:disabled&summaryattributes=traveltime,distance&app_id=...&app_code=..."
As such, I am sure the destination is on the E40/A10. How can I avoid this?
On a related note, why do the travel time and distance differ between the matrix routing API and the routing API?
When I enter the geocodes in GoogleMaps, I actually get the position I wanted.
As you can see, it is not on the E40. Why can't I get a route to the nearest regular street?
So taking the example you gave, the destination waypoint 51.017960,3.694040 lies very close if not on the E40/A10 itself. See image below:
Moreover, using our reverse geocoder API to get the list of address within 200m radius of the destination waypoint returns only addresses (points) along the E40, 9052 Gent, België with street match level . There is therefore no way for the algorithm to know which nearby street you intend to arrive when the waypoint is many hundreds of metres off. I will suggest to correct your waypoints using our reverse geocoder api to determine which waypoints are way off your intended address.
There is a grid G .
G(i,j)=-1 implies path blocked.
Otherwise G(i,j) = number of coins at (i,j).
Always start from point start point (0,0) goto end point (n,n) then come back to start point (0,0). Once coins at any location is collected it can't be collected again. However you can still have a path through that location.
What is the maximum number of coins that can be collected if you can travel in top, bottom, left, right directions?
I know how to get the maximum number of coins when you only have to go from (0,0) to (n,n) using recursion but not able to track which coins I have already collected while traveling from start to end.
Please suggest a good approach or refer to some source.
Task specification doesn't require the path to be shortest nor to avoid repeated visit of field. So if the point (n,n) is reachable from point (0,0), the result is effectively sum of all points reachable from them (which can be computed using Flood-fill algorithm); zero otherwise.
Frankly, I suppose you omitted some important constraint in the task specification. Until fixed, it's hard to guess which algorithm is the best solution (for example Dijkstra when looking for shortest path, dynamic programming when moves restricted to right and down etc.).
As your question does not have any restriction on how many steps can be performed. You only need to add up the value of all grids as you can potentially pick up all coins by walking over all grids.
Consider a network(graph) of N nodes and each of them is holding a value, how to design a program/algorithm (for each node) that allows each node to compute the average(or sum) of all the node values in the network?
Assumptions are:
Direct communication between nodes is constrained by the graph topology, which is not a complete graph. Any other assumptions, if necessary for your algorithm, is allowable. The weakest one I assume is that there's a loop in the graph that contains all the nodes.
N is finite.
N is suffiently large such that you can't store all the values and then compute its average (or sum). For the same reason, you can't "remember" whose value you've received (thus you can't just redistributing values you've received and add those you've not seen to the buffer and get a result).
(The Tags may not be right since I don't know which field this kind of problems are in, if it's some kind of a general problem.)
That is an interesting question, here some assumptions I've made, before I present a partial solution:
The graph is connected (in case of a directed graph, strongly connected)
The nodes only communicate with their direct neighbours
It is possible to hold and send the sum of all numbers, this means the sum either won't exceed long or you have a data structure sufficiently large, which it won't exceed
I'd go with depth first search. Node N0 would initiate the algorithm and send it's value + the count to the first neighbour (N0.1). N0.1 would add it's own value + count and forward the message to the next neighbour (N0.1.1). In case the message comes back to either N0 or N0.1 they just forward it to another neighbour of theirs. (N0.2 or N0.1.2).
The problem now is to know, when to terminate the algorithm. Preferably you want to terminate it as soon as you've reached all nodes, and afterwards just broadcast the final message. In case you know how many nodes there are in the graph, just keep on forwarding it to the next node, until every node will be reached eventually. The last node will know that is had been reached (it can compare the count variable with the number of nodes in the graph) and broadcast the message.
If you don't know how many nodes there are, and it's and undirected graph, than it will be just depth first implementation in a graph. This means, if N0.1 gets a message from anyone else than N0.1.1 it will just bounce the message back, as you can't send messages to the parent when performing depth first search. If it is a directed graph and you don't know the number of nodes, well than you either come up with a mathematical model to prove when the algorithm has finished, or you learn the number of nodes.
I've found a paper here, proposing a gossip based algorithm to count the number of nodes in a dynamic network: https://gnunet.org/sites/default/files/Gossipico.pdf maybe that will help. Maybe you can even use it to sum up the nodes.
Given a directed graph with multiple start nodes and multiple end nodes, I need to form paths that visit every reachable edge, but I cannot visit any edge (or vertex) more than once during a single pass. [This is to electrically test every connection in a network by sending signals from start to end nodes, but I cannot allow paths to short together.]
Because I cannot re-visit edges during a single pass:
I can safely ignore the cycles in the graph.
I know each path I form will block other paths.
Consequently, I cannot visit every reachable edge in one pass, so multiple passes are necessary.
From context, I know that the minimum number of passes will be the maximum number of edges entering any vertex. Once I finish a given pass, I am free to re-visit edges that were visited in previous passes, but never-visited edges are the ones that I most want to visit.
I would like to visit "many" edges per pass, so that I can reduce total the number of passes, but I do not strictly need to minimize the number of passes.
Any suggestions on algorithms to accomplish this? It sounds a little like the route inspection problem, except that my graph is directed.
It is not clear from the question whether you have one or many start points and one or many end points. For simplicity let me assume "one-to-many" network. Then your requirement (not visit any edge or vertex more then once) means you actually generate a spanning tree of your graph with the given root.
A simple but not 100% solution that comes to mind is the following:
Assign some initial weights to the edges and apply random spanning tree algorithm. Then decrease the weight (actually, relative probability) of visited edges. It is very likely all edges will be visited.
In the case of "many-to-many" connection you can play with different starting points. If some sources are not connected to some sinks the algorithm would throw an exception. If this is not what you inspect, you can run regular DFS first to collect all reacheable vertices into some set; then you can use this set as a filter to form a boost::filtered_graph.
I'm new to SQL and learning about Adjacency Lists, Nested Sets, Closure Tables, but from what I understood, these solutions usually apply to acyclic data.
I'm aware that this sort of problem may be better suited to a graphical database engine such as Neo4j, and I am exploring that also. But for this question, I specifically want to know if I can achieve this goal in SQLite.
Before running off with a possible answer for this, please help me understand how to better define or illustrate the problem. Once the problem definition is refined, then point me in the right direction (technique, reference material) and let me try to figure it out.
Objectives:
Maintain a list of areas and how they are connected.
Areas can have different types: Country, Highway, State, City, Neighborhood.
Areas can be connected in cycles (undirected).
Areas can have multiple exits.
Maintain a weighted list from one exit to another, within the area.
Extract optimal path from one area to another (from this neighborhood to nearest highway).
Assumptions:
Will use SQLite 3 (newest version).
Small data set ( < 1,000 areas and connections, < 5s DB creation).
Relatively static ( < 5 inserts or updates/year ).
May be simpler to recreate database from scratch than update?
Highways are areas, not connectors.
Streets are logical connectors, no length, no weight.
Areas and connections are like a house with many rooms with multiple doors. The doors connect the rooms. There is no traversal weight going through a door. The weight in selecting a door comes from the distance between the doors. A hallway is like an extended door, so it has a weight and is considered a type room. A room may have a large size, but if the only two doors are near each other, it may have a small weight. it's not the size of the room that counts for my purposes, but the distance between the doors.
As always, thank you for taking the time to read, and for constructive comments.
Yes, it is possible to use SQLite to store this kind of data.
It is not practical, and you may have performance issues. If you plan to store huge amount of such data and want a well scalable solution, you should go for some graph DB.
If you are gong to store ~1000 nodes, that can work with simple realtions in SQLite.
Especially since you are going to have very little number of updates, you could pre-calculate the distances. So you don't have to actually recalculate it each time, but just load from the DB.
I think you should represent your problem as a graph.
Nodes could be the "doors" and edges the distances between them.
You could store this easily in relational database. (Areas(Id,Name), Doors(Id,Area1,Area2) DoorDoorDistance(Door1, Door2, Distance))
If you have stored these data, you can calculate shortest path from every door to every other. You could store this in a new table. (Distances(Door1,Door2,Path, Distance))
To calculate shortest path you can find different algorithms:
Shortest path algorithms
After this you have the shortest path between each pair of doors.
The only question from now is witch door to take from your starting area to which door in your destination area.
If you don't want to be this precise you just take the one with the shortest path. Otherwise you have to maintain door distances from area starting points.
A; You can can assume that you start from the center of the area, so you can store door distances from the center
B; You can be more precise, by storing exact door locations and calculating door distances from an exact starting point.
In both cases you should select door with the lowest cost, both in the starting area and the destination area:
Total cost: (Walk to door distance) + (starting Door to destination Door Path) + (Walk to destination in the destination area)
I would do this like this. I hope I helped, have fun!