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.
Related
I have a list of lat/long points which form a path on the surface of the earth.
I have another point on the surface of the earth and I want to find the shortest distance from that point to a point that falls on the path.
While I could approximate the surface of the earth as a plane, accuracy is important.
The distance between points on the path could be anywhere from 1-1000m. The distance to the point not on the path is from 1-50m. The maximum acceptable error is 0.1m.
Any method of calculating this is acceptable, whether assuming a plane, sphere, or the real shape of the earth as long as the error would not exceed 0.1m for any point on land.
This question is marked language agnostic to encourage answers from people not familiar with the language used. The implementation will be in Dart.
It sounds like you need to calculate the Great Circle Distance across the surface of the earth. A Great Circle calculation permits the calculation of distance along the earth's surface between two arbitrary latitudes and longitudes.
A trivial example of a Great Circle calculation would be to migrate along the Earth's surface along the line of equator (zero degrees latitude). Each degree of longitude of migration along that line (for instance from [0 deg N, 90 deg W] to [0 deg N to 91 deg W]) equates to 1/360th of 40,070km, or 111.306km. Moving between two latitudes and two longitudes requires transformation of coordinates and is outside the scope of this quick note.
Summary and equations found here:
https://en.wikipedia.org/wiki/Great-circle_distance
The accuracy you are seeking of 0.1m requires further refinement; using a sphere to approximate the shape of the Earth will limit the accuracy to perhaps 0.5% (see paragraph from Wikipedia, below). Put another way, a 0.5% error of two points 1000 km apart would be 5000 m.
A more formal and precise calculation will use the true shape of the earth, known as a geoid. This is determined by gravitational measurements and is updated from time to time by the geodesic community.
It is possible to determine one's absolute position on Earth to +/- 0.1m (or better) with advanced GPS surveying techniques, such as RTK or satellite correction services (e.g. Omnistar), but determining the path distance to that accuracy is not the same thing. A survey-quality receiver has corrections built into it for current geoids so that it can translate the lat/long/height calculation it makes using GPS signals to the current reference geoid used by the surveying / geodesic community.
You may not actually require 0.1m accuracy for your application; very few applications require 0.1m absolute accuracy over any distance except (for example) geographic determinations of movement in the Earth's surface. Relative accuracy is more important; e.g. measuring the same point at different times. It is more important to know how much a seismic fault moved relative to its position yesterday or last week, or whether a critical point on a pipeline has moved 2 cm to the north in the past year.
I hope this helps.
Cheers
GP
Per Wikipedia:
So long as a spherical Earth is assumed, any single formula for distance on the Earth is only guaranteed correct within 0.5% (though better accuracy is possible if the formula is only intended to apply to a limited area). [7]
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'm trying to generate some annotations on a map. Currently, I'm using openstreetmap but the query is general. I have two end points on a map and a corpus of few selected points I would like to highlight.
The two endpoints are given in the form lat, long
<walkSteps>
<distance>9.742464221826811</distance>
<streetName>5th St NW</streetName>
<absoluteDirection>EAST</absoluteDirection>
<stayOn>false</stayOn>
<bogusName>false</bogusName>
<lon>-84.3937361115149</lon>
<lat>33.77692965678444</lat>
<elevation/>
</walkSteps>
<walkSteps>
<distance>508.2608917548245</distance>
<relativeDirection>LEFT</relativeDirection>
<streetName>Fowler St NW</streetName>
<absoluteDirection>NORTH</absoluteDirection>
<stayOn>false</stayOn>
<bogusName>false</bogusName>
<lon>-84.39363494600667</lon>
<lat>33.77692904176358</lat>
<elevation/>
</walkSteps>
My aim is to highlight those points on the map, which are present in the corpus and lie in the line connecting these two points.
How can I go about querying the corpus for the same? Annotating on map given lat, lng is not an issue
Rounding errors will prevent you from directly doing as you want. What you should be doing instead is determining the great-circle path between the two end points and highlighting those members of the corpus which are within a certain distance of the great circle route. This is known as the cross-track distance or cross-track error. Formulas for computing the cross-track distance can be found at one of the standard reference sites for geospatial equations but there are others as well.. The problem then becomes one of searching for points in the corpus which are close enough to the great circle path between the two end points.
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.
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.