GPS - NMEA GST position error to NED frame - gps

For my usecase I convert GPS position from LLA to ECEF to NED coordinate system. Works as expected. No issues.
Now I want to use the position 'standard deviation' delivered within the GPS NMEA 'GST' message. According this side it is defined as follows:
Latitude 1 sigma error, in meters
Longitude 1 sigma error, in meters
Height 1 sigma error, in meters
Is my expectation correct that 'standard deviation' is expressed in ECEF coordinates ? Or what is the right way to convert 'standard deviation' into the NED frame ?

Related

Kalman filtering - latitude longitude needs to be converted to meters?

I have to implement kalman filtering to filter latitude longitude(from a gps sensor) to get precise position information.
i would be getting distance traveled from a wheel sensor and angle from magnetometer or i can also use gps course from gps sensor. I have latitude longitude in degrees or radians and distance in meters.
So before applying the kalman filtering i need to convert this lat/lon to meters, correct?
With this information i think i can predict using the following equation
x=x+dt*xVelocity;
y=y+dt*yVelocity;
I can calculate velocity using the following formula
xVelocity=distance*cos(angle);
yvelocity=distance*sin(angle);
So the problem here is the conversion. i tried to convert the above lat/lon to UTM and then performed the above calculation and just for testing converted it back to lat and lon to give the desired location but the results seemed wrong
For example-
double latitude=24.55662435;
double longitude=55.3525234;
double north,east;
latLonToUTM(latitude,longitude,&north,&east);
int distance=5;//5 meters
int course=200
double xVel=distance*cos(course);
double yVel=distance*sin(course);
north+=yVel;
east+=xVel;
double nxtLat,nxtLon;
UTMtoLatLon(north,east,&nxtLat,&nxtLon);
double distance=calculateDistace2LatLon(latitude,longitude,nxtLat,nxtLon);// Used online tool to get this distance
double bearing=calculateAnglebetween2LatLon(latitude,longitude,nxtLat,nxtLon);//used online tool to get angle also
here the obtained distance is not 5m and angle is 200..
Since this basic test itself is failing i am yet to go to kalman filtering.
First this conversion should be precise to even go further.
Can someone guide me to which method to use to convert this lat/lon to meters to apply velocity to get nxt meter or location?
Also if there is no need to convert then how can we add the distance travelled which is in meters to this lat lon?

gpsd TPV json data has 95% conficence errors (ex: ept, epx, epy ...) How do you use the numbers?

http://www.catb.org/gpsd/gpsd_json.html
Let's say I get
"alt":1343.127
"epv":32.321
in TPV data.
epv is "Estimated vertical error in meters, 95% confidence", so this means, at 95% of chance, the data has 32.321 meters differences in 1343.127(alt) meters from the actual altitude?
Same question goes to other error values such as ept, epx, epy, epd ..
ept for time
epx for longitude
epy for latitude
epv for altitude
epd for track (heading)??
eps for speed
epc for climb
The error estimates are within a "95% confidence interval" -- There is a 0.95 chance that the actual altitude in your example is between 1310 and 1375 meters.

What a set of GPS coordinates means?

I have a set of GPS coordinates 12.9611159,77.6362214. What exactly do these mean? How can I convert them to degrees of longitude and latitude? What formula should I use to get accurate distance between two sets of coordinates when the order of distance is 10km.
Most likely 12.9611159 is the latitude in degrees, 77.6362214 the longitude. In that case, the coordinate is in India. If latitude and longitude are reversed, you end up in the Greenland Sea.
You can easily check this by entering the coordinate pair in the Google maps search box. Google expects latitude first.
For the distance, in python you can easily use the haversine package:
from haversine import haversine
my_coord = (12.9611159,77.6362214)
other_coord = (12.9, 77.6)
distance = haversine(my_coord, other_coord)
This will give you the distance in km.

lat lon coordinates (WGS84) conversion to local x, y plane

Currently I'm trying the following: I have points from google earth (WGS84) which I want to transform to a local x,y coordinate system: a tangential plane with y positive from south to north and x positive from west to east.
There is no need for the plane to be part of a global coordinate system more than the relation (x=0, y=0) = (lat,lon). The scale at which I'm working is in the order of say 100 kilometers (maximum of for example 200 km's). Very small errors (due to for example the curvature of the earth) are acceptable.
I have relatively little understanding of this topic as of yet. Can anybody help me out? Where would I need to look for example.
Thanks!
I haven't found the answer mathematically but have found that the package basemap (of the mpl_toolkit) should help with this respect (from wgs84 to a transverse mercator projection).

GEOS C API - calculating areas with WGS84 coords (SRID=4326)

I create a polygon where each x/y point is WGS84 format
lat/long values.
The polygons are good approximations to circles and sectors of
radius R (each circumference/arc point is a projected lat/long
value of distance R from a centre/apex coordinate - which I have
verified is correct by computing the Haversine distance between
the edge and reference points and getting a value of R back) .
I use GEOSSetSRID(4326) to indicate the coords are WGS84 format.
GEOSGetSRID() confirms the SRID is set.
Use of GEOSArea then gives a value not even remotely close to
the expected value.
I do not see what else I can programmatically do.
If I set the points in cartesian format, and then set the SRID to
4326, will GEOS implicitly convert the polygon points to WGS84 ??
Is the basic GEOS C API incapable of doing the above ??
Dos SRID have no meaning to the API at all ??
Any info/pointers to correct usage/solutions would be much appreciated.
TIA.
The distance that is given is something like degrees between the two points. In actuality, the GEOS API (at least the C++ interface) is units agnostic; the units it gives the distance in is based on whatever you passed in.
In general, multiplying the result you get by 111000 gives you a fairly accurate measurement in meters. For area, you have to do 111000^2.