Skip to Content.
Sympa Menu

msar-riders - [MSAR] Re: Technology in SAR

msar-riders@lists.ibiblio.org

Subject: Mounted search and rescue

List archive

Chronological Thread  
  • From: Una Smith <una@lanl.gov>
  • To: MSAR-riders <msar-riders@lists.ibiblio.org>
  • Subject: [MSAR] Re: Technology in SAR
  • Date: Mon Dec 23 14:01:00 2002

I would not touch MS Access for mission-critical data. It is
not robust enough, nor supported on enough operating systems.
Try MySQL instead?

Una Smith <una@lanl.gov> wrote:
>> Anyway, exactly what problems in SAR is barcoding expected to
>> solve?

Jorene Downs <Jorene@ceoates.com> wrote:
>Management issues in a large SAR. If you have a long line of people to check
>in, it is faster to scan the barcode and generate an automatic entry of data
>than to enter that data manually.

In this case, it may be faster, and is certainly more robust,
to pass out several clipboards with sign-in sheets, and enter
the data later. In time-critical situations, I would not want
to rely on computers and databases and data-entry people
instead of first-hand knowledge of the SAR people who are at
hand. Scanning barcodes takes the place, to a limited extent,
of data-entry clerks. But data-entry is only a tiny part of
the procedural and technological complexity required to run a
management system based on barcoding, or driven by any form of
computer database.


>you reduce the potential for typos or incorrect identification of
>that item if you can automate the process.

Automation does not necessarily solve these problems. Which is
why I say again exactly what problems do you expect barcoding to
solve? Are typos a major problem? Is incorrect identification
of equipment a major problem? Say you have a radio; how likely
is it that it will be recorded manually as...a stretcher? If
you barcode the radio, and record in a database some description
of the radio, then you need to provide software at ICP that lets
the user correct bad records, in the event the radio is scanned
and the computer says it is a stretcher. You have to design for
the event of data corruption or some mysterious human error that
happened who knows where or when, while protecting the integrity
of the data from some well-meaning but incompetent person using
the data in the field.

And what about the Incident Command System? The whole concept
is based on modularity, distributed responsibility, and avoidance
of dependencies. The computing infrastructure I think Jorene
has in mind is full of dependencies: computers on electricity,
local and remote digital communications, and technical support;
people and decision making on computers and computer operators
and databases; databases on procedures, technical designs, and
both initial and ongoing technical, logistic, and administrative
support.

>potential for documentation error, increases speed of the
>processing, and gets personnel assigned and deployed more quickly.

Only in the event (a) the system is designed well and (b) is
being used by people who have the necessary skill to use the
system well (efficiently, fully, and accurately).


>I'm not aware that FidoNet has actual access to Internet/Intranet and the
>various technologies and options available there?

Jorene,

FidoNet is packet radio. All you need is a gateway computer
somewhere with both Internet access (DSL, modem, whatever) and
a radio. It need not be attended. FidoNet can extend as far
as the radio signal. Repeaters and store-and-forward stations
can (and do) extend FidoNet communications across thousands of
miles.

Una Smith
Santa Fe County Sheriff's Posse, in New Mexico





Archive powered by MHonArc 2.6.24.

Top of Page