[aprssig] [SPAM] Fuel Stops (John Ronan)

[Bob Bruninga]

> This would border on commercial interests I believe 
> and if this goes ahead then you can kiss
> Tactical APRS goodbye.

Providing useful local information to the local mobile operator has always been fundamental to the APRS concept (though too many people are trapped in the APRS tracker mentality)...

Providing the location of a nearby cheap gas station from one ham to another makes sense in that context..  BUT ONLY using common sense.  (which seems to be lacking in so many packets on APRS).

The original APRSdos system that provided such useful objects (APRSdata) plus satelite info etc to the mobile operator took the simple philospohy that the nearest one, or nearest 3 objects to a requestor of a particular category would provide sufficient info to him.  AND such packets were transmitted DIRECT or using the minimal path to reach that user and only in his immedate area.

I agree 100% that there are many 'stupid ways' to present such information that would be the end of APRS as we know it.  But I also feel that there are very useful and smart ways to provide such useful information to mobile operators that would not impact local channel capacity.

The problem is that on APRS too many people just flood everywhere their "useful" information to 10 times as much area as is useful, and such spam only kills the potential of APRS.

THe proper query for APRSdata, was ?GAS and the response would be the nearest objects with the cheapest gas in the vicinity of the requester.  Or something like ?GAS-3 might respond with the 3 nearest objects...

I think a UIview add-on was written to do some of the features of APRSdata, but Unless I have looked at it wrong, it is far too simplistic for the original intent.  I think it only responds with a single object for a single query, which in my mind completely misses the point.  

1) It does not allow for a category table with multiple entries for that category.  IE, for ?HOSP it only responds with one and only one FIXED hospital and you get this same hospital whether you are N,S,E,W or 1 mile or 100 miles from that one Hospital!  

2) It does not tailor the response to the location of the requestor.  THe intent of APRSdata was that the APRSSdata server engine has a LIST Of all hospitals and it responds with either the CLOSEST one to the requestor or the closest 3.

3) It does not tailor the response to the PATH of the requestor.  Now with all paths being fully traceable under the New-N paradigm, reverse pathing or minimum path response should be the norm.

If I missunderstand the UIview add-on that tried to implement some of the APRSdata features, please correct me.

But responding to such general queries from mobiles was a fundamental part of the APRS concept.  That is why ONE of the FOUR fundamental APRS packet types is QUERIES!  Again, completely forgotten by the last decade of APRS-tracker mentality...

Bob, WB4APR