City based demand

[brique]

There will be some oddities, I'm sure, like London City : all that near-by demand but absolutely no way to expand (in RL) : I believe a Canadian city has a centrally located airport with similar issues : I suppose Gibraltar would also be in the same category : I do wonder how that will be handled as in, will there be any 'hard-coded caps' to potential expansion given RL geographical limitations?

[mavi]

Well there be anything done to take into account political restrictions on airports.  In particular I am thinking about the DCA/LGA perimeter restrictions.  Without the perimeter restrictions, demand should be much, much greater at these airports.

[exchlbg]

I´m sure that problems like these are considered and the reason why development and implementation take time.

[Dasha]

Sami is a bit like Blizzard....

You always think the next World of Warcraft expansion sucks by looking at it... but when you play it, it's awesome. AWS is like that

[xyeahtony]

So whats the news on demand updates? A simple wikipedia search shows the world's busiest air routes.

http://en.wikipedia.org/wiki/World's_busiest_passenger_air_routes

Many of these high-density routes are not modeled in AWS at all.

[LemonButt]

So whats the news on demand updates? A simple wikipedia search shows the world's busiest air routes.

http://en.wikipedia.org/wiki/World's_busiest_passenger_air_routes

Many of these high-density routes are not modeled in AWS at all.

The data collection is 85.16% done.  Here is what's left:

Afghanistan (id: 157)   20 / 68 boxes done
Central African Republic (id: 7)   0 / 58 boxes done
China (id: 168)   357 / 961 boxes done
Congo (Democratic Republic) (id: 11)   103 / 210 boxes done
Ethiopia (id: 14)   0 / 99 boxes done
Iran (id: 175)   0 / 181 boxes done
Mexico (id: 385)   107 / 224 boxes done
Mozambique (id: 32)   0 / 76 boxes done
Myanmar (id: 165)   0 / 73 boxes done
Nigeria (id: 35)   0 / 95 boxes done
Pakistan (id: 193)   0 / 100 boxes done
Peru (id: 528)   16 / 130 boxes done
Somalia (id: 44)   0 / 72 boxes done
South Africa (id: 45)   0 / 133 boxes done
Thailand (id: 204)   0 / 65 boxes done
Turkmenistan (id: 207)   0 / 63 boxes done
Uzbekistan (id: 208)   0 / 61 boxes done
Zambia (id: 55)   0 / 74 boxes done

[Sami]

Just a few quick previews about the data that's behind the system. (Partly previewed before already.)

The GDP and Population data for the country are one of the important baselines for this feature. Due to the unique feature that we can use any year from 1950 onwards there's quite a bit of data to be digged .. But now finally the GDP and population data changes for all countries have been done.

This means that via GDP we can have country-level economics and things like local recessions or boom cycles, it's not global anymore. Like here the break-up of Soviet Union, causing a huge economic meltdown locally. GDP in turn translates to air travel demand via a series of calculations, and it's widely accepted as one important metric in the travel demand.

With population data we can achieve population growth over time, or like picture here a decline when local people move elsewhere looking for jobs. The countrywide population in turn translates to the data square ("city") population.

Our source data did not span prior to 1970s so it's simply based on averages (visible on the graphs; taken from admin area), but in actual games this would have a bit of randomization then so it's not just flat/level there.

There would be two methods, the historical approach or the dynamic approach. So far the historical data is now done, but there will be also plans to make a completely dynamic global and local economy system. In other words at the start of the game world each country would start at their respective real-world level but any developments from there onwards would be fully dynamic / random. But for now the first plan is to make it work on an historical data level first.

The background calculation of these population and GDP changes will be implemented to some running game worlds too, to test the system. It will be completely invisible to the users.


Just for reference, here's a comparison to wiki's image of the population development of this country: http://en.wikipedia.org/wiki/File:Population_of_Estonia_%281970-2010%29.png    They are quite close, but due to different data sources etc, they do not always match 100% (in 1970 the difference is about 80 000 people). Same for the GDP. But the idea here is to do the trends and such historical events and add the changes to country-based level instead of global level, and such small differences do not have any actual difference.


(this all is just one very small part of the data involved, but one step forward ... please also note that I am working on this feature only occasionally, there are a lot of other things in my list too, so that's why it may seem that nothing happens .. which has been the fact since I haven't worked with it .. ..and ignore also the title of the last chart, it's wrong there ... just previews)

[Sami]

Some more number crunching and so forth .. Just to show some background process, and that work is ongoing. There's a huge amount of data and variations to be considered, and the number of countries and their particularities add to the complexity but I am trying to keep it as simple as possible.

In the world, globally, there were about 3 billion air passengers (3 000 000 000) in a single year (2013). The new AWS demand numbers for the same period will be rather accurate, the current settings are counting about 3.15 billion passengers (read: potential demand) for the same period .. (in actual games this number would be perhaps a tad higher though for game play purposes, since all "potential demand" is not reachable always.) I am currently still processing the country-level passenger travel and basic data, but will dig in to the local travel soon. The country level data consists of country's economic variables and other things, for example a sole island country will increase the travel potential FROM that country by air.

Here are two nice images, not in any way related to the game interface but to show a bit of the data..

First image, total number of trips taken from a country per day.

Second image, number of trips each citizen takes on average in a year per country.

Pics are quite large and labels hard to read, and data is not necessarily from final code - just one example  .. but will give you the idea that with these settings China is the second busiest air market in the world (total trips per day), but still only about 0.2 Chinese people fly every year... Compared to every US citizen making >1.5 trips yearly. So we'd be able to model quite nicely the massive future growth of air markets in Asia, just like in real life here, just by altering the country's preferences and setting as time goes by (= Chinese people become richer -> they will fly more. Where as American people getting richer wouldn't really increase their travel potential that much anymore). And as you see from the previous post, this country's economy data is already finished.

Next, I am moving to create on the relations between countries and the direction of travel of all these people.. Did you know for example that number #1 destination for tourists is France? (if we measure number of tourist arrivals vs. countries) ..I didn't.

[LemonButt]

Graphs would be a lot more interesting if you didn't use a logarithmic scale

[gazzz0x2z]

I guess cultural proximity is taken in account? Like Germany & Turkey, or France & Algeria?

[LemonButt]

I guess cultural proximity is taken in account? Like Germany & Turkey, or France & Algeria?

I'm on the data collection team.  Attached are the factors for determining demand.

[Sami]

I guess cultural proximity is taken in account? Like Germany & Turkey, or France & Algeria?

That's already modelled in current games, though partly incomplete perhaps.

The pic in previous post is not related to this, it's for local data/demand.

[gazzz0x2z]

That's already modelled in current games, though partly incomplete perhaps.

Cool.

The pic in previous post is not related to this, it's for local data/demand.

That's awesome. Potential will be probably wonderful. 

[Sami]

Pax border crossings between countries, talked earlier..

Will make it as simple as possible, but still should be very realistic..

By default pax will NOT cross a border from their country to an airport in another country. However there would be an exception list to this, where we'll have a list of countries from which pax can arrive by land/sea border crossing to the airports of this particular country. It has also a date and probability for the crossings.

So for example from Soviet Union/Russia to Finland there would be no data, until about year 2000 which after the crossing probability would be let's say 0.3 (since they need to have a visa, borders have queues etc.). But from Finland to Sweden this is always 1.0 as there have been no border requirements for ages.

And in similar manner from Netherlands to Belgium this would be always 1.0 since the countries have been always closely linked. Perhaps before Eu/schengen it could be a tad less like 0.8.

Requires a bit of manual work to go through the world, but I figures this would be the least complex way to make it properly. This nicely takes into account any geographical issues between the countries too then. For example Iceland would have no data, no work required, since it is an isolated island.

(this whole issue is just a sidetrack of the main system, but nice and important for realism)

[Sami]

Some stats / data, for my later usage / for info:

There are 15574 squares in the global city data system - these are the areas with land (ocean areas have been excluded). 14663 has data at this point (94.15%) - this is the data collection project that has been ongoing for a long time now.

Of these completed (14663) squares, 9234 are not unpopulated (= not desert or anything), and of these 8474 are within the max catchment radius (250 km) of any airport currently in the database (2800 airports). So basically 8474 data squares (or about ~8700 once all remaining data is inputted) is the max number of data squares we'd process - but this is theoretical as it requires each airport to be at the maximum level & maximum catchment range.

If we use the minimum catchment range, 50 km, on all airports (not realistic or ever happening) the squares catched is reduced to only 2974 (~3200 when all data is entered). The minimum catchment range is for small airports and it's most probable that most airports will use this minimum range.

If we use the current database airport size classes and static catchment radiuses from there (size 1 = 50km, 2=100, 3=150, 4=200, 5=250; these are on the high side for large stations especially, not final by any means and not static with such jumps) then we'd end up with a total of 6597 (~7000 with all data) catched squares to calculate with.

So square-to-square complete data would be 49 000 000 lines which is too much to store naturally. If we however eliminate all lines with 0 demand (even 0 via connection) the figure would probably go down quite much, and will work on this shortly to see what ballpark that would be. Since the question is still should the system be simplified to airport level (based on the square data) instead of the square-to-square level that allows a better system; but is it worth it then. It's hasn't been yet decided since I haven't been able to determine the amount of data since the data collection hasn't been ready, but now it's almost done so I can proceed with this path decision.


The max number of active airports (= that have flights to them) in all game worlds currently is in GW#1 where a total of 1980 airports has traffic to them. The distribution between apt.sizes is:
1   50
2   1070
3   383
4   235
5   242

And the distribution of the airports in the database is as follows:
1    393
2    1582
3    419
4    254
5    269



edit 30.6.:

Final figures, 15557 completed data squares, of those 10226 have population, and of those 9263 are catched by some airport at max 250 km range, or 7181 catched with the static 50-250 km ranges based on apt size class.

[JumboShrimp]

So square-to-square complete data would be 49 000 000 lines which is too much to store naturally. If we however eliminate all lines with 0 demand (even 0 via connection) the figure would probably go down quite much, and will work on this shortly to see what ballpark that would be. Since the question is still should the system be simplified to airport level (based on the square data) instead of the square-to-square level that allows a better system; but is it worth it then. It's hasn't been yet decided since I haven't been able to determine the amount of data since the data collection hasn't been ready, but now it's almost done so I can proceed with this path decision.

IMO, the shortest path to getting the new demand system up and running is to keep everything having to do with airport to airport demand, how it get processed / allocated (to flights) unchanged.

I am assuming that the system already stores airport to airport demand (as opposed to calculating it on the fly).  If the system already does have a table with all airport to airport combinations, all that would change is how this data gets populated (initially), and how it would continuously shift.

So there would be a new process to make it happen.  This process would be continuously updating airport to airport demand based on square to square demand and availability of flights.  This process would be asynchronous, so it would not break anything, it would not affect player interactions or turn processing.

To populate the database initially, the steps would be very simple:
- Let's say we have squares X and Y.  From the global data that the system has, we know the demand between X and Y.
- If square X is catchment area of airports A, B, C, square Y is in catchment area of airports D and E, we have 6 pairs: AD, AE, BD, BE, CD, CE, and the system would just allocate the demand to these airport pairs proportionally.
- so this would be the initial data for the system, and for informational purposes of the player, this value (updated by the process below as the population, GDP, catchment areas shift) could be stored as a "Nominal" demand.

Then, there would be a process running asynchronously, independent of turn processing (could be a game day, several game days, up to a game month to complete, depending on availability of computer resources), and this process would have following goals:
- allocate X-Y demand to airport pairs AD, AE, BD, BE, CD, CE based on:
  a) availability of direct flights
  b) availability of indirect (connecting) flights between AD, AE, BD, BE, CD, CE (potentially later)
  c) quality and competition of these flights
  e) rate of successful completion of flights between AD, AE, BD, BE, CD, CE
- Based on the ranking above, the system would split the X-Y demand.  How to do this without storing square to square data is the tricky part.  Let's say the old split was 16.67% for each pair, the new one is 50%, 25%, 25%, 0, 0, 0.  How do we add this since we don't know what to subtract (the old allocation)?  Couple of options:
a) if we know that the whole cycle (to process all the square combinations) takes 10 days, then every day, we just subtract 10% of AD, AE etc. demand, and the square to square allocation process will replenish it with new values (we would not subtract, just add, the 10% reduction would take care of subtraction).  Or, to slow down the changes, make them very gradual, if the system runs 10 days, maybe only 5% of demand would be subtracted per day, and only 1/2 of X-Y demand would be added (or however fast we want the changes / adjustments to happen.
b) if the process could complete in 1 day (may be optimistic) a lot of new possibilities would open up.  We could then store a pent-up demand on the airport pair combination record, monitor trip completion and accommodate less than daily flights.

Doing the square to square allocation this way would conserve system resources, yet it would be very accurate, fine grained.  Let's say if there is a flight from Newark to Lisbon, and there is none from JFK, or any other airport nearby, Manhattan demand to Lisbon would gradually shift to Newark.

So again, this change would only minimally impact the user interface, turn processing, pax allocation (of demand already pinned to the airport pairs).  The only changes to UI I would foresee is adding additional demand graph (independent of the 7 day graph that would stay unchanged, based on the "Current" demand).  This new graph would be horizontal bar graph, and for now have 3 values, and these values would be just weekly averages:
- Maximum demand - yeah, another set of values, similar to nominal, but assuming all the squares in the catchment area were allocated to the airport pair we are looking at
- Nominal demand - described above, where square to square demand is allocated proportionally
- Current demand - based on how the demand was actually allocated to airport pairs by the process described above
- Later on, other value, having to do with pax connectivity can be added.

After this is done, we could move on to pax connectivity, which again would be a discrete step.  In relation to square to square demand, it would only affect the evaluation of AD, AE, BD, BE, CD, CE airport pairs with the addition of indirect flights.  The initial system with only the direct flights would assign these airport pairs rating.  Addition of connecting flights would still produce the same result: rating of the airport pairs, but the rating process would be more comprehensive, evaluate more of the ways pax can get between 2 airports.

My guess is that connecting flights will take up a lot more computing resources, another reason to conserve them in square to square demand, which would run at its own pace, and only very gradually shift the demand.

[Jung Dong-geon]

Shouldn't airport infrastructure and service factors be included as a airport preference factor as well?

In Tokyo, HND has more runways(and about the same length as) than NRT, but is poorly equipped for LR Intl. flts because its intl. terminal is quite small.

In Seoul, GMP has a much smaller terminal, but has runways about the same length as ICN...

Shanghai also has a similar issue, so does Osaka.

In London, Stansted would be able to accomodate even a B748 pax aircraft, but due to lack of infrastructure, this wouldm't be possible in RW.

Also, even though(as stated by sami before) passengers usually choose airlines before airports, airport capacity(or airport runway capacity) large enough to accomodate multiple LR Intl. flights per hour doesn't guarantee that there will be enough number of gates to accomodate that many number of flights, or that there will be appropriate services ready at the airport for such flights, and passengers don't usually like cramped/packed terminal buildings and climbing airstairs in cold/hot weather.

If these factors are to be implemented properly, I think airport service/infrastructure factor is a must have function for a city based approach to work properly.
Ignoring these factors could lead to wildly inappropriate results...

[NovemberCharlie]

Shouldn't airport infrastructure and service factors be included as a airport preference factor as well?

In Tokyo, HND has more runways(and about the same length as) than NRT, but is poorly equipped for LR Intl. flts because its intl. terminal is quite small.

In Seoul, GMP has a much smaller terminal, but has runways about the same length as ICN...

Shanghai also has a similar issue, so does Osaka.

In London, Stansted would be able to accomodate even a B748 pax aircraft, but due to lack of infrastructure, this wouldm't be possible in RW.

Also, even though(as stated by sami before) passengers usually choose airlines before airports, airport capacity(or airport runway capacity) large enough to accomodate multiple LR Intl. flights per hour doesn't guarantee that there will be enough number of gates to accomodate that many number of flights, or that there will be appropriate services ready at the airport for such flights, and passengers don't usually like cramped/packed terminal buildings and climbing airstairs in cold/hot weather.

If these factors are to be implemented properly, I think airport service/infrastructure factor is a must have function for a city based approach to work properly.
Ignoring these factors could lead to wildly inappropriate results...

LHR for example only has superb international facilities because BA is based there. If at some point in the 50s they decided to move their HQ to Gatwick, then Gatwick would have had better facilities.
If I understand CBD correct, we eliminate things that airlines set on in the past. ATL too would not have been nearly as big if it weren't for Delta (I'd actually say international demand would be fairly low actually)...
In this way we can take the demand from a larger catchment area and use it for JFK, EWR, LGA and whatever else New York has...

Cheers

NC

[Jung Dong-geon]

I of course understand the intention of CBD, but the thing is, most Asian airports only have government run terminals, and LR intl. flights are actually forbidden at some secondary airports in order to force LR pax demand on the primary airport.

In the case of KATL or EGLL, CBD without any infrastructure or airport service factors included would work perfectly, albeit rather off from real world values due to the lack of connecting passengers.

BUT, in the case of RJAA, what if even after RJAA opened, airlines decided to continue Long Hauls out of RJTT? In that case, RJAA would be rendered completely useless, and become a complete waste of Japanese government funds.

Such would also be the case for Shanghai, and also to a lesser extent, Seoul.
Don't assume that airports are all run the same way around the world.
The ways that airports are run are vastly different between EU/US and Asian countries.

Considering all this, my suggestion seems a bit inappropriate considering why CBD was first drafted.

Another suggestion - implementing infrastructure/service index seems a must for me.
But considering the reason why CBD system was made, perhaps we could allow airlines to build terminals to increase infrastructure index, and create lounges to increase service index.
Actual real world JFK is run in this way, and even though I don't exactly know how real world LGW or ATL is run, I think we can all be certain that at least DL and BA both invested a lot of fund in making these airports better, shaping these airports. DL's tech center at ATL would also have cost them a fortune!
I am certain that unless these factors are considered, implementation of CBD could lead to surprising, and perhaps seriously unrealistic results at many Asian cities, making gameplay in Asia a terrible experience.

Cheers, Murphy from RK

[Infinity]

BUT, in the case of RJAA, what if even after RJAA opened, airlines decided to continue Long Hauls out of RJTT? In that case, RJAA would be rendered completely useless, and become a complete waste of Japanese government funds.

No.

The opening of Narita increases the airport capacity in the Tokyo area by a huge amount. As a single airline can quite easily slot control Haneda, the opening of Narita opens the city to a lot more competition.
This is from a game perspective. From a would-be government perspective, this added competition would be greatly beneficial to the consumers in the Tokyo area, as the incumbent airline could impose high prices on them and added airport capacity would help solve this.