[aprssig] Position Ambituity in APRS!

[Robert Bruninga]

Welcome to the 15 year debate!

>> Is, or is not, position ambiguity at the 
>> transmit end simply the
>> truncation of lat/lon digits?  

It is not.  It is NOT truncation.  It is simply the transmission
of the AVAILABLE DIGITS to the degree of precision desired or
known.  If you have only degrees, you transmit only degrees,
which give a position to the nearest degree (60 miles). If you
have only degrees and minutes, you transmit only degrees and
minutes which is the position to the nearest minute (1 mile).  

If you have a position known only to the nearest tenth of a
minute, then you only transmit the degrees, minutes and the
tenth of a minute that you have (position known to the nearest
tenth of a mile).  This is not truncation.  It is transmitting
what you know, and NOT implying additional digits of precision
that you do not know.

That is all that APRS position ambiguity means.  You transmit
the position only with the number of digits that match the
precision that you have.  And you do NOT add precise decimal
digits beyond your knowledge.  The position field in APRS is a
CHARACTER STRING that happens to have room for digits of
precision down to hundredths of a minute.  It is NOT a numeric
field which many programmers incorrectly implemented.

> You have to understand the way Bob's mind works. 

Yes, it is simple.  If the position is known to be 38 degrees 58
minutes, then you transmit ONLY "3858.  N"  It is absolutely
WRONG to send "3858.00N". Any middle school science teacher can
tell us that.

> 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, and an 
> altitude-like extension representing the 
> approximate radius of  uncertainty.

Absolutely wrong.  That precise estimate implies a PRECISION
that does not exist.  Such simplifications by APRS clones
unwilling to properly implement this simplest of concepts
undermines the integrity of information from sender to receiver.
If the sender does not know the precise position, then he should
not under any circumstances send it as a precise position.  He
should transmit only what he knows so that the recepient cleary
sees the same level of ambiguity.

> 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. 

Not true.  I did not reuse "bytes". What I refused to do was to
put in higher digits of precision when those digits ARE NOT
KNOWN.  To do so would violate every principle of "precison" as
taught in middle school.

> 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.

Partly right.  Because the uncertainty is not a precise polygon;
it is a lack of additional precision.  It is an uncertanty of
the number of digits of precision by the sender, and an EXACT
transfer of that same uncertany to the recepient. In that sense
it conveys the "magnitude of uncertainty" from the sender to the
recepient in an exact format that cannot be missinterpreted.

> The problem is that this representation does 
> not fit the reality.  

It may not fit with the reality of some APRS implementations
that took the simplistic approach of truncating digits, but it
does transfer exactly from the sender to the receiver the
knowledge of the ambiguity if displayed properly.  If one
doesn't have a digit of precision, then he should NOT stick in a
ZERO.  Stick in a SPACE character, just like he would write it
on a piece of paper.

> 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.

Yes, now we are talking about how to display it.  This now is
why it is so important to do it consistently across all APRS
clients so that everyone gets the same visualization that the
sender intended...

What you describe above is what I intended for display but with
one additional tweak as implemented in APRSdos.  And that is to
provide a SLIGHT random offset within that area of uncertanty so
that if multiple APRS positions are reported in that same area,
that they are not all stacked on top of each other so that only
the top one appears.

If they all use the same precise center of the area, then only
the latest ICON shows on the map and only one CIRCLE of
ambiguity shows.  This can be very missleading to the casual
viewer of the map.  But in APRSdos, if there are 6 such stations
reporting ambiguity in the same polygon, then each of their
circles of ambiguity will each show, but slightly offset so that
they all individually appear and so at a glance, one can see
that there are 6 stations there.

It is very simple.  This is the definition of APRS ambiguity:

1) The APRS position field is a CHARACTER string
2) The sender only includes the digits he knows
3) On receipt a circle of ambiguity is displayed that represents
the possible ambiguity due to the lack of precision
4) For display purposes, thse circles are offset slightly so
that multiple stations reporting the same ambiguous position do
not all appear as a single display.

In addition, the original APRSdos does the following:

A) The SYMBOL is only shown as long as the size of the symbol
overlaps the size of the circle. In this case the circle is
hidden or not displayed.  Example, viewing a .1 mile ambiguous
station on a 100 mile map scale, you see the symbol and all
looks normal.

B) As one zooms in, and the circle becomes larger than the
symbol, then the SYMBOL disappears and only the circle is
displayed.  This avoids the appearance of the symbol as an
"exact location inside a circle".  It is not.  At this point,
the circle is the best representation for that station, the
symbol is not.

C) Originally, APRSdos simply let the SIZE of the symbol expand
so that it always covered the area of ambiguiy as the map was
zoomed.  But this can clutter the map.  My favorite example, is
when I arrive in a city airport and I enter the estimated
position of the city into my HT with a 10 mile ambiguity just to
show where I am (without carrying a GPS).  I do not want my
SYMBOL to cover the entire city!

So that is why I fell back to (B) above as the best way to
convey the ambiguity to the recepient at high map zooms.

Bob, WB4APR