[aprssig] Traffic Objects (new subject)

[Joseph M. Durnal]

I often wish I had an easy way to transmit a traffic report from my
D700.  When things are really bad I just send out a BLN#.  It is fine
when I'm stopped in the traffic, but if I'm going the other way or
something, I really can't enter that sort of text.  I thought about
creating a PM, but I don't think I can be descriptive enough w/o
stopping and entering some status text info.

I'm often stuck in traffic, 3 or 4 times a month, there is a major
delay on somewhere I-270 in MD caused by an accident.  To detour
effectively, you need to know well before you actually run into the
traffic jam.

73 de Joseph Durnal NE3R


On Wed, Sep 3, 2008 at 5:22 PM, Robert Bruninga <bruninga at usna.edu> wrote:
>>>  As the system was designed, only
>>> MESSAGES can go to RF automatically
>>> (without sysop intervention).
>>
>> I ran into this problem about 18 months ago
>> when I tried to build a system that would
>> look for traffic problems (via the publicly
>> available loop sensor data) and post it to RF.
>
> Fantastic!  We need this kind of initiative in local APRS!
>
>> I could never figure out a way to reliably
>> get the data into the ether - and also couldn't
>> be sure that I could force those objects to be
>> deleted once the traffic cleared.
>
> Huh?  On RF, it's a slam dunk.  Getting the data out is trivial.
> Just TX on RF using the fundamental decay algorithm so they show
> up quickly.  To kill them after use, just transmit them again
> with the KILL indicator (and decay algorithm so that they
> reliably disappear too).  All receiving APRS radios and clients
> will add them and delete them automatically.
>
>> This is a real problem. Not only do we need a
>> design, we need to figure out how to get it
>> widely implemented...
>
> Maybe I am missing something, but if you are designing this for
> RF, then there should be no problems at all.  And it is such a
> great APRS service, I'd be happy to help if there are any
> issues.  Particularly choosing the right local digipeater path
> so that the traffic problem object only goes to the local RF
> area where it applies...
>
> Bob, WB4APR
>
>
> _______________________________________________
> aprssig mailing list
> aprssig at lists.tapr.org
> https://lists.tapr.org/cgi-bin/mailman/listinfo/aprssig
>