Below is the map that captures from Google Map. I want to calculate the angle ABC. I have the coordinate (Latitude/Longitude) of three points.
Is there any approach to resolve my problem?
Thanks
You can find the heading between any two points using the google.maps.geometry.spherical.computeHeading method of the Google Maps Javascript API v3:
computeHeading(from:LatLng, to:LatLng) | number | Returns the heading from one LatLng to another LatLng. Headings are expressed in degrees clockwise from North within the range [-180,180).
The angle between the two will be the difference between the 2 headings.
Example using computeHeading in this answer
You can approximate the angle using the law of cosines. I say approximate because the curvature of the Earth is going to have some non-zero effect on the calculation.
In your example it should suffice to calculate the distances between the points and then perform the appropriate manipulations on the law of cosines. Refer to the second formula in the applications of the law of cosines wiki article and the corresponding picture.
Related
I'm working on the following scenario: I have a geographical location and I need to create a heat-map visualization of travel times (by car) from that location to anywhere around. I'm planning on using Google Distance Matrix API for getting travel duration. But, since it has a limit on the no of API calls, I need to somehow limit the calls.
My plan, so far, is the following: compute the travel duration (basically a numeric value) to a set of points evenly distributed on a grid around the given position (e.g. 0.5km east, 0.5 km east-0.5km north, 0.5 km east-1 km north etc.). This points would represent the centers of square-shaped areas and I will consider the travel duration to the center as the travel duration to anywhere in the area. Display these areas as colored squares on a Google Maps in a heatmap style.
A good example of something that looks alike is this: http://project.wnyc.org/transit-time/#40.72280,-73.95464,12,709 .
So, my questions are:
Does it seem like a good strategy?
Is there a better visualisation strategy for something like this?
How can I create those square-shaped colored areas on Google Maps?
Thanks!
Calculating duration would surely involve traffic flow rather than simply distance. If your calculations are purely on distance you could use the Google Maps direction requests to calculate the distance to each point.
I'm not sure a heat map is the way forward for this scenario.
There a number of way you could achieve this. Here's a few:
a. Use a custom overlay
(https://developers.google.com/maps/documentation/javascript/examples/overlay-simple)
b. Draw polygons on the map and give them different colours based on
the journey duration. This would involve taking the area in question and slicing it up in to polygons however you need to. These polygons could take the same shape as your example. You would need to be rather precise with your latlng. SQL's spacial querys would help you here depending on the tech your using. (https://developers.google.com/maps/documentation/javascript/examples/polygon-arrays)
c. Depending on how specific you wanted to be you could draw circles with different radius value and different colours.
d. You could make custom markers in the shapes you require and add them to the map in the correct latlng in order to fill an area. You could have different markers for different duration and add them accordingly.
I'm sure there are other options as well.
I am working with an application that dumps the latitude/longtitude coordinates into my database. My goal is to apply a grid layout to the earth (using Google Maps), group the coordinates together and update the correct grid cell. However, I am stuck with regards to how to create the grid overlay.
All the formulas I have found (for example here or the Google Maps computeOffset) take the earths shape into consideration. When using these formulas to calculate the coordinates for the grid cells, the lines naturally becomes skewed as the distance increases. My question is therefore, is there a formula for calculating latitude/longtitude that ignores the shape of the earth (where the input is a set of coordinates, bearing and length in meters)? I.e., what I want to achieve is:
If I have a point (0,0) and I want to find the position that is 100m to the east, I want the formula to return (latitude_offset_100m,0). Using a formula which considers the circular shape of the earth, this might give for example (latitude_offset_100m,longtitude_offset_5m).
I finally figured out how to achieve what I wanted. By using rhumb lines, you can get "straight" lines on a Mercator projected map (like Google maps).
I have a set of coordinates data from 3rd party provider. However when I plot those coordinates on google maps with annotations, the annotated points are not exactly on the position they should be. For example, some points should be placed on the road, however they are placed slightly off the road.
My question is, how to solve this kind of discrepancy?
Thanks!
Coordinates (lat and long), by themselves, do not describe a position on the Earth. You need a third piece of information, called the datum. The datum for google maps is WGS84. The datum establishes such things as where 0,0 is on the Earth's surface.
If you've received coordinates, and those coordinates are based on a different datum, then they will not plot correctly on Google Maps.
On the other hand, if the points came from any kind of mobile device (even if it is using WGS84), there are inherent inaccuracies in such measurements (thankfully generally down to < 5m for GPS these days, I believe) that mean that they will not align 100%.
I have a program that takes as input an array of lat/long points. I need to perform a check on that array to ensure that all of the points are within a certain radius. So, for example, the maximum radius I will allow is 100 miles. Given an array of lat/long (coming from a MySQL database, could be 10 points could be 10000) I need to figure out if they will all fit in a circle with radius of 100 miles.
Kinda stumped on how to approach this. Any help would be greatly appreciated.
Find the smallest circle containing all points, and compare its radius to 100.
It's easiest way for me to solve this is by converting the coordinates to (X,Y,Z), then finding the distance along a sphere.
Assuming Earth is a sphere (totally untrue) with radius R...
X = R * cos(long) * cos(lat)
Y = R * sin(long) * cos(lat)
Z = R * sin(lat)
At this point, you can approximate the distance between the points using the extension of the pythagorean theorem for threespace:
dist = sqrt((x1-x2)^2 + (y1-y2)^2 + (z1-z2)^2)
But to find the actual distance along the surface, you're going to need to know the angle subtended by the two points from the origin (center of the Earth).
Representing your locations as vectors V1 = (X1, Y1, Z1) and V2 = (X2, Y2, Z2), the angle is:
angle = arcsin((V1 x V2) / (|V1||V2|)), where x is the cross-product.
The distance is then:
dist = (Earth's circumference) * angle / (2 * pi)
Of course, this doesn't take into account changes in elevation or the fact that the Earth is wider at the equator.
Apologies for not writing my math in LaTeX.
The answer below involves pretending that the earth is a perfect sphere, which should give a more accurate answer than treating the earth as a flat plane.
To figure out the radius of a set of lat/lon points, you must first ensure that your set of points is "hemispherical", ie. all the points can fit into some arbitrary half of your perfect sphere.
Check out Section 3 in the paper "Optimal algorithms for some proximity problems on the Gaussian sphere with applications" by Gupta and Saluja. I don't have a specific link, but I believe that you can find a copy online for free. This paper is not sufficient to implement a solution. You'll also need Appendix 1 in "Approximating Centroids for the Maximum Intersection of Spherical Polygons" by Ha and Yoo.
I wouldn't use Megiddo's algorithm for doing the linear programming part of the hemisphericity testing. Instead, use Seidel's algorithm for solving Linear Programming problems, described in "Small-Dimensional Linear Programming and Convex Hulls Made Easy" by Raimund Seidel. Also see "Seidel’s Randomized Linear Programming Algorithm" by Kurt Mehlhorn and Section 9.4 from "Real-Time Collision Detection" by Christer Ericson.
Once you have determined that your points are hemispherical, move on to Section 4 of the paper by Gupta and Saluja. This part shows how to actually get the "smallest enclosing circle" for the points.
To do the required quadratic programming, see the paper "A Randomized Algorithm for Solving Quadratic Programs" by N.D. Botkin. This tutorial is helpful, but the paper uses (1/2)x^T G x - g^T x and the web tutorial uses (1/2)x^T H x + c^T x. One adds the terms and the other subtracts, leading to sign-related problems. Also see this example 2D QP problem. A hint: if you're using C++, the Eigen library is very good.
This method is a little more complicated than some of the 2D methods above, but it should give you more accurate results than just ignoring the curvature of the earth completely. This method also has O(n) time complexity, which is likely asymptotically optimal.
Note: The method described above may not handle duplicate data well, so you may want to check for duplicate lat/lon points before finding the smallest enclosing circle.
Check out the answers to this question. It gives a way to measure the distance between any two (lat,long) points. Then use a smallest enclosing circle algorithm.
I suspect that finding a smallest enclosing circle may be difficult enough on a plane, so to eliminate the subtleties of working with latitude and longitude and spherical geometry, you should probably consider mapping your points to the XY plane. That will introduce some amount of distortion, but if your intended scale is 100 miles you can probably live with that. Once you have a circle and its center on the XY plane, you can always map back to the terrestial sphere and re-check your distances.
If I have a series of points as longitude and latitude, how would I calculate the center of all of those points?
Geomidpoint covers 3 different methods for calculating this.
Several people have answered to take the mean of the latitudes and longitudes. This is sort of the right idea, but means are more complicated on the sphere.
The latitude/longitude representation is essentially artificial and has discontinuities (at the poles, and opposite the prime meridian if you aren't careful), so it taking means in it doesn't seem likely (to me) to have a sensible geometric interpretation. I think you need to do something like averaging vectors in earth-centered coordinates, and then normalizing the result to put it back on the sphere.
I hope someone with more experience in these matters can comment more concretely.
Don't just take averages.
You can convert to 3d coordinates, then take the average (of x,y, and z coords), then project it back onto the sphere and turn that back into lat/long.
The wikipedia page on spherical coordinates has conversion algorithms.
First off, you need to define which centre you're interested in. Take these two points:
A. .B
The centre is easy, it's halfway between them. Now add a third point:
A. C. .B
Is the centre still halfway between A and B or is it weighted towards A because of C? So is the centre the point nearest to all points or just the points on the enclosing polygon?
Also, as it's long/lat you're dealing with the points are on a surface of a sphere so the distance between long 0 and long 90 degrees is much greater at lat 0 than at lat 45 degrees.
You're probably looking for the centroid of the simple polygon defined by the points. There is information on how to calculate it for various geometries in that article.
Wolfram Alpha will do this for you if you ask the question in the following form:
centroid of polygon with vertices: (X, Y), (X, Y), (X, Y), (X, Y), (X, Y), etc.
Just remember to convert each "(X, Y)" into decimal form first.
Wolfram Alpha will return the answer in decimal form, which you can then copy and paste into Google Earth.
See Moe's answer, although if your points are distributed across the globe, you'll have to be satisfied that your center tends towards the Prime Meridian and not the International Date Line.