[aprssig] Position Ambituity in APRS!
Robert Bruninga bruninga at usna.eduTue Jan 8 15:58:10 UTC 2008
- Previous message: [aprssig] Position Ambituity in APRS!
- Next message: [aprssig] Position Ambituity in APRS!
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
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
- 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