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.
Related
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 put a point at the top of Mount Everest in Cesium. My most likely candidate as of last night was the code I borrowed to do geodetic to ecef conversion (from PySatel.coord). Upon review this morning, it appears to be correct:
a = 6378.137
b = 6356.7523142
esq = 6.69437999014 * 0.001
e1sq = 6.73949674228 * 0.001
f = 1 / 298.257223563
def geodetic2ecef(lat, lon, alt):
"""Convert geodetic coordinates to ECEF.
Units are degrees and kilometers.
"""
lat, lon = radians(lat), radians(lon)
xi = sqrt(1 - esq * sin(lat))
x = (a / xi + alt) * cos(lat) * cos(lon)
y = (a / xi + alt) * cos(lat) * sin(lon)
z = (a / xi * (1 - esq) + alt) * sin(lat)
return x, y, z
I pulled the lat / lon / alt for the peak of Mt. Everest from Wikipedia. I multiplied the ECF coordinates provided by the above code by 1000(m/km) before positioning the object in my CZML. I get an ECF location of: [302995.41122130124, 5640733.98308375, 2981975.8695256836]. With the default terrain provider (described in the tutorial), this point is significantly higher than the peak of Mt. Everest.
Here's the relevant CZML snippet:
{"position":
{"cartesian": [302995.41122130124, 5640733.98308375, 2981975.8695256836]},
"id": "ellipsoid-1",
"ellipsoid":
{
"radii": {"cartesian": [3545.5375159540376,
164.44985193756034,
164.62702908803794]},
"material": {"solidColor": {"color": {"rgba": [0, 255, 0, 100]}}}
},
"orientation": {"unitQuaternion": [0.00014107125875577922,
-0.011462389405915903,
-0.010254110199791062,
-0.70702315200093502]}
}
There are several factors at work here.
First, the source data that Cesium uses for terrain may have a lower than expected height for the peak of Mount Everest. We use the CGIAR SRTM dataset, so this item in their FAQ is relevant:
Why do some mountain regions have peaks significantly lower than they should be?
As mentioned earlier, many original data voids are concentrated in mountainous areas and in snow-covered regions. Hence, many peaks in high-mountain areas are actually interpolated. Without using a high resolution co-variable for the interpolation, the interpolation fails to identify that the data void is actually a peak, and tends to “flatten” the peak, leading to underestimates in the true elevation for that region. This issue is largely resolved in Version 4.
They say that it is largely resolved in v4, the version Cesium uses, so hopefully this first factor is not the actual problem.
Second, our processing of the source terrain data for use with Cesium may flatten the peak a bit. This problem will be corrected soon, hopefully within the next couple of months.
Third, Wikipedia provides the height as an elevation above mean sea level (MSL). MSL is a complicated surface that is hard to work with mathematically, so your geodetic2ecef is not doing so. Instead, it, like Cesium, is assuming that the altitude is relative to the WGS84 ellipsoid, which is a much nicer surface to work with.
NGA has a web site that can be used to find the height of MSL above the WGS84 ellipsoid, also known as the geoid height:
http://earth-info.nga.mil/GandG/wgs84/gravitymod/egm96/intpt.html
It reports that for the peak of Mount Everest (27° 59′ 17″ N, 86° 55′ 31″ E), MSL is 28.73 meters below WGS84. If you subtract that number from the altitude of the peak reported on Wikipedia, you should get closer, at least.
This page has information on computing geoid heights programmatically:
http://earth-info.nga.mil/GandG/wgs84/gravitymod/egm96/egm96.html
I recommend interpolating over the 15-minute geoid height file instead of computing heights from coefficients.
A couple of other notes not directly related to the question:
Cesium has code to convert LLA (we call it Cartographic) to Cartesian. See Ellipsoid.cartographicToCartesian.
You can specify coordinates in CZML in cartographicDegrees or cartographicRadians instead of cartesian, and then Cesium will do the conversion for you automatically. You still have to adjust for the geoid when specifying the height, however. Also, don't forget that longitude is first.
Proj4js - a port of the famous proj4 library - might do the job for you.
I have this file from tsp.gatech but the lat lng coordinate is divide into two half. Why is this?
COMMENT: Created July 7, 2012, www.tsp.gatech.edu/data/usa/
1 33613.158800 86118.306100
2 33100.954000 85529.675300
3 31571.835200 85250.489300
For example the first coordinate should be 33.613158800 86.118306100.
Update: I searched for New York City and I found it lat lng coordinate to be similar.
Update 2: I think it's incorrect formated see this image of points: http://www.tsp.gatech.edu/data/usa/img/usa115475_large.jpg. I get the points from a file from this website: http://www.tsp.gatech.edu/data/usa/index.html. The site is about a challenge and the file I downloaded is usa115475.tsp.
Euclidean Distance would tend to suggest the values are X,Y distances from a reference point (in feet, meters, kilometers, miles, ...). But this is normally reserved for small scale mapping where the effects of the curvature of the earth can be considered minor.
If the data seems to correspond to decimal degrees that are incorrectly formatted, there could be an error in whatever system is returning the data. But its better to review your own processes before pointing the finger. What query/process/code are you doing to obtain this data?
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.
I have a database full of rows if coordinate pairs like this:
ux: 6643641
uy: 264274
uz: NULL
I have been tasked to make all these coordinates appear on google maps as points of interest, but nobody could tell me what the hell those coordinates were.
What I need for Google Maps is longitude and lengtitude coordinates. I know the one can be converted to the other, but nothing more.
I realize this might not be the correct place to ask about coordinate systems, but I honestly couldn't think of any other place to state the question.
Thanks for any help!
That's my bad, I now see that there is more data for each row:
CoordSystemNumber: 23
CoordSystemName: EUREF89 UTM Sone 33
I think that format is called UTM. You need to know the Zone and Hemisphere to complete the conversion. Is there other data associated with this?
Tell me if this seems helpful :
x = 882880 meters
y = -4924482 meters
z = 3944130 meters
Geocentric latitude and longitude are not commonly used, but they are defined by
latitude = arctan( z / sqrt( x^2 + y^2 ) )
longitude = arctan( y / x )
Taken from here :
http://www.cv.nrao.edu/~rfisher/Ephemerides/earth_rot.html
see this too :
http://en.wikipedia.org/wiki/Geographic_coordinate_system
This wikipedia article might offer some help.
The coordinates are often chosen such that one of the numbers represent vertical position, and two or three of the numbers represent horizontal position. A common choice of coordinates is latitude, longitude and elevation.