City based demand

[slither360]

I completely agree.  Pax should not have airport preference - with only variable dictating some preference would be distance from the airport.  As far as distance, I am not sure how you can model that.  You can consider the demand of a square to be at the center of gravity of the squre (I mean rectangle).  And you have the exact location of all the airports already.  So that should really be the distance...

Primary preference should be the "quality" of the flight.  By quality, I mean everything that makes a flight more desirable than other.

Why squares?
I think a circle is the best idea, with the farthest distance of the zone being the same all around

[JumboShrimp]

While smaller airports have shorter taxi times and shorter ways from arriving to the taxi. I think pax should not prefer an airport or maybe it could be some random value (10% of people in NYC prefer JFK, 5% Newark, 5% LaGuardia), but this might be too detailed and unnecessary for most places of the world.
As long as AWS is an airline simulation and not an airport simulation, I'm fully on your side. Airport is airport for absolutely most pax.

I would say people in NYC - at least in Manhattan, I would say 90% prefer LGA, 10% JFK and 0% EWR.  Despite that, they fly out of JFK ~40%, LGA ~35%, EWR ~25% (I am guessing the percentages).  That's because the convenient flights to their destinations are from there.

So I may like LGA, because I can get there quickly, if there isn't a good flight from there to where I am going, I will fly from any airport.

That's just to reinforce the fact that the bottom line is, airport preference should be minimized, and quality of the flights should be emphesized...

[slither360]

I would say people in NYC - at least in Manhattan, I would say 90% prefer LGA, 10% JFK and 0% EWR.  Despite that, they fly out of JFK ~40%, LGA ~35%, EWR ~25% (I am guessing the percentages).  That's because the convenient flights to their destinations are from there.

So I may like LGA, because I can get there quickly, if there isn't a good flight from there to where I am going, I will fly from any airport.

That's just to reinforce the fact that the bottom line is, airport preference should be minimized, and quality of the flights should be emphesized...

Agreed, so the closer the airport is, the more likely you will want to fly from there. But this distance variable should not be the deciding factor, rather it should "gently guide" you toward which airport you would choose if the choices are similar.

[JumboShrimp]

Why squares?
I think a circle is the best idea, with the farthest distance of the zone being the same all around

Squares (or actually rectangle or a trapezoid to be precise) is because the new demand system will be - demand centric.  The world will be devided into these geometrical shapes and each one will provide certain amount of passenger demand (based on population density, wealth), who try to travel into other squares in the world.  Airports will just be dots on the map from where passengers can depart and land.  The players will be there to provide the means for passengers to get from their origin to destinations.

[brasidas422]

This all looks really cool and would add a lot. Regarding airport preference, I can give my personal insight from living in DC.  Reagan is the first choice for domestic flights since you can take the Metro there, but it is rarely the cheapest alternative. Baltimore and Dulles are the International routes, and Virginians hate the drive to Baltimore. But Baltimore usually has the best deals for overseas flights.

The So What? here is the following.

1. As in the NY example, price will trump most everything. An airport with more destinations and airlines will have better prices and draw people.

2. It may be useful to separate International versus local travel. That may be too much of a pain and not really applicable in Europe. In Tokyo they separate airports for this purpose.

[Zabuti]

What happens where there are going to be a handful of big airports together where I assume their catchments will cross?

Gatwick and Heathrow for example. Will pax prefer Heathrow? New York presents the same question.

Hello

Just a thought to avoid bugs or stupid issues later on. Does this feature fixing needs to be in line the future pax connectivity feature ?

For pax going from NYC to LON, they don't mind leaving from Guardia or EWR, and arriving at LHR ot GAT (in AWS, which is fine to me). but when it comes to link connecting flights, things could begin to move.

IRL, pax prefer an airport based on the connecting flights there. This means that they really don't care if they're landing at Heathrow or Gatewick, if the departing flight is from the same airport.

This is just a thought, but I believe we need to look long-term, so that sami does not have to redo all the work when he prepares pax connections. I'm just asking the question to prevent further pb.

Kind regards

Flobacca

[JumboShrimp]

Hello

Just a thought to avoid bugs or stupid issues later on. Does this feature fixing needs to be in line the future pax connectivity feature ?

For pax going from NYC to LON, they don't mind leaving from Guardia or EWR, and arriving at LHR ot GAT (in AWS, which is fine to me). but when it comes to link connecting flights, things could begin to move.

IRL, pax prefer an airport based on the connecting flights there. This means that they really don't care if they're landing at Heathrow or Gatewick, if the departing flight is from the same airport.

This is just a thought, but I believe we need to look long-term, so that sami does not have to redo all the work when he prepares pax connections. I'm just asking the question to prevent further pb.

Kind regards

Flobacca

I think passenger connections and city based demand will be part of the same version release.

[Jona L.]

For pax going from NYC to LON, they don't mind leaving from Guardia or EWR, and arriving at LHR ot GAT (in AWS, which is fine to me).

I think they do mind about LHR or GAT, as the latter is no airport thus the resulr would be a pretty crappy landing I think you refer to LGW

cheers,
Jona L.

[theguv316]

Some very good ideas from people but im still trying to get my head around a few things
I live in Dublin Ireland and base myself there most of the time LHR has a huge demand
from dublin but alot of it would be onward travel to the states or asia/middle east so with
the city based demand could it be a case where the middle man in this case LHR gets cut
out ...i have been to the states about 10 times once thru LHR and the rest direct pax don't
like connecting flight esp ones that travel 2hr in the wrong direction.   
eg: for my wedding this year the flights to FLL were €700-800 thru JFK and €400 thru LHR to MIA
out of 20 guests who were scattered over 2 days no one picked the LHR route as the hassle we felt
was 2 much even with up-to  €400 savings

I see the connecting flights as a great idea esp for the middle to large airports as we could compete
with the larger airports when price comes into play alot more than it does right now 

I would love to run a Ryanair/southwest/air asia type airline

i cant wait for it to start but i'd hate to be Sami as alot of work to be done 

[Shubinine]

But maybe he can ask us to collect data from specific countries. There's enough of us here that i think would be willing to help collect data such as population in some areas and stuff like that...

[Dave4468]

But maybe he can ask us to collect data from specific countries. There's enough of us here that i think would be willing to help collect data such as population in some areas and stuff like that...

I've thought that, maybe opening it out to the community could get it done much quicker. I for one would be happy to find populations of regions. I for one would be happy to sit for a while and find out the population density and location of Wales. I'm sure there are people willing to do the same for most regions of the world.

[Sami]

The data of regions will be community collected. I will however have to first collect data of few areas myself to test the system and build it etc. But there is no need to find any population data or such, if you browse backwards all that has been done and I have already discussed about what is actually needed.

However have not started this yet; plan is to finish the few things in v.1.3, then I have to build country related economics (ie. country specific changes to economic climate and air travel .. since 1950) and after that to the demand things.

(And for now nothing new is required to this thread as it's pretty well covered for now, and seems that the ideas are just looping around the same things what has been talked in this thread earlier.)

[Sami]

City/Population database consists of:
* ~3600 'states' / 'regions'
* ~110000 'cities' or 'places'
* ~15500 'squares' (main unit of calculation, 1x1 lat/lon)

Basically I have now arranged all the base data, and next step is to build a simple data editor for it, and for me to insert some sample data and start thinking and building of the actual mechanics of the system.

This base data consists of areas divided per country, cities etc, but no information about possible passenger locations - so data collection for the 15500 data squares will begin later. The cities & states database is for additional data for now, but most likely will not be used in actual system which will be based on the squares alone (since calculating destinations from 15500 squares vs. 110000 cities is easier).

And still a disclaimer: I would still classify this as an experimental feature.

(this is just a small staus report, no need to post further suggestions to this thread)

[LemonButt]

City/Population database consists of:
* ~3600 'states' / 'regions'
* ~110000 'cities' or 'places'
* ~15500 'squares' (main unit of calculation, 1x1 lat/lon)

Basically I have now arranged all the base data, and next step is to build a simple data editor for it, and for me to insert some sample data and start thinking and building of the actual mechanics of the system.

This base data consists of areas divided per country, cities etc, but no information about possible passenger locations - so data collection for the 15500 data squares will begin later. The cities & states database is for additional data for now, but most likely will not be used in actual system which will be based on the squares alone (since calculating destinations from 15500 squares vs. 110000 cities is easier).

And still a disclaimer: I would still classify this as an experimental feature.

(this is just a small staus report, no need to post further suggestions to this thread)

It seems that you should be able to calculate all of these values rather easily using existing data.  A few factors that come to mind is airport country (GDP per capita to determine wealth), airport isolation (based on number of airports within x distance--areas with more traffic tend to have more airports i.e. Chicago, New York, Los Angeles), and passenger basis (how many people live within a radius of x miles of the airport using the population data).  A system of multiplying all of these together using indexed values should provide at least the number of passengers/year that would be served locally.  Then you could determine route demand by comparing the two airports: people in rich countries tend to fly to other rich countries, same goes with poor countries.  You're not going to have too many people flying from London to Zimbabwe.  Airports too close together have low demand as do airports very far apart.  Airports in big cities will have people flying to other big cities for business.

In the end, it seems that airports should be assigned values based on wealth, relative isolation, and population basis using the defined squares.  After that, the rest of the calculations should be purely based on the resulting airport-to-airport values.

[JumboShrimp]

I think the airports are going to be there just as a place to hop on the plane, nothing really inherent in the airports themselves.  The square geographical areas determine the local population.  The square also determines the country, and the country determines GDP / person for that country.  Population * GDP / person = aggregate demand of the square.  Then going from these aggregate demands of squares (and some modifiers) square to square demand would be determined...

[ICEcoldair881]

I would like to point out the city-based demand for Toronto, because I find Toronto's City Center Airport (now renamed to Billy Bishop Toronto City Center Airport) to be GROSSLY underserved and has FAR too low demand. The fact that you can get right downtown using CYTZ is a BIG plus to many travellers going to nearby destinations (Northeastern seaboard) while those who are flying further would obviously fly from CYYZ. Another airport is CYHM, in Hamilton, which is a big draw for people living outside the main Greater Toronto Area. I know that my cousins fly from CYHM, and they live in Stratford. My Grandmother, who lives in Burlington favours CYHM over CYYZ because of the 20 minutes driver versus the 45 minute drive to CYYZ. Those two should really be implemented because of their locations, but the demand to CYYZ should also still remain relatively the same because the amount of people flying through CYTZ and CYHM is not entirely huge, however if airlines increase flights from those airports the demand would for sure increase, which is when the demand in CYYZ would start to fall. It's up to you how you want to model that, Sami. 

Cheers,
ICEcold

[Sami]

What do you think about following ...

The airports have the threefold classification in demand today: domestic, longhaul, shorthaul. Should this be kept as a baseline in the future too?

Meaning that you cannot fly longhaul from an airport that has in real life only 100% domestic demand for example? I have done some number crunching and this would reduce the need of calculations (number of possible route pairs) quite heavily. But on the other hand it may limit the whole idea of the free demand too much - when you for example cannot start to fly domestic services to some airport that in real life gets only for example shorthaul intl. traffic.

So perhaps the three-level classification could be expanded somehow to provide a bit of user freedom .. but how to do that maintaining the realism and without needing to manually go through the airport data.

...
(with the present dom/intl/long traffic allocation in place there are about 1 000 000 different airport pair route combination possibilities that techniclly can have some demand)

[vitongwangki]

What do you think about following ...

The airports have the threefold classification in demand today: domestic, longhaul, shorthaul. Should this be kept as a baseline in the future too?

Meaning that you cannot fly longhaul from an airport that has in real life only 100% domestic demand for example? I have done some number crunching and this would reduce the need of calculations (number of possible route pairs) quite heavily. But on the other hand it may limit the whole idea of the free demand too much - when you for example cannot start to fly domestic services to some airport that in real life gets only for example shorthaul intl. traffic.

...

If this algorithm could make it done, I could support this use the following example.

Tokyo Haneda vs Narita,
New York La Guardia vs JFK,
Sao Paulo Congonhas vs Guarulhos,
Milano Linate vs Malpensa,

Some of the airports are able to take up long haul demand but it doesn't because the authority not allowed. I guess if the algorithm set like this, it is still acceptable.

[alexgv1]

Or another idea is to change the pie chart to display the percentage of flights that AWS airlines fly from that airport rather than the real life airlines. Therefore this value changes as new routes are added. e.g. in 1980 Heathrow could be 20% long haul but with the new slots by 2000 it could be 39% long haul as the player has used the slots to open more longhaul.

Hope I've made myself clear.

[JumboShrimp]

What do you think about following ...

The airports have the threefold classification in demand today: domestic, longhaul, shorthaul. Should this be kept as a baseline in the future too?

Meaning that you cannot fly longhaul from an airport that has in real life only 100% domestic demand for example? I have done some number crunching and this would reduce the need of calculations (number of possible route pairs) quite heavily. But on the other hand it may limit the whole idea of the free demand too much - when you for example cannot start to fly domestic services to some airport that in real life gets only for example shorthaul intl. traffic.

So perhaps the three-level classification could be expanded somehow to provide a bit of user freedom .. but how to do that maintaining the realism and without needing to manually go through the airport data.

...
(with the present dom/intl/long traffic allocation in place there are about 1 000 000 different airport pair route combination possibilities that techniclly can have some demand)

When speaking of airports, airport needs to have some facilities for international flights, such as customs office, passport/visa/immigration control facility.  If the airport does not have it, no international flights should be allowed.

As far as international airports not allowed domestic flights - my guess is that there are only handful of those, and could be flagged manually.  But it would put some airports at a disadvantage (for example Narita).  If a pax wants to fly to a small Japanese city, there would be no way to transfer at NRT (where in real life, a passenger could take a train from NRT to HND).

As far as domestic only airports, if I take one - Savannah, Georgia (SAV), there are no international flights, but the demand square around SAV would have some international demand.  So as far as the cominations, there would really be a huge number of combinations from square to square.  Instead of that, the square to square demand could be a formula based on some stored parameters of the demand square, and would not have to be coded (or stored) as a set of combinations.

So if a square around SAV has certain demand magnitude, and LHR has a demand magniture, the system would on the fly calculate the SAV-LHR demand.

As far as combinations to consider, the system should perhaps calculate only the ones that are "connected" by scheduled flights.