[aprssig] POI engine on APRS-IS (OBJ engine IS required)

[Lynn W. Deffenbaugh (Mr)]

On 2/21/2012 1:40 PM, Bob Bruninga wrote:
>> Keep the POI server that puts the object at the most recently
>> received posit of the sender, forget the change to the Item-as-Message
>> but have the POI server use that as the confirmation response to
>> the object creation with the ACTUAL lat/lon used for the object.
> IN light of the changing position problem, I agree.  We are back to
> discussing an OBJ server.  And I prefer to call it the OBJ server and not
> introduce yet another new term "POI"...  (Forget also my suggestion to call
> it the ITEM server, since that confuses with the ITEM-in-MSG format.).

POI isn't new to non-technical APRS users.  They've probably used a 
navigation GPS and know what a POI is.  They may or may not be 
APRS-literate enough to know what an OBJ is.  To many APRS appliance 
users (that's who we're targettng, after all, APRS-capable radio users, 
not APRS programmers), all they care about is a point on their map or an 
entry in their station list.  They don't know the difference between a 
station, an object, an item, or anything else.

> It is now back to a message to "OBJ" and based on your other comments, how
> about this format:
>
> ;OBJCTNAME*/*$text
>
> - Where ; flags it as an object
> - OBJECTNAME is from 3 to 9 characters
> - */* is a separator but contains the symbol TABLE (and says use sendrs
> posit)
> - $ is the symbol
> - Text is any of the existing APRS data fields and or comments

Why so cryptic?  Why not just a message to POI that says "OBJCTNAME 
comment" for the simple case.  And if they want something other than the 
default X symbol (/.), then "OBJCTNAME [st] comment".  Done. Simple to 
remember, yet flexible as well.

Oh, and for the advanced users, they can start the comment with CSE/SPD 
if they want to provide that.

And for the VERY advanced users, they can use [/\] CSE/SPD/BRG/NRQ or 
use the DFSshgd for an Omni DF.  This level of user would be going out 
on a special mission and can brush up on the advanced format before 
leaving home.

But the general mobile user can simply key in a message to POI that says 
"I95CRASH 3 Miles before Exit 25" without having to remember or enter 
anything complex.  KISS

>> Retransmission of the object after the originator has moved can be
>> handled by the POI server doing a dupe-detect on the defining request
>> to keep the object where it was for a given message sequence.
> Agree.  The retries will have the same message number, so they are dupes.

At least this part works to avoid re-defining objects from a moving 
originator.  But it DOES require that the original message contain a 
sequence number, or even the owner will lose the ability to move an 
object without changing something in the description or it'll still 
(possibly) look like a dupe.  We're not talking a 30 second dupe detect 
window here because we're trying to dupe-detect retransmissions which, 
by definition, will be longer than that time.

>> I still contend that we need an explicit ADOPT flag to prevent
>> inadvertent movement of objects between users across the global scale.
> The overtaking of objects is fundamental to APRS.  It was designed that way.
> Users are repeatedly educated to this issue and those who intend to make
> meaningful use of this function should be well aware of their need to make
> object names unique.  I do not think we should be adding layers upon layers
> of tweaks to get around things-people-can-do incorrectly.

It's not a tweak, it's a designed-in protection, IMHO.  A single object 
originator will never need to know this.  If the object ID is in use, 
the POI server will respond with instructions on how to force the 
adoption.  Being aware of the need to make names unique is one thing.  
Being ABLE to determine uniqueness when in the field under pressure is 
quite another.  Whatever the remote server can do to protect the user 
from making mistakes is a good thing.

>> Just because one event has a FOOTSORE object, a new FOOTSORE object
>> somewhere else on the planet should NOT automatically move the object
>> unless the new owner really intended the adoption.
> That's how APRS works.  And it is beyond this SERVER's responsibility to
> correct these errors.  Though I do admit that when the design was
> formalized, the APRS-IS was not a primary design factor, local RF was.  If
> we want to resolve these issues in Clients on the APRS-IS, then that is a
> different issue.  For example, all clients that drink from the global
> firehose might consider an OBJECT DUPE RANGE parameter that will not replace
> a previous object if the new object of the same name AND *Case* comes in
> more than XXX miles from the existing location.  But again, that is at the
> clients where the overwriting decision is made, not in the APRS-IS.

I'm not proposing the server to correct an error, but to assist the 
operator in not making an error in the first place.  APRS-IS is now a 
reality and we've got the opportunity to take the global picture into 
account in current and future designs.  If the expected user is not 
expected to be in a position to make the proper uniqueness 
determination, then I believe the server should help.

>> Automatic creation of existing object is especially bad in the UI-View
> world...
>
> If UIview has a fundamental flaw that does not allow the on-air adoption by
> the latest owner (A fundamental APRS precept), then that is something that
> needs to be addressed at the UIVIEW level.

The issue is not only local RF, but the global extension of local RF via 
the -IS.  And that extension might be just out of RF earshot so no 
amount of "don't override unless far enough away" is determinable 
because far enough might still be too close and vice versa.

You know as well as I do that anything in UI-View cannot be "addressed" 
any more.  But where possible and convenient, why not account for it?

>> Adoption is good at the local level (maybe), but when the object
>> definitions hit the global APRS-IS, things get ugly fast.
> Agree.  So can my suggestion above be used?  That is, each client may
> introduce an object-dupe-limit to use when it makes these decisions?  The
> APRS-IS is not involved.  It is only a deliverly mechanism.  It is always
> the client that has to make the overwrite.  Though I do not know how APRS.FI
> will implement this.  Othern than have maybe a typical VHF range limit of
> say 200 miles or 300 km?

Even 200 miles may be too close for some adoptions and too far for 
others.   I still believe that a remote user needs the larger visibility 
provided by the server to avoid stepping on an existing object, and 
maybe the server can even suggest how far away that object is from the 
requester, but I believe the requester should explicitly ask for the 
adoption if s/he doesn't already own the object.

Objects are currently created by APRS clients with more global 
visibiltiy and can therefore make a local uniqueness determination 
easily and safely.  If the POI server is moving this out to a limited 
visibility RF-only client, I believe the check and confirmation should 
be made.   The server should still support adoption by a new owner, but 
it should not be automatic, IMHO.

Lynn (D) - KJ4ERJ - Author of APRSISCE for Windows Mobile and Win32

PS.  I might be swayed to accept OBJ instead of POI, but I'd like some 
others to weigh in on recognizability and rememberability before it is 
finalized.

>
>
> Bob, Wb4APR
>
>
> _______________________________________________
> aprssig mailing list
> aprssig at tapr.org
> https://www.tapr.org/cgi-bin/mailman/listinfo/aprssig
>