City based demand

[Monk Xion]

I have some issues with this... Especially in regards to cities with teo or more airports.

Went to open pdx-MDW, a real life route served at least daily.

Well i cant even fill a 737 sized plane daily. Meanwhile, ord-pdx has 500 pax a day.

It just seems weird that demand is not spread evenly between two major airports.

[Sami]

It just seems weird that demand is not spread evenly between two major airports.

Why should it be even? Makes absolutely no sense ..

I would rather fly to Paris than to Moscow for example. (Both are quite major airports...)

[Yarnam]

Why should it be even? Makes absolutely no sense ..

I would rather fly to Paris than to Moscow for example. (Both are quite major airports...)

But they aren't two airports in the same city which ord and mdw are.

[Sami]

Ah, didn't catch that but still the same idea applies, since I would bet most businessmen would rather travel from London City than Heathrow (if they could..). Call it differences in airport appeal & service. So far it's static and players cannot affect how the demand switches between airports but it's different story in the future.

But to get back to topic, even in the new planned systems, the two or more airports in the same city won't ever be identical in terms of demand.

[Sami]

Small progress report; I am working on this every now and then and bit by bit.

Still working on the base country data, but I believe it should be done now (a test is running for the next days). In other words the whole basis of everything is in the country's population and their purchasing power (GDP). This population is then in these smaller squares (for which separate data was collected by the community), and in order to make everything work in the long run from 1950 to 2030 that data needs to update itself and work properly.. It sounds easy but it isn't with all the countries merging and breaking up and so forth, but it should be done now.

Eventually the news and interface would also have economy predictions based on all this data, so your boffins will tell you how the economy (read: pax demand) will develop in Papua New Guinea next fiscal year .. So you can plan ahead.     (but this is something for later .. once this gdp/population base data works properly I will move on to the airport/square level things again)


= Just a small "dev's blog" type of post to let you know I am doing something even though it looks like I am not. 

[Sami]

Further "blogging" .. 

As already discussed in the past each airport will have a catchment radius around the airport, and this determines which cities (squares) that airport can serve to. The catchment area is a simple range ring around the airport and it is dynamic. The size of the ring will be based on the new airport size classes (more here: https://www.airwaysim.com/forum/index.php/topic,21347.msg268408.html#msg268408).

With the smaller airports it's 50 km, and can extend to up to 200 km from the airport (these figures can be adjusted later).

The calculation is based on the new airport size classes. When the game starts the airport size classifications will be so that the 'infra class' will be from 1-5 and corresponds the current airport size classes, and the 'traffic class' (1-10) will be based on the real-life size/stats of the airport (the highest 1% of all airports will be in class 10, the next 5% in class 9 and so forth). So for example LHR will be infra 5 and traffic 10. A bit smaller airport such as Stuttgart would be infra 5 and traffic 9 (or 8 ). As mentioned in the other thread the traffic class level lives/changes according to how players transport passengers from that airport and it can move freely (step by step, updates 2x yearly) between 1-10. And the infra class level can grow over time when airport expands (not modelled yet).

So initially when each game starts the max range for even the largest airports such as LHR will be about 100 km. The calculation formula is based on these two class levels so that the traffic class has 75% weight and infra class 25% (again may be changed if needed).

When the game starts the catchment area range is updated monthly, and it is based on the same values but creates a bit higher values, so a 5/10 airport would have about 180 km range then. The changes in the catchment range happen step by step, so if the previous was 100 and new calculated is 200 it would take 4 months to change since the max catchment range change per month would be +/-25km to avoid sudden big jumps.

Okay so there we have the circle radius of each airport. On top of that we add the data (in progress) of cross-border travel of citizens. As mentioned by default people will not cross borders, but with a separate manually coded list we can make that happen. If an airport is right next to the border, it's radius extends to the other country, but by default nobody will come from that other country; but once the settings are done it works too.  ...but this takes quite a bit of work!


This airport square catchment stuff is being tested at the moment in the background of a couple of live games since it needs to be made sure it works. On top of everything else the possible changes in geopolitical status of countries need to be considered, and I would suppose the easiest is just to trigger a hard reset type of calculation for those airport/countries involved?

[Sami]

One more update on the subject related to the previous post.. (This has been shown before, but just posting again since it's nearly finalized now and shortly in active testing.)

The catchment range of each airport (prev. post) translates into list of squares the airport can catch (these are the squares with the detailed data about business activity etc.). In other words the area and cities this airport serves.

This list of squares catched by each airport is updated on the background, once a month. As you see from previous post the catchment range of the airports can change, and these changes will in turn affect the number of squares the airport can catch. So the airport's "area of influence" is dynamic.

There are a few rough edges here since we are here moving the circular range ring into the square boxes. The system works it out so that naturally the box where the airport is located is catched fully. Any adjacent squares are catched only if large enough area of that range ring intersects with the area of that square. Example is attached; it's a small airport in the Solomon Islands that has a 50 km catchment range ring. While the range ring itself goes over 4 different squares it will actually catch only two of them (the two lower ones), since the ring isn't large enough over the two other squares.

The second pic shows the catchment area of LHR when it is at maximum, 200 km. (There's still a bit of work in progress about how the partially catched boxes are treated.)

The cross border travel settings are also checked here to determine what percentage of the people, if any, that airport can catch from a square from another country. Example pic #3 shows a sample dataset for one country; the 0.2 factor there means that pax from Iran for example have a 20% chance of going to fly from an airport located in Afghanistan - naturally given that such airport exists and catches the square in Iran. The cross border data settings is just a layer on top of everything else and it should be quite smart this way, after all data is collected there. Currently it's still hugely incomplete. (On top of these basic settings we could then later on even model temporary changes in these settings using the events module. ..but don't see that necessary; just a possibility.)


EDIT: The last (4th) pic shows the cross border thing in action. Using the previously discussed Austria/Slovakia example, I've set (as a test) that people from Austria can cross to Slovakia's airports. And here's how Bratislava would look like .. It has a radius of about 120 km and the two leftmost green boxes belong to Austria, and people from Vienna could then come to this airport too. (note; Czech and Hungary were not set for this example, so that's why they are empty) ... Collecting all this data is a BIG task though. But essential in making it work properly.


Anyway, once the squares it can catch have been figured out the system needs to calculate that airport's relative "score" for each of those squares. This means that how likely the passengers from that square are to use this particular airport. This is still work in progress but involves distance to the airport and other factors - so people who need to drive from very far away are for example less likely to come to this airport.

For now the tests are running to make sure the base data updates itself correctly and the catchment ranges/squares work as intended.

All this is most likely fully invisible to the end-user .. although that info could be presented to them too as "nice to know" stuff.


(Again the possible troublespots here too are the changes in geopolitical environment and airport relocations. Needs to be tested / coded later on.)



Also, minor changes in regards of previous post. The catchment radius will change more slowly when the game is new. When the game is less than 180 days old the max change of radius is +/-10 km per calculation round, and +/- 20 km when it's less than 365 days old and +/- 25 km per round after that. Catchment radius calculation is done once every month. ..so it takes a bit longer for a big airport to reach the max radius when a new game world starts, creating slower demand growth.


edit; added fourth pic.

[CarlBagot]

Looks great Sami!

Any idea how this will be implemented?Such as on only new game worlds?

[Sami]

(Again the possible troublespots here too are the changes in geopolitical environment and airport relocations. Needs to be tested / coded later on.)

These should be sorted now on a technical level for the airport catchment ranges / catched squares. There are the following airport opening / relocation / change events possible, and the system will react as follows:

* A new airport opens with no previous airport in the area
     - Nothing special involved here, apart from demand re-calculation triggered. (like it currently does too)
     - The new airport will start with a catchment range relevant to it's size, with the largest initial range in that case being about 100 km.

* A new airport opens and an old airport closes at the same time
     - The new airport will inherit the 'traffic size class' level from the old airport, but 'infra size class' will be initially fixed (the same as the current 'size class' value).
     - The new airport's catchment range will be in the 85%-115% range from what the previous airport was (depending on the size of the new airport).
     - And the catched squares for the new airport are recalculated based on the data above.
     - Demand re-calc triggers again for the new airport too. (like currently)

* A new airport opens while an old airport moves to be a secondary airport
     - Same as the previous step, with the exception that the old airport's size classes and catchment ranges will have a bigger drop (if such happens to that airport).

* Geopolitical changes such as country's breakup from an union
     - The events trigger the recalculation of the catchment ranges / catched squares of all airports in that country. Because this will then model the changes in any border crossing rules; ref. for example break up of the Soviets.
     - However demand is not recalculated but it instead shifts gradually towards the new values over the following months. This is to avoid too heavy sudden changes and calculations (= calculating a whole country in one go).


Again, all this is not very relevant but has to be done. The main thing in relation to this is now to collect all data on these border crossing possibilities, but that's something for later. It's been technically done and proved now.

Any idea how this will be implemented?Such as on only new game worlds?

Well it's hard to say really yet at this point.

(I mean technically it's not a big trouble, all this stuff shown so far is already running in all live games (for testing purposes) but the main point is that the demand figures will be 100% different in 100% of the routes .. so a big pain for players basically. Some gradual shift could work, but .. not sure)

[Sami]

One more picture for fun ..

Since it's much easier to figure out if everything works properly I built a small tool to visualize the airports, the squares they catch, and the catchment ranges. Here's how New Zealand looks like in a test game from 1950s that's been running a while.

Green = is catched by some airport, red = not.

This picture visualizes quite well one of the basic ideas of this new system in planning. Many airports overlap each others and with some expansion for example the Hamilton's airport can reach Auckland and drive some of the people there instead.

The user interface's airport info page would probably have a small additional data box about all this (but nothing like this pic), and it would tell the user 1) catchment range area, and 2) number of people catched by the airport. Just for reference on what kind of area that airport is expected to serve. However not sure if that's of any use since people from different squares will have different probabilities of coming to this particular airport.

Looks nice and so on, but doesn't do anything yet.

[Cardinal]

I'm curious about the "blank" areas in island nations like the NZ example above, or for example Japan or Cuba. If they fall outside the catchment area of every airport available to them, are they considered less likely to travel at all? (which kind of makes sense, actually)

And what happens if, for example, a region of northern Japan were to fall outside the catchment area of every Japanese airport but within the area of a Russian airport? They are obviously not going to swim to Yuzhno to fly to Los Angeles. A land border crossing is one thing, crossing the Soya Strait takes a bit more effort.  (I'm not suggesting northern Japan will fall into this category, just curious about the possibility.)

[Sami]

I'm curious about the "blank" areas in island nations like the NZ example above

A red square not catched by any airport is simply omitted. (a blank area with no red/green square is an unpopulated area and omitted)

...


Then on to some considerations / thoughts of the system ..

Item 1
As previously posted we now already have the airports tied to the squares, and that is fully dynamic how they react.

One thing to do there is to test/code the airport vs. square "score". In other words, if many airports share a square we need to distribute the pax from these squares to the airports. This is something that's highly debatable, since studies on this matter give different data.

Generally speaking the passengers would prefer the nearest airport, however studies show that while they do this they still actually prefer the alternative larger airport that would be farther away compared to a small airport nearby (given that all other variables remain the same), since they think that larger airport has better services and better chances of re-routing etc. in case of problems (however they also think that larger airport is more prone to delays). (ref. a study made in University of Leeds for example)  So there's no clear method for this, and just a matter of choosing some combination.

If we use a simple method it would be simply a function of distance, airport size and the number of routes perhaps. However one main issue here is that this doesn't take into account the destinations at all. Example: if we have square X from which 100 people wish to travel to square/airport Y, and square X is catched by two airports (A & B) which both are identical in terms of the "score" (for the sake of example). This means that how it would work, in the current plans, is that airport-to-airports demands A-Y and B-Y will be the same (50 pax; since the square related score for departing pax from square X is the same for both). But the problem is that if only route A-Y exists and is flown, then naturally all 100 passengers would move to A-Y and leave the B-Y demand as zero since there's no other option. All logical so far ..

Technically this poses a challenge since the square to square demand figures cannot be stored (too many). So perhaps, as discussed, one approach could be that first we calculate the baseline airport to airport values where each "airport vs. square score" is calculated purely on distance & airport size. Let's say 65% emphasis on distance and 35% of airport size class (50% traffic class / 50% infra class)  .. (though these numbers can be debated). This is the initial setting also when a game starts. Naturally if a square is catched only by 1 airport, then it would catch the entire population regardless of the distance to that airport since people don't have any other choice (and this is mainly in remote areas where there aren't too many airports).

And when game starts and routes start to appear, the system would then take into account the actual service and routes by players to shift this demand to make the people "smart". However this is a slow process and is not able to react immediately. If for example my airline flying B-Y will close down the route (while another airline is flying A-Y at the same time) it would take up to a game month for the people to move to the A-Y route instead. In an ideal system each individual passenger would be "smart" and switch right away but it's not possible. Another thing that needs to be measured here are the prices (etc.) of the available flights; and again the issue is the slow reaction (think of the B-Y airline dumping prices and gaining all the demand, and then raising them through the roof and he'd still have the whole demand available before the system is able to update the data).


Item 2
Passenger destinations.

So far we already know how many passengers will depart from each square in total (based solely on data of each square and country - no relation to airports in this part yet at all). A major thing to be worked on next are the destinations. So we need to know where the guys wish to fly from that square, and this is one of the most important parts here.

Most of the data needed for this on country and square level is collected now,  and this will be transformed into actual values.

One big change is that the Y/C/F class thing will be gone and it will be replaced with passenger types who have different purposes of travel. The main division is still three classes; leisure, business and VFR (visiting friends & relatives), with the addition of cargo (separate stuff). The three classes are roughly ~30% each, but there are huge differences in this for each country and airport, so again no reference material or study can fully give a proper baseline for this. Generally speaking though in rich countries the leisure level is higher and in poor countries it's more business-oriented flying. The VFR is then highly represented on routes where countries share close links, such as France and Algeria for example (immigrants..) - we already have a good database of these country relationships (but could be expanded even further).

Each of these pax types will have different preferences then. A leisure traveller cares just about the price and business traveller just about the schedule, if we exaggerate quite much. If we'd wish it to be even better each group could be divided into sub-groups (such as urgent business, non-urgent business etc.), but I think that's too complicated already. And according to the pax preferences you can then sell different products to them (seat quality etc).

So step 1 is to finalize the pax type calculation for each square; what kind of people depart from that location.

After this is done, the destinations need to be figured out. And naturally each pax type will have a different preference. Usually most leisure travel happens within own continent, about 80% of international tourists are from the same region (region=e.g. Europe) (ref: UNWTO Tourism Barometer), while business/VFR may be more of a mix of short/longhaul more. Though the proportion of longhaul leisure flights does increase once we go more into the future.

Each country will be given a countrywide values for industrial, business and tourism activity. The first two are most likely combinations of existing data (GDP related) since it's been impossible to find any suitable sources for that, and the tourism activity data has been just gathered (however it only takes into account international overnight tourist stays). All this data is then counted (just in the process of working with this) and on top of that is added the country-level data on the squares (that has been collected together). These combined values, added with some distance based data & info on country relations, will then give a single 'desirability score' for each square, for each passenger type separately.

..and that should be how we arrive to figures on where the people wish to go from each square. One possible problem spot is domestic air travel, especially in the small island nations.

Once all that is known this is then moved to airport level and it should be quite close to completion. Easier said than done though.

[CarlBagot]

Looking forward to it 


Just curious for Item 1, are you intending to show catchment demand instead of airport demand for route planning? Since if  airline Z is the only one flying at airport A if we continue with calculating route oversupply from the airport any other airline from airport B or C would never be able to start the route.

[dmoose42]

That's a good point.  The demand should reflect both the "current" demand and the "catchment demand".  If current demand is low, but catchment demand is high, I assume that charging lower fares will increase demand (PAX will switch the low fare airport) as well as increasing supply (more options).

As for the different PAX types, a couple questions: I assume that each type (leisure/business/etc) has different propensities for F/C/Y so not sure how the different classes will work.  How do you know how many seats to config in each class if you just have information on PAX type?  Retrofitting planes is not cheap.  I assume that implicit in this new approach is that by offering "cheap" C fares, some Y PAX will be able to move to C class, whereas right now the allocations are relatively fixed.

Second: How will connecting flights work versus direct flights?  Right now there is a huge advantage to direct flights.  However, in RL people (and leisure in particular) will connect to save some cash.  That's why in the US there are large hubs in places that don't generate nearly as many PAX as the traffic data suggest (ATL, etc.).  How will connecting versus direct be evaluated in this framework?  It seems to me that the settigns should be such that the hub and spoke method works well for lesiure PAX, but worse for business PAX so it depends on the population your airline is trying to target.  That would allow for more strategies to be employed by players.

Third: Does this mean that seat type (and other amenities which i assume will be added over time) will have a much larger impact on business PAX but nearly no impact for leisure PAX?  Again, I think this is a good chance allowign for more business models to be successful (similar to the recent changes in basing)

[CarlBagot]

Just wondering if cargo should have a larger catchment area than passengers. Looking at Europe, an Airline such as CargoLux only serves a few airports in the region as trucks  are the predominant short hop mode for cargo.

[Sami]

Status update

- Slow progress here too, working on this every now and then.

- Finished the first "technical demonstrator" of the basic calculation process which converts all this data and all these figures into plain and simple airport to airport demand figures, which is the desired end result. All of the possible variables and systems should be now incorported into the calculation, but many sub-functions/calculations are still missing (just giving static testing values), so the results are still nonsense, but the baseline concept is done now and it's a matter of finishing the functions that calculate the destinations for the demand for example.

- Cargo calculation possibility is also added on technical level; so there are four "travel classes" that the system calculates (cargo and the three passenger types mentioned earlier).

- In my last post I discussed (item 1) about how to distribute the passengers from a square to multiple airports. This is now done for the initial part of the game (= no routes, no airlines): If a square is catched by many airports they each get their share of the passengers departing from that square. The pax sharing "score" is calculated based on airport's distance from square center (50% weight), airport's traffic size class (35%) and airport's infra size class (15%); added with any settings about the probability of border crossings between nations (data pending). So at the start of the game there's a small bias towards the larger airports already to reflect a more real-life situation. Once the game starts going the score is then also relative to the routes/services offered by airlines, but this is a completely another matter to work on (it extends this basic calculation).

- So once each airport gets his share of departing passengers from each square it catches, the system then proceeds to calculate where the passengers want to go. This is still work in progress to get proper figures, but works already on dummy figures. This will take into account the data of each country and each square in the world, added with data about geopolitical relations and such (like I previously posted). To ease up the calculations this data is translated into airport-level data sets at this stage (airport to airport, instead of airport to squares) based on the properties of squares the airport catches. So we'll then calculate these together and it brings us to airport to airport demand, which is the baseline demand.

- This demand figure can be then worked in a similar manner like in current games (utilizing the current game's codesets); ie. making sure there are no sudden big changes etc, and after that it's stored and will be displayed to the users like in the current interface (apart from the different pax classes).


=> Short summary:
The work is still in progress with the first and fully static model of the system, and it's the first and most difficult thing overall here. Once it's done the minor part related to it is to make the demand shift between airports according to services the players offer. But the hardest part is to make this fully new data to generate proper and logical figures, as the new system does not have anything to do with the current/old airport based system and NO part of it or no data of it is being used in the new system.



Edit, addition:

In my previous message I discussed shortly about the "purpose of travel". This has been now finalized on square level. Like I posted it will have three passenger types, following the normal international standard of travel classification. Leisure travel, visiting friends and relatives and business travel. There's also a small "others" segment in many stats but it usually has a share of <3% so it's irrelevant.

In AWS each passenger departing from a square will have a purpose of travel. This will be a complete change to the current system and will allow us to build more dynamic service and ticketing system in the future (see my previous post).

The system now calculates how many of different pax types depart from each square, based on the details of that square. Simple system, and shortly stated, the richer area the higher the relative percentage of holiday travellers flying out from there. In poor areas the disposable income is smaller and majority of the travel will be business oriented.

And each of these three groups will then have their share of people who seek premium, and people who seek the best price etc. Consider holidaymakers .. Majority of them is after for the best price (will choose a cheap Y ticket) and only a small part is willing to pay a lot for good service. But for business travellers the share of people paying more for schedules/good services&seats is relatively much higher.

[Adam42185]

Any chance for adding connecting passengers?  That's likely another nightmarish coding endeavor, but would be cool if connecting pax (and possibly feeding alliance members via code share) were added to the game.  Someday in the future, perhaps!

[Sami]

Status update

Worked with this again for some time. The item under works is still the first and completely static version of the new system.

Otherwise it's all pretty much planned, but the issue of passenger destinations is still unsorted and the one giving most trouble. Since this new system will have absolutely nothing in common with the current/old system, also the destination calculation will be completely new. In other words the "where the people from this airport wish to fly" bit.

The basic data based on countries and the data squares provides the baseline but it seems that it will still give way too inaccurate results which is the problem here, and more data collection might be needed.

Let's take holiday travellers as an example (one of the three passenger types in the new model). We know already how many holiday travellers depart from each data square, and we know which airports "pick them up" for departure. => We know how many local people depart from each airport.  We also have a global data on tourism, so we know that in a global scale for example France is the number #1 tourist destination. And inside France we have the squares that give out the usual tourist destinations so basically we should able to divide the data into proper destinations.

However after working with this it seems that at least for this passenger group the square's 8 level (-6 to +6) system is not accurate enough, since for example Paris and Bordeaux area are both assigned a +6 on tourism, while in reality Paris would be higher. So basically this means that person's travel desire is the same to both of these places. And it's a bit worse effect in very large countries .. But it's not practical to start changing the square data anymore.

The second and perhaps the bigger issue is to make the destinations work in a logical way and somewhat similar to real life. If we take holiday travellers from Sweden as an example. Currently the system calculates that an airport in the Ukranian area would be their 5th largest destination. Why? Simply because #1) Ukraine is (or in real life "was") a large holiday destination, ranking 12th in the world in the number of foreign tourist visitors (lots of visitors in the Krim area for example), and #2) because that airport is relatively nearby Sweden (80% of holiday travels happen on the same continent, ~<1500 nm). But compared to real life it makes no sense at all, since Swedes don't visit there but fly to Spain for example. But with the current data the system cannot know of this at all. There's some country vs. country relation data, but only on a general level and not for all countries. So in order to make this work properly, each and every country would need dataset on these relations (sort of "where would the people like to go"). This data would then supplement this calculated data, and in this example for example assign a "0.1" factor for the Ukraine.  ...but getting all this data is rather difficult, but on the other hand a must.

However has to be noted that with these current (test) values and factors, the number #1 destination for those tourists Swedes is Palma de Mallorca, so that's rather accurate .. But as you see, without the detailed country relation data there will be a very large number of these oddball destinations.

Another issue is longhaul holiday travel, does not work at all yet, but I'm currently working on that.


This tourism data is probably the most difficult one to tune properly, business travels are easier.


So in summary. System works, but it's not giving very good values so far.

How to proceed: I'll look into tuning this destination thing a while more, but then I will probably move forward to the next thing and come back to this later (just so that the "full" system could be tested in action, and then just tuned later).

[[ATA] Sunbao]

Good with an update on it Sami, sounds to be long way to the goal line, but good with progress.
Sounds to be som rather big bumps still left on the way.

[gazzz0x2z]

That's a big job, it seems. Cultural fit is as important as tough to make.