Re: [gpsd-dev] CEP(50) 0.285 meters

[Fred Wright]

Restoring the original subject (with cleanup).  Sorry about the earlier
subject change; I thought Pine was smart enough not to do that when the
subjects were identical (or maybe they weren't identical due to the funny
characters), but didn't check.

On Sat, 23 Jul 2016, Greg Troxel wrote:
> Fred Wright <address@hidden> writes:
> > On Fri, 22 Jul 2016, Greg Troxel wrote:
> >> That really shouldn't be an issue.    32-bit CPUs of various kinds have
> >> implemented both uint64_t and double (the longer of the two normal
> >> IEEE754 types) for a long time.   The thing to be careful about is to
> >
> > Yes, as long as it's C99 or later.
>
> I forgot that, but surely C99 is an ok restriction and one we probably
> have already.

Indeed.

> >> use uint64_t if you want a 64-bit type, and not to assume that that int,
> >
> > Mostly yes, except that the 64-bit fixed types tend to be "long" on a
> > 64-bit platform and "long long" on a 32-bit platform, so if you want to
> > use *printf you need a bitness-dependent format string.  I sometimes use
> > "long long" directly to avoid that.
>
> PRIu64 :-)  Agreed, but to write portable code with fixed-width types,
> one basicallyy has to use the PRI specifiers.  It's a little ugly, but
> not hard.

I wasn't aware of that, although I have created something similar on
occasion.  But it's *way* ugly and verbose, seriously impairing
readability.

On Fri, 22 Jul 2016, Fred Wright wrote:

> There's a way to compromise on just the ellipsoidality issue by using a
> spherical formula to get the "distance angle" but then using the actual
> ellipsoidal radius (which has a non-iterative formula) at the location in
> question rather than a constant for the angle to distance conversion.
> Very roughly speaking, the error in this approach is proportional to the
> product of the distance and the eccentricity.

I misstated a bit.  The relevant scaling parameter is the normal, not the
radius (assuming geodetic latitude, which is the kind normally used).
This is the perpendicular segment from the local tangent plane to the
equatorial plane.  Except at the equator and poles, it doesn't quite pass
through the center.

BTW, if the only purpose is to calculate GPS error bounds, then scaled
Pythagoras is perfectly adequate.  If the fixes are so badly scattered
that it isn't adequate, then the GPS is severely impaired. :-)

long_scale = cos((lat1 + lat2) / 2)
distance_angle = sqrt((lat1 - lat2) ** 2 + ((long1 - long2) * long_scale)) ** 2)
distance_radians = distance_angle * PI / 180.0
distance = distance_radians * earth_radius

Substituting the latitude-dependent ellipsoidal normal for earth_radius
improves accuracy a bit, but it's a pretty minor difference.

Fred Wright