>> Keane <ke...@keanespics.com> wrote:
>>> On Tue, 14 Aug 2012 18:35:59 +0000 (UTC), Rudeney
>>> <rude...@mickeypics.com> wrote:

>>>> That's too bad.  It really doesn't seem like it would be that complicated.
>>>> GPS tells you where the buses are, you know the routes and average travel
>>>> times, cameras count crowds at stops, drivers give feedback of how many
>>>> board and exit, factor in the number of people in wheelchairs, scooters and
>>>> strollers, and a simple bit of math tells you how long it will take for a
>>>> bus to arrive and if it can carry everyone in the crowd.  When that wait
>>>> time exceeds the standard, you dispatch more buses or redirect buses from
>>>> routes with no waiting guests.  I could probably have this spec'ed out in a
>>>> matter of weeks.  Sheesh!

>>> No, you see, you aren't one of those that see the big picture.

>>> It's a real time system.  That means, it has to track traffic.  It
>>> also has to deal with road closures and know how to reroute
>>> and re-time bus routes.  It can make decisions at certain points
>>> in which route to tell the driver to go.  Because almost all of the
>>> roads in WDW curve, you can't use linear GPS coordinates to
>>> figure times.

>> But you can, because there are a finite number of routes within WDW and the
>> buses travel them hundreds or probably thousands of times per day.  GPS is
>> really not even a critical part of the software, except to be helpful in
>> knowing how far out a bus is when it's not where it's calculated to be due
>> to unforeseen delays (namely accidents and breakdowns of buses or other
>> cars).  All it takes is for the software to continually build a database of
>> how long it takes the buses to get from A to B.  factor in park schedules,
>> weather, etc. and you can have a highly accurate model of what it takes.
>> The unknowns won't have anything to do with tracking buses, it will have to
>> do with crowd levels. And e desires of those crowds.  In fact, if the
>> system had the ability to count people waiting, people on buses, and also
>> factored in turnstile counts, ride closures, special events, number of
>> guests at resorts, sales transaction counts at DD, and ADRs, I'll bet a
>> model could be built that is 90% accurate or better, again, the only fly in
>> the ointment are those road hazards.  Better yet, when they RFID tag
>> everyone, they can then just count, say, the rate of exits at the Mk at
>> 11pm for each resort and have buses ready and waiting appropriately.

> Right.  Now set your Waybak(tm) machine to the point when the project
> started.  RFID was a mis-spelling of the reedy creek fire department
> abbreviation.  GPS was gaining traction, but still had selective
> availability on it.  (I think that was the term.)  Computing costs
> were still pretty darn high.  Reliable storage certainly was.

>> That's why the vendor shouldn't commit until the specs are clear.  Of
>> course we all know how that goes - scope creep and vendor overpromises are
>> the norm.

> Oh, I'm sure the vendor was *sure* they could do it.  You are assuming
> it was the software.  Once you get into the real world there are a
> vast number of reasons why a project can fail, even if the software
> works perfectly...