I'm using an L80 GPS module together with my 8-bit processor. GPS module responds with a massage in NMEA format, giving me information about the date, time, latitude, longitude, altitude (if possible), number of satellites etc.
Latitude and longitude information of NMEA are in the form of degrees and minutes (DD°MM.mmm').
I'm able to convert them into only degrees notation (DD.dddddd°).
I have the following problem: Given a particular location (e.g. 48.858125, 2.294398) and a safety radius of, let's say, 50 meters (no more than 300 meters), how to determine weather (a, b) point is within a safety circle or not?
Can you help me figuring out the math hiding behind?
In short, I would like you to help me determine distance in meters between two points on Earth represented in angular coordinate system. Are there any math guru willing to help me?
Note that my point of calculations is my processor.
I know that, having latitudes and longitudes in degrees, my points are represented in an angular coordinate system, not Cartesian (linear) one.I also know that Universal Transferse Mercator (UTM) representation of points on Earth is in Cartesian coordinate system. Is it, maybe, easier to transform degree notation (DD.dddddd°) into UTM notation? I know there are on-line tools that are able to do a conversion. However, I don't know the math.
Thank you very much for your time and effort to help me.
Sincerely,
Bojan
You can simply find distance b/w two points by longitude and latitude.
you can find reference code on this link.
Hope this helps.
Just use the haversine formula to calcualte the distance between two points on earth.
Search for term "haversine" and the name of your programming language.
Is it, maybe, easier to transform to UTM
No for sure not. It is very complex, and it gets extremly complex when the two points are located in different UTM zones.
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.
There are two points A, B, and distances x (miles from A), and y (miles from B). Let the distance from A to B be N. So, A is N miles away from B. How do I solve the problem: What are the points available that are (N + x + y) miles away from A? I'm not sure how to explain this any better. I really have no clue on how to attack this problem, I read Fastest Way to Find Distance Between Two Lat/Long Points and I believe the solution given calculates the distance between two points and have no idea if this solution could be used to apply to my problem, or if so, how.
If you are looking for an approximation algorithm I suggest to look for a k-means algorithm or a hierarchical cluster, especially a monster curve or a space filling curve. First off you can compute a minimal spanning tree of the graph and then remove the longest and expensivest edges. Then the tree makes many little trees and you can use the k-means to compute group of points i.e. clusters.
"The single-link k-clustering algorithm ... is precisely Kruskal's algorithm ... equivalent to finding an MST and deleting the k-1 most expensive edges." See for example here: https://stats.stackexchange.com/questions/1475/visualization-software-for-clustering.
A good example for a monster curve is the hilbert curve. The basic form of this curve is an U-shape and by copy many of it together and rotating it the curve fills the euklidian space. Surprisingly a gray code can help to find out the orientation of this U-shape. You can look up Nick's spatial index quadtree hilbert curve blog article about more details. Instead to calculate the curve's index you can put together a quadkey like in bing maps. The quadkey is unique for each coordinate and it can be used with normal string operations. Each position in the key is part of the U-shape curve and thus you can select this region of points from select partially from left to right from the quadkey.
In this image you can see the green polygon is found using a hilbert curve:
You can find my php classes here: http://www.phpclasses.org/package/6202-PHP-Generate-points-of-an-Hilbert-curve.html
When dealing with GIS source code you often need to write latitude and longitude coordinate tuples.
E.g. in Google Maps links (123, 456):
http://maps.google.com/maps/ms?msid=214518704716144912556.00046d7689a99e95b721c&msa=0&ll=123,456&spn=0.007996,0.026865
Which is preferred order (and why?)
latitude, longitude
longitude, latitude
I have seen both being used in various systems and I hope to find some evidence to stick with other one.
Is there a standard practice, and if so, what is it / what are they?
EPSG:4326 specifically states that the coordinate order should be latitude, longitude. Many software packages still use longitude, latitude ordering. This situation has wreaked unimaginable havoc on project deadlines and programmer sanity.
The best guidance one can offer is to be fully aware of the expected axis order of each component in your software stack. PostGIS expects lng/lat. WFS 1.0 uses lng/lat, but WFS 1.3.0 defers to the standard and uses lat/lng. GeoTools defaults to lat/lng but can be overridden with a system property.
The GeoTools docs on the history and explanation of the problem are worth a read:
http://docs.geotools.org/latest/userguide/library/referencing/order.html
The prefered order is by convention latitude, longitude. This was presumably standardized by
the International Maritime Organization
as reported here. Google also uses this order in its Maps and Earth. I remember this order by thinking of alphabetic order of latitude, longitude.
The correct order is longitude, latitude, in virtually all professional GIS applications, as it is in conventional math (ie, f(x ,y, z)). The GeoJSON standard is fairly typical and succinct:
The order of elements must follow x, y, z order
(easting, northing, altitude for coordinates in a
projected coordinate reference system, or longitude,
latitude, altitude for coordinates in a geographic
coordinate reference system).
The same is true of the primary Open Geospatial Consortium standards (WKT and WKB, and extensions like EWKB). Likewise Google may output the order in Lat/Lon to make it more familiar to users who grew up with that custom (ie from navigation standards like IMO, rather than computational ones.) But the KML standard itself is like virtually all other GIS systems:
The KML encoding of every kml:Location and coordinate
tuple uses geodetic longitude, geodetic latitude, and
altitude (in that order).
Good rule of thumb: if you know what a tuple is and are programming, you should be using lon,lat. I would even say this applies if your end user (say a pilot or a ship captain) will prefer to view the output in lat,lon. You can switch the order in your UI if necessary, but the overwhelming majority of your data (shapefiles, geojson, etc.) will be in the normal Cartesian order.
By convention in 'real-life', when giving a position, the latitude (i.e. North/South) is always given 1st, e.g. 20°N 56°W (although, this doesn't follow normal convention if thinking about a standard Cartesian grid); similarly, all co-ordinates on Wikipedia follow this convention (e.g. see location for Southampton: http://en.wikipedia.org/wiki/Southampton). To save confusion, especially when units aren't being included, I'd always recommend that the latitude is given 1st in a tuple.
So the preferred order depends on personal preference!
Latitude came first; the equinox has been known for millenia, as the days the "sun crosses the equator"; in March crossing from S to N and Sept from N to S.The only question might have been whether the Equator should have been 0 or 90 degrees. By taking 0 deg, the angle between vertical and the midday solar zenith on the equinox is the latitude of a location, everywhere on the planet. The prime latitude, or prime parallel effectively defined itself.
Longitude could only be by agreement. Britain put up a Longitude prize. Britain needed its ships to know where they were and needed better maps. Harrison (http://www.youtube.com/watch?v=T-g27KS0yiY) produced an accurate marine chronometer; they sent mapmaking voyaging journeys eg James Cook 1770's. Britain therefore claimed the Prime Meridian by using Greenwich as 000deg for their maps. After 100 years of their use, the Prime Meridian was accepted internationally, in 1884.
In Christopher Columbus time Latitude was the only number they had. The strategy was to traverse a parallel before turning left or right for destination; watching for clouds or birds. Measuring speed in knots every hour was common but did not account for currents. Perhaps Columbus's greatest achievement was getting back home from the West Indies four times. Without that, land he discovered could not be added to the maps.
Read "Longitude" by Dava Sobel (ISBN: 9780007214228)
ISO 6709 standardizes listing the order as latitude, longitude for safety reasons. Graham's explanation above sounds correct to me as well. Someone suggested this answer isn't related to the question--it absolutely is, and explains why the order is often given as latitude, longitude.
This is how it has been listed for however long navigators have been using the system; changing that now would be confusing, and as ISO suggests, potentially dangerous. GIS softwares, like ArcMap, list them the other way around because that is the typical convention for x,y coordinate pairs. Latitude is y, longitude is x, so that's how Arc lists them.
Personally I've never seen anything but latitude followed by longitude.
And, when using + and - instead of N and S, it's always been + is N and - is S.
I have observed variation when using + and - for E and W. Generally + has been E and - has been W. However, on older applications where they were dealing overhwlemingly with W longitudes, I've seen + be W and - be E.
Hopefully you'll not have to be dealing with applications that old.
Apart from GeoJSON spec, which others have already mentioned, there are other practical cases where longitude,latitide order is recommended, even mandatory - e.g.: geospatial indexing in MongoDB. If you get the order wrong there, your queries will return wrong results, as if performed again a transposed dataset.
Longitude then Latitude (lon, lat).
When projected to Mercator longitude defines the x direction and latitude defines the y direction. Most geometry libraries strictly uses this format of (lon, lat) as it is the most intuitive way to think of geographic coordinates in a 2D plane.
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.