If I have the following coordinates obtained from the Google API:
[longitude] => 18.12288
[latitude] => -23.1233399
I want to know how accurate this coordinate is. In other words, what area does this specific coordinate cover? Is it a 1 meter by 1 meter area, or is it less accurate and maybe cover a 50 by 50 meter area? How do you calculate the area it covers?
UPDATE
Using this calculator, I could get:
0.000001 = .1 meter
0.00001 = 1 meter
0.0001 = 11 meters
0.001 = 111 meters
0.01 = 1113 meters / 1.1 km
0.1 = 11132 meters / 11.1 km
1.0 = 111319 meters / 111 km
Is this correct?
you can work it out here
http://www.csgnetwork.com/gpscoordconv.html
Coords are usually meter accurate if the seconds are well defined.
Apparently i neeed more rep to comment, anyhow,
No, your last comment is wrong.
coords are usually pim point accurate assuming you have seconds included in your coord.
To work out standard coordinates
xx.xxxxxxxxx
the first two numbers are your degrees
so it will look like this "xx" and "xxxxxxx" for the remainder,
to get minutes, you divide the remainder by 60,
it looks like this now "xx" "xx" "xxxxx"
and what is the decimal of that equation is again divided by 60, to get your seconds.
you may be left with decimals after you work out seconds, but those are fine, the more numbers you have, the more accurate your coord will be.
hope this helps.
The length of a degree in a a projected system (2d system such as the one used by Google Maps) depends on the latitude. Using this simple calculator, you can see that if you change the latitude from 0 degrees to 90 degrees (Equator to North Pole), you get a different length (by up to a kilometer - 110km at North Pole vs 111km at Equator).
Wikipedia has a good summary of the lengths at the equator and those match the ones you typed out. Based on the lat/long that you provided, the accuracy would be around 1 meter.
Related
I try to get some approximate distance between 2 points in mariaDB.
I use that SQL:
SELECT st_distance(POINT(50.6333,3.0667),p) from p
It outputs results such as:
0
1.9128040446888426
8.103248262271125
It seems mariaDB does not handle SRID.
Is there a way to convert these values to km ? (looks like multiplying by 110 is quite correct)
My goal is to avoid handling maths such as sin, cos, atan and approximate result is ok for me.
The result returned by st_distance are not kilometer but minutes.
For a circumference of the equator of d = 40.075km, the distance between two minutes is d / 360 = 111,319 km.
While the distance between the latitudes is constant, the distance between the longitudes from the equator to the pole caps decreases constantly. According to your example the point from one location must be somewhere in France, where the distance between longitudes is around 70km.
Since you don't want to use the Haversine formula, you can also use the Pythagorean theorem to get a more accurate result:
# Distance between Eiffel tower and Lille
SELECT ST_DISTANCE(GeomFromText("Point(50.6333 3.0669)"), GeomFromText("Point(48.853. 2.348)")) * 111.38;
-> 213.84627307672486
select sqrt(pow((50.63333 - 48.853) * 111.38,2) + pow((3.0669 - 2.348) * 70, 2));
->204.57903071304386
ST_DISTANCE is designed for flat-earth advocates.
ST_DISTANCE_SPHERE is available in InnoDB as of 5.7.
https://dev.mysql.com/doc/refman/5.7/en/spatial-convenience-functions.html#function_st-distance-sphere
I am trying to query a MySQL database (version 5.7.15) to retrieve all locations that are within 300 meters from some coordinates (40.7542, -73.9961 in my case):
SELECT *
FROM location
WHERE st_distance_sphere(latlng, POINT(40.7542, -73.9961)) <= 300
From the MySQL documentation:
ST_Distance_Sphere(g1, g2 [, radius])
Returns the mimimum spherical distance between two points and/or
multipoints on a sphere, in meters, or NULL if any geometry argument
is NULL or empty.
Unfortunately, the query also returns points that are more than 300 meters away from POINT(40.7542, -73.9961) such as:
POINT(40.7501, -73.9949) (~ 470 meters in real life)
POINT(40.7498, -73.9937) (~ 530 meters in real life)
Note that in MySql the order of coordinates are:
1. POINT(lng, lat) - no SRID
2. ST_GeomFromText('POINT(lat lng)', 4326) - with SRID
select st_distance_sphere(POINT(-73.9949,40.7501), POINT( -73.9961,40.7542))
will return 466.9696023582369, as expected, and 466.9696023582369 > 300 of course
Just to make it clear for future people (like myself):
Mituha Sergey has answered the question in comments on the OP. The problem was that OP was using POINT(lat, lng) when in fact MySQL expects POINT(lng, lat).
Not sure about the time OP posted the question, but as of today the official documentation makes it a bit clearer:
The geometry arguments should consist of points that specify
(longitude, latitude) coordinate values:
Longitude and latitude are the first and second coordinates of the point, respectively.
Both coordinates are in degrees.
Longitude values must be in the range (-180, 180]. Positive values are east of the prime meridian.
Latitude values must be in the range [-90, 90]. Positive values are north of the equator.
From: https://dev.mysql.com/doc/refman/5.7/en/spatial-convenience-functions.html#function_st-distance-sphere
And if you're getting "invalid arguments" errors it's probably because of that. Try adding WHERE lat between -90 and 90 AND lng between -180 and 180 just to be on the safe side haha :)
I need to calculate the distance between two points, but not in the regular way. I need to know 'the east to west distance' + 'the north to south distance'. I guess this is more simple then the regular 'as the crow flies' calculation but i still can't figure out how to do it.
I want to do this using a MySQL query and preferably have the result returned in km. One of the points will be a constant in the query and the other point is a point from the DB so something like SELECT abs(longitude-39.12345)...+abs(latitude... AS Distance FROM shops WHERE shopname='Bingo'.
Thanks in advance!
The north-to-south distance is proportional to the difference in the latitudes. It's about 1 nautical mile per minute of arc (the circumference of the earth is about 21600 nautical miles).
The east-to-west distance is proportional to the difference in the longitudes, but it also varies with the latitude (e.g. it's zero at the poles): I think it's proportional to the cosine of latitude.
Your answer depends on the accuracy required in your answer. If you don't need an answer more accurate than a spherical earth model, you can use a solution similar to the one given by Captain Tom. If you require more accuracy, you'll need to assume the earth is an oblate spheroid. See http://en.wikipedia.org/wiki/Vincenty%27s_formulae for a couple of solutions.
The east-west difference between two points at different latitudes is a distinct number in degrees of longitude, but converting this to miles is problematic because the miles per degree vary according to the latitude. For example, Los Angles and New York City are 44.3 degrees of longitude apart, but converting this to miles would result in a larger number at LA's latitude than at NYC's latitude, since latitude lines are longest at the equator and shrink to zero at the poles.
A reasonable convention would be to count the E-W distance as the average of the two distances calculated at the two latitudes.
You can determine the distance between any two geocode points using the Great-Circle Distance. Here is another decent article on the subject.
The following is an example in C# which shows how to do this:
var earth_radius = Constants.EarthRadius; // 6377.8 km
var dLat = ToRadians(fromLatitude - toLatitude);
var dLon = ToRadians(fromLongitude - toLongitude);
var a =
Math.Sin(dLat / 2) *
Math.Sin(dLat / 2) +
Math.Cos(ToRadians(fromLatitude)) *
Math.Cos(ToRadians(toLatitude)) *
Math.Sin(dLon / 2) *
Math.Sin(dLon / 2);
var c = 2 * Math.Asin(Math.Min(1, Math.Sqrt(a)));
var distanceInKilometers = earth_radius * c;
Use simple trig. The normal "as the crow flies" distance is the hypotenuse of the right triangle formed with the two points you have in mind at either ends of the hypotenuse.
Just look at this http://en.wikipedia.org/wiki/Hypotenuse and the solution should become clear.
I have the following available:
last reported lat,lon w/timestamp
target lat,lon
estimated time to target
heading
How can I interpolate an estimated position over time?
I know that's enough to calculate the required average velocity for the remainder of the trip. Given a straight-line distance, it's pretty trivial. I know it has to do with vectors but I'm a bit rusty and thought it better to consult some experts.
The reason I need this update rate is limited, so to show smooth animation I need to guess at the current position between updates.
The target platform is a Google Maps application so I have available some basic functionality like a Geo-correct function for distance between two coordinates. Language is unimportant as I know many and can port or adapt any examples if needed. General solutions would be preferred however.
Is this simply two independent vector calculations?
latestimate = latstart + (Δlat * P)
lonestimate = lonstart + (Δlon * P)
Where:
testimated = the reported estimated time to target
telapsed = time since last time estimate
P = telapsed / testimated
Δlat = latreported - lattarget
Δlon = lonreported - lontarget
You want to use a Slerp, or spherical linear interpolation.
Convert your latitude and longitude to a unit 3-vector:
p=(x,y,z)=(cos(lon)*cos(lat), sin(lon)*cos(lat), sin(lat))
Then, "Slerp" gives you a constant-velocity interpolation along the surface of the unit sphere:
theta= angle between 3-vectors p0 and p1 (e.g., cos(theta)= p0.p1)
Slerp(p0,p1,t)= ( p0*sin((1-t)*theta) + p1*sin(t*theta) ) / sin(theta)
Note that if theta is very close to 0 or 180 degrees, this formula can be numerically unstable. In the small-angle case, you can fall back to linear interpolation; in the 180 degree case, your path is genuinely ambiguous.
Lat_to_Travel = CurLat - TargetLat
Long_to_Travel = CurLong - TargetLong
Time_to_Travel = ETA - now
If the distances are relatively small, it is probably ok to assume a linear progression on these three dimensions (*). You then need to decide on a number of intermediate position to display, say 10, and calculate each intermediate point accordingly
NbOfIntermediates = 10 // for example
Lat_at_Intermediate(n) = CurLat + (1/NbOfIntermediates * Lat_to_travel)
Long_at_Intermediate(n) = CurLong + (1/NbOfIntermediates * Long_to_travel)
Time_at_Intermediate(n) = now + (1/NbOfIntermediates * Time_to_travel)
The most complicated in all this is to keep the units ok.
( * ) A few considerations as to whether it is ok to assume a linear progression...
Obviously the specifics of the reality of the physical elements (marine currents, wind, visibility...) may matter more in this matter than geo-spatial mathematics. Assuming that the vehicle travels at a constant speed, in a direct line, it is [generally] ok to assume linearity in the Latitude dimension [well technically the earth not being exactly a sphere this is not fully true but damn close]. However, over longer distances that include a relatively big change in latitude, the angular progression along the longitude dimension is not linear. The reason for this is that as we move away from the equator, a degree of longitude expressed in linear miles (or kilometer...) diminishes. The following table should give a rough idea of this effect, for locations at various latitudes:
Latitude Length of a Degree Approximate examples
(of longitude) in
nautical miles
0 60 Kuala Lumpur, Bogota, Nairobi
20 56.5 Mexico city, Mecca, Mumbai, Rio de Janeiro
45 42.5 Geneva, Boston, Seattle, Beijing, Wellington (NZ)
60 30 Oslo, Stockholm, Anchorage AK, St Petersburg Russia
See this handy online calculator to calculate this for a particular latitude.
Another way to get a idea for this is to see that traveling due East (or West) at the lattitude of Jacksonville, Florida, or San Diego, California, it takes 52 miles to cover a degree of longitude; at the latitude of Montreal or Seattle, it takes only 40 miles.
I am reverse engineering a transportation visualization app. I need to find out the latitude for the origin of their data feed. Specifically what XY 0,0 is. The only formulas I have found calculate distance between two points, or location of a bearing/distance.
They use the XY to display a map in a very legacy application. The XY is in FEET.
I have these coordinates:
47.70446615506108, -122.34469839507263: x=1268314, y=260622
47.774182540800616,-122.3412994737105: x=1269649, y=286031
47.60024792289405, -122.32767331735774: x=1271767, y=222532
47.57012494413499, -122.29129609983679: x=1280532, y=211374
I need to find out what the latitude and longitude of x=0, y=0 is and what the formula would be to find this out.
They have two data feeds, one is more current than the other. The feed with the most current data does NOT include latitude, longitude, but only XY. I am trying to extrapolate based on their less current, yet more informative (includes lat, lon) data feed what 0,0 is so I can simply convert their (more current) data feed's XY coordinates to latitude and longitude.
If you look at the first 2 lines of data, and subtract the latitude
47.7044 - 47.7741 = -0.06972 degrees
There are 60 nautical miles per degree of latitude, and 6076 feet per nautical mile.
-.06972 * 60 * 6076 = 25,415 ft
Subtracting the two 'Y' values:
260662 - 286031 = 25,409 ft
So indeed that seems to prove the X and Y values are in feet.
If you take any of the Y values, and convert back to degrees, for example
260622 ft / ( 6076 ft/nm ) / ( 60 nm/degree ) = .71
286031 ft / 6076 / 60 = .78
So subtracting those values from the latitudes of (47.70 and 47.77) gives you very close to exactly 47 degrees, which should be your y=0 point.
For longitude, a degree is 60 nautical miles at the equator and 0 miles at the poles. So the number of miles per degree has to be multiplied by the cosine of the latitude, so approx cos(47 degrees), or .68. So instead of 6076 nm per degree, it's about 4145 nm.
So for the X values,
1268314 ft / ( 4145 ft/nm ) / ( 60 nm/degree ) = 5.10 degrees
1269649 ft / 4145 / 60 = 5.10 degrees
These X numbers increase as the latitude increases (less negative), so I believe you should add 5.1 degrees, which means the X base point is about
-122.3 + 5.1 = 117.2 West longitude for your x=0 point.
This is roughly the position of Spokane WA.
So given X=1280532, Y=211374
Lat = 47 + ( 211374 / 6096 / 60 ) = 47.58
Lon = -117.2 - ( 1280532 / ( 6096 * cos(47.58)) / 60 ) = -122.35
Which is roughly equivalent to the given data 47.57 and -122.29
The variance may be due to different projections - the X,Y system may be a "flattened" projection as opposed to lat/long which apply to a spherical projection? So to be accurate you may yet need more advanced math or that open source library :)
This question may also be helpful, it contains code for calculating great circle distances:
Calculate distance between two latitude-longitude points? (Haversine formula)
There are many different coordinate systems. You need to find out the what the coordinate systems are for both the lat/lon's (e.g. WGS84 etc) and x/y's first (e.g. some sort of projected system probably).
Once you have that information there are several tools you can use to do conversions and manipulations. One example (of a free open source coding library) is proj4.
Ask them what coordinate system they're using! (or if you got the dataset from some database, look at the metadata for the dataset and it should tell you. Otherwise I'd be skeptical of its value)
Most likely this is one of the state plane coordinate systems. They're for localized areas of the earth (kind of like UTM), and are frequently used for surveying.
You can use CORPSCON (or other GIS programs; ExpertGPS will do this if you have the GIS Option Pack but it's not free. I forget whether GPSBabel does conversion) to convert between lat/long and any of the state plane coordinate systems. You'll also need to know which datum the coordinates are in. WGS84 and NAD83 are very close but NAD27 is different.
You've got good advice on coordinate systems already, so I'll just chime in with the library I've used with great success in the past.
Geotrans is approved for use by the US Department of Defence, so you can be sure that it is well tested. You can grab it from here:
http://earth-info.nga.mil/GandG/geotrans/index.html
That might not be the right link as that page talks about the application, not the library. I expect the library is in the Developers package. Licensing terms were very liberal from memory, but make sure you review the terms before using it commercially.
Edit:
An interesting discussion on Geotrans licensing can be found here:
http://www.mail-archive.com/debian-legal#lists.debian.org/msg39263.html
Over here, I said this:
In Java, I would use the OpenMap converter from a point's expression in UTM to one using Latitude and Longitude (assuming a WGS-84 ellipsoid which is most commonly used in GPS).
OpenMap is open source and I would post a link to their download page but they have a short license script in the way. So, to avoid being rude, I won't deep link. Instead, head to their homepage and click Downloads.
That should either solve your problem directly or at least point you towards a useful algorithm.
I've used Brenor Brophey's gPoint PHP class to do this on a couple of occasions. Solid results, GPL code, and easily deployed. Recommended.