[aprssig] POI engine on APRS-IS

[Lynn W. Deffenbaugh (Mr)]

On 2/24/2012 7:00 PM, Bob Bruninga wrote:
> Quite the contrary.  We only need one QRZ server independent of whether you
> are asking about an OBJECT or a STATION or anything else.  You are simply
> asking QRZ about XXXXXX.  The response would be the same.  You'd get back an
> ITEM-in-MSG with the APRS -IS knowledge on that XXXXXX.

While I agree now with the general purpose QRZ server, I'm still 
confused about your alternating "build it for the current platform" 
versus "build for future capabilities".  It would be far more 
informative to do a requester-relative response to a QRZ query (MMM 
miles @ ddd degrees) along with the queried station/object's comment 
than to burp out a machine-readable, but nearly humanly useless 
Item-In-Message response to a query.

The Item-In-Message is good as a response to the creation of an OBJECT 
request as the user isn't really needing to know much other than "it 
worked".  But with a QRZ query response, one would assume that the 
requester might be interested in where the station/object is actually 
located relatively speaking.  Now if the QRZ server implementer wants to 
detect the requester's known platform capabilities, it could switch to 
Item-In-Message if it is known to be understood, but for a usable 
response, I'm thinking humanly readable/relative is a better approach.

> This is why it should be its own FUNCTIONAL service andnot just another
> format of a special case of something buttoned onto an OBJ server.
>
> The FUNCTIONS should be independent.  Does not matter where they reside.

Once you explained it this way, I'm good with the QRZ and KILL servers 
being outside of the OBJECT.  You can query anything known to the APRS 
system (well, at least known to the QRZ server) and you can kill 
anything you can name (assuming reasonable protections applied by the 
KILL server).

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