I would like to be more specific about what I want to do. I get coordinates in ECI and I need to get the latitude and longitude from this. How can I do? I was searching but I could'nt find anything about it. Thanks again.
(I'm doing a small program in java that shows the position of a satellite in a given time. So, I used the NORAD SGP algorithm, and I have the position (x,y,z) and velocity(Vx,Vy,Vz). But the coordinates system used by this algorithm is the ECI, according what I read. Now I need to draw the satellite in a map, but I can't convert this coordinates to some system that could help me. I think if I can convert it to longitude and latitude it would be easy to draw. Could you help me? how can I do it? What is the best option(UTM,etc)? Thanks.)
What you want to do is called ECI/ECEF (cartessian) to Geodetic (lat/lon) conversion. This conversion is the most complex of all the geodetic conversions as the closed form solution is complicated. See page 34 of Stevens and Lewis, Aircraft Control and Simulation for a discussion of the coordinate systems: http://books.google.com/books/about/Aircraft_control_and_simulation.html?id=T0Ux6av4btIC
ECI to geodetic is a two step process:
The first step is the easiest in that you need to convert ECI (earth centered inertial) to ECEF (earth centered/earth fixed).
The second step is to convert ECEF to geodetic. You can read about solving this via Newton-Ralphson here: http://en.wikipedia.org/wiki/Geodetic_system
However, if I remember correctly, Newton-Raphson becomes unstable around the poles. The closed form solutions are much more complicated. I have successfully implemented Zhu's method. The advantage of the closed form solution is no iterations and there are no singularities (technically there are singularities but not above the earth). The reference: J. Zhu. Conversion of earth-centered earth-fixed coordinates to geodetic coordinates. Technical Report IEEE Log NO. T-AES/30/3/1666, IEEE, December 1993.
The PyMap3D library for Python has the eci2ecef and the ecef2geodetic functions. They interface with Astropy by default and are quite good, thanks to the hard work of Michael Hirsch (SciVision - he accepts donations).
You need, of course, to know the times at which the ECI coordinates were observed; without that you cannot convert them to ECEF. I recommend not using the simpler eci2geodetic function unless high precision and accuracy are not required; it will be somewhat quicker because it does not account for Earth's nutation, etc.).
Related
I am working on a project where I save the Latitude and Longuite of a vehicle each an interval. I have also a route saved as an array of gps coordinates. So I would like to know if there is some library, that helps me to know if a point is inside the rout and other basic calculations with the coordinates as distance calculations for ex.
Any tool an any language helps!
Based on your comment, since you're not building a typical internet map, I might recommend you use a combination of Python and the Shapely library. You can see some nice examples on this post over at GIS.SE.
GIS Analyses: Geometry Types, Buffering, Intersection, etc.
In order to treat several individual Lat/Long positions as a "route", you'll need to format them as points in a LineString geometry type. Also beware: In most GIS software, points are arranged as X,Y. That means you'll be adding your points as Long,Lat. Inverting this is a common mistake that can be frustrating if you're not aware of it.
Next, in order to test whether any given point is within your route, you'll need to Buffer your route (LineString). I would use the accuracy of the GPS unit, + a few extra meters, as my buffering radius. This will give you a proper geometry (Polygon) for a Point-In-Polygon test (i.e. Intersection) that will calculate whether a given point is within the bounds of the route.
The GIS.SE post I linked to provides examples for both buffering and intersection using Python and Shapely.
Some notes about coordinates: Geodetic vs. Cartesian
I'm not confident if Shapely will perform reliable calculations on geodetic data, which is what we call the familiar coordinates you get from GPS. Before doing operations in Shapely, you may need to translate your long/lat points into projected X/Y coordinates for an appropriate coordinate system, such as UTM, etc. (Hopefully someone will comment whether this is necessary.)
Assuming this is necessary, you could add the PyProj library to give you a bridge between the GPS coordinates you have and the Cartesian coordinates you need. PyProj is the one-size-fits-all solution to this problem. However if UTM coordinates will work you might find the library cited here to be easier to implement.
If you decide to go with PyProj, it will help to know that your GPS data is described by the EPSG:4326 coordinate system. And if you are comfortable with UTM for your projected coordinates, you'll need need to determine an appropriate UTM zone for your area and get its Proj4 coordinate definition from SpatialReference.org.
For example I live in South Carolina, USA, which is UTM 17 North. So if I go to SpatialReference.org, search for "EPSG UTM zone 17N", select the option which references "WGS 1984" (I happen to know this means units in meters), then click on the Proj4 link, the site provides the coordinate system definition I'm after in Proj4 notation:
+proj=utm +zone=17 +ellps=WGS84 +datum=WGS84 +units=m +no_defs
If you're not comfortable diving into the world of coordinate systems, EPSG codes, Proj4 strings and such, you might want to favor that alternate coordinate translation library I mentioned earlier rather than PyProj. On the other hand, if you will benefit from a more localized coordinate system (most countries have their own localized systems), or if you need to keep your code portable for use in many areas, I'd recommend using PyProj and make sure to keep your Proj4 definition string in a config file, and NOT hard-coded throughout your app!
everyone
recently I am trying to solve the location error generated by GPS, so I came up with an idea of projecting the GPS points to the nearest road, as shown bellow [1]. But I know that indeed earth is not a flat plane and general projection method is not adaptive to this problem. What should I do to deal with the projection problem that exists on sphere to get a better precision?
![1]: http://imgur.com/nL7tB7m
Similarly, when it comes to interpolation between two points, same problem emerged. I did once assume two points were closed so I could ignore the flatness
effect, but failed if their distance was long enough. Regular interpolation method won't give me a better-precision result.
![2]: http://imgur.com/rOSu8gk
Im trying to transform a path along an arc.
My project is running on osX 10.8.2 and the painting is done via CoreAnimation in CALayers.
There is a waveform in my project which will be painted by a path. There are about 200 sample points which are mirrored to the bottom side. These are painted 60 times per second and updated to a song postion.
Please ignore the white line, it is just a rotation indicator.
What i am trying to achieve is drawing a waveform along an arc. "Up" should point to the middle. It does not need to go all the way around. The waveform should be painted along the green circle. Please take a look at the sketch provided below.
Im not sure how to achieve this in a performant manner. There are many points per second that need coordinate correction.
I tried coming up with some ideas of my own:
1) There is the possibility to add linear transformations to paths, which, i think, will not help me here. The only thing i can think of is adding a point, rotating the path with a transformation, adding another point, rotating and so on. But this would be very slow i think
2) Drawing the path into an image and bending it would surely lead to image-artifacts.
3) Maybe the best idea would be to precompute sample points on an arc, then save save a vector to the center. Taking the y-coordinates of the waveform, placing them on the sample points and moving them along the vector to the center.
But maybe i am just not seeing some kind of easy solution to this problem. Help is really appreciated and fresh ideas very welcome. Thank you in advance!
IMHO, the most efficient way to go (in terms of CPU usage) would be to use some form of pre-computed approach that would take into account the resolution of the display.
Cleverly precomputed values
I would go for the mathematical transformation (from linear to polar) and combine two facts:
There is no need to perform expansive mathematical computation
There is no need to render two points that are too close from each other
I have no ready-made algorithm for you, but you could use a pre-computed sin or cos table, and match the data range to the display size in order to work with integers.
For instance imagine we have some data ranging from 0 to 1E6 and we need to display the sin value of each point in a 100 pix height rectangle. We can use a pre-computed sin table and work with integers. This way displaying the sin value of a point would be much quicker. This concept can be refined to get a nicer result.
Also, there are some ways to retain only significant points of a curve so that the displayed curve actually looks like the original (see the Ramer–Douglas–Peucker algorithm on wikipedia). But I found it to be inefficient for quickly displaying ever-changing data.
Using multicore rendering
You could compute different areas of the curve using multiple cores (can be tricky)
Or you could use pre-computing using several cores, and one core to do finish the job.
We're building a GIS interface to display GPS track data, e.g. imagine the raw data set from a guy wandering around a neighborhood on a bike for an hour. A set of data like this with perhaps a new point recorded every 5 seconds, will be large and displaying it in a browser or a handheld device will be challenging. Also, displaying every single point is usually not necessary since a user can't visually resolve that much data anyway.
So for performance reasons we are looking for algorithms that are good at 'reducing' data like this so that the number of points being displayed is reduced significantly but in such a way that it doesn't risk data mis-interpretation. For example, if our fictional bike rider stops for a drink, we certainly don't want to draw 100 lat/lon points in a cluster around the 7-Eleven.
We are aware of clustering, which is good for when looking at a bunch of disconnected points, however what we need is something that applies to tracks as described above. Thanks.
A more scientific and perhaps more math heavy solution is to use the Ramer-Douglas-Peucker algorithm to generalize your path. I used it when I studied for my Master of Surveying so it's a proven thing. :-)
Giving your path and the minimum angle you can tolerate in your path, it simplifies the path by reducing the number of points.
Typically the best way of doing that is:
Determine the minimum number of screen pixels you want between GPS points displayed.
Determine the distance represented by each pixel in the current zoom level.
Multiply answer 1 by answer 2 to get the minimum distance between coordinates you want to display.
starting from the first coordinate in the journey path, read each next coordinate until you've reached the required minimum distance from the current point. Repeat.
When researching on how to do the classic "get POI in range" problem I've found that the most used algorithms are Haversine and if you need real accuracy then Vincenty's formula. I went the first one because high accuracy wasn't an issue. However, it got me thinking on something that hits me as odd, why is that I found no references to caching the Cartesean coordinates on the database instead of using the haversine formula with the lat/lon?
The issue here is, of course, performance. The haversine formula requires a ton of cos/sin function calls, but wouldn't it be simpler to store the projected X, Y and Z of a lat/lon point on the database and apply the dot product directly? That would require a single arccos call unless I'm mistaken.
Because any given Cartesian projection will only give the correct answer for certain points - a projection which gives the right distance between two points on one particular circle around a sphere will distort distances along another particular circle.
Formulas such as Haversine are independent of the relative locations of the various points on the sphere; they return the correct distance regardless.
No, you are not mistaken. Two things, though. First, obviously, your performance benefits will depend on the nature of your application. If you need to use the same points many times in your calculations, you will improve performance by doing what you suggest.
Second, the formula you use is not the issue here. If you precompute and store sin and cos of lat/lon and use haversine, you will get the exact same performance improvements.
Calculating the distance between two X,Y,Z coordinates will give you the straight line distance (as the arrow flies). The Haversine formula gives the shortest path on the surface of the curved earth (spherical distance). Most geographic software applications need to compute the distance across the earth's surface, thus the Haversine or similar spherical trigonometry algorithms are used.