City based demand

[Jona L.]

You can't tell me people don't cross over into Hong Kong and Singapore to catch a flight, despite international borders.

Agreed, but the Iron Courtain before '89 (in wich area 2 of 3 of the current GWs run) is a whole different thing than China|Hong Kong... so at least that would have to be in it.

Just asides that, while speaking about the Iron Courtain.... West GER --> Berlin (THF and TXL only) was a pretty big demand, unlike how it is in pre-'89 games, where it is also very low, while demand West GER -> East GER should be completely 0 where it is something 50-ish usually.

Wrong topic, sorry about that, but anyways...

cheers,
[SC] Jona L.

[JumboShrimp]

For the current test scripts, this was built earlier. The airport catchment area is a variable (monthly updated) value between 50 and 250 km, based on the number of passengers the airport has transported during the current game year (or previous year in case of january). Catchment happens only in the same country where the airport is - so far.

However; the 250 km may be too large for some countries, if you see the image below, where we have a 250 km ring around LHR .. goes all the way up to Manchester. (almost; as it does not catch fully the square where Manchester is, but very close to it anyway)

I think the system should constantly adjust what percentage of the pax from each square would belong to LHR for example.

In the UK, with a ton of airports, the percentage of the square that would belong to LHR would be relatively small.

But if you take Samo's example, of Vienna airport, and say a country of Slovakia, which has no LH airport, people from as far as 250km routinely catch flights in Vienna (perhaps Budapest or Krakow).

This is more of a case for LH travel than SH travel, when choices are limited.  There might also be some sort of friction (cost) associated with square distance from the airport, so that SH connecting to a larger LH hub would not be unfairly disadvantaged vs. "other means" within the catchment area.  Connecting 250km SH flight might be $75, but getting to the airport by other means may be $75.

[JumboShrimp]

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.

[Sami]

Yes, it would of course immensly help in the volume and number of calculations, if we'd leave out alltogether the aspect of "X people from this square wish to fly to square Y - how do they get there" (as that would mean scouting the routes and connections etc).  (..of course here the demand would move over time to the airport that has some service, but this does not take into account if airport 1 has service only to some remote airport, while airport 2 has services directly to their desired city/square - airport 1 would still show request for the flights there, even though in reality everyone would go to airport 2... ..but it's simplified)

So instead of doing a list of all the squares (destinations) people would fly from this single square (approx 10000 values), we'd have only 1 set of values per square which is "how many people will depart from this square" (three parts in that data: holidaymakers, business pax and visiting family etc. (+cargo)).

However this approach, when it's converted to airport-airport demand in next step, would then mean that the global city and box data is rather useless compared to all the effort..

But have to think. I am pondering the different options and making calculations of what is feasible on this. Would of course like to include as much of aspects and data into it as possible, but the calculation amounts get limiting very quickly - and on the other hand even if it isn't that complicated would anyone even notice.  

[JumboShrimp]

Yes, it would of course immensly help in the volume and number of calculations, if we'd leave out alltogether the aspect of "X people from this square wish to fly to square Y - how do they get there" (as that would mean scouting the routes and connections etc).  (..of course here the demand would move over time to the airport that has some service, but this does not take into account if airport 1 has service only to some remote airport, while airport 2 has services directly to their desired city/square - airport 1 would still show request for the flights there, even though in reality everyone would go to airport 2... ..but it's simplified)

So instead of doing a list of all the squares (destinations) people would fly from this single square (approx 10000 values), we'd have only 1 set of values per square which is "how many people will depart from this square" (three parts in that data: holidaymakers, business pax and visiting family etc. (+cargo)).

Yes, it is a simplification, and it would not get us the fine grained results, such as Airport A is serving HEL demand and is getting pretty much all of that demand from the disputed square, while Airport B, which has a flight to LHR, would get most of the disputed squares pax going to LHR.

But I think it is close enough approximation, to get this part done and move on to pax connectivity, which will deliver more value to the players.

The problem with square to square is not only determining (storing?) the demand, but also who is supplying it and how the airlines are competing for it.  Let's say a square that covers Manhattan, New York City to some central part of Los Angeles.  Manhattan is going to be in the catchment area of 5+ airports, and LA square will be in catchment area of say 4+ airports.  So we have to check 5x4 airport combinations how this 1 square to square is served.  If that is not enough, when we have pax connectivity, it will explode to perhaps 1000+ flight combos for this single square to square.

If we have connecting pax complexity on top of square to square complexity, we will probably reach a dead end.

The best thing about this simplification is the relative ease of implementation, and relatively modest computational requirements.

But have to think. I am pondering the different options and making calculations of what is feasible on this. Would of course like to include as much of aspects and data into it as possible, but the calculation amounts get limiting very quickly - and on the other hand even if it isn't that complicated would anyone even notice.  

The immediate effect is that the legacy hubs disappear overnight.  ATL will likely not be the worlds busiest airport, LHR issues will probably disappear.  LHR will be less of a Trans-Atlantic hub and its demand will be disbursed.

Airports will rise and fall in significance, depending on how well they serve their passengers (with growing / shrinking catchment areas, changing square affinity).

But most importantly the system will have the correct data in preparation for the next stage, pax connectivity, which will be something the players will definitely notice.  The game play is about HQs and building hubs.  Hubs are about connectivity, which is missing.

Another thing we will have is world that is flexible, responsive to player actions.  In one game world, maybe CLT will become the busiest airport (with connecting pax), in another, maybe PHL or AMS.

[JumboShrimp]

More idea on the subject:

I would still keep the demand pinned to the airport to airport pairs.  I think the system already has it, and it would be good to keep it that way.  The question is how to populate this table of airport pairs and demand.

1. simple, granular, square has affinity to airport(s) while in catchment areas of these airports.  Affinity changes and all of the square's demand (all destinations) shift to one airport or another.  Once per month (or even more often), the table of airport pair demand is updated.

2. finer grained - a continuously running process will keep recalculating square to square demand and supply (in a fashion to be determined later).  Supply, and from which airport pair the supply was provided will affect where (to which airport pair) this demand will be pinned.  Result of this process will again be pinned to airport pair table, for a period of a month, for example.  So the end result will be the same.  The same airport pair table will be updated.

I would ignore the "potential" demand.  Too much to store, probably too slow for on-demand web site pop-up.  Let the players figure it out on their own.  We would always be looking at "current", what is currently pinned to the airport (airport-pair demand table).

Since the result of both approaches would be the same, the order of getting things done could be:
1. Simple, granular City Based Demand
2. Passenger connectivity
3. Finer grained City Based Demand, taking into account square to square supply/demand.

This way, we will be looking only at finite level of complexity at the time.  And the one with the most unknowns will be last.

If the approach is to always pin the demand to airport pairs (for fast user access, fast pax allocation processing), that will be the common denominator all 3 steps will have.  We will just be (at every one of these steps) figuring out how to populate and use this data.

[Sami]

Help wanted in the data input!

Read more here: https://www.airwaysim.com/forum/index.php/topic,46511.0.html

[Dasha]

Sorry to bring a dead topic back to life but I have a few questions regarding this city based demand.

1. What will be the major difference between it and the current system and
2. What will happen to quirky airports like Baku, Tashkent, Vanuatu, Guam, which all have higher demand than IRL. Will these airports become 'normal', meaning no more ULH and LH business?

[LemonButt]

Sorry to bring a dead topic back to life but I have a few questions regarding this city based demand.

1. What will be the major difference between it and the current system and
2. What will happen to quirky airports like Baku, Tashkent, Vanuatu, Guam, which all have higher demand than IRL. Will these airports become 'normal', meaning no more ULH and LH business?

1. The current system has large airports based on real life airlines.  Atlanta is not the largest city in the world, but it has the largest airport in the world because Delta decided to put a hub there.  The new model will have demand to/from Atlanta based on the population, industry, etc.  This means cities like London will have the demand distributed across all airports in the catchment area, not just Heathrow.  It also means cities that aren't a hub become a lot more viable, such as St Louis, Tampa, and New Orleans.

2. There is a setting for islands (I'm part of the city data collection team).  Islands with no other transportation options will get a healthy boost--you can't drive from Taipei to Hong Kong.  Guam will probably be nowhere near as busy until connecting pax are modeled since it is a hub IRL.  On the LH front, the good news is the pax should be distributed.  That means instead of basing at an airport like Nice and only having 400pax longhaul demand to a small handful of major hubs, you'll have 150pax longhaul demand to a bunch of major cities instead.  It effectively means there will now be demand between any two points on the map instead of those decided IRL by airline hub placement.

[exchlbg]

I guess you will have to wait until the results of this new calculation show up. Amsterdam is a different case than Atlanta, ii is the central airport of a country.Of course demnd numbers won´t be as high as now. Especially if connecting travel will be coded and you would have to make it a hub with your passengers, like in real lfe.

[Dasha]

Which isn't correct because the main reason Amsterdam is so big irl, is because of connecting passengers. If that's not scheduled, Amsterdam will be reduced to nothing in the game.

[exchlbg]

What is not correct ? Maybe you didn´t read it correctly. If connecting traffic will be coded, all numbers to now existing hubs will be much smaller than used. You will have to expand numbers by connnecting traffic organized by your airline. How can you be so sure about any special airport number, do you lead this project and know so much more details than everybody else ?
We don´t even know if and how connecting traffic will be realized and how that affects basic demand between any two airports, but complaining already started !

[Dasha]

I'm just saying that IF you simply look at how big a city is and the demand from that city and not the airport, which is how I understand from you how it's going to be done, I think you get wrong numbers. That simply means that the biggest cities have the highest demand and that smaller cities will have almost no demand, meaning that an airport like Amsterdam in the game will basically be useless because Amsterdam has less than a million people. The strength of that particular airport is the connecting passengers, not every singly Dutchy flying six times a year

[exchlbg]

You still don´t seem to catch my point. First , it´s not pure inhabitant count of the closest city, calculations will be very complicated in the way every airport attracts not only the neighbourhood, but also those living more distant to it, giving PAX the choice to use more than one airport. Also the economy of the area and the country of every airport will be considered, giving Amsterdam a better hand than especially Atlanta, which is just one big city of many. It is intended to leave it to the players where they open hubs, connect a lot of their flights and so (as in RL) generate a growth on PAX and airport facilities through the mass of changing PAX. So Heathrow and Atlanta won´t be the biggest airports of any world anymore, maybe it will be AMS (for Europe) and Nashville for America, because the biggest game airlines build their hubs there. All airports will start small and will only grow if airlines decide to use them.And giving those opportunities to the players every gameworld will be truly unique, not necessarily depicting lived reality but creating a new. So there can´t be "wrong" numbers unless the base calculation works with wrong numbers in the beginning.

[Dasha]

Okay now I understand it.

So in theory, Vanuatu could become the biggest airport in the world?

[exchlbg]

I didn´t hear of any relevant industry that would push Vanuatu into the first line of airports serving business travellers nor would it be able to host a dense network of local and international lines by geografical position alone. So my answer would be no. Base demand between the centers of economy will determine the logical position of potential hubs, so the world will not turn into a complete fantasy playfield. Since I am not in the development team I am combining the little information that could be obtained through the forums during the last years. I can´t predict how the new demand model will work precisely .

[LemonButt]

I didn´t hear of any relevant industry that would push Vanuatu into the first line of airports serving business travellers nor would it be able to host a dense network of local and international lines by geografical position alone. So my answer would be no. Base demand between the centers of economy will determine the logical position of potential hubs, so the world will not turn into a complete fantasy playfield. Since I am not in the development team I am combining the little information that could be obtained through the forums during the last years. I can´t predict how the new demand model will work precisely .

I'd have to agree with this based on what I know.  However, airports that are geographically centered such as Cincinnati, St Louis, or Oklahoma City could end up being huge.

[BD]

I didn´t hear of any relevant industry that would push Vanuatu into the first line of airports serving business travellers nor would it be able to host a dense network of local and international lines by geografical position alone. So my answer would be no. Base demand between the centers of economy will determine the logical position of potential hubs, so the world will not turn into a complete fantasy playfield. Since I am not in the development team I am combining the little information that could be obtained through the forums during the last years. I can´t predict how the new demand model will work precisely .

Reading the last several posts, if I can interpret what is intended here....

Proximity to a large population (not the population of the city alone), as a proxy for economic activity, will play a determinant in the potential maximum size of an airport.  Perhaps trade restrictions between countries would mitigate that crossover (e.g. East vs West Germany) but open trade helps (e.g. Amsterdam).  Rather isolated cities (e.g. Vanatu), would have limited upside.

Therefore, cities like St Louis, etc can have a pretty large upside, in a fashion similar to Atlanta (irl).

Is this all correct?

[LemonButt]

I believe so.  To give an insight on the data collection, the world is broken up into approx 60nm x 60nm blocks.  Each block is assigned values based on population, infrastructure, industry, etc.  That data will be fed into airports to determine pax demand.  How large the catchment area is I'm not sure, but I'd say it will fade as the radius gets larger.  So the home block = 100%, 1 block out will be 80%, 2 blocks 50%, 3 blocks 25%, 4 blocks 0%...or something similar to this.  The idea being people will drive 2 hours to the airport, which is what really happens IRL.  I live in Asheville, NC for example and will drive 1 hour to GSP, 2 hours to CLT or TYS, or 3 hours to ATL to get the best price and/or a direct flight.

Once connecting pax are implemented, I assume it will be based on opportunity cost.  If flying from NYC to LAX is 3000nm then a pax will connect in an airport if it doesn't make the trip longer than 3500nm with the connection, for example.  This means NYC-STL-LAX could compete with the NYC-LAX routes/demand etc.

sami has IMO thought of everything in terms of city-based demand factors.  Each box has parameters for whether or not it is populated, whether it is an island, industrial activity level (relative to country average), business activity level (relative to country average), tourism level (relative to country average), and the holiday months/seasons.

[BD]

Thanks.  Sounds like an exciting addition! 

You do mentioned 2 hours drive...not sure if that is just a notional number or if that is the actual plan.  The catchment area might cover a larger area where there is some spread between airports is some thinly populated areas.  Might it be dynamic in that sense? 

An example is North Platte, Nebraska (just to pick one), which is 3-4 hours from several larger airports:  Denver, Omaha, Cheyenne, and Lincoln.  IRL, those people would be travelling pretty far to fly.  Not much population in the town itself, but considering the swath of land covered, like droplets of rain, they can accumulate.  Or, perhaps that is already accounted for by some other factor?

Still, whatever it is, it will be an interesting dynamic to play under.