[Xastir-Dev] Re: Xastir SAR feature added

[Owen DeLong]

OK... I still think both modes would be useful.  Like I said, SAR for a
pedestrian os only one type of SAR.  I can see Xastir being useful for
things like helping coordinate a CAP search for an aircraft.  In those
cases, LKP/time, Expected Direction and Expected Speed really matter in 
terms
of the search area and the search area does tend to expand with time.

Also, I can see marine applications where you'd want to set current data
as likely direction/speed.  Not everyone who gets lost is walking at the 
time.

Owen


--On Tuesday, September 23, 2003 10:36 AM -0700 "Curt Mills, WE7U" 
<hacker at tc.fluke.com> wrote:

> On Fri, 19 Sep 2003, Owen DeLong wrote:
>
>> I think it depends on what you're looking for.  If you're looking for
>> a person believed lost on foot, that's one thing, and I would think
>> circles would be best (Cdir=180), and voila.  If you're looking for
>> someone in a vehicle (OK, this starts to get outside of SAR, but,
>> I know there have been times when we've been trying to find people
>> in vehicles) or, say a package of instruments on a balloon platform
>> (yes, this is a relatively specific application, but, I know a bunch
>> of users that are involved with it at http://www.stratofox.org) or
>> something like that.
>>
>> So, for SAR, I guess it's true, Cdir=180 hard coded would probably do
>> what they want.  However, I suspect it's not that hard to allow for
>> Cdir<90 in the code and draw arcs instead of circles and have the arc
>> move over time. One option would be start with making the code capable
>> of everything, then, dumb-down the UI if it's too confusing.  Hide the
>> advanced possibilities elsewhere.
>
> I brought this up to more experienced members at one point, and as I
> recall the gist of the QSO:  By the time SAR is called on a search,
> we're usually a few HOURS after the person has gone missing.  By
> that time we're more interested in the statistical data for that
> type of missing person showing how far they might travel (max) than
> in how far they might have traveled during the time elapsed.
>
> If we were to get called immediately after the person had gone
> missing, we might be able to use the average MPH of travel to
> establish containment boundaries early-on, minimizing the search
> area.  Typically that just doesn't happen though, at least not that
> I've seen in our county.
>
> That's another reason we're usually not asked to drive code
> (lights/siren) on a search.  A few minutes this way or that aren't
> critical for most missions.  Exceptions to the code rule are
> technical rescue of a car/person off a cliff, or certain sorts of
> injuries where the person has to be evac'ed fast from a remote area.
> Cases where we already know something about the subject, and we've
> switched to the rescue phase already instead of the search phase.
>
> I've got a lot to learn yet about SAR though.  That's half the fun!
>
> --
> Curt Mills, WE7U                    hacker_NO_SPAM_ at tc.fluke.com
> Senior Methods Engineer/SysAdmin
> "Lotto:    A tax on people who are bad at math!"
> "Windows:  Microsoft's tax on computer illiterates!" -- WE7U
> "The world DOES revolve around me:  I picked the coordinate system!"
>