[aprssig] Multi control station situational awareness - How's this supposed to work?

[Robert Bruninga]

Perfedt.
APRS has these text capabilities:
Messages (call to call)
Bulletins
Announcements
Status text

Kenwood radios can store up  to 100 incoming messages in order received.

Bulletins were SUPPOSED to be editable.  That is, if you sent a 4 line
bulletin and needed to update the second line, you could just start
resending the edited 2nd line.  And it will replace the 2nd line in
everyone's copy... I don’t think most clients implemented that.

Best to cram all info in a single object at a single location rather than
stacking.

I think figuring out how to use these meger capabilities that EXIST in every
APRS radio and client is better than an Ap.  An AP is great and fun, but is
ususally never finished and only available to a few...

Getting the info to the radios is what counts.

Also, map data ages out.  Or should.

Also there aer AREA OBJECTS that can apply to a large square, rectangle or
triangle of any size.  But I think you need an APRS client to draw it on the
map.  And then also radios them selves with no maps cannot display it
anyway.

Most people will only have radios.  What you can PUSH to the front panel of
a Kenwood Radio is your system goal.

Also BULLETINS can have bulletin groups to separate areas.
Same witth Messages can have group names that people subscribe to in thir
radio.

Bob
-----Original Message-----
From: Greg D <ko6th.greg at gmail.com>
Sent: Monday, December 2, 2019 6:23 PM
To: Bob Bruninga <bruninga at usna.edu>
Cc: TAPR APRS Mailing List <aprssig at lists.tapr.org>
Subject: Multi control station situational awareness - How's this supposed
to work?

Hi Bob,

The recent planned power outages here in California have several members of
our club wondering what the right solution is for coordinating information
from multiple Net Control stations.  I expect APRS is the right foundational
tool for the job, but am unsure how to apply it.  Can you give us some
guidance?  Especially, how should we handle information that is not tied to
a location (map), and how do we search for answers to requests?

Usually, Net Control is a centralized role.  Single operator at a single
location, or if multiple operators working in shifts, there's still a single
log or database for information.  Higher-end solutions exist with commercial
software support, but that's overkill for our needs and situation.

The challenge is that we have had several wide-spread power outages in the
area.  Folks are without power for a day upwards to nearly a week, with some
having no access to city utilities.  Many (now) have generators, but those
need fuel.  Some run short of other essentials.
My own power was restored after the first outage just as the ice I had set
aside in the fridge was about done.  Others were not so lucky.
Critically, Internet access was either totally out, or spotty at best.
Cable-based Internet went out totally, cellular was spotty.  Evidence at my
house was that the cell system only lasted about 2 hours before failing.  I
did have a land-line analog phone that worked, but have no idea what I'd do
with it other than make phone calls.  The modem and dial-up account are long
gone.

Our ham club decided to run an informal information-sharing net, taking
check-ins reporting on where the outages were, what stores were open,
shortages found, requests for supplies, and offers to provide the same.
During the first outage, that was handled mostly by one person, using pencil
and paper for record keeping.  I added my support during the second outage,
and while the needs were fewer (folks were better prepared after the first
one), it became clear that having a split data record between the various
net control stations could be problematic.
So, we're looking for a solution which will be effective across multiple Net
Control stations, and ideally without the need for Internet access, even at
the periphery.  Fortunately, there's no serious emergency, and no "served
agencies" to include in the plan.

If we could count on the Internet, a simple Google Sheets file would be
perfect.  Multiple authors, real-time updates, shared access, persistence.
It provides the model of what we're trying to achieve with the radio links.
The "situational awareness" aspect of APRS suggests that it would make for a
good foundation for a shared-view of the "situation".  Stores open and
closed, locations of fuel available and unavailable, etc. in theory can be
handled with Objects.  But three problems.  Some locations (especially
stores) have multiple reports.  Do we create multiple objects at the same
location?  That could get messy.
Some reports are location-vague, for example, a report of power out for an
entire part of town; do we "pin" it to the location of the person reporting
and explain it in the object text?.  The "all clear" call, for example, was
for the entire county.  Where to put them?  And finally, how to find the
most recent information, given that there is no time context for the map
view.  One would be forced to scan the map, clicking on objects looking for
the information requested, and likely becoming frustrating and ineffective
over time.  It's also a bit tedious to create and manage an object.

During the last outage, I experimented a bit with the use of a Bulletin
packet.  Some simple formatting could be used to indicate the category of
information included, or one could use the bulletin number as a category
indicator.  It was nice that the bulletin was received by a member's HT
without any preparation, but the broadcast nature of bulletins would perhaps
be a bit annoying for those who don't particularly care about this topic.

One of the thoughts was that an APRS application that focused more on
category-oriented text instead of map-based pins would be effective, but we
are not aware of any that provide this sort of view.  Given the lack of
Internet access, the app would need to be running 24x7 in order to provide
data persistence, unless the text information is repeated periodically as it
is with traditional objects.  For something like this to work, would any of
the existing packet formats be appropriate, or would we need to create
something new?

What is the right solution for this sort of situation?

Thanks,

Greg  KO6TH