> On Wed, 15 Aug 2012 19:03:46 +0000 (UTC), Rudeney
>> 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.
Huh? This project didn't start *that* log ago! You act like it was back
when the MK first opened. Although it's just been in the last four or five
years that GPS has become ubiquitous, but it's been around a long time. My
car from 12 years ago had it. Back in the 1980's, I had something called
Loran-C on my boat, but I didn't have that long before GPS was available
and I bought a handheld (no maps, just coordinates and breadcrumbs). Oh,
and just to date it, it wasn't Y2K ready and t became a brick on 1/1/00.
RFID has been around a while, too, but because of costs, it's mostly been
used in government and large industrial companies, ad not in a disposable
Regardless, I wasn't really talking about what could have been, I was
really talking about what we could do today.
> Even cell service in the World sucked back then. None of the
> infrastructure to do it was in place.
Yeah, I remember being there back in the mid 1990's and about the only
place I cold get cell service was on the platform at the TTC.
>>> Sometimes the specification goes beyond what the vendor
>>> can produce.
>> 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...
Well, I would guess that "someone" at the vendor's office was sure, but
I'll bet if you asked the people actually doing the work, they might not be
so sure. i can't tell you how many times I have gone into something
knowing it will fail,but the customer expects perfection because someone in
sales or executive management promised it. And I'm not assuming software
caused a failure, because software doesn't fail - it does exactly what it
was coded to do, so the failure would be in the analysis and spec work,
testing, planning etc.