[aprssig] Position Ambituity in APRS!

[Steve Dimse]

On Jan 8, 2008, at 1:05 AM, Steve Noskowicz wrote:

> Hmmm  I hope I didn't misunderstand this.    Disregarding the  
> (complexities
> added by the) display at the receiving end...I understand that this  
> can make
> things appear much different.
>     Is, or is not, position ambiguity at the transmit end simply the
> truncation of lat/lon digits?   Your explanation below implies this.
>
You have to understand the way Bob's mind works. He talks and acts  
like an engineer most of the time, but every once in a while he takes  
a flying leap into kludgeland. This tops my most-hated of Bob's  
excursions.

The engineering way to handle uncertainty with position is as has been  
suggested, a precise position representing the best guess, with an  
altitude-like extension representing the approximate radius of  
uncertainty. Google does this, Garmin does this, Trimble does this,  
but Bob? To save a few bytes in the protocol, Bob reused bytes in the  
lat/lon. His intention was not that this be interpreted as a question  
mark in the lat/lon, a literal uncertainty interpreted as a polygon,  
as an engineer would, but rather simply as a magnitude of uncertainty.

The problem is that this representation does not fit the reality.  
There is no way to represent the sort of uncertainty the Google cell  
tower position returns. You do not have the ability to place the  
center anywhere you want, just in the center of pre-defined polygons,  
with predetermined radii. (And sorry Curt, my extreme nitpicking  
suggests the linear projection of these polygons is never a rectangle.  
For ambiguities that do not cross the poles or equator (the only case  
allowed by the protocol), the border away from the equator is shorter  
than border towards the equator, making it a trapezoid. Though they  
can't be represented by the APRS implementation, ambiguities that  
cross the equator would be hexagons, and the interesting polar case is  
left as an exercise for the reader!)

So, think of ambiguity as representing a circle, taking the center of  
the polygon described by the lowest and highest values of the missing  
digits, and with the radius of the magnitude of the missing digits.

So much easier to have simply added, say, /PE for position error,  
followed by a few digits documenting the uncertainty. But no...

Steve K4HG