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

[Bob Bruninga]

> 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.).

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

> 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.

> 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.

> 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.

> 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.

> 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?


Bob, Wb4APR