So square-to-square complete data would be 49 000 000 lines which is too much to store naturally. If we however eliminate all lines with 0 demand (even 0 via connection) the figure would probably go down quite much, and will work on this shortly to see what ballpark that would be. Since the question is still should the system be simplified to airport level (based on the square data) instead of the square-to-square level that allows a better system; but is it worth it then. It's hasn't been yet decided since I haven't been able to determine the amount of data since the data collection hasn't been ready, but now it's almost done so I can proceed with this path decision.
IMO, the shortest path to getting the new demand system up and running is to keep everything having to do with airport to airport demand, how it get processed / allocated (to flights) unchanged.
I am assuming that the system already stores airport to airport demand (as opposed to calculating it on the fly). If the system already does have a table with all airport to airport combinations, all that would change is how this data gets populated (initially), and how it would continuously shift.
So there would be a new process to make it happen. This process would be continuously updating airport to airport demand based on square to square demand and availability of flights. This process would be asynchronous, so it would not break anything, it would not affect player interactions or turn processing.
To populate the database initially, the steps would be very simple:
- Let's say we have squares X and Y. From the global data that the system has, we know the demand between X and Y.
- If square X is catchment area of airports A, B, C, square Y is in catchment area of airports D and E, we have 6 pairs: AD, AE, BD, BE, CD, CE, and the system would just allocate the demand to these airport pairs proportionally.
- so this would be the initial data for the system, and for informational purposes of the player, this value (updated by the process below as the population, GDP, catchment areas shift) could be stored as a "Nominal" demand.
Then, there would be a process running asynchronously, independent of turn processing (could be a game day, several game days, up to a game month to complete, depending on availability of computer resources), and this process would have following goals:
- allocate X-Y demand to airport pairs AD, AE, BD, BE, CD, CE based on:
a) availability of direct flights
b) availability of indirect (connecting) flights between AD, AE, BD, BE, CD, CE (potentially later)
c) quality and competition of these flights
e) rate of successful completion of flights between AD, AE, BD, BE, CD, CE
- Based on the ranking above, the system would split the X-Y demand. How to do this without storing square to square data is the tricky part. Let's say the old split was 16.67% for each pair, the new one is 50%, 25%, 25%, 0, 0, 0. How do we add this since we don't know what to subtract (the old allocation)? Couple of options:
a) if we know that the whole cycle (to process all the square combinations) takes 10 days, then every day, we just subtract 10% of AD, AE etc. demand, and the square to square allocation process will replenish it with new values (we would not subtract, just add, the 10% reduction would take care of subtraction). Or, to slow down the changes, make them very gradual, if the system runs 10 days, maybe only 5% of demand would be subtracted per day, and only 1/2 of X-Y demand would be added (or however fast we want the changes / adjustments to happen.
b) if the process could complete in 1 day (may be optimistic) a lot of new possibilities would open up. We could then store a pent-up demand on the airport pair combination record, monitor trip completion and accommodate less than daily flights.
Doing the square to square allocation this way would conserve system resources, yet it would be very accurate, fine grained. Let's say if there is a flight from Newark to Lisbon, and there is none from JFK, or any other airport nearby, Manhattan demand to Lisbon would gradually shift to Newark.
So again, this change would only minimally impact the user interface, turn processing, pax allocation (of demand already pinned to the airport pairs). The only changes to UI I would foresee is adding additional demand graph (independent of the 7 day graph that would stay unchanged, based on the "Current" demand). This new graph would be horizontal bar graph, and for now have 3 values, and these values would be just weekly averages:
- Maximum demand - yeah, another set of values, similar to nominal, but assuming all the squares in the catchment area were allocated to the airport pair we are looking at
- Nominal demand - described above, where square to square demand is allocated proportionally
- Current demand - based on how the demand was actually allocated to airport pairs by the process described above
- Later on, other value, having to do with pax connectivity can be added.
After this is done, we could move on to pax connectivity, which again would be a discrete step. In relation to square to square demand, it would only affect the evaluation of AD, AE, BD, BE, CD, CE airport pairs with the addition of indirect flights. The initial system with only the direct flights would assign these airport pairs rating. Addition of connecting flights would still produce the same result: rating of the airport pairs, but the rating process would be more comprehensive, evaluate more of the ways pax can get between 2 airports.
My guess is that connecting flights will take up a lot more computing resources, another reason to conserve them in square to square demand, which would run at its own pace, and only very gradually shift the demand.