[aprssig] Position Ambituity in APRS!

Tue Jan 8 16:15:00 EST 2008

Nothing is going to change is it .

----------------------------------------------------------------------------
Andrew Rich VK4TEC
vk4tec at people.net.au <mailto:vk4tec at people.net.au>
http://www.tech-software.net

-----Original Message-----
From: aprssig-bounces at lists.tapr.org
[mailto:aprssig-bounces at lists.tapr.org]On Behalf Of Steve Noskowicz
Sent: Wednesday, 9 January 2008 3:40 AM
To: bruninga at usna.edu; TAPR APRS Mailing List
Subject: RE: [aprssig] Position Ambituity in APRS!

Yikes!
RE: Steve's response...
 Well Steve, I am an Engineer and understand your response (paraphrasing -
"it
would be nice...") , but it didn't answer my question.  Perhaps I should
re-phrase.

RE: Bob's response...
  I understand your response as well (paraphrasing - ("Precision vs.
accuracy &
The system is designed to..."), but I'll choose my words more carefully.

Q:
  I have a D700.  What does *it* do to the GPS Lat/Lon data when Pos-ambig
is
turned on?  ...While completely ignoring what any application may do in its
display of the transmitted data. To give examples of the type of answer I am
seeking,  I can think of these three possibilities:
1- Truncate some posit digits (coming from the GPS) before (converting to
base
94 or whatever and) transmitting the data.  Thus placing you at the (lower
right - in the US) corner of the resulting spherical polygon.
2- Round the posit data to a more significant digit.  Thus placing you at
said
corner of one of the adjacent spherical polygons.
3- Otherwise manipulate the posit data to add ambiguity perhaps in a manner
already described by Bob...which I'd have to think more about the
implications
of, but am not after that much detail.

   Seems to my engineering and math sense that even any #3 results in
something
similar to #2 regardless pf the encoding algorithm because a limited
precision
(limited digits) in the tx data must "represent" the corner of one polygon
or
another.  [[I understand the concept that sending the missing digits as
zeros
is much different in implication than omitting them, but the data without
the
digits still "represents" the polygon corner.  You can't get around that.]]

This is what I am trying to understand at a basic level without the math.
Just
some understanding of the encoding algo.

If it takes a long explanation, you may save bits and your otherwise
valuable
time .  I was hoping it was a simple thing and don't need to satisfy my
curiosity that much.  I and you both have spent way more typint time time
than
i wanted to on this.
73, Steve

--- Robert Bruninga <bruninga at usna.edu> wrote:

> 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
>
>
> _______________________________________________
> aprssig mailing list
> aprssig at lists.tapr.org
> https://lists.tapr.org/cgi-bin/mailman/listinfo/aprssig
>

--
73, Steve, K9DCI

      ______________________________________________________________________
______________
Looking for last minute shopping deals?
Find them fast with Yahoo! Search.
http://tools.search.yahoo.com/newsearch/category.php?category=shopping

_______________________________________________
aprssig mailing list
aprssig at lists.tapr.org
https://lists.tapr.org/cgi-bin/mailman/listinfo/aprssig