City based demand

[JumboShrimp]

Sami,

I was wondering if it would bot be possible to have "suggested values" for squares pre-filled.  For example, if we have the population data for the square and GDP for the country, maybe the system can generate the suggested values for industry, commerce that would fit well within the given Pop and GDP.  Then, the data gathering will be just adjusting the suggested values up or down a notch based on the contributors knowledge of the country.  This would avoid large scale errors in data. 

[Sami]

I was wondering if it would bot be possible to have "suggested values" for squares pre-filled.

Not really since if we have a country with industry, then certainly not all squares have industry in them etc. The whole idea of the squares is to override the general "mass" calculated by GDP and other factors, to pinpoint the demand into the certain cities and areas that have the major action places.


---

About airport catchment areas.

Basic passenger catchment area is a simple "range ring" based on airport size. For example 200 kilometers for size 5 (=biggest) airport (the values are  highly depatable still).

In real life the catchment area is determined by the travel time to the airport, and that depends on roads etc. that are available - modelling that is a bit hard (1st version at least), so has to be this for now.

Another issue is that our data is in squares, for practical reasons, and catchment area is a circle (yet again for practical reasons). Well, here's one mess of an image on how it will work:

- Center airport is EFHK, Helsinki (small red circle).
- Catchment area is the black circle (200 km).
- The squares in the background (red/yelllow) are potential squares from which pax can come to that airport. (people will not come overseas from Estonia to Helsinki!)
- The catchment area only slightly crosses some of the squares, like in the West with towns of Rauma and Pori, or Lappeenranta in east. However it's not good that such minor catchment will catch the whole square, so there is a certain limiter on how much it must catch the box before it is entirely inside the catchment area.

=> Thus the true catchment area will be the area covered by the boxes coloured in red.

All people in these boxes are potential passengers to the center airport (Helsinki). Their willingess to travel to this airport would decrease when the distance increases (directly proportional?).

Catchment area can be variable. Meaning that if airport size changes (or other similar change), the catchment area will change and data is re-stored accordingly.

Catchment areas of two airports can overlap of course.

[JumboShrimp]

Not really since if we have a country with industry, then certainly not all squares have industry in them etc. The whole idea of the squares is to override the general "mass" calculated by GDP and other factors, to pinpoint the demand into the certain cities and areas that have the major action places.

Agreed.  But my point is to make sure it is done within reason.

Suppose you have the US and a GDP per person of some 20k (I guess depending on year we are doing).
Now we have a square with 100k people in it.  Country specific GDP of 20k x 100x = 2 billion.
Now 2 billion would suggest the level of industrialization and commerce of say 7 on 1 to 10 scale.  So I would prefill the square with 7 for both.  Combined number of points would be 14.

Now where the contributor knowledge would come in, they would have questions to ask about the square:
1. Is the area wealthy part of the country or poor?  The player would get a range of +5 to -5.  So very poor area would get 9 points, very wealthy area would get 19 points.
2. Is the area industrial or commercial or mixed?  Based on the answer to that, the player would allocate the points determined in step 1.

So, for example, if I am doing the US, and I am looking at a wealthy New York City suburb vs. poor city in Mississipi with equal population, I would start with the bases of 14 points, the wealthy NYC suburb would get +5 (=19), -5 for poor square (=9) and distribute the points based on what's going on the squares.

Why is this important?  Suppose I am looking at a square in Senegal that has equal 100k population.  What do I do with that?  Well, if the system pre-calculates that based on Senegal GDP of say $5k per person, the number of points to give out should be 4 on average for Senegal, as a starting point, with player being able to modify it by +5 to -5, we will stay within reason.  So for example the wealthiest area of Downtown Dakar would be at best equal to the poorest area in the US.  Without these constraints, I think we will end up with lot of crazy data...

So where we would go from here is to get the actual demand, we would take the 3 components:
1. industrialization x population x GDP which would result is certain amount of cargo and a certain amount of pax
2. business x population x GDP and that would result in another set of values for cargo and pax.
3. holiday destination (not sure how to scale that one)

Combining the 3 components we would get the demand of the square.  So it starts from generic, but would get specific with contributor adjustments, but at the same time stay within reason.

Another check might be on the countrywide basis, to do a c***rywide sum of the discretionary player adjustments.  On the net basis, it should be generally close to zero.  If some areas are wealthier than the average of the country, other areas need to be poorer and net result should be getting back to the average for the whole country.

[Sami]

Writing initial testing versions of the calculation script, and generally speaking does this make any sense (just wish to make sure I have not omitted anything):

(assume that we have the world full of the data squares, in a suitable format)

- Firstly, the system checks for squares that fall within reach of any airport (ref. my previous post, airport catchment area). Discarding the squares with no reach to any single airport, or unpopulated squares etc.. People won't travel from there, or use other means.

- Then the system figures, bit by bit (one longitude at a time for sake of CPU/mem usage) potential passenger demand between each square from that longitude to any other squares around the globe. Done using the variables assigned for each square, and country relations data, and country GDP, and other such factors. Result is passengers per day (/month, whatever) between each square (or 0 if not possible/no demand). Demand is allocated between four travel types: leisure travel, business (= not business class, but business related travel), premium (= high-paying business or holiday travel etc.) and cargo. This all is of course the trickiest part, in order to tune the calculations so that the results actually make sense compared to reality.

- Once the square-to-square demand for each square from the given longitude is done, system will then make this into airport-to-airport data that will be saved. (square to square data cannot be saved since there would be ~100-250million data entries; airport to airport gives a manageable number of results.)  System will check the specs of each airport that can use each given square; airport will be given a score based on the desirability (distance mainly) and airlines serving to it (if we have a direct connection from the airport to our desired box -> good score, if we have one-stopover connection -> less points ... if no service at all, show still some interested passengers as "demand" if there is no other alternative..  some other factors like images and avg. prices are possible factors too). Result will be Y/C/F/X(cargo) breakdown in pax demand, and this is the figure that is also shown to players.

- The above demand figures are updated once or twice a game month for each airport with a rolling background calculation (or instantly in case of any events, or airport data changes). This is a tradeoff between balancing the calculation CPU usage, data storage size and playability. This way everything is calculated only at background, data storage is still within reasons and any changes in the demand will be gradual to players (= if a player enters to another airport overlapping your airport, the demand will shift to that airport over time, if he is "much better" than you.. or other way around). My only concern is how to make the player-made changes to affect the shift in demand fast enough (like opening/closure of a route, major change in pricing ..etc) - these should be seen in a game week or less, not in a game month.

- Actual pax demand distribution is then another module, that checks the apt-to-apt demand figure and uses it as a baseline for the distribution of passengers. For first test version we could actually even use the present demand allocation module, and then move to next version that can handle connections etc. (demand storage in this format poses on problems to it)

- Also some thought must be given on how the data is displayed to players. We naturally will keep the airport to airport style route planning search still, but if there are many airports overlapping some demand, how would that be shown so that it is clear. ("demand from X to Y is 500 pax, but it includes 200 pax that can be flown from Z to Y" .. ?!?)

..This is just the rough baseline, but comment if you wish. Posting it here just in case someone figures something essential or an idea on how to do it smarter (my brains are overheated ....)

[JumboShrimp]

First thing I have to say that it is a brilliant plan.  It may not be instantly responsive - as in instantly responsive to guy at the other airport going into a C check, instantly shifting demand to another airport - but responsive enough to the normal scheduling of flights.  And the potential slowness (speed) of responsiveness will eventually depend on the performance on real data, and that is something that would be extremely hard to determine now.  But if the world can be updated once per month, that could serve as a minimum.

- Then the system figures, bit by bit (one longitude at a time for sake of CPU/mem usage) potential passenger demand between each square from that longitude to any other squares around the globe. Done using the variables assigned for each square, and country relations data, and country GDP, and other such factors. Result is passengers per day (/month, whatever) between each square (or 0 if not possible/no demand). Demand is allocated between four travel types: leisure travel, business (= not business class, but business related travel), premium (= high-paying business or holiday travel etc.) and cargo. This all is of course the trickiest part, in order to tune the calculations so that the results actually make sense compared to reality.

Sounds good.  But I guess this is not really a "step" (since the data is not being stored anywhere), just a description of a concept / algorithm of how it will be done.

- Once the square-to-square demand for each square from the given longitude is done, system will then make this into airport-to-airport data that will be saved. (square to square data cannot be saved since there would be ~100-250million data entries; airport to airport gives a manageable number of results.)  System will check the specs of each airport that can use each given square; airport will be given a score based on the desirability (distance mainly) and airlines serving to it (if we have a direct connection from the airport to our desired box -> good score, if we have one-stopover connection -> less points ... if no service at all, show still some interested passengers as "demand" if there is no other alternative..  some other factors like images and avg. prices are possible factors too). Result will be Y/C/F/X(cargo) breakdown in pax demand, and this is the figure that is also shown to players.

I think it might be useful to store the info that is static, as in aiprort - square table, something like:
AirportID
SquareID
Distance

So that it would be quick lookup to go from square to airports (where square is within its catchment area) and squares belonging to an airport (within its catchment area).  This would be done one time before the game start, or when something about an airport changes.

The initial allocation of square to square demand to airports within origin's square while no-one is flying seems straight forward conceptually.  I think the tricky part will be to figure out how to update and what has already been updated.

Let me give you an example.  Suppose this process is run for the first time for all squares to prepare the game world.  Suppose we calculate the demand for JFK-LHR route.  This demand (or more precisely, the 4 components of the demand) are an aggregation of square to square demand between these 2 airports, store as a scalar (one per each of 4 demand categories), without knowing how much each square contributed.  Let's call it old aggregated value.

Now we are going to update, and we are updating LHR square 1 to JFK squre 1.  We figure out the new value, but how do we update the aggregate figure of JFK-LHR if we don't know the the old one?  If we knew the old, it would be simple as: aggregate - Old_LHR_Sq_1_to JFK_Sq_1 + New_LHR_Sq_1_to JFK_Sq_1.

So the updates would have to performed on route basis, route being JFK-LHR.  So let's say we are doing JFK-LHR route, we zero the 4 components, and then process the set of combinations of JFK squres to LHR squares.  Anyway, you may have planning on doing it this way all along...

The concept of quality of connection affecting demand is great.  I guess where it fits within steps is in the square to square demand calculation.  So we might have this set of possible contenders for one of NYC and one of London squares (probably the worst case scenario):
JFK-LHR
JFK-LGW
JFK-STN
JFK-LTN
JFK-LCY
EWR-LHR
....
LGA-LHR
...
LGA-LCY
(total 15, could be more if we the squre is within range of smaller airports such as ISP, HPN)

So to figure out JFK-LHR demand for the square, we need to figure out what fraction of the set of possible direct routes our JFK-LHR route is.  If there is no connection of, say LGA-LCA, it should be possible to make that a zero.

Now, this is the worst case, but if we include the routes with 1 stop, the set will defnitely grow substantially

- The above demand figures are updated once or twice a game month for each airport with a rolling background calculation (or instantly in case of any events, or airport data changes). This is a tradeoff between balancing the calculation CPU usage, data storage size and playability. This way everything is calculated only at background, data storage is still within reasons and any changes in the demand will be gradual to players (= if a player enters to another airport overlapping your airport, the demand will shift to that airport over time, if he is "much better" than you.. or other way around). My only concern is how to make the player-made changes to affect the shift in demand fast enough (like opening/closure of a route, major change in pricing ..etc) - these should be seen in a game week or less, not in a game month.

- Actual pax demand distribution is then another module, that checks the apt-to-apt demand figure and uses it as a baseline for the distribution of passengers. For first test version we could actually even use the present demand allocation module, and then move to next version that can handle connections etc. (demand storage in this format poses on problems to it)

- Also some thought must be given on how the data is displayed to players. We naturally will keep the airport to airport style route planning search still, but if there are many airports overlapping some demand, how would that be shown so that it is clear. ("demand from X to Y is 500 pax, but it includes 200 pax that can be flown from Z to Y" .. ?!?)

..This is just the rough baseline, but comment if you wish. Posting it here just in case someone figures something essential or an idea on how to do it smarter (my brains are overheated ....)

As far as representing the demand graphically, for JFK-LHR route, there are a lot of values that can be shown, that may need to be considered:
- local demand allocated to this airport: what we are calculating
- base local demand: demand between JFK-LHR absent of any flights, where the square demand is split just based on distance of squares to airports
- maximum potential local demand: if all passengers of all JFK squares to all LHR squares use JFK-LHR route
- potential pax from connecting flights (might be too difficult to figure out, and would be huge potentially), so we may just as well skip it.
(each one of these would have the 4 components).

- actual number of local passengers flown on average for last week
- actual pax from connected flights
- total actual pax: total of actual local + actual connecting

Supply is another story, and how to show it.
- direct route supply: sum of flights on JFK-LHR - easy enough to figure out
- neighboring airport direct route supply: Looking at all of JFK squares, what other airports could JFK squares be served by?  We get one set for JFK, another set for LHR, so we sum the supply of all combinations (minus JFK-LHR).  Still straight forward, but we are back to a lot of calculations just to show the demand screen
- connecting, 1 stop supply: yet another set of flights.

Of all of these, some may be too difficult to implement.  Differences in values may be too great that we may need to use logarithmic scale (if the graphing software supports it).  Monday - Sunday demand display may have to be discarded if some of this other useful data is going to be shown.

I will try to think of ways to display it in next few days....

[JumboShrimp]

Variable catchment area:

It may be useful to have a variable catchment area.  This could be independent of airport "size" as it is currently defined in the system.  It could depend strictly on number of passengers flown.  The system could have a simple function of:

Catchment radius = Function of (Passengers flown from the airport).

The system could have a minimum of say 50km as a base, and every airport would start with that.  Than, as the airport grows (as far as passengers served), the radius could grow to potentially to 200km or even 300 km for the busiest airport (not sure if the picture around Helsinki is radius of 200km or diameter.  This way, with radius of airports with very low number of passengers would stay very small, the system will not be wasting too much time calculating square to square demand of squares that may never really end up being connected by supply.

And since this would be a very simple calculation for the catchment area radius (and the table of AirportIDs to SquareIDs) it could be updated as part of every round of updates.

It might be useful for playability as well.  The system would not start with astronomical demand and no supply.  The demand would build up as the catchment area grows, as more passengers is brought in through connecting flights, and as the catchment areas grow, there would be more overlap, and more indirect competition as the game progresses.

It would be a great way to make the game world more dynamic.  Also, with airport growth, there could be some way to grow slots as well, to make that area dynamic as well.  The game could start with number of slots that is lower than current start, and then grow with number of either pax or take offs and landings.

[Riger]

Variable catchment area:

It may be useful to have a variable catchment area.  This could be independent of airport "size" as it is currently defined in the system.  It could depend strictly on number of passengers flown.  The system could have a simple function of:

Catchment radius = Function of (Passengers flown from the airport).

The system could have a minimum of say 50km as a base, and every airport would start with that.  Than, as the airport grows (as far as passengers served), the radius could grow to potentially to 200km or even 300 km for the busiest airport (not sure if the picture around Helsinki is radius of 200km or diameter.  This way, with radius of airports with very low number of passengers would stay very small, the system will not be wasting too much time calculating square to square demand of squares that may never really end up being connected by supply.

And since this would be a very simple calculation for the catchment area radius (and the table of AirportIDs to SquareIDs) it could be updated as part of every round of updates.

It might be useful for playability as well.  The system would not start with astronomical demand and no supply.  The demand would build up as the catchment area grows, as more passengers is brought in through connecting flights, and as the catchment areas grow, there would be more overlap, and more indirect competition as the game progresses.

It would be a great way to make the game world more dynamic.  Also, with airport growth, there could be some way to grow slots as well, to make that area dynamic as well.  The game could start with number of slots that is lower than current start, and then grow with number of either pax or take offs and landings.

This sounds/feels like a pretty good way to make the game more dynamic/variable.  It might be worth considering "letting go" of the logical geographical (country) restrictions (people will not come overseas from Estonia to Helsinki!) because while this may not represent reality, it will add another dynamic factor and will probably make for easier algorithms for the code.

If nothing else, this would certainly be a good starting point for at least 1 game world as a test.

Regards

Richard

[JumboShrimp]

System will check the specs of each airport that can use each given square; airport will be given a score based on the desirability (distance mainly) and airlines serving to it (if we have a direct connection from the airport to our desired box -> good score, if we have one-stopover connection -> less points ... if no service at all, show still some interested passengers as "demand" if there is no other alternative..  some other factors like images and avg. prices are possible factors too). Result will be Y/C/F/X(cargo) breakdown in pax demand, and this is the figure that is also shown to players.

I think it is useful to have some zeros, some elimination of useless things to calculate over and over, to get smaller sets back from querries.  So if no connection, no demand to allocate for the route.  So if there is no direct or 1 stop way to go from LGA to LCY, the point value could just be multiplied by zero, so allocated demand for the route would be zero.  If we store some guideline demand figure (that I called "base local demand", "maximum potential local demand") to show to players.  But the allocated demand would be zero for routes at the start of the game until there is an actual flight.

My only concern is how to make the player-made changes to affect the shift in demand fast enough (like opening/closure of a route, major change in pricing ..etc) - these should be seen in a game week or less, not in a game month.

If the background calculation goes down the list all of the routes stored, and the target is to update the routes once per month, once the route is processed a date can be stored on the route as far as when to recalculate the route.  Let's say next day to process = current date + 28.  If a player schedules a route (assigns it to an aircraft), the next day to process could be set to current day.  And the day would not advance until all the routes with next process date = current date are not processed.  So the responce to a new route creation would be "instant" or equal to AWS 1.3.  Same should be done for any re-assignment of aircraft.

Pricing changes?  I would ignore those and only use them the next time the route comes up naturally (within a month).

As far as the price, if I understand it correctly, it would be in 2 places:
1. - background calculation to allocate the square demand to airport to airport routes
2. - allocation of the above airport to airport demand to individual flights on the route serving the demand.  In this step, the responce would be instant (= AWS 1.3).  Shifting of demand in 1. as result of price change would be slow.

[JumboShrimp]

This sounds/feels like a pretty good way to make the game more dynamic/variable.  It might be worth considering "letting go" of the logical geographical (country) restrictions (people will not come overseas from Estonia to Helsinki!) because while this may not represent reality, it will add another dynamic factor and will probably make for easier algorithms for the code.

If nothing else, this would certainly be a good starting point for at least 1 game world as a test.

Regards

Richard

I agree.  The only "catch" is that there used to be the iron curtain, and such travel (Estonia to Helsinki) would not really happen a lot.  But that could easily be deferred to much later in the process.

As far borders, let's say Slovakia to Austria, that I cross often, it is completely meaningless now, and probably 1/3+ of Slovakian pax use Vienna airport, especially for LH flights.  And the "catchmet" area of VIE airport is easily 200 km into Slovakia (in addition to ~50km from VIE Schwechat from the border)...

BTW, not that I would want to complicate things, I think the catchment area for LH flights > catchment area for SH flights...

[Sami]

The cross border thing ... I've thought it so that at first all border crossings are disabled. Then we can ALLOW them one by one (country by country) by setting the first possible year and country pair.

This is easiest this way since a box that overlaps two countries is already defined twice in the database, and has unique population figure for both countries. So calculationwise I do not have to separate anything to get the border closed. To get it "opened" it needs another round of checking.

(= simple)

[Riger]

Sounds good so ....  Lets Go !!

[Monk Xion]

idk if i brought this up or not.

I think there should be tweaks for certain destinations to reflect real life routes.

Routes that come into mind for me personally are ATL/IAH/MIA-MGA.

irl Delta flies 1x from ATL, UAL 2X from IAH and AA 2x from MIA. AA used to use a mix of 738's/A300's (until 2009) and then 763's until last year. Now its all 738's  

I was on the DAL service in 2009 and it was full bothways. I suspect the UAL/AA flights were the same (along with the TACA/Copa Connections)


Ik alot of the pax are connecting to go to other destinations via those 3 hubs , and potentially just flying to MIA because of the large Latino Population in florida, but it raises a question about the numbers for countries that have routes like that :s

Idk im kinda rambling but the point is that there should be minor tweaks to reflect real life load factors on certain routes like this, especially to destinations in the Carribean and Latin America IMO.

Edit: I can not view the City Editor either. I was curious to see what demand for certain places was 

[alexgv1]

I had an idea for passenger connectivity:

Using my current DOTM3 airline, I am HQed in Toronto and have a base in Vancouver.

I use CYYZ as European gateway for Transatlantic, and CYVR as the Asian/Australasian gateway. However there is decent demand from Vancouver to Europe and vica-versa.

Therefore, rather than calculate all potential routes and connections possible, my idea is to create a "virtual route" between Vancouver and Toronto which transfers the passengers and instructs them to go to Europe via Toronto. Therefore all pax demand from CYVR will be transferred to CYYZ (just for me) as my passengers are connecting, provided that I provide enough seats for the spoke flight (this demand goes up).

This may effect competiton as we are all fighting for the same demand, so how about X% of passengers are transferred to my route with that number depending on the normal competition statistics. Treat the hub flight as a tech stop and use connection time into account of flight time, compare it to the direct route then I will take a certain amoutn of passengers from the direct route. If no competition then all pax will have no choice than to route with me (standard LF calculations apply).

This would be strenuous as it would have to have a route made for each airport to fly to through connections (but no more work than making a non-stop route). Of course at first it is limited to your own bases as a first stage to keep calculations simple, but eventually it can be expanded to alliance bases and regional flights to feed long haul flights from non bases.

Just an idea, please let me know your thoughts.

[JumboShrimp]

This would be strenuous as it would have to have a route made for each airport to fly to through connections (but no more work than making a non-stop route). Of course at first it is limited to your own bases as a first stage to keep calculations simple, but eventually it can be expanded to alliance bases and regional flights to feed long haul flights from non bases.

Just an idea, please let me know your thoughts.

Well, hopefully the passenger connectivity will be automatic, calculated by the system, rather than player manually creating all the combinations...

At first, just 1 connection only limited to player's own flights would be good enough, later expanded to the alliance.

[Sami]

When you create a route the system will show you all potential connections within your network, automatically. You can tick and choose the ones you wish to sell tickets to (default = all), and adjust prices if you wish. (or later)

Simple.

For pax calc each connection shows like a regular flight, having extra stop.

Connection thresholds would be for example, only one stop (2 consecutive flights max) and connection leaving no earlier than 60mins from arrival and no later than 4 hours. Would prefer to keep these as fixed values.

Actual flight data stats/info will be shown like they are today, with perhaps added by data of amount of connecting pax share, or smilar. But still very simple too.

[JumboShrimp]

When you create a route the system will show you all potential connections within your network, automatically. You can tick and choose the ones you wish to sell tickets to (default = all), and adjust prices if you wish. (or later)

I am not sure about this part (the user input into what is connected and prices).  It may be too overwhelming for the user.  It should be done automatically by the system, and the connections the passengers actually chose to fly would largely depend on price and duration (described below).

BTW, are you planning on storing the possibilities in some tables?  I guess it might be necessary...  Looking at the number of combinations for 1 hub, n destinations, I think it is going to be 1 + 2 + 3 + .... + (n-1), so something like (n-1)^2 / 2 or if each direction is considered as separate, (n-1)^2

Simple.

For pax calc each connection shows like a regular flight, having extra stop.

Connection thresholds would be for example, only one stop (2 consecutive flights max) and connection leaving no earlier than 60mins from arrival and no later than 4 hours. Would prefer to keep these as fixed values.

Actual flight data stats/info will be shown like they are today, with perhaps added by data of amount of connecting pax share, or smilar. But still very simple too.

As far as prices, my understanding of current pricing is that it is = a constant for taking off + some rate per nm flown.

Maybe the connecting flight price should be calculated the same way, that is, one single constant for taking off, not 2.  As a result, the planes will be more full in general, but if they are carrying a lot of connecting passengers, the revenue per passenger will be slightly less.

If we keep the distance based on miles flown between A-Hub-B, rather than distance AB, that alone would discourage passenger flights where A-Hub-B >> AB, since the price would be too high, compared to their expectation for AB.  The more A-Hub-B looks like a stright line, the more the flight look like a direct flight pricewise, except with longer duration.

[NovemberCharlie]

Any news on when we can get started on inputting data?

regards,

NC

[Sami]

I've been on holiday, and have not worked on this for a while. But I am still in process of building a test version of the calculations to see how much CPU time it would take. Before that is done and found doable there's no sense in spending time in data entry yet.

[Sami]

The latest game engine had the large changes on the way the demand is distributed, but also on how the demand data is stored on the server ( https://www.airwaysim.com/forum/index.php/topic,41747.0.html ). It was one of the pre-requirements for work on this feature. I would hope that last bugs of that new system have been ironed out now (airport transfers etc), so next thing I am working is the country specific economies (based on GDP data). Data is collected but all the country splits and combinations (like Germany and CCCP ..etc) make it difficult again.

Here's one ex-CCCP country. The GDP does have a direct relationship to air travel volume in that country and with this feature we can have real boom or depression periods for each country or continent. Realworld data is the baseline but in the future nothing would prevent making up these figures for random economic events too.

[Infinity]

Looking forward to this.