[aprssig] Position Ambituity in APRS!
Robert Bruninga bruninga at usna.eduTue Jan 8 19:04:22 UTC 2008
- Previous message: [aprssig] Position Ambituity in APRS!
- Next message: [aprssig] Position Ambituity in APRS!
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
> 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? No not at all. That is the incorrect BOX interpretation which was never intended. The original APRSdos plots a circle of 60 miles radius approximately at 35N and 83W. A sufficient random offset from that location would be added so that if there were several stations all reporting that same position ambiguity, they would not all appear as one circle but would all be visible. The circle is not a precise boundary of ambiguity. It is a REPRESENTATION to the VIEWER that that station's position is not well known and its ambiguity is on the order of the size of the circle presented. If we had just been allowed to put those words into the spec, we would not still be having different interpretations for the last 10 years. > So that would be the possible area (whatever > geometric shape it may be) that I can be in, > right? Sorry, wrong. It is exactlly that missinterpretation that we are trying to avoid. It is not a box. It is a circular image of a large amount of ambiguity on the order of a circle of radius appropriate to the missing digits of precision. If you want to send a SEARCH box or other precisely bounded area, then send an AREA object instead. Bob, WB4APR > > -- > 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