I tried using the google.maps.geometry.poly.isLocationOnEdge(position, path, tolerance) function to decide whether the position(lat,lon) pair is within a certain distance (geodesic distance) from a designated path. The API says that the tolerance refers to measurements made in degrees, so one simple way of finding, let's say, points within a buffer radius of 50km from a certain path is to supply the tolerance as being 50/111 degrees (because one can assume that a degree corresponds to 111 km as the traveled distance on a sphere). Unfortunately, this is very erratic and gives many false positives even if they're 200 km away from the path. Am I misinterpreting what that function does?
111km is the length of a longitudinal degree at zero latitude, but this distance is going to vary based on a few factors for different locations. What you need is a function that will calculate the distance (in degrees) between two LatLngs.
See the top answer in this question for an example implementation.
Related
I have a list of Points-of-Interest (e.g. car rest areas).
The user selects the Starting Point and the Ending Point.
This generates a route.
How can I programmatically filter the POIs that are close (e.g. 50 meters distance from the road) that route?
Can Google Maps SDK or OSRM offer this functionality?
Thank you,
Nick
1. You have to find the distance from one POI to the road.
In order to accomplish this, you have to store your road in a mathematical fashion:
You can sample equidistant points of your road and store them in an array (more practical, less precise) and then calculate the distance of the POI from every point in the array, then save the minor result and repeat the whole process for every POIs.
You can store a road in a function (more and more complex, but more precise). Now that you have this function, you can calculate same distance from your POI, take the minimum value and repeat for all POIs.
2. Google Distance Matrix can actually do this
With this Api you can calculate distance till 2500 origins * destinations points.
The result will give you an array of rows, with each row corresponding
to an origin, and each element within that row corresponds to a pairing of the origin with a destination value.
Example of a request:
https://maps.googleapis.com/maps/api/distancematrix/json?units=metric&origins=32.777211,35.021250&destinations=32.778663,35.015757&key=YOURAPIKEY
This is very useful to your goal, because lets you specify more than one points of which calculates distance.
we are using rethinkdb geospatial features to calculate distance between two latitude and longitude but the result returned by rethinkdb is different and looks wrong if i cross check on google maps or any distance calculator website. I have copied same code given rethinkdb help.
var point1 = r.point(-122.423246,37.779388);
var point2 = r.point(-117.220406,32.719464);
r.distance(point1, point2, {unit: 'km'})
// result returned
734.1252496021841 km
but when i test same point on http://www.onlineconversion.com/map_greatcircle_distance.htm it return following result 642.1854781517294 km.
Different from some other geo systems, RethinkDB uses the convention of having the longitude first, followed by the latitude.
We made that decision in order for being consistent with the GeoJSON format.
See http://www.rethinkdb.com/api/javascript/point/
From looking at your example, it looks like you've computed the distance correctly in RethinkDB, but entered the coordinates in the opposite direction in the online tool.
With latitude and longitude entered into the correct fields, I'm getting consistent results:
A more advanced note:
There is some difference behind the decimal point. The online calculator claims that "The script uses "Haversine" formula, which results in in approximations less than 1%." by which I assume it means up to 1% error, so this sort of deviation is to be expected.
RethinkDB uses geodesics on an ellipsoid for computing distances, based on the algorithm by C. F. F. Karney 1. This is an extremely precise algorithm, that calculates geodesics up to the limits of double-precision floating point numbers.
You will see even more deviation from Google maps (it gives me 735.234653 km for these two points). It looks like Google maps uses great-circle distances, which do not take the ellipsoidal shape of the earth into account at all.
1 http://link.springer.com/article/10.1007%2Fs00190-012-0578-z
I have a SQL database set of places to which I am assigned coordinates (lat, long). I would like to ask those points that lie within a radius of 5km from my point inside. I wonder how to construct a query in a way that does not collect unnecessary records?
Since you are talking about small distances of about 5 km and we are probably not in the direct vicinity of the north or south pole we can work with an approximated grid system of longitude and latitude values. Each degree in latidude is equivalent to a distance of km_per_lat=6371km*2*pi/360degrees = 111.195km. The distance between two longitudinal lines that are 1 degree apart depends on the actual latitude:
km_per_long=km_per_lat * cos(lat)
For areas here in North Germany (51 degrees north) this value would be around 69.98km.
So, assuming we are interested in small distances around lat0 and long0 we can safely assume that the translation factors for longitudinal and latitudinal angles will stay the same and we can simply apply the formula
SELECT 111.195*sqrt(power(lat-#lat0,2)
+power(cos(pi()/180*#lat0)*(long-#long0),2)) dist_in_km FROM tbl
Since you want to use the formula in the WHERE clause of your select you could use the following:
SELECT * FROM tbl
WHERE 111.195*sqrt(power(lat-#lat0,2)
+power(cos(pi()/180*#lat0)*(long-#long0),2)) < 5
The select statement will work for latitude and longitude values given in degree (in a decimal notation). Because of that we have to convert the value inside the cos() function to radians by multiplying it with pi()/180.
If you have to work with larger distances (>500km) then it is probably better to apply the appropriate distance formula used in navigation like
cos(delta)=cos(lat0)*cos(lat)*cos(long-long0) + sin(lat0)*sin(lat)
After calculating the actual angle delta by applying acos() you simply multiply that value by the earth's radius R = 6371km = 180/pi()*111.195km and you have your desired distance (see here: Wiki: great circle distance)
Update (reply to comment):
Not sure what you intend to do. If there is only one reference position you want to compare against then you can of course precompile your distance calculation a bit like
SELECT #lat0:=51,#long0:=-9; -- assuming a base position of: 51°N 9°E
SELECT #rad:=PI()/180,#fx:=#rad*6371,#fy:=#fx*cos(#rad*#lat0);
Your distance calculation will then simplify to just
SELECT #dist:=sqrt(power(#fx*(lat-#lat0),2)+power(#fy*(long-#long0),2))
with current positions in lat and long (no more cosine functions necessary). It is up to you whether you want to store all incoming positions in the database first or whether you want to do the calculations somewhere outside in Spring, Java or whatever language you are using. The equations are there and easy to use.
I would go with Euklid. dist=sqrt(power(x1-x2,2)+power(y1-y2,2)) . It works everywhere. Maybe you have to add a conversion to the x/y-coordinates, if degrees can't be translated in km that easy.
Than you can go and select everything you like WHERE x IS BETWEEN (x-5) AND (x+5) AND y IS BETWEEN (y-5) AND (y+5) . Now you can check the results with Euklid.
With an optimisation of the result order, you can get better results at first. Maybe there's a way to take Euklid to SQL, too.
I'm trying to query any locations within a specified distance from another location. The query is not the problem, but the distance returned by geography.STDistance is.
It seems STDistance makes fairly accurate calculations on locations close to the equator, but I need this to work with locations in the nordic countries. Norway, Sweden, Finland and so on...
According to my calculations, made on locations in northern Sweden, the distance is wrong by a factor of around 2.38?!
Expected result is 1070 meters and returned distance is 2537,28850694302 meters
My query looks like this:
DECLARE #g geography = geography::STGeomFromText('POINT(65.580254 22.179428)', 4326)
SELECT name, [pos].STSrid as srdi, [pos].STDistance(#g) as d
FROM [GPSCHAT].[dbo].[USERS]
and the "other location" has coordinates (65,578541 22,202286) (stored with SRID 4326)
I'm guessing this has to do with the distance from the equator (close to the polar circle), but there has to be a way to calculate this more accurately based on the Latitude or am i wrong?
It looks like you're creating your point using 'X, Y'.
When creating a point from text, use 'Y, X' instead.
Check out this MSDN Article for some more info.
Why don't you make use of another spatial reference identifier which fits better the earth curvature around your position. SRID 4326 might not been measured as accurate as other local referential systems
My question is somewhat related to this similar one, which links to a pretty complex solution - but what I want to understand is the result of this:
Using a Mysql Geometry field to store a small polygon I duly ran
select AREA(myPolygon) where id =1
over it, and got an value like 2.345. So can anyone tell me, just what does that number represent seeing as the stored values were long/lat sets describing the polygon?
FYI, the areas I am working on are relatively small (car parks and the like) and the area does not have to be exact - I will not be concerned about the curvature of the earth.
2.345 of what? Thanks, this is bugging me.
The short answer is that the units for your area calculation are basically meaningless ([deg lat diff] * [deg lon diff]). Even though the curvature of the earth wouldn't come into play for the area calculation (since your areas are "small"), it does come into play for the calculation of distance between the lat/lon polygon coordinates.
Since a degree of longitude is different based on the distance from the equator (http://en.wikipedia.org/wiki/Longitude#Degree_length), there really is no direct conversion of your area into m^2 or km^2. It is dependent on the distance north/south of the equator.
If you always have rectangular polygons, you could just store the opposite corner coordinates and calculate area using something like this: PHP Library: Calculate a bounding box for a given lat/lng location
The most "correct" thing to do would be to store your polygons using X-Y (meters) coordinates (perhaps UTM using the WGS-84 ellipsoid), which can be calculated from lat/lon using various libraries like the following for Java: Java, convert lat/lon to UTM. You could then continue to use the MySQL AREA() function.