When trying to add a placemark to the plugin via the API. The place mark positions itself to an invisible grid that seems to be about a metre square.
My application needs accuracy to 10cm, does anyone know how to stop the place mark snapping to a grid and positioning at the mouse pointer location exactly???
Can you show an example of the placemark? Without seeing it is hard to say but I would guess that you are probably defining its coordinates using 5 decimal places. This would account for the "invisible grid that seems to be about a metre square."
My application needs accuracy to 10cm
The Google Earth and Maps APIs work with coordinates with an accuracy of six decimal places. This provides a precision of around 11 cm around the equator. The further you move from the equator the greater the inaccuracy. So you can't have accuracy to 10cm, at best it will be 11 cm at equatorial latitudes.
You can use the following table to give a rough an idea of how decimal places in the coordinates relate to precision on the earth. Again, the precision will fall-off the further you move from the equator.
Accuracy of decimal coordinates at the equator
0 1.0 111 km
1 0.1 11.1 km
2 0.01 1.11 km
3 0.001 111 m
4 0.0001 11.1 m
5 0.00001 1.11 m * (What I think you are using now.)
6 0.000001 0.111 m * (The highest accuracy possible in the api.)
7 0.0000001 1.11 cm
8 0.00000001 1.11 mm
Related
How can I calculate the bearing from an relative "origin" by lateral and longitudinal speeds?
For example if the lateral speed was 0 meters a second and the longitudinal speed is positive, that would mean the bearing would be 0 degrees of "origin" but if the longitudinal speed was negative that would indicate the bearing is 180 degrees of "origin". This scenario is simple. (I think, laughs at self).
Now lets make things interesting. The longitudinal speed is still positive, say 30.0 meters a second and my lateral speed is -0.05 meters a second. That would indicate my bearing would be angled ever so slightly "left of origin". But specifically what degree?
Is there a formula to calculate the bearing from two speeds?
Thanks!
After digging into the trigonometry trenches. I found a solution.
Given a lon/lat speeds create a 90 degree triangle. In this scenario the hypotenuse doesn't matter.
It boils down to (in python for folks)...
fraction = a / b # sides of the projection that form the 90 degree angle
if b < 0:
fraction = b / a
bearing = 360 - (90 + math.atan(fraction))
Using that bearing. If you have a distance you can project a point.
I have a service that looks for nearby locations(300m) from a user specified point.
I'm using the haversine formula to check if a location is near the point
https://en.wikipedia.org/wiki/Haversine_formula
My problem is that it's slow since it's checking against all of the points in my DB.
What I want to do is limit the initial query and apply the haversine formula to a list of points in a smaller bounded area
e.g.
results = (SELECT * FROM location WHERE location.latitude BETWEEN 14.223 AND 14.5 )
AND location.longitude BETWEEN 121.5 AND 122
haversine(results, user_point)
Is there a loose way of getting the bounds from a given point?
Or basically a dirty conversion of lat/long to meters?
If you can modify your database structure, there's one super-easy way to do it: instead of (or in addition to) storing latitude and longitude, convert your location coordinates into 3D space, with columns for x, y, and z in meters. Then you can just do
SELECT * FROM location
WHERE location.x BETWEEN center.x - 300 AND center.x + 300
AND location.y BETWEEN center.y - 300 AND center.y + 300
AND location.z BETWEEN center.z - 300 AND center.z + 300
That will trim down your list pretty well, and you can do the haversine calculation on the resulting set.
If you're stuck with using a database that has only longitude and latitude in it, you can still narrow down the search. It's easy for latitude: one degree of latitude due north or south always corresponds to 111 km of distance, as long as you ignore the complications that arise when you get close to the poles. That means a distance of 300 m is 0.0027... degrees of latitude, although you might as well be a bit conservative and use 0.003 or 0.004.
Longitude is a bit trickier because the conversion factor changes depending on how far north or south you are, but it's still not too complicated: you just multiply by the cosine of the latitude.
distance = cos(latitude) * 111.19... km/degree * delta_angle
At the equator, it's the same as with latitude: one degree change in longitude at the equator is 111 km. At 80 degrees north (or south), you multiply by a factor of cos(80 degrees) = 0.17..., with the result that 1 degree change in longitude is only 19.3 km. For your purposes, you could invert this and find the range of longitudes to select as 300 m / cos(latitude) / (111.19... km/degree) = (0.0027... degrees) / cos(latitude). That coefficient is the same quantity from the first paragraph; it's not a coincidence.
The tricky problems come up near the discontinuities of the coordinate system, for example when you get near the poles. You can see why when you start plugging in latitudes like 89.9996 degrees:
0.0027... degrees / cos(89.9996 degrees) = 386... degrees
Well, how can that be when there are only 360 degrees in a whole circle? This is an indicator that you've gotten to the point where your 300 m radius extends all the way around the pole and comes back to include your starting location, in a manner of speaking. At that point, you might as well just search all points in your database close enough to the pole. Of course you should really start doing this at 89.999 degrees or so, because that's where the 600 m diameter of the region you're searching just about encircles the pole completely.
There's another issue at (well, near) the International Date Line, or more precisely the "antimeridian", having to do with the jump from -180 to +180 degrees of longitude. A point at +179.9999 degrees and one at -179.9999 degrees, both on the equator, will have very different coordinates even though they are geographically just a few meters apart. Since you're just doing this as a preliminary filter for a more detailed search, it's probably easiest to just pass through every point within 0.006 degrees (that's roughly the diameter of a 300 m-radius circle) of the antimeridian, and then the haversine calculation will determine whether the points are actually close.
To sum up, you can use the bounds on latitude and longitude I mentioned above and just add special cases for the poles and the antimeridian. In some kind of pseudo-SQL/code hybrid:
IF abs(center.latitude) > 89.999
SELECT * FROM location WHERE abs(location.latitude - center.latitude) < 0.003
ELSE
IF abs(center.longitude) > 179.997
SELECT * FROM location
WHERE abs(location.latitude - center.latitude) < 0.003
AND 180 - abs(location.longitude) < (0.006 / cos(center.latitude))
ELSE
SELECT * FROM location
WHERE abs(location.latitude - center.latitude) < 0.003
AND abs(location.longitude - center.longitude) < (0.003 / cos(center.latitude))
ENDIF
ENDIF
If you want a pithy statement at the expense of having to test potentially twice as many points, you can only compare the absolute values of longitude:
SELECT * FROM location
WHERE abs(location.latitude - center.latitude) < 0.003
AND abs(abs(location.longitude) - abs(center.longitude)) <= min(0.003 / cos(center.latitude), 180)
Approximating the earth with a sphere, the distance between two consecutive latitudes can be calculated by
dPerLat = pi * r / 180°,
where r is the radius of the earth. This will be about 111 km.
So, if your reference point is (lat, long) and your search radius is d then you want to search for latitudes in the range
lat* \in [lat - d / dPerLat, lat + d / dPerLat]
Then, for a given latitude, the distance of consecutive longitudes is:
dPerLong = pi * r * cos(lat) / 180°
Again, the range of longitudes to search is +- d / dPerLong. You should use the lat value that gives you a conservative (maximal) range, i.e. the lat value with the highest absolute value.
Be careful at the poles.
Problem: Use the following data to find the velocity and acceleration
at t = 10 seconds:
Time, t, s 0 2 4 6 8 10 12 14 16
Position, x, m 0 0.7 1.8 3.4 5.1 6.3 7.3 8.0 8.4
I resolved the centered finite-difference
How can I apply this in Scilab?
This calculates velocity from the given arrays x and t, using central differences:
v = (x(3:$) - x(1:$-2)) ./ (t(3:$) - t(1:$-2))
To see what this does, focus on the first index in each range:
(x(3) - x(1)) ./ (t(3) - t(1))
Clearly, this is the velocity at the 2nd moment of time. The formula performs this calculation for all times when it's possible to do; the centered difference formula does not apply at the first and last moment. One may want to introduce truncated time range to reflect this:
tr = t(2:$-1)
Similarly for acceleration:
a = (x(3:$) - 2*x(2:$-1) + x(1:$-2)) ./ (t(3:$) - t(1:$-2)).^2
This can now be plotted with plot(tr,v) or plot(tr,a). And to look up their values when time is 10, use
v(tr==10)
and
a(tr==10)
I have a number of coordinates and I want to plot them in a gridded interface by using R.
The problem is that the relative distance between observations is large. Coordinates are in a geographic coordinate system and the study area is Switzerland. Moreover, id of the points is required to be plotted.
The problem is that two clusters of the points are dense and some other points are separated with a large distance. How I can plot them in a proper way to have readable presentation? Any suggestion for plotting the data?
Preferably, do not use ggplot as I used it before and it did not present proper results.
Data:
id x y
2 7.1735 45.86880001
3 7.17254 45.86887001
4 7.171636 45.86923601
5 7.18018 45.87158001
6 7.17807 45.87014001
7 7.177229 45.86923001
8 7.17524 45.86808001
9 7.181409 45.87177001
10 7.179299 45.87020001
11 7.178359 45.87070001
12 7.175189 45.86974001
13 7.179379 45.87081001
14 7.175509 45.86932001
15 7.176839 45.86939001
17 7.18099 45.87262001
18 7.18015 45.87248001
19 7.18122 45.87355001
20 7.17491 45.86922001
25 7.15497 45.87058001
28 7.153399 45.86954001
29 7.152649 45.86992001
31 7.154419 45.87004001
32 7.156099 45.86983001
GSBi_1 7.184 45.896
GSBi__1 7.36 45.901
GSBj__1 7.268 45.961
GSBj_1 7.276 45.836
GSB 7.272 45.899
GSB_r 7.166667 45.866667
Location of points:
As you can see in the plot, the points' ids are not readable both for the dense parts and others.
Practically, it is not always possible to ensure that all points are visually separable on the screen when plotting a set of points that contains very close and very far points at the same time.
Think of a 1000x800 pixel screen. Let's say we have three points A, B and C that are located respectively on the same horizontal line such that: the distance between A and B is 1 unit and the distance between A and C is 4000 unit.
If you map this maximum distance (4000 unit) to the width of the screen (1000px). Then a pixel will correspond to 4 units in horizontal. That means A and B will fit into one pixel since the distance between them is only 1 unit. So, they will not be visually separable on the screen.
Your points are far too close to really do too much with, but an idea might be spread.labels from plotrix:
opar <- par()
par(xpd=TRUE)
plot(dat$x, dat$y)
spread.labels(dat$x,dat$y,dat$id)
par(opar)
You may want to consider omitting all the numerical labels and placing them in a different graph.
What is the maximum length (in kilometers or miles - but please specify) that one degree of latitude and longitude can have in the Earth surface?
I'm not sure if I'm being clear enough, let me rephrase that. The Earth is not a perfect circle, as we all know, and a change of 1.0 in the latitude / longitude on the equator (or in Ecuador) can mean one distance while the same change at the poles can mean another completely different distance.
I'm trying to shrink down the number of results returned by the database (in this case MySQL) so that I can calculate the distances between several points using the Great Circle formula. Instead of selecting all points and then calculating them individually I wish to select coordinates that are inside the latitude / longitude boundaries, e.g.:
SELECT * FROM poi
WHERE latitude >= 75 AND latitude <= 80
AND longitude >= 75 AND longitude <= 80;
PS: It's late and I feel that my English didn't came up as I expected, if there is something that you are unable to understand please say so and I'll fix/improve it as needed, thanks.
The length of a degree of latitude varies little, between about 110.6 km at the equator to about 111.7 near the poles. If the earth were a perfect sphere, it would be constant. For purposes like getting a list of points within say 10 km of a known (lat, lon), assuming a constant 111 km should be OK.
However it's quite a different story with longitude. It ranges from about 111.3 km at the equator, 55.8 km at 60 degrees latitude, 1.9 km at 89 degrees latitude to zero at the pole.
You asked the wrong question; you need to know the MINIMUM length to ensure that your query doesn't reject valid candidates, and unfortunately the minimum length for longitude is ZERO!
Let's say you take other folk's advice to use a constant of about 111 km for both latitude and longitude. For a 10 km query, you would use a margin of 10 / 111 = 0.09009 degrees of latitude or longitude. This is OK at the equator. However at latitude 60 (about where Stockholm is, for example) travelling east by 0.09 degrees of longitude gets you only about 5 km. In this case you are incorrectly rejecting about half of the valid answers!
Fortunately the calculations to get a better longitude bound (one that depends on the latitude of the known point) is very simple -- see this SO answer, and the article by Jan Matuschek that it references.
Originally, the definition of a nautical mile was the length of one minute of longitude on the equator. So, there were 360 * 60 = 21,600 nautical miles around the equator. Similarly, the original definition of a kilometer was that 10,000 km = length from pole to equator. Consequently, assuming a spherical earth, there would be:
40,000 ÷ 21,600 = 1.852 km per minute
1.852 × 60 = 111.11 km per degree
Allowing for a spheroidal earth instead of a spherical one will slightly adjust the factor, but not by all that much. You could be pretty confident the factor is less than 1.9 km per minute or 114 km per degree.
If you can use MySQL spatial extensions: http://dev.mysql.com/doc/refman/5.0/en/spatial-extensions.html, you can use its operators and functions both to filter the points and calculate distances. See http://dev.mysql.com/doc/refman/5.0/en/functions-that-test-spatial-relationships-between-geometries.html, specifically the functions contains() and distance().
The reference ellipsoid used for the earth is the WGS84 system, meaning
that the earth radius for the equator has the length of
6 378 137 m or 3963.19 miles
The maximum length of longitude is reached at the equator and is approximately (upper bound)
111.3195 km or
69.1708 miles
The maximum length of one degree latitude is reached between the equator and 1°. It is almost exactly equal to the maximum length of longitude; a first approximation shows that the difference is less than 4.2 meters yielding
111.3153 km or
69.1682 miles