Return of ABCBA - "Focus City" Option

Started by vitongwangki, October 26, 2011, 09:58:39 AM

vitongwangki

Dear all,

I am writing to introduce my idea on the return of ABCBA routing. I guess most of you are seeking the return of it, although it has many controversies when someone tried to abuse it heavily. Therefore I would like to suggest "Focus City" option to prevent the abuse, in order to allow the ABCBA routing returns.

First, we need to know some of the fact in Real life, in order to understand the proposal down below.

1. ABCBA isn't necessarily transport passenger between B and C.
In real life, some of the route has not enough passenger demand to fit a long haul plane. If the company wants to serve the route, a company may fly ABCBA without the 5th Freedom. The plane flies to city B, drop passenger and continue the flight to city C. The return will take up passengers in both C and B then return to homebase.

2. 5th freedom is rare in real life.
5th freedom usually granted towards airline in flying certain dense, high demand route such as JFK-LHR, HKG-TPE, HKG-BKK etc. Not only bringing competition on dense routes, also facilitate the operation of Ultra-long haul, such as 5th freedom granted to JAL on JFK-GRU; NRT-GRU are ~10000NM away.

3. In domestic market ABCBA is common.
ABCBA is common to serve the demand between medium cities and small cities. The airline can reduce the cost by using ABCBA, without basing pilots and aircraft in those medium cities.

Second, the below is about the concept of “focus city” option.
1. Any airline needs to open “Focus City” to transfer passenger between focus city and other airport. Means if I was in SIN, I want to transfer passenger between HKG-NRT, I need to set up a focus city in HKG.
2. Any airline can fly ABCBA despite he has open a “focus city” in city B or not. If he has not opened focus city in B, he can still fly but cannot transfer passenger between B and C. Means if I was in SIN, I want to serve ATH and CPH but the demand is low to launch direct flight to both ATH and CPH, I can fly ABCBA with stop at ATH. Then I can transport passenger between SIN-ATH and SIN-CPH without opening a focus city in ATH. i.e Opening “focus city” outside home-country can be considered as gaining the 5th freedom.

Third, limitation and operational difficulty on “focus city”
1. Number of Focus-city should be limited, to 4-8 in my opinion. Otherwise someone will abuse the market outside its home base for attacking purpose.
2. Demand supplied on ABCBA should count towards supply on A-B stint, in certain percentage (30%-50%). And the total supply on A-B stint still limited to 200%. This measure is to limit the influence to City B’s airline which reflecting real life; the local authorities would like to protect their flag carriers or airline based in their airports.
3. Staff cost should be different between foreign focus city and domestic focus city. Of course due to language and training cost, foreign focus city should be more expensive. Staff cost should have exponential increase if the focus city is far away from the home base (use route type on “route planning” page as standard), to prevent abuse the market far away from them; rationale to this is the flight crew needed to be changed (due to flight hour limit) in the focus city so another set of crew to be employed.

Fourth, possible problem would be appeared.
1. The focus city option is limited.
   Due to the demand limitation on A-B stint, the focus city option is probably quite limited or easy to guess. Using LGW as example, the number of routes which demand exceed 500 (using 1988 data collected in AWS) is ~15, only FRA-LGW exceeded 1000. Thus, it is clear that the airline will open a focus city in those choices. And very probably some airports will be paired up for competition, such as HKG and TPE, TPE and NRT, while long haul as LHR and JFK.
   I guess this is reflection on real-life because no airline will open or able to have 5th freedom granted to an airport without strong interaction.

(subjected to edit)

Please kindly review the above proposal. I would think the “Focus City” requires quite a lot of programming effort. I expect to have a robust plan on ABCBA returns so Sami can work on it as long-term works.

Best regards,
Vito

LemonButt

In real life, airlines with focus cities like Southwest will run a plane across the country hitting focus cities along the way.  For example, they may have an aircraft fly Baltimore-Greenville-Nashville-Dallas-Las Vegas.  This allows them to sell tickets for Baltimore-Nashville, Greenville-Dallas, Nashville-Las Vegas, Baltimore-Dallas, Baltimore-Las Vegas, and Greenville-Las Vegas via tech stops with passengers getting on board.  If focus cities are implemented, I'd much prefer to be able to create a "chain" of destinations like this to maximize my pax potential.  Not sure how this could be implemented, but it's what Southwest and other focus city airlines do in the real world.  City-based demand and connecting flight functionality should help facilitate this.

vitongwangki

Quote from: LemonButt on October 26, 2011, 12:45:15 PM
In real life, airlines with focus cities like Southwest will run a plane across the country hitting focus cities along the way.  For example, they may have an aircraft fly Baltimore-Greenville-Nashville-Dallas-Las Vegas.  This allows them to sell tickets for Baltimore-Nashville, Greenville-Dallas, Nashville-Las Vegas, Baltimore-Dallas, Baltimore-Las Vegas, and Greenville-Las Vegas via tech stops with passengers getting on board.  If focus cities are implemented, I'd much prefer to be able to create a "chain" of destinations like this to maximize my pax potential.  Not sure how this could be implemented, but it's what Southwest and other focus city airlines do in the real world.  City-based demand and connecting flight functionality should help facilitate this.
I think the allocation of ticket sales on different legs is rather tedious to program on, comparing with 2-leg option which implemented before.
I appreciate your suggestion which the domestic market is rather different from international market. I think in domestic market the flexibility should be bigger. Combination of "hub" and "focus city" could bring reasonable flexibility, and not giving too much program demand to sami. 

vitongwangki

I guess the passage is long and required some time to read it through? :laugh:

JumboShrimp

Even though this happens in real world, I think it would be very complex to implement in AWS.  The reason is that the allocation of passengers to flight is already the single most complex algorighm in all of AWS, and dividing the capacity of aircraft, as in the example of SIN-ATH, SIN-CPH adds a lot of extra complexity on top of the very complex algorithm.  Then there is the issue of User Interface for this, showing SIN-ATH and SIN CPH routes, passenger flying it etc.

I think 2 features, 1 existing (bases) and 1 future (passenger connectivity) will address 90% of what is needed.  The extra 10% is not worth the trouble.

2 cases:
- International: You carry the pax to ATH, and they connect to another flight (operated by someone inside or outside of your alliance) and the pax will get to CPH.  You will get partial ticket income for the SIN-ATH leg, and someone else will get the other part.

- Domestic / inside EU: when we have pax connectivity, passengers will connect at your hub (base).  Focus City could just be a form of a base - perhaps some limited version of base

vitongwangki

Quote from: JumboShrimp on October 27, 2011, 08:09:51 AM
Even though this happens in real world, I think it would be very complex to implement in AWS.  The reason is that the allocation of passengers to flight is already the single most complex algorighm in all of AWS, and dividing the capacity of aircraft, as in the example of SIN-ATH, SIN-CPH adds a lot of extra complexity on top of the very complex algorithm.  Then there is the issue of User Interface for this, showing SIN-ATH and SIN CPH routes, passenger flying it etc.

I think 2 features, 1 existing (bases) and 1 future (passenger connectivity) will address 90% of what is needed.  The extra 10% is not worth the trouble.

2 cases:
- International: You carry the pax to ATH, and they connect to another flight (operated by someone inside or outside of your alliance) and the pax will get to CPH.  You will get partial ticket income for the SIN-ATH leg, and someone else will get the other part.

- Domestic / inside EU: when we have pax connectivity, passengers will connect at your hub (base).  Focus City could just be a form of a base - perhaps some limited version of base
Hey Jumbo Shrimp,

About the complexity of SIN-CPH, SIN-ATH, is rather easy to solve. We can just let the airline to allocate manually the seat to CPH or ATH, then the problem is solved. The allocation ratio can be changed at anytime, I guess usually the airline will follow the demand ratio. If they tune as 9:1 then they are stupid for not flying direct flight.  ;) I think it will be reasonable for a player to address the seat allocation on every ABCBA route.


On the other hand, I don't know have you ever investigated on the complexity of "Passenger Connectivity" is. :) I could roughly throw some issue about it.

1. Bonus on intra-Alliance connection, and codeshare partners.
- How much bonus should be given on individual flight
Passengers concern a lot for taking a flight for connection, Arrival time, Connectivity, destination diversity, time to spend in connection airport. Some issue come from it, How to address which factor is more important? Is it fair to use one or two factor to count towards the bonus, would it cause abuse? And one more important issue is the processing demand on giving of bonus. Each flight need to calculate all flights Departure from the destination, which would cause huge workload on the server I am sure.

2. Competition between connection hubs.
- This is more complicated to simulate and I guess without this feature will be just another form of ABCBA with more than 1 company contributing the whole route, and the connection passenger allocation to different airlines, will be more complicated issue. No airlines wants the passengers connect to flights that are not operated from the same alliance.

3. Ratio of direct flight demand/connect pax demand of each route.
- It is impossible to allocate the ratio one by one, setting general ratio isn't seems fair.

JumboShrimp

Quote from: vitongwangki on October 27, 2011, 09:13:47 AM
Hey Jumbo Shrimp,

About the complexity of SIN-CPH, SIN-ATH, is rather easy to solve. We can just let the airline to allocate manually the seat to CPH or ATH, then the problem is solved. The allocation ratio can be changed at anytime, I guess usually the airline will follow the demand ratio. If they tune as 9:1 then they are stupid for not flying direct flight.  ;) I think it will be reasonable for a player to address the seat allocation on every ABCBA route.

Then, the flight would become 2 separate flights: SIN-ATH and SIN-ATH-CPH (tech stop at ATH).  Well, it is another level of complexity...

Quote from: vitongwangki on October 27, 2011, 09:13:47 AM
On the other hand, I don't know have you ever investigated on the complexity of "Passenger Connectivity" is. :) I could roughly throw some issue about it.

Passenger contectivity and City (square) based demand would be the biggest change to AWS, no doubt about that, but it would be a major leap toward realism of the game, and of the demand model (which at this point is based on where real world airlines chose to locate their hubs).

Quote from: vitongwangki on October 27, 2011, 09:13:47 AM
1. Bonus on intra-Alliance connection, and codeshare partners.
- How much bonus should be given on individual flight
Passengers concern a lot for taking a flight for connection, Arrival time, Connectivity, destination diversity, time to spend in connection airport. Some issue come from it, How to address which factor is more important? Is it fair to use one or two factor to count towards the bonus, would it cause abuse? And one more important issue is the processing demand on giving of bonus. Each flight need to calculate all flights Departure from the destination, which would cause huge workload on the server I am sure.

I am sure there would be some preference built into the system so that pax woud choose connecting flight based on following priorit:
- same airline
- same alliance (code-sharing)
- other airlines

As far as connecting, the for any pair AB the system would have to look at set of flights
A-B
A-some connecting airport-B
A-some connecting airport-some other connecting airport-B

So you would have a set of these flights, and the system would allocat the pax based on number of different parameters, one of which would be time travelled.

Quote from: vitongwangki on October 27, 2011, 09:13:47 AM
2. Competition between connection hubs.
- This is more complicated to simulate and I guess without this feature will be just another form of ABCBA with more than 1 company contributing the whole route, and the connection passenger allocation to different airlines, will be more complicated issue. No airlines wants the passengers connect to flights that are not operated from the same alliance.

3. Ratio of direct flight demand/connect pax demand of each route.
- It is impossible to allocate the ratio one by one, setting general ratio isn't seems fair.

Hopefully, it will be all dynamic.  Player will just set up flights, the same way as now.  The system will do all the allocations automatically.  You connect new airport to your hub, all other flights from you hub may get extra passengers connecting from this new airport.  It will not be pre-determined (as it is in the current system) that everybody connects in Atlanta.  Atlanta will be just another city...

vitongwangki

Quote from: JumboShrimp on October 27, 2011, 09:38:07 AM
As far as connecting, the for any pair AB the system would have to look at set of flights
A-B
A-some connecting airport-B
A-some connecting airport-some other connecting airport-B

So you would have a set of these flights, and the system would allocat the pax based on number of different parameters, one of which would be time travelled.
Um.. You get to the point, how many AB pairs we have and how many connecting airport we can have?
I would guess a supercomputer could do it. ::)

JumboShrimp

Quote from: vitongwangki on October 27, 2011, 09:43:27 AM
Um.. You get to the point, how many AB pairs we have and how many connecting airport we can have?
I would guess a supercomputer could do it. ::)

Doing exhaustive search might need a supercomputer.

But doing it in a smart way may be doable on regular PC server.

You don't take all possible routes, only connected ones, and you give up at certain limit, eliminating many choices.

For example, A-B distance is 1000nm.  So you set a limit of say 1.5 x original distance (1500nm), and will eliminate all connections over that limit.

Let's say you want to solve: A - connecting city - B, which is good enough for first version.

So you get a set of cities connected from A (under the 1500 limit)
Next, you get a set of cities connected from B (again under 1500 limit)
Then, you get the intersect between those 2 set, and those are all your connecting cities.
Next, you eliminate all routes over the 1500nm limit, and you have a resulting set of A-X-B routes to consider.
Really easy.

Solving A-X-Y-B is more complex, but a shortcut similar to the above could be found, and it should still be well within capabilities of current PCs, and hopefully within the time constraints of 35 minute turns...

vitongwangki

Quote from: JumboShrimp on October 27, 2011, 10:05:55 AM
Doing exhaustive search might need a supercomputer.

But doing it in a smart way may be doable on regular PC server.

You don't take all possible routes, only connected ones, and you give up at certain limit, eliminating many choices.

For example, A-B distance is 1000nm.  So you set a limit of say 1.5 x original distance (1500nm), and will eliminate all connections over that limit.

Let's say you want to solve: A - connecting city - B, which is good enough for first version.

So you get a set of cities connected from A (under the 1500 limit)
Next, you get a set of cities connected from B (again under 1500 limit)
Then, you get the intersect between those 2 set, and those are all your connecting cities.
Next, you eliminate all routes over the 1500nm limit, and you have a resulting set of A-X-B routes to consider.
Really easy.

Solving A-X-Y-B is more complex, but a shortcut similar to the above could be found, and it should still be well within capabilities of current PCs, and hopefully within the time constraints of 35 minute turns...
Let me use your example, to simulate Passenger connection of US Domestic market.

Number of AB pairs:
(478*477) / 2 = ~114,000

To do it in a smart way, we consider level 3 airport or above to be possible connection airport. (I guess ~150 included)
(Using range is not a smart way becasue long-haul route cannot be simulated, e.g LHR-SIN-SYD)

Each time when the date proceeds, the computer will need to consider those hundred thousands pairs.
1. Search connected City in between, ~75 classified in average ----> 7.5Mi combination
2. Rectify by deleting non-connected city, if 20% connected ---> 1.5 Mi combination

Only US domestic market we can have 1Mi combination to deal with. I can't see that it is possible to deal with 2700 airports in the whole world.

JumboShrimp

Quote from: vitongwangki on October 27, 2011, 10:27:59 AM
Let me use your example, to simulate Passenger connection of US Domestic market.

Number of AB pairs:
(478*477) / 2 = ~114,000

I think you would only consider only pairs that:
- have demand between them above certain threshold (say 10 pax / day)
- the cities that are "connected", meaning there is at least 1 incoming flight to them

The number of pairs after this filter is applied would shrink considerably.

Quote from: vitongwangki on October 27, 2011, 10:27:59 AM
To do it in a smart way, we consider level 3 airport or above to be possible connection airport. (I guess ~150 included)

That may be one of the approaches.


Quote from: vitongwangki on October 27, 2011, 10:27:59 AM
(Using range is not a smart way becasue long-haul route cannot be simulated, e.g LHR-SIN-SYD)

For LHR-SYD you would ask:
What are the cities connected to LHR?  Answer: ~500
Then: What are the cities connected to SYD? Answer: ~200
Then: What is the intersect between these 2 answers: Answer: ~100
Then: Which LHR-X-SYD routes are within 1.5 x distance of LHR-SYD?  Answer: ~15

So you would consider routes:
LHR-X1-SYD
through
LHR-X15-SYD
and allocate the passengers.

But actually, under the city based demand, you would start with the squares, rather than the airports.

vitongwangki

Quote from: JumboShrimp on October 27, 2011, 11:04:41 AM
I think you would only consider only pairs that:
- have demand between them above certain threshold (say 10 pax / day)
- the cities that are "connected", meaning there is at least 1 incoming flight to them

The number of pairs after this filter is applied would shrink considerably.

That may be one of the approaches.


For LHR-SYD you would ask:
What are the cities connected to LHR?  Answer: ~500
Then: What are the cities connected to SYD? Answer: ~200
Then: What is the intersect between these 2 answers: Answer: ~100
Then: Which LHR-X-SYD routes are within 1.5 x distance of LHR-SYD?  Answer: ~15

So you would consider routes:
LHR-X1-SYD
through
LHR-X15-SYD
and allocate the passengers.

But actually, under the city based demand, you would start with the squares, rather than the airports.

Oh, I haven't consider something, it is the demand of long-haul which one end is airport without long haul demand (such as SIN-TLL). We can't decline there should be passenger in between, as it is not simulated in present demand data. That's the most difficult part to simulate. To simulate it, the system needed to handle large amount of detail. Not to simulate it, the passenger connection is nothing more than ABCBA. ;)

I guess the passenger have not less than 50 choices between LHR-SYD, using 1.5x limitation.

Sami

#1 - already discussed in other threads, three leg routes should return, with some restrictions.

#2 - 5th freedoms will not be modelled as finding global and historical data for that is not possible (also discussed previously)

#3 - See #1.

#4 - Focus cities are not to be build since we have the bases feature already and they overlap.

https://www.airwaysim.com/forum/index.php/topic,27301.0.html
https://www.airwaysim.com/forum/index.php/topic,31730.0.html

Pls do a search first.

vitongwangki

#13
Quote from: sami on October 27, 2011, 12:51:32 PM
#1 - already discussed in other threads, three leg routes should return, with some restrictions.

#2 - 5th freedoms will not be modelled as finding global and historical data for that is not possible (also discussed previously)

#3 - See #1.

#4 - Focus cities are not to be build since we have the bases feature already and they overlap.

https://www.airwaysim.com/forum/index.php/topic,27301.0.html
https://www.airwaysim.com/forum/index.php/topic,31730.0.html

Pls do a search first.
#1 - I know ABCBA will returns, I am suggesting restriction features to allow it returns in a proper way.

#2 - Nothing above deal with real 5th freedom data.

#4 - Focus cities can be opened outside home country/region which not really overlapped with base feature.

Pls read through it first.

slither360

Quote from: vitongwangki on October 27, 2011, 12:57:16 PM

#4 - Focus cities can be opened outside home country/region which not really overlapped with base feature.


Exactly.

This would be like AMS/CDG for DL or NRT for UA