[aprssig] conveying map view

[Bill Herrmann]

At 06:15 PM 9/22/2004 -0400, William McKeehan wrote:
[snip]
>Maybe this information is published as an object as has been described here
>(with an EYEBALL and RNG), requiring minimal modification to the spec, but
>have these views presented in a list.

William brings up a good point.

First a brief visit to the soapbox. The protocol and the UI (to be clear 
UI=User Interface throughout this message not the other UI meaning) are NOT 
one and the same! An object with a specific symbol and a specific attribute 
(i.e. the eyeball and RNG) is a good way to transport the information. What 
the users view does from there is not part of how to transport the 
information! It can be a recommendation or even a part of a specification 
but shouldn't be embedded in the "how to transport it" part. (end of 
soapbox section)

If I were going to make some recommendations on what the UI should do they 
would be:
1. Keep a list of views based on views received. (So that the user can 
select the one they want.)
2. Optionally switch to a new view (possibly based on criteria such as "I 
accept views from call xy#abc") but be sure to keep a record of the current 
view before switching. In other words give the user the ability to switch 
back if they still want their old view! Ideally give the user the ability 
to say that they want to always, never, or "prompt me" want to switch to 
new views when they are received.
3. Put any new views whose centers are in the current view on the map as 
the "view" (eyeball) object. Provide users some feedback that a new view 
has been added to the list (from item 1)
4. Give the user the ability to whitelist and blacklist view senders.

Bill