[aprssig] APRS<=>Google

[Kurt Kochendarfer]

Hello all,

I'm new to the list, so a brief intro is probably in order.  I'm a
relatively new ham (licensed about 18 mos. ago); however, I've been
around amateur radio my whole life.  My grandfather David, K4DC (SK) got
started in amateur radio in the 1930's.  My father Rich, WD4FMO has been
licensed since the 1970's.  I drug my feet for a long time getting into
amateur radio.  Sadly, I was one of those "new generation" kids who
thought that amateur radio would go the way of the dinosaur with the
advent of the Internet and cellular telephones.  Since I got licensed
last year, I've come to discover I couldn't have been more wrong.  The
more time I spend around radio, the more I'm drawn in.

Packet radio, and APRS in particular have been of significant interest
to me over the last six months.  I dabble in computer programming every
now and then, and I've started to formulate an idea that's gotten to the
point I need some competent feedback.

As a matter of background, I spend a lot of my free time here in Arizona
camping or otherwise spending time away from the bustle of the big city.
I often find myself out of cell coverage; however, due to our truly WIDE
repeaters out here, APRS coverage in out-of-the-way places is generally
good.  

In my travels, I often find myself in need of local area info for places
with which I am unfamiliar.  I don't have a GPS navigation system in my
truck, and I don't usually have an Internet connection, so my ability to
get local info is limited.  In a pinch, when I am in cell coverage, I
often find myself using Google Mobile to get local info.  I simply send
an SMS message to "GOOGLE" with my query and Google returns an SMS with
my search results.  See this link for a demo of the concept from a
mobile phone:

http://www.google.com/mobile/default/sms/

You can see the variety of information that would be useful to a mobile
station in unfamiliar territory: nearby fuel stations, eateries, weather
forecasts, METAR reports, and even directions.  Functionally, it's
automating the age-old repeater voice call for local info.

The concept is simple:  bring this functionality across to APRS.  I see
many parallels between SMS messaging and APRS messaging.  With a
well-written gateway between APRS and Google search engine, the local
area information available to a mobile/portable user is almost limitless
and the bandwidth required is low.  No fancy graphics, no gigabit
pipes...just format the info to fit into one or more APRS messages and
send it on its way.  The reach of APRS, at least in my neck of the USA,
is far greater than any cell network, and once you bring in the
"satellite factor", there's nothing that beats it.

Due to the short length of an APRS message compared to an SMS message,
my concept for implementing the query would utilize message tags to
specifically limit requested info.  Example:

User sends APRS message "hospital 12345 -p -l3" to APRS station
"GOOGLE" (for lack of a better address...)

The server daemon searches the APRS-IS stream for messages to "GOOGLE",
pulls them and analyzes the content.  The -p option would instruct the
server to return the phone number for the hospital nearest zip code
12345.  The -l3 option would limit the number of responses to phone
numbers for three nearest hospitals.

Through this mechanism, we can control what information (and what amount
of information) we want to send and receive. Some of the info types I
thought would be relatively useful are:  

- Local services (food, fuel, emergency services, law enforcement, etc.)
- Weather forecast & METAR (aviation weather) reports
- Local amateur repeater info (non-FREQUENCY participating repeaters)
- Directions
- Airport information (Runways/runway lengths, freqs, navaids, fuel
types, etc.)

Some tag types that might be useful:
-a (address)
-d (directions)
-p (phone number)
-c (city/state of query item)
-g (GPS coordinates of query item)
-ap (nearest repeater with an open autopatch)
-nm (near me - returns nearest requested info based on your most recent
APRS position report...useful if you don't know exactly where you are.)

The options are clearly limited only by the imagination... 

"airport -d -nm -l2" - returns the direction and distance to the two
airports nearest the requesting station...useful if you are air mobile
and suddenly find yourself needing to locate a nearby runway...even
better if your return message(s) includes runway orientation, length,
tower frequency, and fuel available.

"directions TO:Dayton, OH" - returns driving directions to get from
wherever the sending station is to Dayton in a series of messages.

"2m repeater -nm -ap" - returns info for nearest 2m repeater with an
open autopatch

Hopefully you get the picture.

A few questions for the crowd:

1)  As I'm new to APRS, I'm not completely up to speed on the accepted
standards for what should/shouldn't be transmitted on 144.39.  What data
types would violate generally accepted standards for distribution via
APRS?    

2)  As I understand it, APRS messages that originate from an APRS-IS
station and stay in -IS are routed without a hitch.  Locally generated
RF messages are locally digipeated without a hitch, as well.  As I
understand it, most I-Gates will digipeat APRS messages to mobiles that
they have heard within a designated amount of time.  Are there any
hitches in the routing between RF and IS that I haven't considered, have
misunderstood, or have overlooked?

3)  Limits to the amount of data sent will obviously have to be imposed
server side to keep the band from getting plowed under with frivolous
requests and replies.  There are a number of ways to do this:  a) limit
number of response messages sent and/or b) limit types of data that can
be requested are the two that primarily come to my mind.  Any other
thoughts on implementation that would balance utility and bandwidth?

4)  Would this be something that would be better served up on an AltNet?
(Like FireNet or PropNet)?  I know Bob is very vocal about APRS being
designed to provide rapid tactical situational awareness to a station,
and this seems like it fits in line with that idea, if carefully
implemented.  I guess the issue is really the age old balance between
limited bandwidth and utility to the max number of users.

5)  Any other show-stoppers that anyone can think of or other
considerations that come to mind implementing something like this?

6)  Maybe I should have asked this first:  Anyone think this might be
useful?  Or am I spinning my wheels?  Alternate suggestions, if that's
the case?

Bring your spears, thoughts, suggestions, or criticisms.  Inputs are
greatly appreciated.

Kurt
KE7KUS