[aprssig] POI engine on APRS-IS (was: SPOT engine on APRS.FI)
Lynn W. Deffenbaugh (Mr)
ldeffenb at homeside.to
Tue Feb 21 08:42:53 CST 2012
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.
> 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.
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
More information about the aprssig