[aprssig] APRS<=>Google

[Scott Miller]

I think there are two big legal issues that need to be addressed here. 
First, is this going to be classified as commercial use?  Can you ensure 
that only factual data comes back and not advertising copy?  And second, 
are you going to run afoul of Google's terms of service?

But yeah, it'd be nice to have...

Scott
N1VG

Kurt Kochendarfer wrote:
> 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
> 
> 
> 
> 
> _______________________________________________
> aprssig mailing list
> aprssig at lists.tapr.org
> https://lists.tapr.org/cgi-bin/mailman/listinfo/aprssig
> 
>