Let us break down the project into three possibilities:
1) Wireless per BUS, allowing real-time updates en-route between cities. This would require data reception anywhere.
2) Wireless per BUS Rest-HUB, allowing updates when the buses stop for the day at their rest-station.
3) Wireless per BUS stop, allowing updates at certain points along a bus's daily route. The problem here depends on how long it takes to do an update, what if a bus leaves the WIFI area before it is finished? Just how many wireless BUS-Hubs would this method require? Too many, IMO.
#2 would be much cheaper since only the bus-hub would need internet access, with the buses getting their updates via free WIFI. The data downloaded would also be minimized since the computer at the Bus_Hub would store the updated versions and disseminate to multiple buses. It would allow daily updates to the content versus bi-weekly. It might save some manpower but not sure how much given the fact that employees would still need to enter the buses at a frequent-interval to check the catalogs. This one is the easiest to implement but the benefits are limited.
Option #1 is more flexible but much more expensive (even if they can get data reception anywhere as they go between cities). The buses would each need their own wireless connection, data updates would each need to be downloaded from the telecoms separately (How big is an update? Times how many buses? How many gigabytes is that that CCME would need to pay for?). The costs for this option would not only be high on the cap-ex for all the hardware, but it would be high every month for all the telecom data service charges.
-Fernando
Market Data 
Markets 
AI
