Disney Bus Transportation: Clever Devices Intelligent Transportation System (ITS)

[peter11435]

No longer

Not currently

 

[JoeCamel]

Not currently

!!

 

[Doberge]

It'd be great if one could log on the app before leaving the room or park and say where you'd like to go so there's some data *before* the bus stop itself. It's the difference between "reactionary" and "preventative" and would go a long way to decrease wait times and increase guest satisfaction scores to have the data to dispatch the extra bus before everyone queues at the stop.

 

[Mouse Transit]

The point of implementing this system to is reduce staffing...no need for “as many” dispatchers, coordinators, etc. to manage the traffic.

Btw, it takes about six months to two years before any systems like this show both fruit and significant savings.

Absolutely. Also, your sentiment about it taking years was echoed by some experienced bus drivers I spoke with. That’s why I thought a thread here might be useful to track observations of the implementation of this system over timecould be a while before the system is considered a “success” (however one would assess that.)

So, as others have asked, why this approach and NOT just a GPS-based knockoff of Uber’s app? That would allow for geofencing at the previous stop to send users alerts “the bus you’re looking for just left the stop immediately before yours.” Which is really all most of us would need.

Also, why is WDW still using buses?

I don’t know about the future capabilities of the system or “where” Disney intends to take this system. It’s not even being used property-wide on a regular basis.

I did not attend any Disney bus driver briefings/classes about the new system. However, some drivers I spoke with did attend them earlier this year. Regarding those briefings, the drivers only told me there’s increased use of guests’ mobile devices with the new system. Outside of that, I only have my own data collection, discussions with drivers and guests about their experience, and some Clever Devices manufacturer research. And now, this forum!

Regarding real-time tracking of buses, I suggest you first imagine what that would look like on a map of WDW. I don't know exactly how many buses there are in the fleet, but you can count them using the latest imagery on Google Earth. There are ~400 buses (or more) in the fleet. Even if all of them aren't being used at the same time, what would even 100 buses look like moving around on a map? I imagine it to be incomprehensible. Therefore, I don't think there's any utility in something like that. Same thing with geofencing.

Buses are the eyes and ears of WDW resort. They are the most reliable transportation method. The boats and Skyliner all go down if there's lightning and/or high winds (launches affected by lightening/cruisers by high winds). If even one train on the Monorail has an issue, the entire line goes down. Buses pick up the slack for every other mode of WDW transportation. That's why there is the Gold Route, Blue Route, Green Route, Red Express, and even the Otis Route.

It'd be great if one could log on the app before leaving the room or park and say where you'd like to go so there's some data *before* the bus stop itself.

Hopefully, this is one of the goals of the updated/upgraded system.

 

[HongKongFooy]

Also, why is WDW still using buses?

Because the masses of guests eat up any garbage WDW throws at them and thinks its magical as proven by being the most expensive Disney destination with the lowest quality and yet is the most visited.

Buses---- they couldn't even dress them up Mickey old school 1940's/retro style like in Tokyo with Mickey addressing riders piped in.

High tech routing doesn't change the fact that you're riding a bus during vacation.

 

[_caleb]

There are ~400 buses (or more) in the fleet. Even if all of them aren't being used at the same time, what would even 100 buses look like moving around on a map? I imagine it to be incomprehensible. Therefore, I don't think there's any utility in something like that. Same thing with geofencing.

Yes, showing 300 buses crawling around on a map of the entire property would be too much to show all at once. This is why they’d never do that. Have you ever used the apps for Uber/Lyft (or ZipCar, or even Lime/Bolt/Bird scooters)? They track every car/scooter, but they refine the view as you zoom in on the map to only show what you’re looking for—in-service cars/scooters nearby.

The utility in this is a realtime view of what buses are coming, traffic jams, etc. This is helpful for drivers and passengers alike. If you’ve ever stood in the hot sun or pouring rain waiting for a bus that wasn’t coming, you can see the value of knowing where on property the buses are.

Geofencing would send alerts to the phones of whoever requests to be notified of the arrival/departure of a particular bus. Clever Devices ITS already includes these features, Disney just hasn’t implemented them.

Your initial post mentioned that Disney‘s bus system requires flexibility (surge deployment, realtime rerouting, etc.). This is true of any municipality, where construction, traffic, accidents, and hazards constantly affect bus routing and scheduling.

A Disney guest should not have to ride hundreds of buses or interview 40-50 bus drivers (as you say you did as part of your “research”) to understand how to get from a resort to a park and back with minimal stress or delay.

BTW, Disney has been using Clever Devices to manage their bus system (starting with onboard audio) since at least as far back as 2009, according to this post from right here on wdwmagic:
https://forums.wdwmagic.com/threads/bus-dispatch-control-system-hardware.523881/#post-3875977

 

[Mouse Transit]

If you’ve ever stood in the hot sun or pouring rain waiting for a bus that wasn’t coming, you can see the value of knowing where on property the buses are.

My argument has to do with using a map to solve this problem. The system needs to be accurate enough to indicate by time the next bus departure to Hollywood Studios or Polynesian Village Resort, for example. You don’t need to zoom in and out on a map to determine that.

Geofencing would send alerts to the phones of whoever requests to be notified of the arrival/departure of a particular bus. Clever Devices ITS already includes these features, Disney just hasn’t implemented them.

How would a guest choose this particular bus notification? I just think this is unnecessary if the app just tells you the accurate time of departure and arrival at a certain location.

Also, I’m making a distinction between capability and practicality here. We are talking about an app (MDE) that most people can’t even use for FastPass+ correctly (another topic). I don’t think most people would use the app to set up all their bus arrival and departure time notifications for their entire trip.

A Disney guest should not have to ride hundreds of buses or interview 40-50 bus drivers (as you say you did as part of your “research”) to understand how to get from a resort to a park and back with minimal stress or delay.

Of course not. It’s a weird project even for me as a local who has been going to the park since 1975. But, in my opinion, you always learn something new at WDW by doing something new, as extreme as it may be.

BTW, Disney has been using Clever Devices to manage their bus system since at least as far back as 2009, according to this post from right here on wdwmagic:
https://forums.wdwmagic.com/threads/bus-dispatch-control-system-hardware.523881/#post-3875977

Correct. This information was already on this forum so I didn’t discuss it in the original post.

In any case, whatever app features Disney decides to give to guests, it won’t matter if the system can’t accurately determine arrival and departure times. That’s where my interest now resides mostly.

 

[_caleb]

My argument has to do with using a map to solve this problem. The system needs to be accurate enough to indicate by time the next bus departure to Hollywood Studios or Polynesian Village Resort, for example. You don’t need to zoom in and out on a map to determine that.



How would a guest choose this particular bus notification? I just think this is unnecessary if the app just tells you the accurate time of departure and arrival at a certain location.

Also, I’m making a distinction between capability and practicality here. We are talking about an app (MDE) that most people can’t even use for FastPass+ correctly (another topic). I don’t think most people would use the app to set up all their bus arrival and departure time notifications for their entire trip.



Of course not. It’s a weird project even for me as a local who has been going to the park since 1975. But, in my opinion, you always learn something new at WDW by doing something new, as extreme as it may be.



Correct. This information was already on this forum so I didn’t discuss it in the original post.

In any case, whatever app features Disney decides to give to guests, it won’t matter if the system can’t accurately determine arrival and departure times. That’s where my interest now resides mostly.

I guess I don’t understand what you are interested in then. Disney has had the ability to determine where a bus is, how many people are in it, and the rate at which it is traveling for a long time now. Scheduling, on the other hand (how long a bus should wait at each stop), needs data in order to be effective.

As the system gets smarter (by collecting data over time), scheduling and surge deployment of buses becomes easier to (and more predictable). The benefit of including a guest-facing app (assuming it would be incorporated into Genie/MDE) is that Disney would also have access to guest data: demographic info, sure, but also are those riding the bus resort guests? Did they visit the park that day? How long did they wait for a bus? etc.

Also, notifications would be easy- guests choose where on property they’d like to go, the app shows transportation options. If you‘re at MK and want to go to AoA, the app pings you when a bus is arriving. There are lots of examples of some pretty good user interfaces out there that are accessible and friendly to non-tech-savvy users.

 

[Mouse Transit]

Scheduling, on the other hand (how long a bus should wait at each stop), needs data in order to be effective.

What data do they need? They have transit time data. They need to calibrate the system correctly. They hadn't at Disney Springs, then Animal Kingdom. Then, they rolled it out at EPCOT. I don't know. Maybe they were planning on reviewing system performance before Hollywood Studios and Magic Kingdom started using it, as neither had dates when I asked the drivers/load zone coordinators back in March.

It's possible I'm missing something important (and so are all the drivers I talked to,) but I observed consistent system over-calculation of total transit times. That was one of the main points of my discussions with the drivers during the time we spent burning the clock down at load zones. One driver told me, "I would have to drive 10 mph in order to stay in sync with the clock." Unless there was a bus waiting to get into the load zone (for single load zone resorts, mostly) the drivers ran out the clock. That's one bus loaded with people just sitting there for 7+ minutes.

It seems to me that the transit time between, say, the Polynesian Village Resort and Animal Kingdom Park is affected by traffic congestion/accidents, traffic lights, and load zone delays (ECVs, stroller collapsing, etc.) Now, if the bus always left when it was ready to go, then there wouldn't be an issue here. This is not what I observed, however.

It might help if Disney wasn't implementing the system in such a brute force manner. Or, so it seems. When I asked one driver why Disney thought a bus management system made for a city would work at WDW out-of-the-box, he said they (corporate) were mostly deadline-oriented. If the square peg didn't fit into the round hole then, well, make it fit.

 

[_caleb]

What data do they need? They have transit time data. They need to calibrate the system correctly. They hadn't at Disney Springs, then Animal Kingdom. Then, they rolled it out at EPCOT. I don't know. Maybe they were planning on reviewing system performance before Hollywood Studios and Magic Kingdom started using it, as neither had dates when I asked the drivers/load zone coordinators back in March.

It's possible I'm missing something important (and so are all the drivers I talked to,) but I observed consistent system over-calculation of total transit times. That was one of the main points of my discussions with the drivers during the time we spent burning the clock down at load zones. One driver told me, "I would have to drive 10 mph in order to stay in sync with the clock." Unless there was a bus waiting to get into the load zone (for single load zone resorts, mostly) the drivers ran out the clock. That's one bus loaded with people just sitting there for 7+ minutes.

It seems to me that the transit time between, say, the Polynesian Village Resort and Animal Kingdom Park is affected by traffic congestion/accidents, traffic lights, and load zone delays (ECVs, stroller collapsing, etc.) Now, if the bus always left when it was ready to go, then there wouldn't be an issue here. This is not what I observed, however.

It might help if Disney wasn't implementing the system in such a brute force manner. Or, so it seems. When I asked one driver why Disney thought a bus management system made for a city would work at WDW out-of-the-box, he said they (corporate) were mostly deadline-oriented. If the square peg didn't fit into the round hole then, well, make it fit.

The fact that the system was designed for a city really has no bearing on its deployment at WDW. The problem is the same, but the variables differ. In a city, stops might be consistently short, while the transit time (between stops) can vary widely due to traffic conditions. At WDW, the transit time will likely stay consistent while load/unload times might vary due to ECVs/passenger needs. Flexibility is built into the system-that’s what makes it different than just an old-fashioned route schedule.

The data is what makes the system smart and efficient. Without data, the system estimates what an average load time might be (average for time of day, time of year, etc.) and schedules each stop as a sort of window. In order to stay on schedule, the driver has to sit and wait for the scheduled departure time (even if the bus is loaded to capacity) and drive a predetermined speed. The only way the system can reliably predict when the bus will arrive at a stop is to know when it left the previous stop. This is what you observed during your research.

But when properly implemented, realtime GPS + guest tracking gets rid of the “window” idea and treats the problem of moving guests as a logistical one. It knows how many guests are waiting at a stop and where those guests are trying to go.

This allows buses to leave a stop when they reach capacity (or when there are no guests waiting to board). When the bus leaves a stop, the system knows when it will arrive at the next stop and can show that on the signage in real time. If the wait time for guests approaches the maximum allowable (whatever Disney determines), new buses can be deployed to that route to relieve the demand.

In this case, buses don’t necessarily need to follow the same route or stick to any certain schedule. Once the demand has been met, buses can be redeployed as needed or pulled out of service.

 

[Mouse Transit]

The fact that the system was designed for a city really has no bearing on its deployment at WDW. The problem is the same, but the variables differ.

I don't fully agree and neither would many drivers I spoke with. The system being designed for a city is the reason it works well out-of-the-box at Fort Wilderness. With its internal bus routes (i.e., yellow and purple/orange) and closed circuits, FTW has spatial conditions and requirements more similar to that of a city compared to Magic Kingdom Park.

The variables at WDW parks differ from a city's drastically enough to require the initial configuration and continual modification of the new system. The variables of getting families and groups of individuals ("who") from the resorts to the parks ("where") in the morning and vice versa in the evening ("when") so they don't miss the time they paid for to be at the park ("why") are variables that I'd argue fundamentally change the problem (getting people from one place to another) considerably enough to require major adjustment of a new bus management system made for a city.

But when properly implemented, realtime GPS + guest tracking gets rid of the “window” idea and treats the problem of moving guests as a logistical one.

I think it's important to make a distinction between what you think the new bus management system should be able to do, what it can do, and what it was actually doing when I observed it back from Feb-Mar of this year. I tend to stick to what I observed the system actually doing or not doing based on what I observed it attempting to do. It seems like you are talking about how things can work.

For example, I did not observe the system attempting to track guest locations. You are saying this is necessary for proper implementation. You lost me there because that's not something I think the system is attempting to do.

There are some things the system can do that I did not assess. I didn't assess the system in all of its capabilities because Disney is clearly not using certain functionality. If you look at the TCH UI picture I posted, some of those indicators are not active because the associated feature is not being used. The odometer, security camera, and wifi indicators are turned off. Therefore, there is no reason for me to assess these features.

However, the system was attempting to calculate arrival times. Regions with the new system (other than FTW) did this poorly; regions using the old system did this better. There was a noticeable difference.

 

[_caleb]

The variables at WDW parks differ from a city's drastically enough to require the initial configuration and continual modification of the new system. The variables of getting families and groups of individuals ("who") from the resorts to the parks ("where") in the morning and vice versa in the evening ("when") so they don't miss the time they paid for to be at the park ("why") are variables that I'd argue fundamentally change the problem (getting people from one place to another) considerably enough to require major adjustment of a new bus management system made for a city.

People in cities around the world take public bus systems to work and school every day, and many of them have to make transfers to other modes of transport in order to arrive at their destinations on time. Many of these people are special needs, elderly, and children. Maybe more ECVs at WDW, but other than that, I'm not seeing the major difference.

Any implementation of a tracking system would require adjustments in order to optimize performance, right?

I think it's important to make a distinction between what you think the new bus management system should be able to do, what it can do, and what it was actually doing when I observed it back from Feb-Mar of this year. I tend to stick to what I observed the system actually doing or not doing based on what I observed it attempting to do. It seems like you are talking about how things can work.

For example, I did not observe the system attempting to track guest locations. You are saying this is necessary for proper implementation. You lost me there because that's not something I think the system is attempting to do.

I agree that there is a difference between what the system can/should do and what it's currently being used to do. But I don't understand why you'd approach learning about it through observation and interviews and not include a look at the specs of the product being used. It'd be like trying to understand how MDE works by interviewing CMs at the front gate. Sure they have experience with the app, but they probably don't understand the underlying architecture. Meanwhile, the company who actually built the app brags on their website about all the app can do. Wouldn't you want to factor that into your process?

There are some things the system can do that I did not assess. I didn't assess the system in all of its capabilities because Disney is clearly not using certain functionality. If you look at the TCH UI picture I posted, some of those indicators are not active because the associated feature is not being used. The odometer, security camera, and wifi indicators are turned off. Therefore, there is no reason for me to assess these features.

I'm not sure the UI display is indicative of what the system is/isn't doing. It seems like it would only be indicative of what they are allowing to be displayed on the interface.

However, the system was attempting to calculate arrival times. Regions with the new system (other than FTW) did this poorly; regions using the old system did this better. There was a noticeable difference.

From what you're saying, it sounds like the arrival times were being calculated according to set departure times. In other words, the "smart" aspects of the system wasn't being used and it was just assuming a set schedule. I can see why this might be frustrating to bus drivers (who can easily reproduce this with a sheet of paper), but I'm not sure this actually tells us anything at all about the bus tracking system.

I observed nothing indicating that Disney waits until a bus is full of people to deploy another bus.

Didn't mean that, I meant this:

the cameras there were used to monitor how many people were waiting for a bus so they could send another bus if needed.

 

[Mouse Transit]

People in cities around the world take public bus systems to work and school every day, and many of them have to make transfers to other modes of transport in order to arrive at their destinations on time. Many of these people are special needs, elderly, and children. Maybe more ECVs at WDW, but other than that, I'm not seeing the major difference.

It's necessary for the sake of discussion for you to see the difference. The good news is that I can help you see the difference.

Do you know what an upstream coordinator is?

But I don’t understand why you’d approach learning about it through observation and interviews and not include a look at the specs of the product being used. It’d be like trying to understand how MDE works by interviewing CMs at the front gate.

I already stated that I did some Clever Devices manufacturer research about this system.

Also, your MDE/CM analogy doesn't hold any water. I collected arrival, departure, and delay time data over about six weeks riding buses all day long. I also monitored the TCH screen on buses and observed the continued overcalculation of bus stop wait times, as shown in the picture I posted. I compared the arrival times posted at bus stops with actual bus arrival times. I compared data from one region to another. The bus staff discussions were necessary to find any consensus about the system if one existed - not to take the place of my observations and data collection.

How is that like me only asking a CM how MDE works?

I’m not sure the UI display is indicative of what the system is/isn’t doing. It seems like it would only be indicative of what they are allowing to be displayed on the interface.

So, the wifi indicator is not active on the TCH home screen but there’s wifi available on WDW buses?

 

[UNCgolf]

I think a fundamental difference between the Disney bus system and public transit buses in a city is that Disney buses take one route from starting point to destination without any additional stops on the way (barring resorts that have multiple stops, but that's still different). City buses are on a continuous loop with people getting on and off at each stop, because the bus is simply a way to get them closer to their ultimate destination. They don't exist to transport people to one specific location.

Disney buses function more like a shuttle service than public transit, which also affects rider load and so on -- e.g., Disney knows that when a bus reaches the Magic Kingdom, everyone on the bus is going to disembark.

I have no idea if/how that affects dispatch etc. though.

 

[_caleb]

It's necessary for the sake of discussion for you to see the difference. The good news is that I can help you see the difference.

Hmm. After several posts about it, I'm not sure you can. Obviously there are differences. I just don't think those differences are significant enough to say, "This system requires a significant amount of adjustment because it was designed for a city and not for WDW." As @UNCgolf mentions, the point-to-point service works more like a shuttle than a typical bus route. But it's still logistics of moving people from place to place. And the technology is there to do this more efficiently than Disney has in the past.

Do you know what an upstream coordinator is?

If you mean controls in the system that supersede other controls in the system, then yes, I do. Do you mean something else?

Also, your MDE/CM analogy doesn't hold any water. I collected arrival, departure, and delay time data over about six weeks riding buses all day long. I also monitored the TCH screen on buses and observed the continued overcalculation of bus stop wait times, as shown in the picture I posted. I compared the arrival times posted at bus stops with actual bus arrival times. I compared data from one region to another. The bus staff discussions were necessary to find any consensus about the system if one existed - not to take the place of my observations and data collection.

How is that like me only asking a CM how MDE works?

Well, it's a little bit like downloading MDE onto multiple mobile phones and comparing the performance on each in an attempt to understand how the app works. The thing is, unless you have access to the backend, you're probably not going to get a good idea of what Disney is doing with the system. Even then, if you don't have insight from an insider on why they're using the system the way they are, you still won't get too far. There are too many variables.

So, the wifi indicator is not active on the TCH home screen but there’s wifi available on WDW buses?

I have no idea whether wifi was available on the bus. Did you push the touchscreen control to see what the wifi button does? Doe the indicator mean that wifi is not available to passengers, or that it's not working at all?

This is a strange conversation for me.

Obviously I offended you with my comments. That wasn't my intent. I'm sorry. Please don't be discouraged by my pushback. Even though I wouldn't go about it the way you are, I'm glad you are enjoying trying to figure out how the system works. Good luck with your research.

 

[gljvd]

What i don't get is why aren't they using the fast pass experience and magic bands to better meet demands ? Based on fast passes you should know how many people are going to your park (outside of covid) that day or at least a good starting estimate. You also know the times of their first passes which isn't a guarantee that they will go before that time but again a good estimate. You also have nfc on the magic bands , why not set up a sensor at the bust stops that show demand on the busses. If your at down town disney buss stop and 30 people suddenly show up to and tap at the the fast pass for epcot. Disney would then know they need x amount of busses dispatched. They could also see that at that location no one is waiting for magic kingdom so they can divert that bus over to meet epcot demand.

 

[Mouse Transit]

I think a fundamental difference between the Disney bus system and public transit buses in a city is that Disney buses take one route from starting point to destination without any additional stops on the way (barring resorts that have multiple stops, but that's still different). City buses are on a continuous loop with people getting on and off at each stop, because the bus is simply a way to get them closer to their ultimate destination. They don't exist to transport people to one specific location.

Disney buses function more like a shuttle service than public transit, which also affects rider load and so on -- Disney knows that when a bus reaches the Magic Kingdom, everyone on the bus is going to disembark.

I have no idea if/how that affects dispatch etc. though.

That's right. That's one major difference between WDW's bus transportation system and that of a city. It's the resort/park nature of WDW and everything that stems from it. A city is not a resort and does not have these conditions. Although they provide many services, one primary mission of the WDW bus transportation system is to get people from the resorts to the parks in the morning and from the parks to the resorts later in the day.

Hmm. After several posts about it, I'm not sure you can. Obviously there are differences. I just don't think those differences are significant enough to say, "This system requires a significant amount of adjustment because it was designed for a city and not for WDW."

First, you described that WDW bus transport was like a city's bus transport except for more ECVs. You didn't see much of a difference otherwise. Now, you claim to recognize the differences ("obviously") and but that doesn't mean significant adjustment is necessary. Which is it?

...unless you have access to the backend, you're probably not going to get a good idea of what Disney is doing with the system. Even then, if you don't have insight from an insider on why they're using the system the way they are, you still won't get too far. There are too many variables.

It doesn't require being a system engineer to consistently observe inaccurate arrival times and overcalculated bus stop wait times on a system home screen.

"There are too many variables" for what, exactly?

If you mean controls in the system that supersede other controls in the system, then yes, I do. Do you mean something else?

A WDW bus transportation upstream coordinator is a person. Do you know what this person does for WDW bus management and how that differs from city bus management?

Obviously I offended you with my comments. That wasn't my intent. I'm sorry.

I'm not offended. You stated:

I'm not sure the UI display is indicative of what the system is/isn't doing. It seems like it would only be indicative of what they are allowing to be displayed on the interface.

So, I asked you if you thought the wifi worked but the indicator didn't indicate this. That's what the wifi indicator is for - to indicate that wifi is connected.

Did you push the touchscreen control to see what the wifi button does?

You don't push those indicators on the TCH home screen. They indicate connectivity.

In short, I think you are over-simplifying the bus transportation needs of WDW resort. Although comments like "you still won't get too far" and "there are too many variables" read pretentious, I'm not offended by them. However, your changing of the argument is a bit of a red herring since it's an effort to avoid your original argument of WDW bus transport being like a city's.

Most importantly, I would love to hear how you would have investigated the new Clever Devices ITS at WDW other than the ways I did, as you mentioned you wouldn't have done it the way that I did.

why not set up a sensor at the bust stops that show demand on the busses

In addition to years of bus supply and demand knowledge (and probably other methods I don't know about), they use cameras at the bus stations to monitor the lines for increased demand.

 

[Mouse Transit]

In short, I think you are over-simplifying the bus transportation needs of WDW resort.

I meant over-complicating. It's complex but it's not rocket science.

 

[_caleb]

First, you described that WDW bus transport was like a city's bus transport except for more ECVs. You didn't see much of a difference otherwise. Now, you claim to recognize the differences ("obviously") and but that doesn't mean significant adjustment is necessary. Which is it?

It’s both. There are obvious differences between the WDW bus system and many city bus systems. But I still maintain that the differences between WDW and a typical city aren’t greater than the differences between one city and another.

Some parts of a typical urban system run on a circuit with frequent stops. Other parts of those same systems (such as commuter express lines or those running form central hubs to airports or train stations) run more like Disney’s. WDW does not only run buses from resorts to parks when there are people waiting, so it’s not exactly like an on-demand shuttle service either. In both cities and at WDW, the goal is to collect data that allows the system to be more efficient, flexible, and reliable.

It doesn't require being a system engineer to consistently observe inaccurate arrival times and overcalculated bus stop wait times on a system home screen.

"There are too many variables" for what, exactly?

Too many variables for you to learn how the system works (and why it’s currently not accurate) primarily though observation and interviews. Overcalculated wait times may simply be a trick in customer satisfaction, like the posted attraction wait times in the parks. As we’ve discussed, certain key features may not be functional just yet for a variety of reasons.

A WDW bus transportation upstream coordinator is a person. Do you know what this person does for WDW bus management and how that differs from city bus management?

No, but it sounds like this person might lose their job once the Clever Devices ITS is fully functional.

So, I asked you if you thought the wifi worked but the indicator didn't indicate this. That's what the wifi indicator is for - to indicate that wifi is connected.

You don't push those indicators on the TCH home screen. They indicate connectivity.

I have no idea how that interface works. How do you know? The UI is obviously a touch screen. Did you touch it? Did you ask the bus driver?

In short, I think you are over-simplifying the bus transportation needs of WDW resort. Although comments like "you still won't get too far" and "there are too many variables" read pretentious, I'm not offended by them. However, your changing of the argument is a bit of a red herring since it's an effort to avoid your original argument of WDW bus transport being like a city's.

Sorry I came across as pretentious, I generally try not to be a jerk. I’m glad you’re not offended.

From my perspective, I haven’t changed my argument. In fact, I’m not entirely clear what the argument is, other than whether the WDW bus system is or isn’t enough like a typical city’s bus system to warrant significant adjustments.

Most importantly, I would love to hear how you would have investigated the new Clever Devices ITS at WDW other than the ways I did, as you mentioned you wouldn't have done it the way that I did.

Honestly I’m not sure how I would have gone about it. Probably by reaching out to the developers or someone at Disney who knows about the implementation of the system. It never would have occurred to me to ride the buses hundreds of times, record posted wait times, and note discrepancies. I would never have assumed that bus drivers (or their managers) would know anything at all about how the system works.

That’s just me, and we all go about these things in our own ways. I’m really glad you’re doing it your way—you seem to enjoy it.

 

[JoeCamel]

I'll be back once this system is calculating people at stops and knows where they are going so it can dispatch according to load requirements. After that is met they need to make the distance, destination and expected time available to the riders on an app with any intermediate stops shown.
See you in the future.