City based demand

[LemonButt]

The problem with setting direct and connecting flight pricing is you don't know where pax will be connecting to.  Setting a price for JFK-ORD-LAX is nice and all, but what about JFK-ORD-every other airport you fly to.  The number of prices you have to set grows by a factorial with every flight you create.  The simplest when it comes to coding and player management IMO is a simple connecting flight discount where you add the two leg prices together and discount by a % set by the player in their pricing settings.

I disagree on trip time is the only thing that matters and distance is irrelevant.  If you have a 12 hour trip which involves two 4 hour flights with a 4 hour layover versus two 5.5 hour flights with a 1 hour layover I'm going to pick the former because I want to spend as little time in a cramped airplane as possible (time in an aircraft is a function of distance traveled).  Thus, the geographic information does matter.  The more extreme the angle the legs of the connecting flights create, the more time you spend in an airplane.  The Albany-NYC-LAX example forms an extreme angle and should be penalized because you are travelling west and the first step is to fly east (southeast).  All else being equal, a connection in Chicago should get preference because the distance traveled and presumably flight time will be less.  Perhaps short hops would have less of a penalty, but nonetheless it's better to fly in the general direction of your destination versus the direct opposite.  You can fly CLT-JFK-MIA on jetBlue, but it doesn't make much sense.  I'm not saying overall trip time isn't a factor, but I would rank time in an airplane/distance as a bigger factor as airport time > airplane time.

IRL you can see the angle concept is true.  The largest international airports by pax are on the coasts--LAX, JFK, MIA.  The largest domestic airports by pax are in the middle--ATL, DFW, DEN.  Those large domestics have a fair amount of international traffic just by virtue of the large number of domestic pax.

[Frederik]

Suggestions with regard to the Handling of Connection flights:
1. Pricing: the baseline pricing is based on the non stop distance between the departure and arrival points (much as it is done today). The revenue is then allocated ex post between the flights (and/or carriers) on a prorating basis. (As is done in RL). Rather than today's free market prices this would be closer to the way prices were set in the IATA days - old fashioned may be must much simpler to determine and manage (at least for the default values)
2. Routing and pax distribution: total travel elapsed time is the main parameter. Passengers will a priori chose the shortest travel time and only fall back on more time consuming alternatives if there is a price advantage. Different types of passengers F/C/Y value their time differently and prices per hour could be set for each type of passengers in their choice algorithm. The price and time elasticity es could therefore be merged in a single demand curve/equation
3. Connecting times: each airport should have its own minimum connecting times based on its size and also whether the connection is domestic only/domestic-international/ or international. (Security and immigration considerations make these different)

Ps elapsed time would also be a good parameter to allocate demand between aircraft with different speeds (props/jets/Concorde) and replace the current penalty for flights with a technical stop.

PS2: how many stopovers should be included (1,2,3?) may be 1 for flights less than 1000 nm, 2 less than 3000nm 3 for more?

[JumboShrimp]

Demand would also have a big impact on how many possible flights are stored. If demand is only 5 pax per day, then storing 100s of flight combinations is unnecessary. If demand is 5000 per day, then storing more combinations is a good idea

Yeah, that's what I posted in one of my previous posts.  That the number of combination system would store would depend on pax demand.  More demand, more combinations stored.

And to continuously refine this list, the system would keep track of how many pax used each one of the flight combos, and periodically dump the worst ones (fewest pax carried) and replace them with other combos from the list of possibilities.

[CarlBagot]

How about total flight time (With transfer) instead of angle? That and what we currently have in frequency, price and aircraft. Pax care more about that  and this would be more appropriate in a regional feeder sense as what was mentioned in the Albany - NYC- LAX example.

[JumboShrimp]

Suggestions with regard to the Handling of Connection flights:
1. Pricing: the baseline pricing is based on the non stop distance between the departure and arrival points (much as it is done today). The revenue is then allocated ex post between the flights (and/or carriers) on a prorating basis. (As is done in RL). Rather than today's free market prices this would be closer to the way prices were set in the IATA days - old fashioned may be must much simpler to determine and manage (at least for the default values)

The pricing - how player manages pricing - can always be fine tuned later, some interface can be build for that, but to get something going, it can for the first version be simply sum of the legs of the flight.

2. Routing and pax distribution: total travel elapsed time is the main parameter. Passengers will a priori chose the shortest travel time and only fall back on more time consuming alternatives if there is a price advantage. Different types of passengers F/C/Y value their time differently and prices per hour could be set for each type of passengers in their choice algorithm. The price and time elasticity es could therefore be merged in a single demand curve/equation

I am not exactly sure how this can be modeled, but the there should also be some fluidity between Y, C, F, related also to seating quality.  I don't think these should be distinct classes of demand, but should flow from one to another.  If there is not Y or C seats, the F traveler will not simply give up, and not fly, he will fly in other classes.

Also, if there are no more Y seats, it is completely sold out, some Y pax will pay the higher price for C.  Also, if the aircraft has, say, 10 C seats, and there is no demand for them.  If a player sets the price of the C seats lower, let's say as low as Y seats, those seats should sell in a heartbeat.

Agreed with you about the total time being the most important factor, which would automatically (and very strongly) favor direct flights in pax allocation.  No need to hard code special penalties for transfers / tech stops.  Of course, a 1500nm direct flight in an HD seat on a Turbo Prop would not just automatically win over connecting flight on a jet.

3. Connecting times: each airport should have its own minimum connecting times based on its size and also whether the connection is domestic only/domestic-international/ or international. (Security and immigration considerations make these different)

That sounds like a refinement that can be added later on.

Ps elapsed time would also be a good parameter to allocate demand between aircraft with different speeds (props/jets/Concorde) and replace the current penalty for flights with a technical stop.

YES

That was such a bad decision to hardcode the tech-stop penalty to completely destroy a valid strategy.  As if passengers wanting to travel to a certain destination simply abandoned / postponed their plan for 30-50 years, knowing that Boeing will launch of 777-200LR in 30-50 years, and then they can complete their trip.  If there is a superior choice, a non-stop flight, that should get a strong preference, due to shorter total time.  But if that option is not available, half of the demand should not just disappear, as it currently does...

From the POV of a passenger, tech stop is no worse than a connecting flight, and people take connecting flight all the time.

If I want to go on vacation, I pick a place where I want to know, and then figure out the flights to get there.  Not the other way around.  Looking first where I can fly non-stop, and if it does not include my destination, I will not simply cancel my vacation.

PS2: how many stopovers should be included (1,2,3?) may be 1 for flights less than 1000 nm, 2 less than 3000nm 3 for more?

That's a good point about the distance.  I would say 3 is excessive, but for some far away places, it would be great if the system could model 2 stopovers.

[LemonButt]

it can for the first version be simply sum of the legs of the flight.

This goes back to my first post on this.  You cannot implement connecting flights without first answering the price question first because price is a relatively major factor in determining pax distribution.  If a direct flight is $500, then the two legs of the flight will 99% of the time be more than $500 because they are designed to be two independent flights--not one.  If pricing were simply the sum of the two legs, then you'd have $500 vs $800 and no pax would end up connecting price drives down the quantity demanded to zero.  Pricing MUST be determined before you can even start to think about how the pax are distributed because you need to compare apples to apples in terms of creating a pricing coefficient (that makes sense) for the algorithm.  Pricing could ultimately simply be a discount on the two legs added together to get a reasonable price for competing against a direct flight or if time is going to be the ultimate decider, establishing what time is worth.  If connecting takes 2 hours longer than flying direct, then for a connecting flight and direct flight to have the same "price image" then the connecting flight would be priced at (direct flight price) - 2 * (cost per hour) = connecting flight price.  So if a direct flight is $100 and a pax time is worth $10/hour, then the connecting flight would be $80.  Assuming all else being equal, an $80 connecting flight would get 50% of the pax and the $100 direct flight would get 50% of the pax.

[ekaneti]

The problem with connecting flights is AirwaySim will become a job not a game for the users.

[Klaas]

Pricing is already very complicated in the "real world" of airlines, and this discussion makes this very clear.

The primary solution for this would be (as mentioned) before a discounting value for people taking connecting flights, compared to the sum of the separate legs. This can be modeled against the extra time it takes to taak the connecting flights.

For example
AMS-Paris charles de gaulle. Demand = 400
AMS- Johannesburg Demand = 100
Paris-Johannesburg demand = 300

It wouldn't be viable to fly from AMS to johannesburg, so a connecting flight would be the solution for most people. Discounting this connecting flight does devalue your seats, but this added opportunity of flying these people trough france and adding them on a possible B747 flight with a capacity of 300-400 makes this a viable flight. You also could do the direct flight, since a 100 daily demand might be just enough (and the right plane) to fly this route. Discounting the route trough paris has the added benefit for the player to feed their high-demand routes which they own.

Added issue: will the passenger be able to switch to another airliner? If yes, this would be great since the discount model would be in full effect here. It adds the dimension for a player to capitalise on his potential, but at the same time a player that has a very very cheap flight for a leg of the trip might benefit from the added demand.

Second added issue: will this mean airlines will be able to hold base in other countries outside of their terrority?

[DannyWilliams]

Personally i think we should be focusing on the most important thing missing from this game: Realistic Passenger Demand!!!
I really like how we have almost 18 flights on average to most airports here in Norway, and end up with routes on the game that has a demand of 40-100 pax...


I am almost desperate enough to offer my services to get this fixed!

[MenyBethTerry]

Personally i think we should be focusing on the most important thing missing from this game: Realistic Passenger Demand!!!
I really like how we have almost 18 flights on average to most airports here in Norway, and end up with routes on the game that has a demand of 40-100 pax...


I am almost desperate enough to offer my services to get this fixed!

They should fix the demand in a lot of countries. Thailand domestic passenger demand is lower than real life.

http://airportthai.co.th/corporate/en/invester-relations

[Andre]

I'd just like to suggest something regarding the City Based Demand system. I know there's a lot of coding going on with this, and that it's a completely new system. In the real world not all routes are flown every day. Many long haul routes are flown two-three times a week, simply because there's not enough demand for a daily flight with a large aircraft. If this could be implemented in CBD, that would be great.

Here's an example of what I envision:

Days: Mon Tue Wed Thu Fri Sat Sun
Pax:   100 100 100 100 100 100 100
Flights: 0    1     0    0    1    0    0


If the catchment area of each day is extended, you could pick up pax who would want to fly the next day instead. The day of the flight gets 100% of the traffic, the day before and after you can pick up 50% of that. Meaning if the flight is every Tuesday and Friday, you would pick up 200 pax on Tuesday and Friday (100 + 50 + 50). In my example, the green suggests 100% pax, orange is 50% pax, and red is 0% pax. If a competitor opens a route the days you're not flying, you lose those 50% of the pax and they all go to the competitor. Hope it makes sense.

[11Air]

There are two problems here.
1. Pax in RW will migrate quite some distance for their preferred airport or connection.
2. Airports will expand when demand justifies it, or they are losing Pax to a neighbour.

The problem with Heathrow is that they don't migrate to Gatwick, Stanstead (terminal expanded hugely in the last five years) or Luton and it doesn't expand either. RW they Migrate.

I did some design work on the New T5 at Heathrow. It was apparent to me that an additional runway between the other two was viable in the 1990's for 737 departures westwards, and with the current demolition of T3 (and Queens Building) it would now become a full length runway allowing parallel landing on 27R +27L (and 09's) while 27C provided T/O only.  Note has been happening since Concordes days at peak times with a stagger between aircraft.
What ever the RW solution there's plenty of scope for an additional runway at Heathrow (or Gatwick with Pax migration) at any time after the late 1980's.
Manchester Pax demand is far too heavy. It is still operating RW far below capacity, 60% in 2015. This great airport location can't work fully until the High Speed Rail Link provides a fast link to/from London.

It would be nice to see a more realistic migration model where airports are relatively close.

The landing and parking fees should also increase as demand saturation increases.

[Sami]

Work in progress still, but here's a quick preview (to be posted better & "officially" a bit later).

One of the remaining things still in progress with the city demand is how airports share the market from an area they overlap.

Think of New York region; there are (to simplify) three major airports: LGA, JFK, EWR. The New York city area generates a huge amount of demand and this needs to be split to these airports in a logical way.

As you may remember from earlier talk in this thread, each airport has a range of influence over which it can catch the demand from the city areas. In the game starting situation the demand from this one area (NYC city as an example) will be split to these three airports based on the existing AWS airport data and a few other factors. These are for example the airport size and the distance from the airport to the city area ("square"). Then later on the airport's area of influence can grow too etc. This all has been built and well tested already. (so initially it's not 33%/33%/33% split but let's say 40/30/30)

Now, when the three airports all catch the same city area we need to make this demand split move to the airport with the best service - slowly. There are many cases in world where the small city airport serves only local demand and the major intl airport nearby is the main hub to the country. But the whole idea of the city based demand is that players could potentially make this small city airport grow too, and this is why a) the initial demand between airports is quite equal and b) will move slowly from airport to another if services improve. So for example if nobody flies to EWR, the demand will slowly move to JFK and LGA.

There have been many suggestions on how to do this, but after some testing I believe the final technical specs are now locked in. In the simplified version we'd transfer ALL of airport's demand based of the availability of services from the players, but this would cause issues and confusion. The system I am planning will take this demand shift into route-specific level.

Simply, if we have demand from NYC city to Dallas, it will be caught by the three airports initially and will be shown as the traditional airport-to-airport demand like already now. But if no player airline flies from EWR to Dallas, the demand will slowly move to the other two routes in question (JFK-DAL and LGA-DAL). Technically this requires a bit more effort than the whole airport-level movement but not too much hopefully (process still pending). Good point to this is that the response is very lifelike .. no service from some airport, they choose the other. And then when a player would like to start EWR-Dallas the demand will slowly move back...

And also later on there will be another level to this that actually takes the service (prices, flight timese etc) into account. (Probably 50% from the amount of supply and 50% from the level of service ...)

Due to technical requirements the demand shift will happen in slow pace, checked once a month and even then too will only move in small bits (like already all demand changes now). So it would take months (depending on the overall demand) before all of EWR's demand is moved to the other airports. This also means that cities with many airports in the area will have initially very small demands at the major hub airports, before the demand slowly moves to it (assuming people fly there).

The user interface will remain familiar, but will have some new elements:

+ Current demand between two airports
+ Player supply
+ Possible event related demand changes
+ Maximum potential demand (= when this airport will catch all demand for this routepair)

Maximum demand is pretty static, it will only move in response to economy changes. While the current demand will move more in response to player actions. Oversupply checker will be tied to the max demand figure.

The only downside is that when the demand has shifted to other airports it may be slow to regain it, making opening new routes slower. But this can be compensated by RI boost (open a new route with no other airlines, gain initially 50% RI?) and possibly making the demand transfer back towards "initial" status faster.

Comments on this general scope of things?

[gazzz0x2z]

Me likes. Parisian adaptation : Currently, in real life, there are 2 flights to Montpellier from Orly, one from CDG, and zero from Beauvais. If a company tried to fly from Beauvais, it would suffer to get some demand. OTOH, if other lines would disappear for some reason, that line from Beauvais would be soon overcrowded by passengers to Montpellier.

If I understand well, it's the kind of phenomenon you're trying to simulate.

Ideally, there would be also other parameters linked to the nature of the airport. Beauvais being a low-cost airport, it would attract mainly economic class passengers, but never first or business. In reverse, London City would have a bonus for first or business. But that's really secondary.

[JumboShrimp]

It all sounds great.  Maybe initial demand allocations between airport should be influenced by the Airport Size (5 Large, 4 Significant etc.)

As far as UI, there could be a way to implement this without any UI changes - have 2 levels of demand screen:
- Current - currently allocated demand between airport pair, and current supply only between current airport pairs
- Maximum - maximum demand of the catchment area and total supply between all airport pairs serving the catchment area.

There would be an icon to switch between these views (similar to the current icon that can show returning supply demand).  So the UI stays the same (except some labels / titles), only the SQL behind it changes.

[Mr Yoda]

As long as airports like LGA don't get any LH traffic then I'm cool with this.

[JumboShrimp]

As long as airports like LGA don't get any LH traffic then I'm cool with this.

The current runways at LGA are not long enough for some of the LH aircraft.  Other than that, why not?

[Mr Yoda]

The current runways at LGA are not long enough for some of the LH aircraft.  Other than that, why not?

1) RWY length as you've mentioned
2) No Immigration and customs in RL at LGA so it won't be realistic to have any kind of international flight with the exception of places with pre clearance facilities like YYZ etc.
3) LH ops in LGA would remind me of something like this: http://theaircache.com/2012/07/23/air-force-c-17-lands-at-wrong-airport-in-tampa/

[01miki10]

2) No Immigration and customs in RL at LGA so it won't be realistic to have any kind of international flight with the exception of places with pre clearance facilities like YYZ etc.

What if in real world there would've been international traffic at LGA for years? Then it would also have immigration and customs... City-based demand is supposed to be realistic, not real-to-life.

...the whole idea of the city based demand is that players could potentially make this small city airport grow too...

[gazzz0x2z]

I wonder what will be the fate of London City. Crazy opening hours, very limited slots, poor list of aircraft available..... Will be fun to watch. I'm not sure I't set up a base here, anyways, as I did in previous GW3.