Another small example from the case of overlapping airports.

In the image below we see Western Finland. It has three airports, Vaasa (VAA) - Kokkola (KOK) - Seinäjoki (SJY) . Each will have a 50 km catchment range and each of them will reach to catch the one lone square in the middle, marked in blue.

Well, firstly there's the need to calculate the destination where they wish to travel from that blue square. There are some 65 000 people living inside that blue area, and we'd need to calculate how often and most importantly where they wish to travel. This is the separate, most difficult, process. Let's skip it for now and assume from that square 100 people wish to travel to capital Helsinki every day. How would the people in the blue square choose their airport of departure?

This process would be kept rather simple preferrably...

For sake of simplicity, I would shift most of the calculations to the airport level, away from square to square level.

A square would just have the demand represented as a scalar, aggregate of passengers, broken down into SH, LH / YCF. I think we should be ignoring square to square demand that would just blow up the system

Now these 3 airports would be trying to earn the business of this square. At the start, each airport would have 33% of the square's business - square's affinity to the airport.

Now shifting the center of attention to the airport. Airport aggregate demand would be just a sum of the demand of the squares within it's catchment area, taking into account each square's affinity.

So at the airport level, we now have again a simple aggregate demand broken into SH/LH, YFC.

Next, we would calculate all of the airport to airport combinations. Using the aggregate demand, borders relations etc. we would end up with airport to airport demand, that could fit right into the current system. Except, it would not be hard coded, it would be calculated, and then recalculated at desired intervals.

Perhaps, we should ignore pax connectivity for now, to get something going quickly. Using all of the current pax allocations system, we can process flights.

At the end of the month, we get pax totals (as the system is currently tracking). We compare the actual flown pax totals, and compare them to airports aggregate demand. Comparing the demand vs. supplied demand, we get a new variable (single number), that is the ratio of these two, representing how well the airport is serving its demand.

Going back to 3 airports in Finland, they may start with 10%, 10%, 0% pax served. We take these percentages and use them to change the affinity of the disputed square. We started with 33/33/33. We move to 34/34/32.

We take this new affinity of the squares, and change the aggregate demand of the airports. And we recalculate the airport to airport demand.

As far as demand display, airport to airport, UI does not change, everything stays the same. This is a greatly simplified approach, keeping the vast majority of the system as is.

The dynamic variables would be changes of the catchment area, as the airport serves more passengers, and ever changing affinity of individual squares within the catchment area. The distance of square from the airport would affect the affinity. A local airport within the square would never quite go to zero in affinity. A local airport serving high percentage of pax within a very small catchment are would still be a viable business proposition.

As far as the work involved, the tasks I foresee are:

- Completing the crowdsourcing of the squares within countries, this just to get the ratios of squares within countries.

- massaging the crowd sourced data, applying country's population and GDP, assuring reasonableness of the square data.

- airport aggregate demand would be derived from squares. Initial catchment areas would be derived from current airport size, but far smaller than the maximum catchment radius. That will have to be earned.

- each airport will have its aggregate demand from the initial calculation above.

- we get the global aggregate demand (sum of all airports), and calculate the airport's percentage of this global demand. This is again a single variable per airport.

- if we look at HEL in particular, and we know that JFK is 2% of global demand, we know that 2% of HEL's LH pax will be going to JFK and we know how many LH pax are originating in HEL. So we get a numerical representation of HEL-JFK demand. We save it for a month, and then recalculate again.

- country relations would modify the previous step

All of the steps above have a finite level of complexity, as far as I can tell.

I think the variable catchment area and squares affinity are a close enough proxy for the square to square demand.

Once this is in place, and fine tuned and put into production (actual live game worlds), a more complex step of pax connectivity could be built on top of it. I think there is more complexity in pax connectivity than in building this City Based Demand. And this City Based Demand will be new and different enough to keep all the players glued to AWS.

Of course, this new, dynamic world should not have RL hard coded slot levels. The slots should start lower and grow organically, based on demand, so that the new hubs will be where successful players establish them.