I am making a routing application on Android when user can input the amount of hours to travel a place and my application would give an output of possible route users can travel.
I am using genetic algorithm (GA) to give the route to the user, and I use PHP to execute my GA.
Here comes the problem, in order for routing to be effective, I need to know distance between each city to verified if the route is possible and the distance in minimized. How to store distance between each city in order to make the execution faster? I have tried to get the distance directly
from Google Maps API but it takes longer execution time.
I was thinking to store the distance to json file, but is it possible? Or is there another effective ways?
Note that the destination will be dynamic. Users can add a new destination, so whenever there is a new destination the matrix distance needs to be updated.
Please help me :) Thank you.
You know the initial position of the user and want to know different destination distances. I suggest you to use single source shortest path deterministic algorithm like Dijkstra instead of evolutionary algorithm. The implementation based on a min-priority queue implemented by a Fibonacci heap running in O(E.logV) where E is the number of edges and V is the number of vertices. It runs much faster than genetic algorithm and also find the best answer instead of some approximate one. It also has the property that finds the first nearest destinations first which is suitable for you.
Related
So I'm tracking a number of vessels as they travel across the ocean, creating a LINESTRING() in MySQL once I've gotten all the known GPS points from departure to arrival. Sometimes, however, I'm able to find additional points after creating the linestring, sometimes without associated time data.
So my question is: What would be the simplest way to take a linestring and add a point to it? It's reasonable to assume that, point by point, the LINESTRING doesn't change direction much and that it should be possible to deduce mathematically between which points the new point should be placed; but I can't seem to figure it out.
My solution so far finds which given coordinate on the LINESTRING is the closest, but I haven't been able to figure out the math that decides whether it should come before or after. Maybe the solution involves finding out which part of the linestring the point is closest to and then inserting it between the two coordinates that define that part of the line?
A possible answer...
Sort the GPS points by either latitude or longitude. Pick the one that has the most variation. Then construct the string that defines a line.
If the line is not "straight" or arcs in certain ways around the globe, or has to maneuver around a peninsula, or ..., the algorithm is to simplistic. Also, if the error in GPS is sometimes greater than the distance between two 'consecutive' points, the algorithm is flawed.
I try to create a system for detecting if a sporter is on the route that he has to do. Therefor I have a component where I can draw the route they should do. That route is stored in mysql, using LINE.
The next step I do is when I have a coordinate of the user, is finding if the distance between the user and the line. I use for that this query:
select *, st_distance(point(50,2),map_points) from tbl_route_new
This returns good information (I think), but this is how I see the information:
3.7770580579682638
Can someone tell me how I can know what the real distance is. I think this is in degrees. If I try some converters I find across the Internet I get a value, but that value is wrong unfortunatly.
If this isn't possible, then I will use PHP to do the calculations, but I think mysql is faster, then a loop over all the points.
I am working on a mobile web site for a MS Bike event. I already have geo code for tagging email requests, and a check-in site to check riders in to a location based on their location. I would like to add the distance to the next rest stop / finish. I know how to figure out the distance between two locations. And all my research on this, it to allow Google to provide the route. But since this is an event, there is a predetermined route that the riders ride.
Does anyone have any ideas on how to tackle this? I have the Lat/Long of the routes (each corner and turn) and I have it in a kml format.
If the resolution of the way-points is distinct enough I can see two cases: The nearest way-point is either the next point or was the previous point:
So if you not only calculate the distance to the nearest point but also to the previous and next to it, you should be able to simply decide which one the next is.
As written, this requires that the resolution between the points is good enough. E.g. if you have a course with a 180 degree curve things don't evaluate that well any longer:
The solution is to have enough way-points in these areas then. So this might or might not be suitable for your problem. Sorry for the trashy graphics, but I hope they illustrate this well enough. Also the concept is a bit rough, but probably good enough to create a first mock.
I need to be able to quickly find n closest destinations for a given destinations, calculate n x n distance matrix for n destinations and several other such operation related to distances between two or more destination.
I have learned a Graph DB will give far better performance compared to a MySQL database. My application is written in PHP.
SO my question is - Is it possible to use Graph DB with a PHP application, If yes then which one is the best option and opensource and how to store this data in graph DB and how would it be accessed.
Thanks in advance.
Neo4j is a very solid graph DB and has flexible (if a bit complex) licensing as well. It implements the Blueprints API and should be pretty easy to use from just about any language, including PHP. It also has a REST API as well, which is about as flexible as it gets, and there is at least one good example of using it from PHP.
Depending on what data you have, there are a number of ways to store it.
If you have "route" data, where your points are already connected to each other via specific paths (ie. you can't jump from one point directly to another), then you simply make each point a node and the connections you have between points in your routes are edges between nodes, with the distances as properties of those edges. This would give you a graph that looks like your classic "traveling salesman" sort of problem, and calculating distances between nodes is just a matter of doing a weighted breadth-first search (assuming you want shortest path).
If you can jump from place to place with your data set, then you have a fully connected graph. Obviously this is a lot of data, and grows quadratically as you add more destinations, but a graph DB is probably better at dealing with this than a relational DB is. To store the distances, as you add nodes to the graph, you also add an edge to each other existing node with the distance pre-calculated as one of it's properties. Then, to retrieve the distances between a pair of nodes, you simply find the edge between them and get it's distance property.
However, if you have a large number of fully-connected nodes, you would probably be better off just storing the coordinates of those nodes and calculating the distances as-needed, and optionally caching the results to speed things up.
Lastly, if you use the Blueprints API and the other tools in that stack, like Gremlin and Rexter, you should be able to swap in/out any compatible graph database, which lets you play around with different implementations that may meet your needs better, like using Titan on top of a Cassandra / Hadoop cluster.
Yes, a graph database will give you more performance than an extension for MySQL or Postgres will be able to. One that looks really slick is OrientDB, a there's a beta implementation in PHP using the binary protocol and another one that uses HTTP as the transport layer.
As for the example code, Alessandro (from odino.org) wrote a implementation of Dijkstra's algorithm along with a full explanation of how to use it with OrientDB to find the minimum distance between cities.
Actually it's not that much about database as about indexes. I've used MongoDB's geospatial indexing and search (document DB), which has geo indexing designed for finding multiple nearest elements to given coordinates - with good results. Still - it runs only simple queries (find nearest) and it gets a bit slow if your index doesn't fit in the RAM (I've used geonames DB with 8mln places with coordinates and got 0.005-2.5s per query on VM - 1. hdd overhead 2. probably the index didn't fit in the RAM).
I am designing a web app where I need to determine which places listed in my DB are in the users driving distance.
Here is a broad overview of the process that I am currently using -
Get users current location via Google's map api
Run through each place in my database(approx 100) checking if the place is within the users driving distance using the google places api. I return and parse the JSON file with PHP to see if any locations exist given the users coordinates.
If place is in users driving distance display top locations(limited to 20 by google places), other wise don't display
This process works fine when I am running through a handful of places, but running through 100 places is much slower, and makes 100 api calls. With Google's current limit of 100,000 calls per day, this could become an issue down the road.
So is there a better way to determine which places in my database are within a users driving distance? I do not want to keep track of addresses in my DB, I want to rely on Google for that.
Thanks.
You can use the formula found here to calculate the distance between zip codes:
http://support.sas.com/kb/5/325.html
This is not precise (door-step to door-step) but you can calculate the distance from the user's zip code to the location's zip code.
Using this method, you won't even have to hit Google's API.
I have an unconventional idea for you. This will be very, very odd when you think about it for the first time, as it does exactly the opposite order of what you will expect to do. However, you might get to see the logic.
In order to put it in action, you'll need a broad category of stuff that you want the user to see. For instance, I'm going to go with "supermarkets".
There is a wonderful API as part of google places called nearbySearch. Its true wonder is to allow you to rank places by distance. We will make use of this.
Pre-requisites
Modify your database and store the unique ID returned on nearbySearch places. This isn't against the ToS, and we'll need this
Get a list of those IDs.
The plan
When you get the user's location, query nearbySearch for your category, and loop through results with the following constraints:
If the result's ID matches something in your database, you have that result. Bonus #1: it's sorted by distance ascending! Bonus #2: you already get the lat-loc for it!
If the result's ID does not match, you can either silently skip it or use it and add it to your database. This means that you can quite literally update your database on-the-fly with little to no manual work as an added bonus.
When you have run through the request, you will have IDs that never came up in the results. Calculate the point-to-point distance of the furthest result in Google's data and you will have the max distance from your point. If this is too small, use the technique I described here to do a compounded search.
The only requirement is: you need to know roughly what you are searching for. However, consider this: your normal query cycle takes you anywhere between 1 and 100 google Queries. My method takes 1 for a 50km radius. :-)
To calculate distances, you will need Haversine's formula rather than doing a zip code lookup, by the way. This has the added advantage of being truly international.
Important caveats
This search method directly depends on the trade-off between the places you know about and the distance. If you are looking for less than 10km radii, use this method to only generate one request.
If, however, you have to do compounded searching, bear in mind that each request cycle will cost you 3N, where N is the number of queries generated on the last cycle. Therefore, if you only have 3 places in a 100km radius, it makes more sense to look up each place individually.