I am using the Microsoft.SqlServer.Types DLL in my projects for validating Latitudes and Longitudes.
The Library validates longitude values between -15069 and 15069 degrees instead from -180 to 180.
Can anybody explain what is the significance or reason that Microsoft is checking the longitude values to be between -15069 and 15069 degrees?
Microsoft has listed the standards for Geo Spatial standards on this website which mentions the Longitude values MUST be between -15069 and 15069 degrees, inclusive.
https://msdn.microsoft.com/en-us/library/ee301753(v=sql.105).aspx
Your inputs in understanding this concept will be appreciated!
Why is longitude not restricted to [-180°..+180°]?
Here's a brief thought experiment.
Which of the following three lines does LINESTRING (-180 0, 180 0) represent?
A line going around the whole globe along the equator in an eastward direction.
A line going around the whole globe along the equator in a westward direction.
A line of length 0, since -180° latitude denotes the same meridian as +180° latitude.
As soon as you decide on any of the three possibilities, you will find that you have no way of modelling the other two cases as LINESTRING (try it!)… at least not when you restrict longitude to the (geographically correct) interval [-180°..+180°]!
Let's see what happens when we relax that restriction:
The line going around the globe in an eastward direction can now be modelled as LINESTRING (-180 0, 180 0). (This seems to match our expectations, since increasing degrees of longitude means "going eastward".)
The line going around the globe in a westward direction now becomes LINESTRING (-180 0, -540 0). (Decreasing degrees of longitude denotes "going westward".)
The line of length 0 becomes LINESTRING (-180 0, -180 0). (No change in coordinates means "no distance travelled".)
Yes, but why did they chose exactly ±15069 degrees?
That, I cannot say. It might have to do with floating-point precision (i.e. spatial computations becoming too imprecise if you specified a point that's "wrapped around" the globe more than 15,069° ÷ 360° = 41,8583… times) or simply a arbitrary limit (i.e. they thought noone will need to be able to construct a spiral that goes around the globe more than approx. 42 times).
Why was latitude restricted to [-90°..+90°], if longitude wasn't restricted?
Let's repeat the above thought experiment: What does LINESTRING (0 90, 0 -90) mean?
A line going around half the globe along the prime meridian in a southward direction.
A line going around half the globe along the prime meridian in a northward direction.
A line of length 0.
We can rule out (3), since POINT (0 90) and POINT (0 -90) are distinct points: namely, the north pole and the south pole. A line going from one to the other definitely does not have zero length.
We can also rule out (2), simply because it does not make any sense to say "going northward" when starting at the north pole. You can only stay there, or go south, which is already covered by (1).
So we end up unambiguously with (1). The reason, therefore, why latitude was restricted to the geographically meaningful [-90°..+90°] is because there is never any ambiguity when modelling lines that touch or cross the geographic poles. This is because there are no sudden degree "jumps" like there are with longitude (where one and the same meridian is described both by -180° and +180°).
Related
I'm trying to decide whether it makes cpu processing time sense to use the more complex Haversine formula instead of the faster Pythagorean's formula but while there seems to be a pretty unanimous answer on the lines of: "you can use Pythagora's formula for acceptable results on small distances but haversine is better", I can not find even a vague definition on what "small distances" mean.
This page, linked in the top answer to the very popular question Calculate distance between two latitude-longitude points? claims:
If performance is an issue and accuracy less important, for small distances Pythagoras’ theorem can be used on an equirectangular projection:*
Accuracy is somewhat complex: along meridians there are no errors, otherwise they depend on distance, bearing, and latitude, but are small enough for many purposes*
the asterisc even says "Anyone care to quantify them?"
But this answer claims that the error is about 0.1% at 1000km (but it doesn't cite any reference, just personal observations) and that for 4km (even assuming the % doesn't shrink due to way smaller distance) it would mean under 4m of error which for public acces GPS is around the open-space best gps accuracy.
Now, I don't know what the average Joe thinks of when they say "small distances" but for me, 4km is definitely not a small distance (- I'm thinking more of tens of meters), so I would be grateful if someone can link or calculate a table of errors just like the one in this answer of Measuring accuracy of latitude and longitude? but I assume the errors would be higher near the poles so maybe choose 3 representative lattitudes (5*, 45* and 85*?) and calculate the error with respect to the decimal degree place.
Of course, I would also be happy with an answer that gives an exact meaning to "small distances".
Yes ... at 10 meters and up to 1km meters you're going to be very accurate using plain old Pythagoras Theorem. It's really ridiculous nobody talks about this, especially considering how much computational power you save.
Proof:
Take the top of the earth, since it will be a worst case, the top 90 miles longitude, so that it's a circle with the longitudinal lines intersecting in the middle.
Note above that as you zoom in to an area as small as 1km, just 50 miles from the poles, what originally looked like a trapezoid with curved top and bottom borders, essentially looks like a nearly perfect rectangle. In other words we can assume rectilinearity at 1km, and especially at a mere 10M.
Now, its true of course that the longitude degrees are much shorter near the poles than at the equator. For example any slack-jawed yokel can see that the rectangles made by the latitude and longitude lines grow taller, the aspect ratio increasing, as you get closer to the poles. In fact the relationship of the longitude distance is simply what it would be at the equator multiplied by the cosine of the latitude of anywhere along the path. ie. in the image above where "L" (longitude distance) and "l" (latitude distance) are both the same degrees it is:
LATcm = Latitude at *any* point along the path (because it's tiny compared to the earth)
L = l * cos(LATcm)
Thus, we can for 1km or less (even near the poles) calculate the distance very accurately using Pythagoras Theorem like so:
Where: latitude1, longitude1 = polar coordinates of the start point
and: latitude2, longitude2 = polar coordinates of the end point
distance = sqrt((latitude2-latitude1)^2 + ((longitude2-longitude1)*cos(latitude1))^2) * 111,139*60
Where 111,139*60 (above) is the number of meters within one degree at the equator,
because we have to convert the result from equator degrees to meters.
A neat thing about this is that GPS systems usually take measurements at about 10m or less, which means you can get very accurate over very large distances by summing up the results from this equation. As accurate as Haversine formula. The super-tiny errors don't magnify as you sum up the total because they are a percentage that remains the same as they are added up.
Reality is however that the Haversine formula (which is very accurate) isn't difficult, but relatively speaking Haversine will consume your processor at least 3 times more, and up to 31x more computational intensive according to this guy: https://blog.mapbox.com/fast-geodesic-approximations-with-cheap-ruler-106f229ad016.
For me this formula did come useful to me when I was using a system (Google sheets) that couldn't give me the significant digits that are necessary to do the haversine formula.
I have over 350,000 pairs of latitude and longitude decimal values. These pairs represent locations in the US. These data give me fairly precise data, but I don't need to be this precise.
I'm looking for recommendations on how to round these values so that I can reduce my locations from 350,000 to something smaller.
Rounding both values to the nearest hundredth produces 138k pairs.
Rounding both values to the nearest thousandth produces 320k pairs.
If rounding to the 2nd decimal, I fear that I'm reaching out too far. If rounding to the 3rd decimal, I feel like I still have too many pairs. Ideally, I would like to be within perhaps 400 to 600 meters of the actual lat/lon. I suppose rounding to the 3rd decimal is indeed approaching that desired area, but slightly on the strict side.
Has anyone tried this, and maybe taken the approach of rounding latitude to the 2nd decimal and longitude to the 3rd decimal? Would you recommend one over the other? Again, most data in the continental US, with some in Alaska and Hawaii.
Keeping the precision in your latitude values is more helpful than the precision in longitude. At the equator the precision (in degrees) comes out to the same, but as you move north or south from there, the distance in a degree longitude becomes less and less.
If you really need within the 500 meters, and you assume your rounding of each location has equal loss of distance, you can round each value by 354 meters. (That is you target rounding each an equal distance on average.)
354 meters is about 0.0033 degrees of latitude anywhere in the world. (There's less than a percent of variance in this depending on location.)
But longitude changes size much more dramatically:
In northern Alaska, at a latitude of 70 degrees N, 354 meters comes close to 0.01 degrees longitude, but in Hawaii, the same distance east-west equals 0.0033 degrees.
Instead of just rounding, could you group to nearest even thousandth for latitude? For longitude, group to nearest hundredth if latitude is greater than 50 group to nearest even thousandth otherwise.
Might be a pain to explain to people, but not too painful to code, I think.
I have GPS coordinates provided as degrees latitude, longitude and would like to offset them by a distance and an angle.E.g.: What are the new coordinates if I offset 45.12345, 7.34567 by 22km along bearing 104 degrees ?Thanks
For most applications one of these two formulas are sufficient:
"Lat/lon given radial and distance"
The second one is slower, but makes less problems in special situations (see docu on that page).
Read the introduction on that page, and make sure that lat/lon are converted to radians before and back to degrees after having the result.
Make sure that your system uses atan2(y,x) (which is usually the case) and not atan2(x,y) which is the case in Excell.
The link in the previous answer no longer works, here is the link using the way back machine:
https://web.archive.org/web/20161209044600/http://williams.best.vwh.net/avform.htm
The formula is:
A point {lat,lon} is a distance d out on the tc radial from point 1 if:
lat=asin(sin(lat1)*cos(d)+cos(lat1)*sin(d)*cos(tc))
IF (cos(lat)=0)
lon=lon1 // endpoint a pole
ELSE
lon=mod(lon1-asin(sin(tc)*sin(d)/cos(lat))+pi,2*pi)-pi
ENDIF
This algorithm is limited to distances such that dlon <pi/2, i.e those that extend around less than one quarter of the circumference of the earth in longitude. A completely general, but more complicated algorithm is necessary if greater distances are allowed:
lat =asin(sin(lat1)*cos(d)+cos(lat1)*sin(d)*cos(tc))
dlon=atan2(sin(tc)*sin(d)*cos(lat1),cos(d)-sin(lat1)*sin(lat))
lon=mod( lon1-dlon +pi,2*pi )-pi
How to find a few coordinates that are in the straight line, between 2 coordinates?
For example:
Start coordinate: Lat=X1 Long=Y1
End coordinate: Lat=X2 Long=Y2
Make a straight line from X1,Y1 to X2,Y2.
Then find 5 points that are located in that line, that are spread in the same distance.
Anyone can help to find the algorithm and calculation?
The coordinate is in decimal format, e.g. 50.123456, 6.123456
Thanks.
There are no "straight lines" on a sphere (or ellipsoid).
Anyway, you'll need to:
Calculate the distance and initial azimuth from (x1,y1) to (x2,y2).
You can use Vincenty's inverse method.
Calculate the coordinate of points with distance (0,25d, 0.5d, 0.75d) from (x1,y1) at that azimuth (plus points (x1,y1) and (x2,y2) of course).
You can use Vincenty's direct method.
Both direct and inverse methods are described on Wikipedia.
An extremely accurate implementations for both direct and inverse problems are available as part of GeographicLib.
Less accurate, but much simpler methods are described in Aviation Formulary.
I append a collada file into the plug-in, and then move it (append.Child, then remove.Child, then append.Child, etc) based on very small Latitude and Longitude increments. When the Latitude increment = Longitude increment, however, the file moves in a rectangular fashion and NOT a square fashion. What am I doing wrong? Shouldn't the "path" which the collada file travels be "square"?
The increment in both directions (lat or long) is the same increment (0.00001499817). In trying to figure this out, I also noticed that the "circle" polygon code also shows up as an oval unless you place it along the equator.
Should I be assuming that a latitude increment EQUALS a longitude increment in Earth???
Anybody know what might be going on? Thanks. Paul
Should I be assuming that a latitude increment EQUALS a longitude
increment in Earth???
Do you assume the Earth is a perfect sphere?
Do you assume that latitude and longitude lines are evenly spaced out?
To quote someone else from a quick google search
Longitude is the east-west (right/left) measurement on a map. It goes
from 180 degrees west to 0 (through Greenwich, London, UK) then to
180 degrees East. 180 degrees West or East is actually the same line
- its in the middle of the Pacific ocean.
There are thus 360 lines of integer Longitude.
Latitude goes from the Equator - 0 degrees, North to the North Pole at
90 degrees north. Or south to the South Pole at 90 degrees south.
There are thus 180 lines of integer latitude.
Technically, you'd have to say that the number of possible lines is
actually infinite. Since between any two lines you choose, no matter
how close together they are, you can always fit a bunch more in
between them.