City based demand

[Kazari]

I was under the impression that one goal of the city-based demand system was that any airport could become a hub.

The problem with limiting it the way you're proposing is that it eliminates the possibility down the line of transfer passengers in a middle-of-nowhere hub. Let's say Point B is a traditional airport with all domestic traffic. And Point Z is an international destination. B-Z has zero demand. But there may be 20 demand from A to Z, 20 demand from C to Z, 20 demand from D to Z, etc., but if you fly a bunch of people from A, C, D... to B then there is plenty of demand for B-Z.

Your proposal would prevent that for a lot of airports because, for example, they never had international demand in reality.

Perhaps it should be based on another metric that can be a proxy for infrastructure.

* Runway length
* Population of its cell

[LemonButt]

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)

I'm not sure if this helps, but most domestic airports cannot support the largest planes (with exceptions).  You can fly a 747 into a small airport with a short runway if you only have a handful of passengers, but this would be pointless.  The easiest way to overcome this, in my opinion, would be to have a standardized max distance avail based on max runway length.  Chicago Midway, for example, has a 6500 foot runway.  This means you cannot fly 8000+ nm routes with 777 or otherwise because the runway isn't long enough, therefore any airports >8000nm (or whatever the cutoff would be) you wouldn't calculate demand.

The easiest way to do this would be to create a scatterplot with the minimum runway length on the x-axis and maximum MTOW range for every aircraft model avail.  Then come up with a cubic regression line and then shift the entire curve of best fit by adding a standard value (such as 100nm) to put 90% of the points below the line.  Then, you can input an x-value for every airport in the game based on runway length and split out a y-value for maximum range from the airport to eliminate large numbers of airports from the demand calculations.

Also, while JumboShrimp has a good point about international airports needing customs facilities etc, you essentially have a chicken/egg problem.  If a major carrier like Delta came into a smaller airport and said they wanted to fly daily flights to an international destination, you'd see a customs office pop up overnight.  Even the smallest crappiest airports like Duluth, MN (which actually has been renovated recently and supposedly not as terrible as it used to be) has a customs office for international service.  Minot, ND has a population of 28,000 and also has customs offices and they don't even fly to Canada anymore.

[JumboShrimp]

Sami,

It would be good if you presented an outline as far as which ideas you are going with, which ideas you have rejected, so that we could provide more useful feedback.  In my opinion:

Passenger connectivity >> City based demand

By City Based Demand, I mean that for example, JFK, LGA and EWR are competing among themselves for passengers, and an airline based at EWR can take a pax away from JFK.  I would forget all that for now.

To simplify things greatly, I would just take some local demand and pin it to an airport.  So New York City and surrounding areas would be initially split between these 3 airports in certain ratio, and that ratio would forever be fixed.

Majority of demand would be brought from the outside through passenger connections, and that's the dynamic demand that  airlines would be fighting for, when they create their hubs.  So while an airline at JFK can't take pax from EWR to LHR, it can take pax from another 300 North, even South American airports.  So I would say, forget 2 out 300 (LGA, EWR), give us 298 out of 300.

For playability, passenger connectivity trumps city based demand by a wide margin.  Passenger connectivity is complex enough to tackle (allowing for up to 2 connections).  And I think a lot of AWS players would like something to see the light of day.

I would use the system of geographical squares to gather data on local population surrounding the airports, but that would be a one time thing, to populate the database of airports and their demand.

The demand would continue to be from airport to airport (not square to square) and this demand can be served either by a direct flight, or by a connecting flight.

I would love to see a full implementation one day, of geograpical areas (squares) having some demand to every other geographical areas, with airports within range being able to pull that demand, but I am afraid that it is too complex.

Serving a fixed airport to airport demand with passenger connectivity is enough of a leap for AWS, that will make AWS deaper, more rewarding.  And that alone may take a year to implement and another year to fine tune.

[Sami]

Well, the first step is to create some new background features that are necessary for either of them.

For example, determination of airport 'catchment' area (range from airport), and with that the airport size class update (talked previously). Then we'd need to have some country specific dataon GDP and purchasing power (also in progress), and also data on country relations (demand from HKG to UK is higher than from HKG to Germany for example due to historical relations) - this one is unplanned (although it exists in present model too already it has no data). These got to do more with the square demand system.

For either system (squares or present), I need to build a better way to storing the demand data (now it's prettymuch calculated on the fly all the time causing extra stress). I am testing this (just started) with the current demand system first, and when it's done I can build the new better demand allocation systems based on this - and later on with the square demands I can just modify the first system (replace the current) with the new one more easily.

Added on top of this would be the connectivity but I am not that far yet.

The squares demand system is important in my mind as that will allow a flexible system in pax demand, it will be "live" and fluctuate and change according to what happens nearby (not necessarily just in the adjacent airports). However I do not know yet if it's possible technically. The second part of new demand allocation is too just simple testing yet.

[L1011fan]

I would just like to request more passenger demand from KDAL during the current DOTM game. I don't have much more room to grow, but would like to be able to.
My airline is Lone Star and is based at KDAL. I thank you for your consideration.

[Sami]

I would just like to request more passenger demand from KDAL during the current DOTM game

Ain't happening.

(ever to any running game world - already for technical reasons, let alone dozen others)

[Kazari]

Sami: This is a large undertaking and I want you to know that I admire the way you're going about this -- as collaboratively as you can. These are not simple problems. Thank you for tackling them.

[Sami]

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

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.

Did some checking again, and if we use the present-day demand allocation (DOM, SH, LH) we end up with about 950 000 route combinations that can have demand more than 0 pax (don't say they have, but with settings and demand allocation in mind, it would be possible). This figure is bearable taking into account the required update interval.

If we take into account only the country relations (where for example demand between two countries is set to zero by master settings), and the route minimum length rules (ie. domestic route must be at least 40 NM etc), we end up with 7,5 million potential route combinations. Which is too much to handle if the demand system would become "live" and changeable with the squares method.

So would need to come up with the mentioned classification for airports to eliminate most of the 0-demand routes right from the beginning, by setting certain airports 'domestic only' and so forth.

Probably a combination of current demand allocation (if DOM=100%) and low overall pax level at the airport (< 50 000 pax / year?) and low airport size classification (sizeclass < 3?) would do the trick... With the ability to set the 'domestic only' flag manually too for any exceptions to this, and perhaps even hardcode it to events module for some historical changes (ie. airport turning from intl to domestic only).

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

Due to the increased complexity of the square demand model and base demand has to be pre-calculated in my mind, and it also enables us to make smooth "over time" changes to the demand instead of rapid overnight drops. It could be for those flights that have schedules but then route planning would become quite slow, as it would need to calculate the demand data on the fly for non-served route you are checking out. But this is the another option - currently I will focus on seeing if it's feasible to make the base data of all possible combinations in the background...

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).

Any other airports that are international, but do not allow domestic flights? Cannot think of any really, so in that sense I would leave this "intl only" flag out alltogether.


edit: here's a list of all airports that have 0% domestic demand set in database, I guess most of these are in small countries that have no other domestic airports or they are too close - or have only LCC operating to them, like EBCI and EKSN?

VHHH, VHHK, WSSS, WSAP, EBBR, OTBD, LHBP, OKBK, OBBI, VMMC, OLBA, PGUM, TBPB, ESKN, TFFF, ELLX, EBCI, FMEE, LJLJ, WBSB, EHRD, TIST, LCEN, TXKF, LATI, FYWH, WPDL, LUKK, TLPL, GUCY, SOCA, TLPC, TISX, LXGB, TUPJ, DBBB, SMJP, NCRG, EBLG, PLCH, ANYN, EHGG, TVSV, TQPF, GGOV, FDMS, EBOS, EBAW, PTRO, FXMM, EIWF, LUBL, TVSU, VNVT, LJMB, VQPR, WSSL, LHSM, HKEL, LHDC, LHPR, YPXM, GMMH, LFBU, EERU, EGMD, KHKS, KCXY

I'm not sure if this helps, but most domestic airports cannot support the largest planes (with exceptions).  You can fly a 747 into a small airport with a short runway if you only have a handful of passengers, but this would be pointless.  The easiest way to overcome this, in my opinion, would be to have a standardized max distance avail based on max runway length.

Indeed .. This sounds smart too, with some alterations. There is the airport size classification vs. airplane size limit already in place, so this is the easiest way to determine this perhaps:
- if airport can accept only sizeclass "small" planes
- check generally what is the longest range "small" plane (the 'ferry range')
- if the route length is over that (^), then demand is assumed 0.
- this does not take into account possible techstops, but generally speaking should be enough as the ferry range (=full fuel, no pax) is used.

Also, while JumboShrimp has a good point about international airports needing customs facilities etc, you essentially have a chicken/egg problem.  If a major carrier like Delta came into a smaller airport and said they wanted to fly daily flights to an international destination, you'd see a customs office pop up overnight.

But would see this quite unlikely..? And perhaps we should set some realistic limits anyway to avoid people making "ridiculous" hubs and transfer airports?

[JumboShrimp]

Did some checking again, and if we use the present-day demand allocation (DOM, SH, LH) we end up with about 950 000 route combinations that can have demand more than 0 pax (don't say they have, but with settings and demand allocation in mind, it would be possible). This figure is bearable taking into account the required update interval.

So this, if I understand correctly, would be the demand stored in the database, for quicker retrieval.

I am still wondering if it would not be better to leave it as a formula, and not store it.  Formula being a demand between a set of squares around origin and destination.  If that could be fast enough, there would be no need to limit the combinations.  And the only update would be a rolling updates of the squares based on GDP and population growth.  Once a month is probably sufficient for this update...

This calculation would be performed when a route is created (infrequently) and when the route is flown (frequently - which could be an issue).

Here is another idea that might satisfy all requirements:

Perhaps a concept of a cache could be introduced for what is to be stored.  If there is a query to it, calculate it and store it.  And the stored info for the pair of the routes would have the last queried date (by a player or by system to fly the route).

With this type of system, the theoretical number of combinations that can have demand can be unlimited, the storage of only the "live" (recently queried routes) being probably smaller than 950,000.  And it would have the desired response time most of the time (except for the first - not-yet-cached query.

As far as the load on the database, there slightly more writes:
- ~once per game world to write for the first time
- once per game date to update last date queried (Today > last queried -> write)
- same amount of writes to update the demand (Once per month?)
- then, perhaps once per month, purge the unused pairs, with a threshold of 4 months not flown (longest D check + some padding) would be a purge candidates.

Reads would be the same, but most likely a smaller set than 950,000

A slight downside:  a feature that many players request - to show on route planning the actual demand between a pair, sort by it, rather than just sort by airport size.  This feature is not curcial, IMO.

[JumboShrimp]

One thing I am trying to figure out is if we considering storing the data on airport pair level or pair of squares.

Just looking at some figures posted as far as number of combinations, the 950,000 limited combinations (with data in current AWS) or 7,500,000 of more comprehensive combinations, I am still not clear.  If there are 9,000 squares with some population than all combinations of would be 9,000 * 9,000 = 81,000,000 or approx 40,500,000 if both legs are equal.

And since there are 2750 airports modeled in the system, 7,500,000 looks awfully close to 2750^2 (taking each leg of the flight as distinct).

So if we are talking about airport to airport demand, is this really a city based demand (where demand can shift between airports with overlapping catchment areas) or a generic local demand absent of current real world demand skewed by where the real world airlines set up their hubs?

If the demand is per airport pairs, how can it possibly shift?  Suppose a simple example where a catchment of 2 airports (EWR and PHL) is 9 squares each, there is an overlap of 1 square (let's say Princeton, NJ, halfway between the airports) and there are no other airports in the area to confuse things.  Princeton square has a demand of 20 to LHR.  If we allocate it to airports, both EWR and PHL both get 10.  But if the demand is stored to the airport pairs, the EWR-LHR flight can gets its 10, but can never get the other 10, even if there is no PHL-LHR flight.

Once the demand is pinned to either EWR or PHL, unwiniding of this demand to its components would be impossible.  Not that I mind this simplified approach.  I was advocating this as a shortcut to get to passenger connectivity quicker.

But to really implement the "City based demand", it would have to be square to square demand.  With the concept of cache (above), it might just be feasible with reasonable storage requirements, reasonable response time with given available CPU cycles and storage performance.

Square to square demand would require a ground up rewrite of the allocation of the demand to available flights.  It would again be square to square allocation.  I wrote a post on it here a while ago (about some buckets etc).  One thing that would improve the feasibility of square to square system would again be the cache.  Instead of processing 40 or 81 million square to square combinations, only the combinations in alredy in the cache would be considered, reducing the number of combinations down to perhaps 1% of the total number of combinations.

Well, this would be before passenger connectivity.  Passenger connectiity would increase the ~1% of connected squares ...

[Sami]

Almost finished with the data editor for square data ... this is the data collection tool ("crowdsourcing")...

Feel free to take a look but note that you cannot add any data yet.
https://www.airwaysim.com/Cityeditor/

I will need to test and add some data myself and (STILL) investigate if it's feasible at all, and so forth. And also to create documentation on how to input the data. (built this editor since I hate to input manually any test data, and if go-ahead is given, then it can be used for the crowdsourcing too.)

Please let me know what else you think is necessary to be included and any wishes on the interface to make it as smooth as possible.

[Meicci]

You should somehow define those categories (small, medium...) since people can have different approaches into these factors.

As for example, a relatively new mine here in northern Finland seems quite large from finnish view, but somewhere like US it would be tiny.. (as a part of "cargo" -section).

[Sami]

As said, there is no "documentation" yet.

[JumboShrimp]

Almost finished with the data editor for square data ... this is the data collection tool ("crowdsourcing")...

Feel free to take a look but note that you cannot add any data yet.
https://www.airwaysim.com/Cityeditor/

I will need to test and add some data myself and (STILL) investigate if it's feasible at all, and so forth. And also to create documentation on how to input the data. (built this editor since I hate to input manually any test data, and if go-ahead is given, then it can be used for the crowdsourcing too.)

Please let me know what else you think is necessary to be included and any wishes on the interface to make it as smooth as possible.

Good to see the size of the boxes, just to get a sense of their size.

One thing:  there are boxes on borders between countries that appear as part of 2 countries.  For example, between Austria and Slovakia, the box with capital of Slovakia (Bratislava) is part of Austria and Slovakia.  I think it might be simpler to just say if the center of a box is in a country, than the entire box belongs to that country.

Edit: Looking at Slovakia (as an example why some may say don't do it) it would lose 9 out its 12 boxes with the above approach (and probably 2/5 of population) but who cares?  I is not a country simulation.  The only time it would make some difference is if relations between neighboring countries are bad.  But still, I would go for simplicity...

[Sami]

Each country gets a box even if part of the country touches that box. The same box may have multiple countries as "owner" (see the box id # in your examples), but the calculation is country specific due other variables in place.

[Kazari]

I assume you will have population data for each box.

* Would a regional capital or power center (I'm thinking of Santa Cruz in Bolivia here) count as greater Business Activity? (The greater population isn't enough alone.)

* For boxes that cover more than one country, it would seem to me that the country relations setting is important. Is that going to be set for all 232 countries over time?

* The lack of squares in parts of Russian Asia makes me assume that those areas are unpopulated.

* Would Melilla, Spain, count as an island?

[Sami]

#1) Yes, capital increases business/administrational region status.

#2) Cross-border travel to be defined later.

#3) Yes. It didn't have any population data to begin with, nor airports (even tiny ones with no pax data) so they are ignored to save time.

#4) No idea where that is, but if the box has only an island (or 2-4 adjacent boxes are part of the same island) and no links to anywhere in main continent from that island then it's "isIsland".

As said, usage instructions are coming later once it's time to actually start using it.


Edit: updated the script a bit, and it actually now saves the data too. But if you test it and save something, no worry since I will erase the database before we actually begin later on. (for the time frame, no clues on that yet)

[Dasha]

Wouldn't Amsterdam be annihilated with City based demand? I mean Schiphol is a big airport but only because of the transfers happening there. As a city, Amsterdam doesn't play any role in the world so the demand from or to Amsterdam is not very big.

Am I missing something about the whole city based demand or....


Just a bit worried that some airports would no longer become attractive (like Baku, Tashkent, stuff like that)

[Jona L.]

#4) No idea where that is, but if the box has only an island (or 2-4 adjacent boxes are part of the same island) and no links to anywhere in main continent from that island then it's "isIsland".

It is located in Northern Africa and is a Spanish enclave to the Black Continent, about 200-250NM south-east of Gibraltar (please don't tell me you are unfamiliar with that either )

[JumboShrimp]

Wouldn't Amsterdam be annihilated with City based demand? I mean Schiphol is a big airport but only because of the transfers happening there. As a city, Amsterdam doesn't play any role in the world so the demand from or to Amsterdam is not very big.

Am I missing something about the whole city based demand or....

Just a bit worried that some airports would no longer become attractive (like Baku, Tashkent, stuff like that)

Passenger connectivity will be added at some point.  So there will be additional demand from connected flights.