[aprssig] Position Ambituity in APRS!
William McKeehan mckeehan at mckeehan.homeip.netTue Jan 8 16:23:04 UTC 2008
- Previous message: [aprssig] Position Ambituity in APRS!
- Next message: [aprssig] Position Ambituity in APRS!
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Let me jump in and ask a really simple question. If I transmit my position to degree precision (for example 35 . N\083 . W), to plot that "location" on a map, I would mark an everything from 3500.00N to 3559.59N and 08300.00W to 08359.59W, right? So that would be the possible area (whatever geometric shape it may be) that I can be in, right? -- William McKeehan KI4HDU http://mckeehan.homeip.net On Tue, January 8, 2008 10:58 am, Robert Bruninga 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 > >
- Previous message: [aprssig] Position Ambituity in APRS!
- Next message: [aprssig] Position Ambituity in APRS!
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
More information about the aprssig mailing list