[aprssig] POI engine on APRS-IS (was: SPOT engine on APRS.FI)

[Lynn W. Deffenbaugh (Mr)]

On 2/20/2012 10:11 AM, Bob Bruninga wrote:
> I wonder if we should implement a SPOT engine that looks for messages to SPOT and then turns them into objects at the senders location.

Implement a POI engine that looks for messages to POI and turns them 
into objects at the senders most recently received location.  If the 
sender doesn't have a recent-enough (10 minutes?  30 minutes?) position 
available, a failure response is sent and no object is created.

> For example.  For the upcoming Appalachian Trail survey (http://aprs.org/at.html), our southbound survey hikers will pass the northbound through hikers.  They could send a SPOT message from their APRS HT's which would put that hiker on the map.

... a POI message ... put that object .... a POI message ...

The hiker is already on the map if they're beaconing the required positions.

> The process for the SPOT engine would be simple.

POI

> If the message is sent to "SPOT" then the first word of the message becomes an OBJECT NAME placed on the map at the present location of the sending station. The second word (two bytes in brackets [/>] would be the symbol and all additional words would be the object comment.

POI.  Also, can we make the [ts] (table symbol) allowed to appear 
anywhere in the message and if not present, a default symbol will be 
used.  Special characters are harder to type than characters and if the 
sender doesn't care, why put them through the agony.

If the first word contains more than 9 characters, a failure response is 
returned.  ADOPT and KILL are reserved first words for the POI server.  
See below.

If the first word is already known as a station or object recently in 
APRS-IS at a different position and different owner, then a warning is 
returned and the POI message must be retransmitted with ADOPT at the 
beginning followed by the remainder of the POI message.  This way we 
allow the current object owner to easily move a named object, but 
require an explicit adoption intention for other known objects.

> In this way, this can be a universal means of easily inputting objects from APRS radios.

I like it so far.

> Did I overlook anything?  I guess it should be a stand-alone engine that then generates an OBJECT onto the APRS-IS so that all systems see them?

I'm trying to figure out an easy way to specify an object interval and 
lifetime, but haven't landed on anything that is memorable enough to 
actually work.  For now, I'm thinking a 10 minute refresh interval for 
such objects and a default 24 hour lifetime, but I'd really like to have 
a way to specify that in a message.

"KILL objectname" would probably also be a good idea which results in 
the POI server sending a series of object Kill packets and then deleting 
the object from its internal list.

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

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