AirwaySim

Hi Sami, I know this was mentioned quite a while back but are we any closer to city based demand? There are plenty of routes (to holiday places mostly) that have big demand from Gatwick but non from Heathrow. The stats are based on the real world experience but this is not because people would not be willing to fly from LHR to these destinations but rather that traditionally that has been that airlines have chosen Gatwick for leisure and Heathrow for business routes. I can see three ways of remedying this.

1) Create city based demand (the best way but I understand this would be a big task)

2) Allow an airline based in a city with multiple airports to base aircraft out of all of them

3) Allow short repositioning flights, at the moment I'm not allowed to fly an acf from LHR to LGW and start a route from there even though I accept that I wont get any revenue for the ferry flight, if this was allowed then 1 or 2 would not be necessary provided the positioning flight was not counted as a leg for turnaround basis other than the time taken to make the flight.

For example - I have a 747 that is based at my LHR hub that I want to send out of LGW. I make a positioning flight for the acf to LGW. Rather than a traditional leg the time taken to do this is just added to the turnaround time for the flight. Say if we needed 200 mins to get 0% delay possibility before from LGW this would be 260 mins. I think this would keep the balance of the game but stop the unrealistic impossibility of flying out of two airports in the same city.

Being planned for future versions but actual coding / planning is 0% at the moment, as that's for a thing for "AirwaySim v2" or something like that.

I acknowledge the problems in the current airport based model but that's the first version as it was faster and easier to make.

thats cool, thanks Sami

I'm slowly gathering data on this and planning the system, however this is NOT expected anytime soon. If expected at all, I cannot tell yet.

But the first step has been to get list of cities worldwide and also their coordinates, and population... Here's a few pics where I've compared the results from a single country (Finland) to what Google is giving on their maps function. As you can see the city dots (location) is very close to what they should be on the map. The city location is of course needed as I must tie each airport to the cities and each airport would have a certain 'catchment' area... The system cannot be fully accurate but plan is to find data on cities with population of over 1000-10 000 people which would bring the countrywide accuracy of population to 90-95%.

But this is all just very early testing, the decision to start building the city based system instead of airport based is not even made or planned.

(the maps won't be ever visible to users, there's so much data to display .. but just showing here what kind of data the system is built on)

[attachment deleted by admin]

Very, Very cool Sami.  This is definitely something I'd like to see in the future.

Quote from: sami on August 08, 2009, 05:44:50 PM
I'm slowly gathering data on this and planning the system, however this is NOT expected anytime soon. If expected at all, I cannot tell yet.

But the first step has been to get list of cities worldwide and also their coordinates, and population... Here's a few pics where I've compared the results from a single country (Finland) to what Google is giving on their maps function. As you can see the city dots (location) is very close to what they should be on the map. The city location is of course needed as I must tie each airport to the cities and each airport would have a certain 'catchment' area... The system cannot be fully accurate but plan is to find data on cities with population of over 1000-10 000 people which would bring the countrywide accuracy of population to 90-95%.

But this is all just very early testing, the decision to start building the city based system instead of airport based is not even made or planned.

(the maps won't be ever visible to users, there's so much data to display .. but just showing here what kind of data the system is built on)

very good sami but please do not forget that statistical/economic indicators have to be available to players otherwise I see no chance/logic to take decisions or drive the company. For heaven's sake is not to earn money nowadays!

the economics of a country is a completely different module and that of course is needed for the city demand too.

Very cool!

But, what about airports which serve cities but that also have a huge catchmen area?

Like Malpensa (Milan - Italy). That airport serves basically all the north of Italy, not just Milan.

My very ideal imagine:  ;D
probably they will pick the closest airport(AIRPORT A) that serve the flight to AIRPORT C
if the closest airport are too far away from the city,they will pick another closest airport(AIRPORT B)with connection to AIRPORT A.
that generate AIRPORT A to AIRPORT B demands,and also boost the demand from AIRPORT A to AIRPORT C(connecting passenger).

we can have different kinds of passenger AI,"wealth passenger" AI,who aim for luxury."business traveller"AI,who aim for flight timing,fastest flight,late departure and morning arrival.
"budget travller"AI,who aim for lowest fares,they don't care about comfort."normal"AI,they aim for decent service,and normal fares.etc.......

I know that city based demand is planned. But there's another problem - what about close airports which are in different cities (sometimes even countries), but passengers are popular for people from both cities.

For example, Bratislava and Vienna. That airport are about 59km from each other and people from both cities use both airports... Vienna is large airport and provide many destinations which are not available in Bratislava (that's why many people from Bratislava use Vienna) and on other hand, Bratislava airport is cheaper and is more attractive for low costs like Ryanair and therefore, passengers from Vienna which are looking for low fares often use Bratislava...

So, any ideas how situations like this could be implented?

Yes that's a problem with it still ...

Each airport will have a radius of influence and all cities under it will be served by that airport. But as you pointed out there are very close-by airports, even at the same city .. So dealing this may be complicated and haven't yet found a proper solution. Calculating demand individually for each city & village isn't really an option as the city database has over 100 000 locations.

Close airports and the changes you could have there over the current system, are one of the best potential features of having the city-based demand.  So I wouldnt call it a "problem", I'd call it almost the entire reason why we need the feature in the first place.

On of the best parts of having the feature is that you could either Bratislava or Vienna, or DFW or Love, or JFK or LaGuardia or Newark (to pick 3 in close proximity), to become to dominate airport in the region in our world, regardless of what reality has dictated.  Airport size and runway length would still be 'realistic' and would create a limiting factor, but one of the defining 'needs' for the feature, are that you should have to worry about a start-up coming to the airport across town and flying to your destinations and stealing your pax.  As it is now, an airport 10 miles away can't steal one iota of your demand to a destination city, whereas in real-life airlines do this constantly.   Southwest Airlines' entire business model for example is based off the idea.

If a solution can't be found to the problem, it takes away a good 90% of the value of the feature in my mind.  It still would lend itself to regional demand variations, which would be a plus, but it would still be a significant hindrance on the 'realism' of the game, as it would still leave us in an environment that is simply a mirror of the reality we know with little ability to change it (which, I suppose, mirroring reality is "realistic" in its own right, but not "realistic" as a business sim of sorts).

Yes, I know the benefits and I'd like to have the city system too, I just described the biggest problem what I am having with the planning right now .. All clever ideas welcome  ;)

Well, my post was in regards to Samo's calling it a "problem" of city-based demand -- in my opinion it's not the problem, it's the reason.  The problem is trying to make it work.

I would have to think it would be fairly easy (and I use the term loosely) to have airports within Xkm be, essentially, the 'same' airport as far as the pax demand was concerned.  You would see the same demand graphs (and associated flights so you'd need a header for airport at the bottom so it was clear where the competition was flying from) from either airport.

However, that would be a very big "band-aid".  Why, for example, would it be 100km and not 200km or 50km?  And what if you're 2km based the 'border'?  You don't have to worry at all anymore.

In a perfect world, the further an airport got from another, the less demand it would 'share'.  But that becomes exceedingly difficult to both program as well as display on a demand chart.  If you're 100km away and half the demand for your airport is willing to drive to a further one to grab a flight, how do you put that on a graph?  You can't show the flight capacity like we do now for sure.   And how do you show the passengers that aren't as willing to travel.  And then you have to put a travel function in the preference model -- at what price are they willing to drive Xkm to a different airport?

It certainly gets difficult.

Problem is that it doesn't exits now and it will not exist if it will compare just airports in one city :)

But, yes, same problem is that we don't have any solution... I was thinking lot about it and I didn't found nothing...

.  I'm going to argue that even if airports are close together, if their is real world demand then they are in different regions.  As posted above there are places where people fly 40km.  However, there are places where people don't fly 40Km.  Manchester-Boston Regional to Boston (about 40km)  has a free bus that runs between the two, no one needs to fly it because even though they are in Diffrent US States they are in the same region.  It would be a ton of work, but Probably the best way to handle it is to manually assign regions to airports, or manually tweak it once you do it automatically.

I wonder, as I'm typing this, if it makes sense not to have one regional catigories, but several.  People will travel farther to travel farther.  I'm not going to drive two hours for a 45 minute flight, but I will drive (or rail or what ever) that long for an 8 hour flight.  What I'm thinking is You have a Metropolitan region, that draws from a very small area around the airport, The pax from this region don't want to fly very far at all.  Then you have a 'local' region (that needs a better name,) People come from a larger region to travel farther,  I would say this would be larger than states, but not the whole country for the US, and European countries for the EU.  The final region would be the International Region, these are the PAX that are looking to travel long haul.   Now to help with the connecting flights Idea, you  take a percentage of the pax from the smaller region and add it the demand of the next region.  IE  some pax will be flying regionally to fly internationally.  Now your DHC-6's help bring regional travel to your Hub.   I'm not sure I'm explaining this as well.   Does it make sense?

Christopher

The radius can also be a problem as for example EHAM (Amsterdam) is a main airport for the entire nation. That's why train services from all corners of the country go to the airport, and not Amsterdam. ;)

-First of all, I'd like to say, Im only typing with on hand so, there are bound to be alot of mistakes -

As I sent in a Pm to you, Sami, its pretty easy to do cities with with 1-2 airports, If the second one is very small.

Examples: for Seattle you have SEA and BFI, the main is Seattle and a very small amount pax go through BFI [Less than 20,000].
Another: for Portland you have three, PDX, Troutdale, and then Hillsboro. The last two are like BFI, with very few passengers. To get more accurate demand, these airports can - A: Be left alone and have indiviual route data submitted, B: Demand is generated by only the local communities. The main airports obviously have demand from their whole cities population.
----

For Airports like DFW/DAL and IAH/HOU, where we have a clear main airport.... but there is still a secondary airport that has noticable service. So, as before the major airport has demand from the whole area, but this time this larger secondary airport takes demand from a larger chunk of the local area. In both cases, HOu/DAL are located closer to the city's center. So they might take demand from the county/cities/region/prefrecture/provence/etc that they are in.
----
Alright, Im going to split this post into two as.... The forum does funky thing after making it longer than this, which makes it hard to type.

There will be no "submitted routes" as the idea is not to mimic what real airlines do and where they fly, the demand must be fully generated..

So, then you get to the messy cities with more than three major airports: Los Angeles, New York, London, Berlin, Bay Area, Stockholm, London, London, and London again  :P ;D.

What I proposed to Sami in my pm was that [Im using LA for an example] the main airport, in this case LAX caters to the whole of LA's population and then the smaller airports: SNA, BUR, LGB, ONT all have demand from there local areas. For example, SNA is in Orange County, therefore it serves Orange County, pop. 3 million. For BUR, you can use the local cities population and you kind of guestimate that some of LA's [the municipal city] 3.8 million people will use it [500-600,000?] along with Burbank, Pasidena, Glendale, and San Fernando.

It's compliacted, but I dont really see another way to do it for these huge cities with 5 airports.
----

For cities like New York, where you have to main airports and a third major airport, you could potentially have demand for JFK/EWR come from the whole NY area and for LGA you could have just New York's municipal population. For Whiteplanes/Newburgh/Long Island, demand comes from the local communities.

Of course, the way I see it is pretty complicated but, I dont really think there is anything else outhere. :P :)

Quote from: sami on September 04, 2009, 03:23:58 PM
There will be no "submitted routes" as the idea is not to mimic what real airlines do and where they fly, the demand must be fully generated..

Okay, then you can use the B option for those tiny airports in cities with a major one.

I think a reasonable "sphere of influence" might be based on the size of the airport. That would be easiest to program.

Another possible way to calculate/complicate it would be to take the traditional sphere of influence and add (1/(recommended fare-actual fare). This would mimic the effect of a lower fare on people's willingness to travel further by showing larger demand.

The problem is that Sami then has to account for that on EVERY city pair and every shared airport influence zone.

A compromise, Sami, would be to calculate all those "extended" influences fewer times a day than you do the immediate market of a fare.

I don't see the ultimate point of having these small airports remain small?

Again, the entire point is not to mimic reality.  Why should Burbank be perpetually limited to being only a regional player?  Why are some people stuck on making sure that these small airports stay small?  I fail to see the point of that.  If there's a big airline using LAX as a major domestic hub, why shouldn't I be able to "sneak in", start an airline in Burbank, and work to steal at least a sizeable percentage of their business away?  Why shouldn't we be able to make Burbank the next LAX?  At least provided it has the infrastructure (within the confines of what we have modeled in the game) to do so.  If they really are, literally, "small" airports -- with short runways and limited hours, then they'll be self-limiting as a major player for that reason alone.  But, outside of that, there's no reason we should be attempting to limit their potential.

Now, as the game progresses and we finally get connecting passengers, then LAX will naturally had an advantage for international connections at least.  But there's little reason why Burbank, or any of the countless others, shouldn't be equally viable as a destination airport for that municipal region.  This already happens now -- people don't fly to Burbank or Ontario or John Wayne because they want to go to those immediate areas, they do it because it's cheaper (often MUCH cheaper) and easier then the behemoth that is LAX.  Anyone who's flown into LA knows that LAX only makes sense if you're connecting somewhere or have to go somewhere right nearby -- any of the countless surrounding airports make much more sense most of the time and are growing everyday for just this reason.   Southwest, one of the most successful airlines in the world, did precisely this at Love field just a stone's throw from DFW, even with all the restrictions that were placed upon their operating out of it.  The strategy of using smaller airports nearby these huge mega-airport is practically the only viable one for any new carriers around the globe because the world's major airports are already packed full.  

You cannot compare DAL/DFW to what your saying because DAL was the first airport there and Southwest chose to stay there + its much closer to the center of Dallas.

I do see your point, but there are reasons why the airports that are big... are big. LAX is very centrally located and therefore can be looked at as Los Angeles Airport, while the other 4 airports serve specific purposes to there near by communities.

For example SNA/ONT are close to Disney Land and all those other parks.

and, I think the point is to mimic reality to a certain point... just not exactly, as it is now.
It just isnt feasible to think that BUR could ever handle as many pax/flights as LAX can. [from an airport standpoint and a geographical standpoint.].

I think there are one more difficult case happened at China: the Pearl River Delta region, having HKG, CAN, MFM, SZX and ZUH within 100NM ;)  HKG's long international demand is not just based on local demand, but also some Taiwan or SEA connection, also competing with CAN for demands amount South China, and the Cross-Strait demand from Taiwan with MFM; CAN has inter-relation with SZX in domestic and some international demand; SZX also has a big international demand and a number of short haul international demand; MFM has competition with HKG for Cross-Strait and SEA routes; ZUH is the smallest but also having competition on domestic with others. All of them have a long runway and long running hours. Also there are no domestic demand for HKG and MFM because they are independent administrative regions of China and have their own boarder.

I don't have the idea to solve it, but I wonder the methods above can help to handle the problem :-\

I like the kernel of Sigma's idea. I also think would be easier to program.

Let the permitted departures govern how large an operation can get.

The only problem with it is that then you have to program what the sphere of influence of an airport is. So if you operate out of Newbergh (KSWF) -- on Long Island -- how would YOU measure the difference in influence between that, KLGA, KJFK and KENR? I would say that while fares alone would -- and do get many people to go out there, that as you grow further from the "center" that your influence must wane. There's a reason people fly out of LaGuardia -- and it's not always fare.

My problem would be determining WHERE that center is. Sami's going to have to take all these communities he has mapped and somehow assign airports to them.

Should that "influence sphere" be based strictly on x NMs from the airport? Then traffic is determined by the population within x NMs (with arithmetically diminishing percentages as you go out)? Or are there other factors to consider?

Perhaps the "sphere" could vary by population density.

So if you're out in the middle of South Dakota your sphere, at its limits, would be well over 100 miles in radius.    But if you're at NYC, that sphere only radiates, say, 10 miles.  And within that sphere, as you radiated further from the center, the population would be less likely to travel to your airport until it got to 0.  In a perfect world you'd consider geographical barriers, but that would be difficult.  Considering political barriers would also be nice, and would be easier than geographic ones, but still quite difficult I'd imagine.

The purpose would be to represent greater transportation options as wellas the fact that, the greater the density, the more resistance to travelling further (traffic, time to travel X distance, etc).

The problem then lies in what "density" do you use.  You can't use that of the area immediately around the airport, because an airport in a rural area near an urban one could end up with a large sphere that fully-encompasses an urban area (or in many cases, several urban areas if they were close enough and the airport rural enough to be granted a large sphere).  

As an aside, we have "Airport Size" in the game now.  While we should start with the figures that are already in there now so that "large" airports are already large even when the game starts, that figure ultimately should be variable based off the number of routes/flights flown out of an airport (or, even better, the number of pax going through).  And certain costs need to be a function of that number -- particularly landing/pax fees.  Perhaps it could even change how often or how many slots are added each year.  This would make smaller airports attractive for start-ups, particularly later in the game due to their lower costs as well as having available slots, but it would prevent an airline from jumping into a municipal airport smack downtown somewhere that happens to have decent infrastructure, and turn it into a major bustling airport without having to pay the higher fees of those in 'larger' airports.  If an airline really was filling up every slot, the airport would have to increase their fees to cover the operating and capital improvement costs necessary to provide service.

and we also have to take into account wealth/affluence.

BOM might have apopulation of 20 million.... but has way less traffic than SEA with 4 million people.

I think it would way too complicated to use a sphere of influence system based on pop. density because of what Stigma said earlier.

However it makes the most sense....

Don't limit their capabilities please? LGW should have a chance to be LHR  ::). So let them serve the same population. It'll be very interesting. And... we won't be always seeing LHR at the top.

I have an idea.

We calculate the catchman area for each airport based on it size (infrastructural)
Eg: Since LHR has a bigger infrastructure than LCY, LHR is bound to have a much bigger catchman area than LCY.

The cathman area will be depicted as a circle on a map. The circle will be colour-coded from green to red (like the load factors), where green is an area which is very likely to use the airport, and red can only be attracted to the airport (eg by low fares).

There will be 3 circles for each airport: domestic, international, intercontinental. Obviously, this is because the catchman area varies according to the flights people have to take. The intercontinental catchamn area is bound to be bigger than the domestic one.

Where the circles overlap, the airport which circle results greener in that area is bound to take the majority of the traffic. Though, airlines can compete on this with fares or other factors such as comfort etc. Thus, airlines based at different airports will be able to compete with each other for city to city based demand as smaller airports can now "steal" traffic from bigger airports as they usually have the advantage of being closer to city centers.

How about just sharing demand based on distance between airports?
For example:
Domestic flights: demand combined for airports within 25 Miles
Short Haul: Combined for airports within 50 Miles
Long Haul: Combined for airports within 100 Miles

So LHR and LGW would share all demand, but they wouldn't share domestic traffic with STN, whilst all three would share international traffic

Distances could be varied by country, as the UK is more densly populated than the US for example.

Large airports could have a preference modifier based on their current size so LHR would be 5x, LGW 4.5x, STN 4x, etc which influences passenger choice along with price, time, seat quality, etc

I don't know much about progamming, but I imagine it'd be fairly simple to combine the existing data rather than creating a whole new model?

Thinking into this a bit again for change (..after a year).

The population data, growth rates, GDP data and it's history are mainly all OK and needed elements to make this work. But that alone does not give anything yet, as the model has to be more specific and go into more details to be able to create better regional variations and realistic scenarios about popular tourist or business destinations. Plan is to completely exclude the current demand system, and all real-world passenger demand data and make the system behave naturally on it's own by giving it only values of the population and travel needs - combined with available airlines and their tickets.

A big project all in all that one should not expect in a year at least, if ever. All is still just testing.

Anyways ... I figured that the easiest way to incorporate this "regional knowledge" into the system is to create a world of squares (1x1 lat-lon spacing). There are some 130 000 such squares inside the globe I believe but land only covers some 40 000 of them. So piece of cake, just check each of these and check if the square contains areas that are a) major business locations, b) popular holiday destinations (include main seasons for travel too; all year; or only part year?), c) capital city of country or other major administrative center, d)  ... something else that needs to drive the demand up from any other area.

Did you lose track already? ;D

When we combine this additional data that needs to be manually inserted (to this help will be needed) with the city&population data  ... and that combined again to data of available airports .. etc ... and that we again would combine into a database of country relations (ie. friendly or unfriendly countries) and such other data ... then we could calculate each square separately, and determine the travel needs for people from that square to somewhere in the world thus making the demand values.

User would basically look still for demands from airport to airport; but the system will then just calculate the catchment area of that airport as the base population and check their travel needs from all squares that are within the reach and combine the data into the demand values. However this sounds easier since there are for example country borders that in some cases can be crossed and in other cases cannot, there are mountains, there are seas etc which may still all be inside the same square but essentially impassable... So that 1x1 lat-lon square size may be too much. But reducing it to 0.5x0.5 would bring quite much more work and requires more processing. The size of the squares are 111x111 km per side in equator and getting narrower when coming closer to poles, for example 71x111km at 50N...  (oh, and also, what about short island hops that happen inside that same 100x100km square?)

Pic #1: Here's part of USA and of it's ~5500 squares just for fun.

Pic #2: Squares combined with population data pointers (each dot is a city unit with population number and yearly pop. growth rate number).

Feel free to brainstorm.

[attachment expired]

About airport catchment areas  ... it is usually defined as travel time to the airport, instead of distance. Normal max. catchment area limit is 2 hour travel time.... But with the available data I believe such system is hard to make up, but would be nice.

Here's some catchment areas purely based on 100km range ring. As you can see Helsinki ring would go all the way through the sea to Tallinn even, and that's a trip people don't take unless they fly far away.

[attachment expired]

Wow, excellent thread.

Now I understand what you meant by regional demand.  It can be quite complex.  It introduces a concept of competition between airports.  Player based in some airport can steal local demand from another player in neighboring airport.  It is very interesting, but as I said, quite complex.

Deciding between:
1. regional demand
2. connecting traffic
from the point of view of game playability, I think connecting traffic adds more value.  But, unfortunately something on the regional demand has to be done to get realistic demand figures, in order to do the connecting traffic.

I envisioned only a half step on regional demand that is far easier to implement than a full fledged regional demand.  It could be done by fixing local demand to an airport with more realistic figures and concentrating more heavily on connecting traffic.  This way,  LGA, JFK and EWR would all be assigned some local demand, and this local demand would stay within the same ratio for the length of the game.

What does a full fledged demand buy you?
- more perfect assignment of demand to the airport
- competition between airports
- potential of airport to grow in influence over surrounding squares
- saving a half step in implementation, since 1/2 + 1/2 tends to be > 1

Again, for purpose of game playability, these are much smaller than connecting traffic, ability to grow the slots of your airport as you turn it into a hub...  For the purpose of running hubs, connecting traffic is more important than perfection of determining local demand.

I have a lot of ideas on the regional demand as well, and I will post them in follow-up posts.

Comment on demand in general:

Suppose we jump forward and assume we have figured out a local population demand for flying to places.  Suppose the demand (aggregate demand for flying) boils down to a single numerical figure for the airport (or a square).  How should the demand for a route between 2 airports (squares) be determined?

I think it should be a combination of 2 things:
1 - simple population demand, people visiting families, minor business travel.  If we have a numerical value for aggregate demand for airport A (or square A) and numerical value for aggregate demand for airport (or square) B then good model for A-B demand is a simple multiplication of those numerical values.  Suppose you have A-B pairs with following values:

<pre>
  A  |  B  | Demand |
   0 | 200 |     0  |
   1 | 199 |   199  |
  10 | 190 |  1900  |
  50 | 150 |  7500  |
100 | 100 | 10000  |
</pre>

This way, demand for a route from a low population place anywhere (and back) would always be tiny.

2. Demand to an attraction.  This would be the second component of demand for A-B route.
Suppose A has an attraction with some rank of attractiveness.  The demand for this 2nd component would be the magnitude of the attraction at A * numerical value of B.

This way, demand from B (a major population center) to A (tiny island in Caribbean with almost no population but beutiful beaches) would be a function of beuty of the beaches at A multiplied by population representation of B.

I just had an idea how to figure out the vacation / convention / business center demand.  A good proxy for all of these combined would be hotel capacity in the area.  And if that is hard to get, just number of hotels would probably do.

Faster just click all that data in manually (by clicking the desired spot at googlemaps and then entering the data into appearing popup, and pressing save) than try to incorporate that data from various sources I'd say.

A couple of things.

1. I think the squares are too large. I think your idea about slicing them in half is a good one.

2. I think it would be more realistic if the catchment area of any given airport were directly proportional to the marketing spent by an airline in that airport. OR by the number of flights departing from that airport. In your example Somero residents would have an equal affinity for Turku, Helsinki or Nokia (?); in the system I'm suggesting the airport with the most spent out of it would draw them out more.

3. I understand JumboShrimp's diagram and I even get the idea of using Google to post features on a per-square basis. But I'm bothered by the randomness of grid-to-grid travel. If I understand this correctly, the odds of a person in Tallahassee going to the grid square of Macon or to a square in Malaysia are roughly equal as long as they have the same population? How does the international/domestic mix apply here, if at all?

Quote from: Kazari on July 24, 2010, 02:59:49 AM
2. I think it would be more realistic if the catchment area of any given airport were directly proportional to the marketing spent by an airline in that airport. OR by the number of flights departing from that airport. In your example Somero residents would have an equal affinity for Turku, Helsinki or Nokia (?); in the system I'm suggesting the airport with the most spent out of it would draw them out more.

Interesting idea - catchmant area for player would depending on marketing of that player.

I like the idea of the catchment area being variable.  The greater percentge of the travel demand being fullfilled by the airport (player) should in turn grow regional influence of the airport (or player)

Quote from: Kazari on July 24, 2010, 02:59:49 AM
3. I understand JumboShrimp's diagram and I even get the idea of using Google to post features on a per-square basis. But I'm bothered by the randomness of grid-to-grid travel. If I understand this correctly, the odds of a person in Tallahassee going to the grid square of Macon or to a square in Malaysia are roughly equal as long as they have the same population? How does the international/domestic mix apply here, if at all?

The way it should work is that you start with demand of airports (or squares).  Multiply a pair of them to get the demand for the route.  Then, apply a distance multiplier.  Let's say the sweet spot is 500 miles, zero demand is at 50 miles.  So the demand would start at 0 at 50 miles, go up to 100% at 500 miles, and then start a long descent.

I thought of a solution of the islands.  Instead of going down from 500 miles, go up instead.  So each island airport would have an "IsIsland" flag, and a different multiplier would be applied.

[attachment expired]

Quote from: Kazari on July 24, 2010, 02:59:49 AM
1. I think the squares are too large. I think your idea about slicing them in half is a good one.

I think would agree that the squares are too large for Metropolitan Areas. However, for most of the world they are fine. For example, Siberia in Russia will not have any demand for flights. I think the squares should be a factor of population density. The larger the population density, the smaller squares are used. The smaller the population density, the larger squares are used. This will probably allow much easier coding and time management should this be implemented.

Quote from: Kazari on July 24, 2010, 02:59:49 AM
2. I think it would be more realistic if the catchment area of any given airport were directly proportional to the marketing spent by an airline in that airport. OR by the number of flights departing from that airport. In your example Somero residents would have an equal affinity for Turku, Helsinki or Nokia (?); in the system I'm suggesting the airport with the most spent out of it would draw them out more.

I agree with this statement. However, it should be a total of all Airlines operating out of the airport. Meaning, it should incorporate route marketing. If an airline is not based at an airport, but flies there and thus has route marketing on that particular route, that marketing money spent should be taken into account.

I believe the Airport's Image (to define it) could be based on:

1) marketing,
2) company images of all airlines that operate there and
3) average pricing.

The airport's image could then become the "multiplier" for demand like which was discussed earlier. This multiplier could then increase (or decrease) the sphere of influence of the airport itself.

Quote from: sami on July 22, 2010, 11:07:30 PM
Here's some catchment areas purely based on 100km range ring. As you can see Helsinki ring would go all the way through the sea to Tallinn even, and that's a trip people don't take unless they fly far away.

Finally, in order to help solve the connection problems and passengers traveling between countries (or islands) to get to the airport, you can do the either of the following:

A) Have border crossings reduce demand by 50%. This is because of customs and the lack of will of the traveler to change countries unnecessarily. I feel even this 50% reduction could still generate (and steal) more passengers if the airport in question had a multiplier of 150%-175%.
B) Make the airports in question a ratio of airport images divided by 2. Say Airport A is 80 and Airport B is 10 (using the current scale of -100 to +100). The math being 8/2= 4. Thus Airport A's multiplier is 4 times as large as Airport B and thus has a much larger draw.
If traveling to the airport means the traveler must cross a border, then the ratio could be divided by 2 or 3. Thus, assuming that Airport B is in a different country than A, Airport A's multiplier is only 2 or 4/3 as large as Airport B.

I hope that this all makes some sense. I feel this question/ problem is definitely on the right track to being solved.  :)

Cameron

I like it...

But don't forget a lot of larger airports function as a hub to an entire country. EHAM for example is the main airport for the Netherlands and I know a lot of Belgium residents find it easy to use Amsterdam as well.

Quote from: Maarten Otto on July 24, 2010, 09:23:28 AM
I like it...

But don't forget a lot of larger airports function as a hub to an entire country. EHAM for example is the main airport for the Netherlands and I know a lot of Belgium residents find it easy to use Amsterdam as well.

That might be too complicated for the first version.  :-\ Though with what I was saying, the countries in the Schengen area will (assuming it exists in the game year) create no borders between Belgium and Amsterdam, thus it is merely a factor of distance between the 2 airports. On that same note though, the base distance (from which to base the multiplier) could be manual set to be higher for the European airports due to increased infrastructure- high speed rail notably. These base distances could be manually set per geographic area prior to the game starting- each tailored to each geographic needs. Greater distances in Europe for example.

I've only just started playing but this all looks really exciting - even if it's a way in the future.

I think the small squares approach is about as good as you'll get. With all the players from different countries that there appear to be on here I'm sure you could find a team of researchers to help out with the data for various parts of the world as well if needs be.

I think the larger squares will do the job to find out how things work.

Don't forget The amount of work needs to be tested. So you better do large squares of one continent (Europe) first to see it it works out well. Then you can adjust it to get better results. Finally when all is working properly, you can decide to take the whole thing one more time into the next level of detail.

I think this feature should be implemented in phases so people can get used to it and Sami can work on it without time pressure.

Therefore I suggest the following roll-out:

- Europe in large squares, and test by all players in a Euro Challenge scenario.
- Europe in Smaller squares. Fully tested in a next Euro Challenge.
- Northern America smaller squares.  Fully tested in a North America Challenge.
- Northern America and Europe together in a trans-Atlantic game world.
- Finally Implement Asia and Oceania as well.

I think Maarten Otto is on the right track, but why not consolidate that release schedule into this:

European Challenge: Larger Squares- merely to see if it will work. Game time 5 years or something small.
Trans-Atlantic Game: Larger Squares- Full game style. Long term testing.
Whole World: Larger Squares- Final Prototype
Whole World: Smaller Squares- The End result.

The first three would be game engine 1.3 (I would guess) and the last would be 1.4. 1.4 could then be developed in 9 months-1.5 years as the game worlds were testing the larger squares. I think less releases would take less time and the lessons learned through the Larger Square games could then be applied in full to the final release.

just to mention this... if you have a game from the fities into our time, then the amounts of flights that are offered from one airport would have to influence how it is improved over time... so, this would have to be modeled as well... and this is getting even more complex... maybe even not possible to simulate... or would you also simulate the politics and how easy/hard it is to develop airports in different countries? ... e.g. in Switzerland... try to build a new runway... you'll get into troubles for decades
so I wouldn't make it that complex and simply link some airports together (KJFK, KLGA, KEWR for example) ... oh, and by the way... a lot of the demand from KATL for example are transit passengers... how to model that?  8)

Quote from: meiru on August 01, 2010, 07:52:59 PM
just to mention this... if you have a game from the fities into our time, then the amounts of flights that are offered from one airport would have to influence how it is improved over time... so, this would have to be modeled as well... and this is getting even more complex... maybe even not possible to simulate... or would you also simulate the politics and how easy/hard it is to develop airports in different countries? ... e.g. in Switzerland... try to build a new runway... you'll get into troubles for decades
so I wouldn't make it that complex and simply link some airports together (KJFK, KLGA, KEWR for example) ... oh, and by the way... a lot of the demand from KATL for example are transit passengers... how to model that?  8)

That would be a nice extra feature - which is - development of cities (their growth rates) coould depend not only on their country population and GDP growth, but also on how well their demand is being served (by all airlines serving that city).

Quote from: JumboShrimp on August 02, 2010, 02:38:26 AM
That would be a nice extra feature - which is - development of cities (their growth rates) coould depend not only on their country population and GDP growth, but also on how well their demand is being served (by all airlines serving that city).

I think he was talking about airport improvement, not city improvement (though that'd be pretty cool too I suppose).  That's something I talked about either early in this thread or in one of the other ones that were discussed a year or so ago.

If airports are in AWS what airports are in reality, then we once again end up with a world that does little but recreate the same routes we have in the real world simply because we're recreating the infrastructure and that infrastructure is necessary.  Atlanta, for example, would continue to be a mammoth airport simply because it's runways/capacity allow it to be a major player.  But, in real-life, if not for the fact that Delta had chose for it to be its hub, there's no reason why Atlanta would have become a fraction of the airport that it has become.  Its airport would have instead been like most every major city airport in the southeast US.  It could have just as easily chosen Birmingham or Charlotte.

There needs to be a system that creates additional capacities (within some bounds) as demand requires it.  But that becomes very tricky.  People would then complain that Dallas Love has international routes. Or complain when London City is the biggest airport in Europe.  Up to sami whether he wants to go down that road or not, or even go down the infinitely more complicated road of trying to establish limitations on what certain airports can and cannot do within AWS.

Quote from: Sigma on August 02, 2010, 05:26:58 AM
If airports are in AWS what airports are in reality, then we once again end up with a world that does little but recreate the same routes we have in the real world simply because we're recreating the infrastructure and that infrastructure is necessary.  Atlanta, for example, would continue to be a mammoth airport simply because it's runways/capacity allow it to be a major player.  But, in real-life, if not for the fact that Delta had chose for it to be its hub, there's no reason why Atlanta would have become a fraction of the airport that it has become.  Its airport would have instead been like most every major city airport in the southeast US.  It could have just as easily chosen Birmingham or Charlotte.

I am all for adjustment to demand to reflect only regional demand, and then, players will be able to write their own history by locations of their hubs.  Passenger traffic between AB pairs will depend as much (or more so) on connecting traffic as the the local demand.  Then, Charlotte can indeed become the busiest airport.

Quote from: Sigma on August 02, 2010, 05:26:58 AM
There needs to be a system that creates additional capacities (within some bounds) as demand requires it.  But that becomes very tricky.  People would then complain that Dallas Love has international routes. Or complain when London City is the biggest airport in Europe.  Up to sami whether he wants to go down that road or not, or even go down the infinitely more complicated road of trying to establish limitations on what certain airports can and cannot do within AWS.

I think that a feature to grow capacities of airports (slots) based on player demand for slots could probably go into version 1.3, rather than wait for huge overhaul of demand and connecting traffic capability.  This feature is, IMO, small in scope and completely independent of demand / connecting trafic project.

It would enhance playability and it would start an effort to change the game world from striclty fixed and copying history / decisions of real world airlines to history written by players of the game scenarios.

BTW, I am playing ATB, and DTW has this incredible demand to AMS.  No real reason for it, other than decision of NWA and KLM to cooperate...  In the AWS, it should be based on how the AWS airlines operate...

The starting point of any scenario should correspont to the real world of that era (as far as sizes of airports, runways, slots), but from that point, the airports should develop on their own, based on player demand for slots.

That growth (of slots) could either be automatic (system would grow slots when they are running low) or player initiated (and paid for).

As far as DAL having international flights, I would not complain, but Sami probably already has an "international" flag for airports, and if he does not, it could be added.  But that's an extremely low priority item IMO.

Quote from: Riddle Me This on July 24, 2010, 08:34:33 AM
A) Have border crossings reduce demand by 50%. This is because of customs and the lack of will of the traveller to change countries unnecessarily.

This is not realistic everywhere, especially in Europe (there are no customs for individuals when travelling between EU members /with some exceptions/ and no immigration inspections between Schengen Area members)... Second sentence is not really true for most of the world.

Generally I like the idea of squares, but I believe that flight connection feature should be completed first, otherwise it won't work properly...

Quote from: Samo on August 15, 2010, 12:05:15 PM
Generally I like the idea of squares, but I believe that flight connection feature should be completed first, otherwise it won't work properly...

Well, the 2 go hand in hand, but if it is going to take a year or more to get the city based demand done correctly but only, say 3 to 6 months for the connection feature, I would opt for connection feature first, with current less than perfect demand distribution.  Basically, bypassing the squares / city based demand to get the connection feature done ASAP.

I feel that connections will be just as complicated... especially for players.

Anyway, city based demand opens up many more possibilities in the game, especially when it comes to allowing people greater choices in basing.

So, for instance there will possibly be many airports that can fly from a to b if they are in the same box.  This will change the dynamics around MANY cities.  For example, flying out of BWI internationally versus out of Dulles.

Also, I feel that this should never be incorporated before we implement some controls first (for instance, flying larger a/c out of London City).  

Swiftus.... those controls are already in place! Sure, you can fly an A319 into LCY, but see how many passengers it holds. ;)

Sami the Benevolent finally changed it? 

That's a great thing to hear!!!

I am more for authenticity than I am for fun.  I'd love to see this stuff.

However, I should be able to fly internationally from Reagan instead of Dulles in a City Based Demand model.  That will be interesting. 

Except that there is the Perimeter rule, so you cant fly more than 2500 miles, exculding SEA and LAX. So Canada, Mexico, and the carribean would be fine, but transatlantic is more doubtful.

Quote from: Seattle on September 03, 2010, 06:36:15 PM
I feel that connections will be just as complicated... especially for players.

Well, it would make for a much deeper simulation, and it would introduce something sorely lacking (IMO) - competition between players.  The competition is very limited, as is.  Ok, there may be more than one player starting from the same base, as you, but eventually (with exception of slot limited airports), one player will become dominant, and from that point on, we are pretty much playing solitaire.

The bases added some competition, but with the 70 plane limit, you can't really challenge a larger player at his home turf.  You can challenge a smaller player at a second tier city, and that's about it.

The current demand system is based on existing hubs.  Meaning that if a guy is flying from Buffalo, NY to, LHR via JFK, he is built into the LAX LHR demand.  If there is a dominant player at LHR (and of course there are no slots), and a dominant player at JFK, no-one can compete for this passenger, and the demand is misplaced anyway, because it is represented as JFK-LHR demand, rather than BUF-LHR demand.

With the connection feature, anybody (or their team-mate) who happens to fly to BUF and LHR can compete for this passenger's business, not just JFK and LHR incumbents.  So there would be a lot of indirect competition.

Quote from: Seattle on September 03, 2010, 06:36:15 PM
Anyway, city based demand opens up many more possibilities in the game, especially when it comes to allowing people greater choices in basing.

I guess there may be many interpretations of what a city based demand really is. It can be:

1. just a way to figure out inherent airport (demand originating from airport's surrounding ares, not from connecting flights).  This would be my preference to get things off the ground quicker.  Under this scenario, each airport would be allocated some demand based on the population surrounding the airport.  For example, JFK would get some allocated, as well as LGA and EWR.  The ratio would stay constant throughout the game.  All the action would be in building connecting flights.

2. City would have a certain demand, and airports serving the same city can steal traffic from each other from overlapping areas.  Demand would really be tracked not on airport to airport bases (2755 of them) but on the land squares, some 40,000 of them, and even those square were too big according to some.  So multiply 40,000 x 4 if you want each square to really be divided into 4 sub-squares.

And what does it buy for us?  Not a whole lot, because of the 6,000 pax demand between JFK and LHR (in current ATB), maybe 2,000 live withing the squares of JFK and LHR, and the remaining 4000 are transferring from places such as Buffalo, New York, Scranton Pennsylvania, Glasgow, Scottland.

IMO, multiple airports with overlapping coverage is just an ugliness of the real world that threatens to bog down the beauty of the simulation that Sami is building, with little to no improvements to playability.

As far as flexibility in player basing, we are talking about a handful of cities with these "issues" needing flexibility.  But the LHR problem would be greatly diminished.  If you take current AWS demand allocated to LHR, in the new version of demand (whatever it turns out to be)  LHR demand will be cut down to probably no more than 25% of its current demand.  The demand will be distributed throughout the other UK and continental airports that LHR is serving (connecting).  And suddenly, LHR slot problem disappears.  It is no longer crucial to be based at LHR, to have slots at LHR, since the action is in the connecting flights, and the hub connecting these flights can be anywhere.

I've worked on this feature a bit too .. The population data globally is almost complete now. But this feature will eventually require a huge deal of manual work.

So far I know roughly the borders of countries, location of cities and their populations (and historical populations). In other words the information where people live has been now established, and also it has been distributed into the 'square model' I talked earlier (the model will not consider individual cities, but assigns each city into square and each airport will access the population data of the nearby squares to determine the demand).

But I know nothing about what happens in each city (or "square area"..); in other words is the city a famous tourist location, central of large business life .. etc. This data needs to be manually inserted for each country and is a big task, and will require community help eventually.

But for now I will continue to make small-scale experiments on how to proceed further. But the first step towards this feature (= base data) is almost done, the next step (= detailed data) and further steps (= forming the demand demand & airports accessing them) are much more complicated than this mere data collection.


(edit: there are some 50 000 'squares' in the world, but according to present data about 9000 of them have some sort of city or village. But seems that the data still has gaps in rural areas.)


[attachment expired]

What about we do the city demand like a sum of the demands by all the airports serving that city, and make it grow according to historical passengers of both airports?

For example, Bucharest has 2 airports, Baneasa(mainly low-cost) and Otopeni.

Bucharest's total demand would look like this:

Year       Baneasa       Otopeni       Total

2005      385,759      3,031,719    3,417,478

2006      673,000      3,513,576    4,186,576

2007      970,000      4,978,587    5,948,587

2008     1,768,000    5,064,230    6,832,230

2009     2,005,694    4,483,661    6,489,355

I'm not saying that you should make it look like the exact numbers, but like make it a sum of the airports serving that city, and when you plan the route to have like a drop-down box where you select at which airport you wanna make that route to... This way we can implement the"profitable" low cost airline aswell :P

I just wanted to praise you, Sami. This is a significant development.

Quote from: sami on December 07, 2010, 06:00:07 PM
But I know nothing about what happens in each city (or "square area"..); in other words is the city a famous tourist location, central of large business life .. etc. This data needs to be manually inserted for each country and is a big task, and will require community help eventually.

I don't know how you are mining the population data, for squares (Google?), but I am glad you have that part figured out.

As far as figuring out whether the square contains important business or tourist centers, doing this manually will be very time consuming and subjective.  A good proxy for whether the the area has any kind of attractions is the hotel capacity.  While that (number of hotel rooms per square) may be hard to figure out, is it possible to figure out jus number of hotels - through some Google data mining?  That would be a good starting point, and the raw number of hotel establishments can be scaled by population density of the squre.  A hotel in Manhattan may have 100+ rooms average, while a hotel in a rural are may have 20 room capacity on average...

This step could be sufficient for 99 out of 100 squares, and manual adjustment would be necessary on just ~1 out of 100. squares...

Quote from: sami on December 07, 2010, 06:00:07 PM
But for now I will continue to make small-scale experiments on how to proceed further. But the first step towards this feature (= base data) is almost done, the next step (= detailed data) and further steps (= forming the demand demand & airports accessing them) are much more complicated than this mere data collection.

That is a complex problem, but it is just a question of developing algorithms and fine tuning them.  The algorithms may be somewhat computantionally intensive...

The way I think it should work is as follows:

For each AB pair of squares:
1 - we know the AB demand from the population / business / tourist data
2 - put all this demand into 4 buckets: AB-Y bucket with certain number of passengers, AB-C, AB-F and AB-cargo buckets.
3 - gather the list of flights (including connecting flights - up to 2 stops) that can take passenger from square A to square B
4 - rate the flights based on all of the current desirability factors.  Plus add new factors such as number of stops, distance from square to the airport  
5 - allocate the passengers to flights.  Do this by splitting AB-Y bucket to AB-Y-flight_sequence_1 bucket, AB-Y-flight_sequence_2 bucket etc. based on overall desirability.  This may result in overbooking flights, which we will deal with later.

Next step is we look at each flight.
- each flight will have a certain number of buckets associated with it.  Add up all the Y seats in those buckets, compare with plane capacity.  If demand is, say 2x the number of available seats, split all buckets between those who are going to be taking the flights (1/2 from each bucket), return the rest to their original bucket.

So this would be iterative, it may need 2, 3 or more iterations.  So the modification of the algorithm would be:
1 - we know the AB remaining demand from the population / business / tourist data that are left to be allocated from previous iteration
2 - we will already have them in the buckets, some returned to these buckets because of lack of capacity
3 - gather the list of flights (including connecting flights - up to 2 stops) that can take passenger from square A to square B that still have capacity left
4 - rate them as above
5 - allocate

Then again, we will look at the flights, their capacity, and the passengers that don't fit will be returned to their original AB buckets.

Each iteration will take less time, since
- there will be fewer and fewer AB squares pairs with passengers that have not been served in previous iterations
- there will be fewer and fewer flights with capacity left

In case you take up this "bucket" concept, it can be used to refine the pricing demand to make it a lot more elastic.  Instead of fixed YCF categories, the demand between any AB squares can be split into more price based buckets.  For example, now, we may have
90 pax Y demand with default price of $100
9 pax C demand with default price of $300
1 pax F demand with default price of $600

Total 100 pax.  Suppose you split it into more bucket, that are more gradual, we can model a scenario where we have, let's say 1 bucket at 100% price of $100, another say 6 buckets above that price going up to $600+ price.  The sum of pax would remain 100, but the passengers would just take the seating based on the prices and what they are willing to pay.  Let's say:
$100 - 50 pax
$120 - 25 pax
$150 - 13 pax
$200 - 5 pax
$300 - 4 pax
$450 - 2 pax
$600 - 1 pax

Total 100 pax

We can add additional price buckets:
$90 - 10
$80 - 15
$70 - 25
$50 - 50

So if an airline were to price their Y seats at $70, $30 below the default price, the demand would go up by 50%, and at price of $50, it would double.

This way, the demand elasticity would be closer to real world, and cutting prices would not just take passengers from the other guy, but more passengers would become available...

When calculating the demand between two squares or "areas" .. what would be the needed infos / factors for every square?

- population (got it)
- country GDP (got it)
- other country related variables (got it)

Manual work is required for assigning the following information for each square:

- does the square have cities or areas with some of the following:
    - industrial area (increases cargo & business pax)
          - size: small to large

    - holiday area (increases leisure pax)
          - size: small to large
          - seasons: winter/summer/spring/autumn

    - location for business, or capital or other administrative city/region (increases business pax)
          - size/importance: small to large?

     - level of local infra; roads, trains, ..etc. (able to make short journeys land-based?)

    - ...what else that could affect the air traffic demand?


- or is the square:
    - ocean (no pax/cargo; this is already done)
    - inhabitable area (desert, mountains; no pax/cargo)

Quote from: sami on January 25, 2011, 02:12:08 PM

    - ...what else that could affect the air traffic demand?

Other transport options... for example, islands usually have relatively high passenger demand for the size of their population as trains and cars are not an option. (Eg. Isle of Man/Channel Isles to UK airports).

Also cultural/language links... such as naturally high demand between Spain and other Hispanic countries, Portugal and Brazil and France and French speaking Canada. Same can be said for Miami having strong links with Hispanic central America.

Re: Data collection

I found something for Europe, that if we had this available for the entire world, it would solve all the pax demand issues.
http://epp.eurostat.ec.europa.eu/statistics_explained/index.php/Tourism_statistics_at_regional_level

In particular, this graph: Number of bedplaces in hotels and campsites per 1 000 inhabitants
http://epp.eurostat.ec.europa.eu/statistics_explained/index.php?title=File:Number_of_bedplaces_in_hotels_and_campsites_per_1_000_inhabitants,_by_NUTS_2_regions,_2007.PNG&filetimestamp=20091002110042

would make things really easy.  We have population per square.  Number of hotel beds per 1000 inhabitants would give us number of hotel beds in the square.  Hotel beds are a great proxy (IMO) for overall passenger demand.  I will look around to see if I find something.

We would still need the business / industrial area info to adjust mix of business passengers and cargo. 

Quote from: sami on January 25, 2011, 02:12:08 PM

    - ...what else that could affect the air traffic demand?

1)  I think you should extend the definition of

Quote from: sami on January 25, 2011, 02:12:08 PM

     - level of local infra; roads, trains, ..etc. (able to make short journeys land-based?)

The local infrastructure should include airports.  I think that if there are no airports in a given "square", demand should move into neighboring squares.  For instance, Rapid City (Where I live), while only at an official population of 65,000, doesn't have a city over 15,000 for 120 miles, and the nearest airport (other than ours) with jet service is 300 miles away.  Therefore, the serviceable area is roughly a population of 400,000. 

2) I think you should also take security into effect. International demand out of "non-secure" squares (Pakistan, Iraq, Lebanon, etc.) should be less.

I agree with Rushmores 2 point only I'd expand on that by saying inbound and outbound flights to those areas. Also areas of conflict (if these are implemented events in later versions) should affect the demand to those countries or even stop demand all together if given the right situation (ie Flying from South to North Vietnam should be impossible during the war years for obvious reasons)

Quote from: sami on January 25, 2011, 02:12:08 PM
   
- ...what else that could affect the air traffic demand?
   

Geographical size of the country in question combined with the availability of other modes of transportation. As an example, Norway has a high percentage of air travelers compared to it's population due to the distances involved when traveling. In addition, roads and railways are not a satisfactory travel option, which leads people to the airports for longer journeys. Australia is another example, with huge distances involved, meaning air travel is the obvious choice unless one has days to move between cities.

On a cargo-related issue, transport of fresh foodstuffs and agricultural products is big business. Salmon from Norway to the US and Asia and flowers from Africa to Europe.

And as already pointed out, ethnic travel demand is a very large factor indeed affecting demand.

Quote from: TFC1 on January 26, 2011, 08:45:23 AM
Geographical size of the country in question combined with the availability of other modes of transportation. As an example, Norway has a high percentage of air travelers compared to it's population due to the distances involved when traveling. In addition, roads and railways are not a satisfactory travel option, which leads people to the airports for longer journeys. Australia is another example, with huge distances involved, meaning air travel is the obvious choice unless one has days to move between cities.

On a cargo-related issue, transport of fresh foodstuffs and agricultural products is big business. Salmon from Norway to the US and Asia and flowers from Africa to Europe.

And as already pointed out, ethnic travel demand is a very large factor indeed affecting demand.

I agree. Norway has a much smaller population than the UK for example, but domestic air travel in Norway is much higher and has some of the busiest air routes in the world. Not all of them are long distances by air (eg. Oslo to Bergen) but the geography in between makes it almost impossible to travel quickly by road or rail.

Quote from: NorgeFly on January 26, 2011, 01:16:47 PM
I agree. Norway has a much smaller population than the UK for example, but domestic air travel in Norway is much higher and has some of the busiest air routes in the world. Not all of them are long distances by air (eg. Oslo to Bergen) but the geography in between makes it almost impossible to travel quickly by road or rail.

Yeah domestic air travel in the UK mainland is virtually non existant except flights from London to the North and Scotland. I guess it's because it's such a small country and the railways and motorways are good.

Quote from: alexgv1 on January 26, 2011, 01:30:28 PM
Yeah domestic air travel in the UK mainland is virtually non existant except flights from London to the North and Scotland. I guess it's because it's such a small country and the railways and motorways are good.

The island if Britain is the size of Kansas... Americans will understand the scope. 

Quote from: alexgv1 on January 26, 2011, 01:30:28 PM
the railways and motorways are good.

I was going to ask if you'd ever been to Britain, then realised you live here  :o

;)

Quote from: JonesyUK on January 26, 2011, 06:07:29 PM


I was going to ask if you'd ever been to Britain, then realised you live here  :o

;)

Well okay I've commuted by rail for 6 years previously and yes I have no end of groans and moans about the service, the delays. Also the traffic jams driving and the idiots on the road. So yes I know what you're saying.

But you can get a high speed rail service to most major cities in the country, and now even to the European capitols of the nearby countries. So maybe the demand for say LHR to CDG, AMS, BRU may be reduced in the future if this is factored into it.

Compared to most countries the transport is good in the UK, say compared to a train journey in the USA (which I have been on) or even driving state to state (which can take a whole day or more). So that is why domestic demand flying in the Americas is so high compared to here. Most of our passengers are just business flyers going to a city for a few days or holiday makers. If you look at South America it is quicker to fly over the jungle than drive or ride through it.

I actually learnt the difference between US and EU markets for flying in the current game world I'm playing. The distances is huge. An average route is 1000NM and in Europe that would take you from one side of the other. I mean there are people in USA that commute from coast to coast to work, for example going from San Francisco to work in Charlotte.

likewise with air travel here in Australia. The distances are so vast that most prefer to fly rather than drive, especially considering the infrastructure here is obsolete and crumbling under existing demand. Hence why Melbourne-Sydney and Melbourne-Brisbane are among the busiest routes in the world.

As for Holland, Schiphol Airport (EHAM) has a rail service to EVERY corner of the country. All are operated at 2tph (trains per hour) or more. There are 9 tph between Schiphol Airport and Amsterdam Centraal alone. And more then 12 tph between Schiphol Airport and Amsterdam South which is the business district at just 5 minutes train journey from the airport.

I don't see how this can work without connecting passenger, but if you included them this would be really cool.

Quote from: Klcosta on June 14, 2011, 05:34:30 PM
I don't see how this can work without connecting passenger, but if you included them this would be really cool.

What?

Sure connecting pax could greatly enhance this feature, but even by itself, it is a hugely better than our current system.

Quote from: BobTheCactus on June 14, 2011, 07:11:56 PM
What?

Sure connecting pax could greatly enhance this feature, but even by itself, it is a hugely better than our current system.

I'm not sure what/how he was referencing connecting pax, but it is key in my opinion.  If I were to open up a hub at some small base like Sioux Falls, SD and flew to/from both JFK and LAX, I should be able to compete for pax on the JFK-LAX flight even though I'm not based there.  When you goto expedia etc you'll see options for connecting at different prices and it's usually MUCH cheaper to connect 1x than fly direct--especially international flights.  Atlanta isn't the biggest city is the world, but it has the biggest airport in the world thanks to connecting passengers.

Dynamic city based demand + connecting pax = ftw :)

Quote from: BobTheCactus on June 14, 2011, 07:11:56 PM
What?

Sure connecting pax could greatly enhance this feature, but even by itself, it is a hugely better than our current system.

You can't make it work without connecting passenger because the number of passengers between hubs like Miami, Paris, Singapur... will decrease and you will not have the option of making up for it with connecting passenger making the number of plausible flights a lot lesser. I don't know if I explained myself so let me give an example:

In real life you have x demand from Valencia, Spain to New York, Boston, San Francisco, Miami... but the demand between either of these is not high enough to create a direct flight. In real life the solution is to create connecting passenger and channel these through a hub. In the current AWS model all of those passengers simply boost the demand between that hub and the final destination. So all the passangers attempting to fly from Valencia to NY, Boston... all apear on the Madrid-NY, Boston... flight or the Paris-NY, Boston...flights. This is just one airport, to Valencia you need to add all the passengers from other small airports attempting to do a long journey that in the real world is done through a hub.With this new system those passengers will no longer appear in the longer flight Madrid-NY or Paris-NY but now appear in the Valencia-NY so now the flight between Madrid-NY has lost a lot of its prior potential, that could be made up with connecting flights but without them you just have a much smaller number of passenger hoping to fly between the two major cities.

I hope I got my point across

Quote from: Curse on June 15, 2011, 07:14:00 PM
Dynamic city based demand + connecting pax = ftw :)

Agreed, but I think we are missing vital and somewhat easy step as well. I am not entire sure if we have discussed including "fantasy" events? I haven't been following the thread for the last couple of months, though I just caught up on this last page.

What if we make the game worlds into a more alternative reality? For example, a war breaks out between 2 previous friendly countries with high pax demand between eachother, thus eliminating demand for those routes. I think there could a canned amount of events that could happen randomly throughout the 30 years of the world. This would change the game from mimicking real routes into a game that could be dynamic enough to provide significant challenges for older, less flexible airlines.

To modify Curse's quote...

Dynamic city based demand + connecting pax + dynamic events= ftw


Some possible events include:
-High Speed Rail opens in California, connecting Los Angeles and San Francisco- LAX-SFO pax demand in half.
-A Tsunami hits a country, drastically affecting flights in the affect region.
-The Vietnam War never happens, or happens at a random time.
-World Economy changes, thus passenger demand goes up and down significantly in a few short months (e.g. our current recession)
-European Union initiation date is random, or potentially nonexistent.
-Any country or region could have a major oil discovery, dramatically improving their economies and passenger demands, along with decreasing the fuel price.
-With any war, there could be an associated rise in fuel prices.
-A Country may gain its independence randomly, if at all.
-Diseases, natural disasters, volcanic eruptions, etc.. The list goes on.

I think you get my point. These could happen once every 10 years, or 2 with in a few months- it would be completely random. I don't mean to include ridiculous, unrealistic events; but having these events affect the game world's alternative reality would drastically improve the excitement and challenge of the game. For some events, (like building the HS rail in California) an announcement could be posted saying that construction has begun on the project and it is expected to be finished in the late part of 1999. This would give airlines notice and they could then adjust to the coming changes. Other events could be completely sudden and unexpected- natural disasters for example.

It would all be random, thus making the game quite dynamic and exciting. And because you couldn't necessarily anticipate things happening, it would be harder to plan farther out into the future. These events would also improve the gameplay for old, established airlines because they could have hard times adjusting to these events, leaving "holes" for new startups or simply bankrupting them completely.

What do you think?


EDIT: I forgot to say fantastic work to Sami and everyone else. This concept sounds like it is quickly becoming more than a concept and I am quite excited to see it in action!

I think the only missing piece actually is "airport-based demand" where slots expand based on actual utilization.  Considering city based demand, the passenger demand for Chicago O'Hare and Chicago Midway should be the same, but O'Hare has 4x the slots.  Same goes with LAX, Burbank, Ontario, and Long Beach airports in California.  San Francisco, Oakland, and San Jose should have the same demand, but San Francisco I'm guessing will magically get all the international traffic.  Toronto has a similar problem.

So the question is, should smaller airports like Chicago Midway be able to grow to Chicago O'Hare size?  Also, since it's city based demand, if there is a 500pax demand to fly from Chicago to New York and you schedule a flight from Midway to JFK, does that mean the airlines at O'Hare will be a direct competitor on the ORD-JFK route or will there in essence be 1000pax demand from Chicago to New York?

All of this is starting to make my head hurt...

Quote from: LemonButt on June 26, 2011, 12:49:01 PM
I think the only missing piece actually is "airport-based demand" where slots expand based on actual utilization.  Considering city based demand, the passenger demand for Chicago O'Hare and Chicago Midway should be the same, but O'Hare has 4x the slots.  Same goes with LAX, Burbank, Ontario, and Long Beach airports in California.  San Francisco, Oakland, and San Jose should have the same demand, but San Francisco I'm guessing will magically get all the international traffic.  Toronto has a similar problem.

So the question is, should smaller airports like Chicago Midway be able to grow to Chicago O'Hare size?  Also, since it's city based demand, if there is a 500pax demand to fly from Chicago to New York and you schedule a flight from Midway to JFK, does that mean the airlines at O'Hare will be a direct competitor on the ORD-JFK route or will there in essence be 1000pax demand from Chicago to New York?

All of this is starting to make my head hurt...

The main issue with most of the airports you just mentioned is they simply don't have space to expand. Secondly, they shouldn't have the SAME demand. Because these airports (and passengers) are separated geographically, someone in the southern california, say Long Beach, would want to fly from the closest airports before commuting somewhere else, assuming all other factors are the same (ticket price, route selection, frequency, speed, etc.). Long Beach area residents would want flights in this order:  1. LGB, 2. SNA, 3. LAX, 4. ONT, 5. BUR, 6. SAN, 7. Every other airport would be different as well. It sounds like the grid system will solve these problems.

If we were to change airport size drastically, then that also have the possibility to significantly change population densities in the affected grids and may prove to be a bigger problem than benefit. However, these airports could see a small increase (2+ slots per hour)/ year instead of 1 slot per hour normally- with a certain slot ceiling (10-50, depending on the airport size (small to large). AND, if an airport ISNT being used, I think slots should decrease to a certain "slot floor" (~5 per hour) because the airport management is down sizing to match necessary demand.

I would like to add that airport initial facilities shouldn't be ignored.
If a comparable ATB game is opened in the new demand system version, the current airport facilities will restrict the type of airplanes capable of operating in it. For example, if a man who lives in Tokio wants to go to the Los Angeles area, according to the city based demand he can chose at which airport he wants to arrive in LA. But Ontario, or Burbank or any other airport in tha area except LAX don't have the facilities required to receive, say, a B77W. So, there's no other choice than the big LAX, thus making it the most popular international airport in the area.
Sure Ontario could expand (I don't know if it's actually able, don't know the place) in order to be a good international choice. But is impossible to build a big airport overnight, let alone the money needed.
So, in a ATB or MT game, LAX would still be the only Southern California gateaway.   

Quote from: ArcherII on June 27, 2011, 10:33:35 PM
I would like to add that airport initial facilities shouldn't be ignored.
If a comparable ATB game is opened in the new demand system version, the current airport facilities will restrict the type of airplanes capable of operating in it. For example, if a man who lives in Tokio wants to go to the Los Angeles area, according to the city based demand he can chose at which airport he wants to arrive in LA. But Ontario, or Burbank or any other airport in tha area except LAX don't have the facilities required to receive, say, a B77W. So, there's no other choice than the big LAX, thus making it the most popular international airport in the area.
Sure Ontario could expand (I don't know if it's actually able, don't know the place) in order to be a good international choice. But is impossible to build a big airport overnight, let alone the money needed.
So, in a ATB or MT game, LAX would still be the only Southern California gateaway.   

Hmm, I don't now if I agree with you - now that we are moving to games that span "The Early Days" to "Modern Times", I think that airports should all start out relatively similar and "build new runways" and "build new terminals", etc. to add slots as service increases.

Is it confirmed that that's the way it's gonna be? If so, great!
Nevertheless, the date of airport openings could drive to their greatness or littleness in the game IMHO. Such is the case of Love Field and DFW. If we start at middle 50s and KDAL is the only available airport in Dallas (alongside the former fort Worth one), by 1975 Love Field could be a 6 runway multi-terminal domestic hub ala DFW, and DFW would be opened already as a state of the art airport maybe without the planned business case.
KDAL couldn't expand I think due to lack of space, and surely is hard to implement that kind of code in-game.
Anyway, I'm all for the correlative game worlds!

Quote from: BobTheCactus on June 28, 2011, 12:56:57 AM
Hmm, I don't now if I agree with you - now that we are moving to games that span "The Early Days" to "Modern Times", I think that airports should all start out relatively similar and "build new runways" and "build new terminals", etc. to add slots as service increases.

Yep, that would be nice and I requested this earlier, but I think in this topic it has also relevance.

There should be a hard coded maximum expansion for some airports that were
a) restricted in expension even in 1950
b) that are not this important a goverment would do nearly everything to extend this airport
c) the airport is planned as a business airport (Toronto City Centre, London City for example)

If the aviation industries would have developed in another way, it could be possible that Frankfurt for example has in the year 2011 already five or six runways.

So, unlimited expansion for most airports and limits (that could be published) for some others and growth depends on disappearance of slots.

I think Curse said it quite well. We can call the limits "Local Laws" or something along those lines as that could provide an umbrella for every city and country in the game.

+1

What about airports in other country than city? For example, Bratislava is mainly served by Vienna airport - is there any chance passengers from BTS would use VIE airport even though it's in another country?

Quote from: Samo on July 05, 2011, 02:55:37 PM
What about airports in other country than city? For example, Bratislava is mainly served by Vienna airport - is there any chance passengers from BTS would use VIE airport even though it's in another country?

Yes if it's in that airport's "catchment zone" I think it should do.

between those cities sami could establish a fictive railway or bus transport system and makes available a defined percentage of demand, for example 80% of people at Bratislava would fly via Vienna or 30% Vienna people would fly via Bratislava. In my dreams this could also be dynamic, so if a huge airline is at Bratislava, maybe 90% out of Vienna would use this and only 10% of people would fly out of Vienna.

Yes, I understand that, I just hope borders won't be problem :) On the other hand, Vienna shouldn't serve Bratislava prior to 1989 (at least for flights to wester hemisphere)...

Well the world will be divided up into squares/rectangles to calculate demand so hopefully this means that the national borders will not mean so much.

Quote from: Curse on July 05, 2011, 05:34:08 PM
between those cities sami could establish a fictive railway or bus transport system and makes available a defined percentage of demand, for example 80% of people at Bratislava would fly via Vienna or 30% Vienna people would fly via Bratislava. In my dreams this could also be dynamic, so if a huge airline is at Bratislava, maybe 90% out of Vienna would use this and only 10% of people would fly out of Vienna.

I think the key will be (or should be) from which airport will the passengers be able to get to his desired destination easier.  Suppose the destination of the passenger is Oslo, and there is a direct flight from Bratislava (BTS) to Oslo, while there is not one from Vienna (VIE), the passenger would more likely chose to fly from BTS.

As far as catchment area, I guess at some point in the game, there may be some airport enhancements such as rails - to potentially increase the catchment area, that is proably way down the road.  It would probably be easiest to start with a constant catchment area around all airports.

With the system Sami is envisioning (the squares etc), it may turn out that VIE and BTS airports and cities will end up in one square and be handled as one big demand square that happens to have 2 airports...  No different than, say LGA and JFK in New York City.

As far as national borders, I hope it will not end up being a show stopper for the entire project.  I would he happy enough ignoring national borders (for the purpose of demand squares) in first iterations.  It could be fine tuned later on in subsequent revisions....

Quote from: JumboShrimp on July 08, 2011, 04:31:43 AM
As far as national borders, I hope it will not end up being a show stopper for the entire project.  I would he happy enough ignoring national borders (for the purpose of demand squares) in first iterations.  It could be fine tuned later on in subsequent revisions....

Agreed.

- Each airport will have a catchment zone based on airport size (and other factors?).

- Each country would (if possible) have preferences if people of neighbouring countries are allowed to travel cross-border to another airport (in catchment zone) and fly from there. This models both geographical constraints like sea and also political boundaries.


ie. people from Estonia don't really take the boat and travel 3 hrs to Helsinki airport, although the distance between two cities is less than 100 km and Tallinn region would definitely be in Helsinki's Intl Airport catchment zone if looking only the distance. And people from East Germany cannot travel cross border to West in 1985 to fly from there.

This requires, yet again, quite a bit of manual work in setting all the country relations, but I feel is a must for it to work properly.

For catchment zone; in reality it is determined by the time required to reach the airport. Longer time, the less people are willing to go to that airport. But since we cannot model areas with poor infra (like deserts, mountains etc) that increase the ground travel time, the catchment zone will be just a fixed sized radius around the airport. Added with the things above.

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.

I would guess that pax do not prefer any airport; or preference is built by the airport infrastructure size class (= larger = better services?). But basically it should be dictated by the airlines servicing the airports. Pax will pick the most suitable service regardless of airport.

As if I have two airports to choose from, with both being roughly the same distance from my house, and both have flights to same destination I am not choosing the flight by the airport but by the airline service, price, etc.

Quote from: sami on July 08, 2011, 11:27:31 AM
I would guess that pax do not prefer any airport; or preference is built by the airport infrastructure size class (= larger = better services?).

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.

QuoteAs if I have two airports to choose from, with both being roughly the same distance from my house, and both have flights to same destination I am not choosing the flight by the airport but by the airline service, price, etc.

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.

Quote from: sami on July 08, 2011, 11:27:31 AM
I would guess that pax do not prefer any airport; or preference is built by the airport infrastructure size class (= larger = better services?). But basically it should be dictated by the airlines servicing the airports. Pax will pick the most suitable service regardless of airport.

As if I have two airports to choose from, with both being roughly the same distance from my house, and both have flights to same destination I am not choosing the flight by the airport but by the airline service, price, etc.

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.

Quote from: JumboShrimp on July 08, 2011, 11:09:11 PM
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

Quote from: Curse on July 08, 2011, 09:38:29 PM
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...

Quote from: JumboShrimp on July 08, 2011, 11:17:54 PM
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.

Quote from: BobTheCactus on July 08, 2011, 11:11:37 PM
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.

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.

Quote from: Dave4468 on July 08, 2011, 11:21:10 AM
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

Quote from: Flobacca on September 09, 2011, 08:51:42 AM
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.

Quote from: Flobacca on September 09, 2011, 08:51:42 AM
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 :P I think you refer to LGW ;)

cheers,
Jona L.

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 

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

Quote from: Shubinine on September 23, 2011, 09:59:34 AM
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.

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

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)

Quote from: sami on October 27, 2011, 05:43:26 PM
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.

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

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.  :P

Cheers,
ICEcold

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)

Quote from: sami on March 05, 2012, 12:23:24 AM
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.

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.

Quote from: sami on March 05, 2012, 12:23:24 AM
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.

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

Quote from: sami on March 05, 2012, 12:23:24 AM
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.

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.

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.

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

Quote from: L1011fan on March 06, 2012, 08:03:30 PM
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)

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.

Quote from: sami on March 05, 2012, 12:23:24 AM
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

Quote from: JumboShrimp on March 05, 2012, 12:53:26 AM
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).

Quote from: JumboShrimp on March 05, 2012, 12:53:26 AM
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...

Quote from: JumboShrimp on March 05, 2012, 12:53:26 AM
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

Quote from: LemonButt on March 06, 2012, 01:15:15 AM
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.

QuoteAlso, 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?

Quote from: sami on March 18, 2012, 07:25:01 PM
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.

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

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.

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

As said, there is no "documentation" yet.

Quote from: sami on March 19, 2012, 08:15:17 PM
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...

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.

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?

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

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)

Quote from: sami on March 20, 2012, 07:51:40 AM
#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 :P ;) )

Quote from: Dasha on March 20, 2012, 08:37:22 AM
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.

Quote from: sami on March 20, 2012, 07:51:40 AM
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)

I just looked into populating one or a couple of small countries in Europe.  The question is, some of the categories where data is collected, I can use a pretty good judgement as far as which parts of countries are major, minor centers (relative to the rest of the country), it may be difficult to judge this in absolute terms.

So is the data entered by users going to be "scaled" by the population, gdp data to get the absolute figures, or is what we are entering the absolute data.

Ok, populated one country (Slovakia).  It would be useful to have a way to view data (once populated), perhaps have a record who entered it, and a way to update / override data entered.

The idea is that you basically know that country, or have good general knowledge otherwise, so that you are able to fill in the data about holiday/industrial/business to every country without having to really google or search the data. Of course in Africa etc. we don't have locals to do the job, so guesstimation comes into effect ... And so on.

GDP is a factor, but for this tool, the 1-5 figures for the values are absolute. If you choose "large" to the holiday destination, then it will be large in global scale. At least that's how I have figured it out.

But as said, I will need to play and test around with this still (and make the instructions) before this tool can actually be used for real work.


So once again a general reminder: if you edit some data with this tool, it may very well be erased. So pls do not spend time on it just yet. Once the project really starts I will make own subforum for the coordination and talk

The tool works well on a small country.  Larger country takes a while to load, but still within reason.  View and edit of data enetered is i think something that may need to be added.

Additional improvement possible to this data entry tool (if it is not too dificult) would be to have some easy way of checking reasonableness of data, such as global map by industry, business, tourist destination, roadway quality by color, so that the potential problematic data would stand out.

Populated Latvia. Hope I got the data +/- alright. One thing about the squares - they are really kind of malplaced when it comes to Latvia. In reality, Riga-Jurmala is the largest industrial and tourism centre of the whole country, with approximately half the population living in the area. Right now this area is in the middle of four squares, making it quite hard to segment it adequately.

With regards to air travel, Riga is the only place. There have been a few attempts for domestic services (on small <30 pax planes) between Liepaja/Ventspils and Riga, but they have all failed since it is not economically feasible. Also the bus&rail services are very cheap, very few would pay 50 EUR+ to go by plane when the bus takes 3 hours and costs maybe 7 EUR.

Over the past years rumours are flying that RyanAir will establish a base at Tukums Airport (plans to convert it to civilian airport at the moment) - http://en.wikipedia.org/wiki/Tukums_air_base - which could take a chunk of Riga's traffic, but otherwise there is only Riga for air travel and that is how it looks to remain in the near future.

Anyway, if you want some help with regards to Latvia, let me know, I can to try dig up some more data if you want to.

We are looking for a couple of members who would like to be the "moderators" in the data collection.

In other words to be able to spend some time in checking out the data submitted by others. Just to scout for large-scale errors for example. Drop me a note if interested.

I'm really excited this is going forward.

I was not able to follow the forum and the overall development in detail the last month, so please forgive if I ask a question that was answered well before.


Is part of this city based demand system - or an addition to it in the future - something like DYNAMIC city based demand?


As far as I know the data we add is based on actual time line, so 2012? Wouldn't it be an alternative to add additionall data for 1950? An algorithm between those datas could show and express the developmend.

Background: We can do some math to see how most Western states developed, like the US or Germany. But what about states that fall (Russia) or were some kind of desert before a big boom (UAE).


What my questions aim to:
Will there be dynamic city based demand to push cities like it was done in real life for Atlanta, Dubai or earlier Halifax and Tahiti?

An example story of what I mean was once written here (post #1, long text, please ignore everything else beside the Tahiti-development-story):
https://www.airwaysim.com/forum/index.php/topic,30655.0.html

Country GDP history will take of the historical effects.

However, what we cannot model that in this tool ... -> We tag for example Dubai as major holiday destination, then it will be that also in the 1950s when it was bare desert. Of course the GDP coefficient will have effect on that (1950 vs 2012) but I have no clue how much that will actually be. But we cannot collect the square data on historical aspect, it would be too difficult.

And the GDP can be dynamic/randomn if we want or follow history (I do have historical data globally / per country between about 1970 and 2010).

Quote from: Curse on March 21, 2012, 08:04:31 PM
like the US or Germany

Bad examples... either ones (especially Germany) developed a lot better than most other countries (*cough*PIIGS states*cough*) which means that the worlds economy would be boosted by about 5-6% every year, while some countries degraded by over 10-20%...

But the idea of considering a couple of countries to find a possible average-growth, though this would lead to under-real development for some countries (such as West GER) and over-real development for others (e.g. East Germany)...

cheers,
Jona L.

US and Germany were examples of relatively constant growth from 1950 to 2010.

@ sami

I see your point.

But could it be possible that some kind of algorithm takes into account when cities are very well served (that means they have a base of a very large airline in there) and when some are poorley served (small airline, no airline, airline BK)?

This would make it much more attractive to base at a random airport like Marseille or Kansas City instead of always choosing Paris and Chicago.

Unfortunately I have no clue if this could be coded some way.

Curse,

I think modeling relative rise and fall of different areas within countries would be a nightmare from data collection, and also, it would add complexity to the system.  For example, within the US, the relative rise of the South and West, and relative decline of the North East and Mid West would be one example of this.

As far as dynamic growth of the squares depending how well they are served by airlines (for passengers and cargo) would be a fantastic feature, but I would leave it after we have a bare-bones square demand and passenger connectivity implemented.

I'm fully on your side. I just wanted to bring the idea up again to avoid something like "oooh, hm, why didn't you have said this before we gathered data" or something like that.

I can't wait to see the first step, city based demand, go online. :)

Quote from: sami on March 21, 2012, 12:36:05 PM
We are looking for a couple of members who would like to be the "moderators" in the data collection.

In other words to be able to spend some time in checking out the data submitted by others. Just to scout for large-scale errors for example. Drop me a note if interested.

Sami,

I was wondering about something before we the project is started.  I suspect we will get a lot of inconsistent data.  To combat that, I would store, on country level, industrilization level, comerce level and tourism level.  Let's say the scale is 0 to 16.  Then, on the square level, we would be entering data relative to the country, maybe the current 6 (IIRC) degrees.  They would be +4, +2, +0, -2, -4 and absolute zero.  Adding the relative level to the coutry level would produce the absolute level on a scale of 0 tp 20.  So let's a country is a major commercial center (let's say Japan), it may be, a 15 as a country.  Then, Tokyo city center would get a +4 on commerce, and would be a 19 on an absolute scale.

The contribution to the absolute (from country data and relative within country) could be different, it is just an example...

The country level data could facilitate industrial and commercial development over time, while within country, the relative figures to the country would remain fixed.

Entered data for Taiwan

Quote from: plasticforks on March 22, 2012, 03:25:56 PM
Entered data for Taiwan

How will things like HSR (high speed rail) be modelled which are built at a set time (1990s?) and dramatically change Taipei-Kaoshing air demand? Same for Channel tunnel (LHR-CDG, BUR).

Quote from: plasticforks on March 22, 2012, 03:25:56 PM
Entered data for Taiwan

As it reads in this thread and written in the data editor tool at the page top too (the large warning box!), this is still useless work as the actual instructions have not been published and the tool data will be reseted when it actually starts.


(and since people are missing the obvious info, the tool is now offline)

Quote from: alexgv1 on March 22, 2012, 03:33:25 PM
How will things like HSR (high speed rail) be modelled which are built at a set time (1990s?) and dramatically change Taipei-Kaoshing air demand? Same for Channel tunnel (LHR-CDG, BUR).

shhhhhhhh, keep that to yourself. ;)

Quote from: ICEcold on March 24, 2012, 08:35:48 PM
shhhhhhhh, keep that to yourself. ;)

if I were you, I'd see a couple of solutions:
a) place a bomb on the HSR; b) buy the HSR and terminate the service; c) choose different location and don't care for rail; d) simply l2p and stop caring about unimportant things...

Austin, just live with it, life is unfair... e.g. FRA being closed at night now, Environmental TAXes on flight tickets in the EU, etc, etc, etc....

GDP will be one value that will affect the demand (most studies show that GDP change equals 2x air travel demand change, roughly). This can be actually installed to present-day demand module too.


Here's an example from admin area view:

Data pre-1970 is missing for all countries, otherwise data is historical & real for most of the countries, and post-2010 are estimates. I will also create global and world area specific graphs in similar style so countries with no real data can follow the global economic model.

By default all data is based on this, but each game would also allow customization of these graphs. But I would suspect that goes to be too difficult.

(have to say that the future estimated values of this data are quite optimistic ... each country is labeled with a ~2-7% growth. will probably discard the future estimated data)

And while talking of the desert countries, here's Qatar.

Gives you an idea how the demand of a single country will change over time .. take 2010 for example, and scroll back to 1980 and look the difference. Similar difference is expected in the pax demands in/to this country.

Sami,

I was wondering if it would bot be possible to have "suggested values" for squares pre-filled.  For example, if we have the population data for the square and GDP for the country, maybe the system can generate the suggested values for industry, commerce that would fit well within the given Pop and GDP.  Then, the data gathering will be just adjusting the suggested values up or down a notch based on the contributors knowledge of the country.  This would avoid large scale errors in data. 

Quote from: JumboShrimp on March 27, 2012, 07:43:14 PM
I was wondering if it would bot be possible to have "suggested values" for squares pre-filled.

Not really since if we have a country with industry, then certainly not all squares have industry in them etc. The whole idea of the squares is to override the general "mass" calculated by GDP and other factors, to pinpoint the demand into the certain cities and areas that have the major action places.


---

About airport catchment areas.

Basic passenger catchment area is a simple "range ring" based on airport size. For example 200 kilometers for size 5 (=biggest) airport (the values are  highly depatable still).

In real life the catchment area is determined by the travel time to the airport, and that depends on roads etc. that are available - modelling that is a bit hard (1st version at least), so has to be this for now.

Another issue is that our data is in squares, for practical reasons, and catchment area is a circle (yet again for practical reasons). Well, here's one mess of an image on how it will work:

- Center airport is EFHK, Helsinki (small red circle).
- Catchment area is the black circle (200 km).
- The squares in the background (red/yelllow) are potential squares from which pax can come to that airport. (people will not come overseas from Estonia to Helsinki!)
- The catchment area only slightly crosses some of the squares, like in the West with towns of Rauma and Pori, or Lappeenranta in east. However it's not good that such minor catchment will catch the whole square, so there is a certain limiter on how much it must catch the box before it is entirely inside the catchment area.

=> Thus the true catchment area will be the area covered by the boxes coloured in red.

All people in these boxes are potential passengers to the center airport (Helsinki). Their willingess to travel to this airport would decrease when the distance increases (directly proportional?).

Catchment area can be variable. Meaning that if airport size changes (or other similar change), the catchment area will change and data is re-stored accordingly.

Catchment areas of two airports can overlap of course.

Quote from: sami on March 27, 2012, 10:20:16 PM
Not really since if we have a country with industry, then certainly not all squares have industry in them etc. The whole idea of the squares is to override the general "mass" calculated by GDP and other factors, to pinpoint the demand into the certain cities and areas that have the major action places.

Agreed.  But my point is to make sure it is done within reason.

Suppose you have the US and a GDP per person of some 20k (I guess depending on year we are doing).
Now we have a square with 100k people in it.  Country specific GDP of 20k x 100x = 2 billion.
Now 2 billion would suggest the level of industrialization and commerce of say 7 on 1 to 10 scale.  So I would prefill the square with 7 for both.  Combined number of points would be 14.

Now where the contributor knowledge would come in, they would have questions to ask about the square:
1. Is the area wealthy part of the country or poor?  The player would get a range of +5 to -5.  So very poor area would get 9 points, very wealthy area would get 19 points.
2. Is the area industrial or commercial or mixed?  Based on the answer to that, the player would allocate the points determined in step 1.

So, for example, if I am doing the US, and I am looking at a wealthy New York City suburb vs. poor city in Mississipi with equal population, I would start with the bases of 14 points, the wealthy NYC suburb would get +5 (=19), -5 for poor square (=9) and distribute the points based on what's going on the squares.

Why is this important?  Suppose I am looking at a square in Senegal that has equal 100k population.  What do I do with that?  Well, if the system pre-calculates that based on Senegal GDP of say $5k per person, the number of points to give out should be 4 on average for Senegal, as a starting point, with player being able to modify it by +5 to -5, we will stay within reason.  So for example the wealthiest area of Downtown Dakar would be at best equal to the poorest area in the US.  Without these constraints, I think we will end up with lot of crazy data...

So where we would go from here is to get the actual demand, we would take the 3 components:
1. industrialization x population x GDP which would result is certain amount of cargo and a certain amount of pax
2. business x population x GDP and that would result in another set of values for cargo and pax.
3. holiday destination (not sure how to scale that one)

Combining the 3 components we would get the demand of the square.  So it starts from generic, but would get specific with contributor adjustments, but at the same time stay within reason.

Another check might be on the countrywide basis, to do a c***rywide sum of the discretionary player adjustments.  On the net basis, it should be generally close to zero.  If some areas are wealthier than the average of the country, other areas need to be poorer and net result should be getting back to the average for the whole country.

Writing initial testing versions of the calculation script, and generally speaking does this make any sense (just wish to make sure I have not omitted anything):

(assume that we have the world full of the data squares, in a suitable format)

- Firstly, the system checks for squares that fall within reach of any airport (ref. my previous post, airport catchment area). Discarding the squares with no reach to any single airport, or unpopulated squares etc.. People won't travel from there, or use other means.

- Then the system figures, bit by bit (one longitude at a time for sake of CPU/mem usage) potential passenger demand between each square from that longitude to any other squares around the globe. Done using the variables assigned for each square, and country relations data, and country GDP, and other such factors. Result is passengers per day (/month, whatever) between each square (or 0 if not possible/no demand). Demand is allocated between four travel types: leisure travel, business (= not business class, but business related travel), premium (= high-paying business or holiday travel etc.) and cargo. This all is of course the trickiest part, in order to tune the calculations so that the results actually make sense compared to reality.

- Once the square-to-square demand for each square from the given longitude is done, system will then make this into airport-to-airport data that will be saved. (square to square data cannot be saved since there would be ~100-250million data entries; airport to airport gives a manageable number of results.)  System will check the specs of each airport that can use each given square; airport will be given a score based on the desirability (distance mainly) and airlines serving to it (if we have a direct connection from the airport to our desired box -> good score, if we have one-stopover connection -> less points ... if no service at all, show still some interested passengers as "demand" if there is no other alternative..  some other factors like images and avg. prices are possible factors too). Result will be Y/C/F/X(cargo) breakdown in pax demand, and this is the figure that is also shown to players.

- The above demand figures are updated once or twice a game month for each airport with a rolling background calculation (or instantly in case of any events, or airport data changes). This is a tradeoff between balancing the calculation CPU usage, data storage size and playability. This way everything is calculated only at background, data storage is still within reasons and any changes in the demand will be gradual to players (= if a player enters to another airport overlapping your airport, the demand will shift to that airport over time, if he is "much better" than you.. or other way around). My only concern is how to make the player-made changes to affect the shift in demand fast enough (like opening/closure of a route, major change in pricing ..etc) - these should be seen in a game week or less, not in a game month.

- Actual pax demand distribution is then another module, that checks the apt-to-apt demand figure and uses it as a baseline for the distribution of passengers. For first test version we could actually even use the present demand allocation module, and then move to next version that can handle connections etc. (demand storage in this format poses on problems to it)

- Also some thought must be given on how the data is displayed to players. We naturally will keep the airport to airport style route planning search still, but if there are many airports overlapping some demand, how would that be shown so that it is clear. ("demand from X to Y is 500 pax, but it includes 200 pax that can be flown from Z to Y" .. ?!?)

..This is just the rough baseline, but comment if you wish. Posting it here just in case someone figures something essential or an idea on how to do it smarter (my brains are overheated ....)

First thing I have to say that it is a brilliant plan.  It may not be instantly responsive - as in instantly responsive to guy at the other airport going into a C check, instantly shifting demand to another airport - but responsive enough to the normal scheduling of flights.  And the potential slowness (speed) of responsiveness will eventually depend on the performance on real data, and that is something that would be extremely hard to determine now.  But if the world can be updated once per month, that could serve as a minimum.

Quote from: sami on March 28, 2012, 10:18:03 PM
- Then the system figures, bit by bit (one longitude at a time for sake of CPU/mem usage) potential passenger demand between each square from that longitude to any other squares around the globe. Done using the variables assigned for each square, and country relations data, and country GDP, and other such factors. Result is passengers per day (/month, whatever) between each square (or 0 if not possible/no demand). Demand is allocated between four travel types: leisure travel, business (= not business class, but business related travel), premium (= high-paying business or holiday travel etc.) and cargo. This all is of course the trickiest part, in order to tune the calculations so that the results actually make sense compared to reality.

Sounds good.  But I guess this is not really a "step" (since the data is not being stored anywhere), just a description of a concept / algorithm of how it will be done.

Quote from: sami on March 28, 2012, 10:18:03 PM
- Once the square-to-square demand for each square from the given longitude is done, system will then make this into airport-to-airport data that will be saved. (square to square data cannot be saved since there would be ~100-250million data entries; airport to airport gives a manageable number of results.)  System will check the specs of each airport that can use each given square; airport will be given a score based on the desirability (distance mainly) and airlines serving to it (if we have a direct connection from the airport to our desired box -> good score, if we have one-stopover connection -> less points ... if no service at all, show still some interested passengers as "demand" if there is no other alternative..  some other factors like images and avg. prices are possible factors too). Result will be Y/C/F/X(cargo) breakdown in pax demand, and this is the figure that is also shown to players.

I think it might be useful to store the info that is static, as in aiprort - square table, something like:
AirportID
SquareID
Distance

So that it would be quick lookup to go from square to airports (where square is within its catchment area) and squares belonging to an airport (within its catchment area).  This would be done one time before the game start, or when something about an airport changes.

The initial allocation of square to square demand to airports within origin's square while no-one is flying seems straight forward conceptually.  I think the tricky part will be to figure out how to update and what has already been updated.

Let me give you an example.  Suppose this process is run for the first time for all squares to prepare the game world.  Suppose we calculate the demand for JFK-LHR route.  This demand (or more precisely, the 4 components of the demand) are an aggregation of square to square demand between these 2 airports, store as a scalar (one per each of 4 demand categories), without knowing how much each square contributed.  Let's call it old aggregated value.

Now we are going to update, and we are updating LHR square 1 to JFK squre 1.  We figure out the new value, but how do we update the aggregate figure of JFK-LHR if we don't know the the old one?  If we knew the old, it would be simple as: aggregate - Old_LHR_Sq_1_to JFK_Sq_1 + New_LHR_Sq_1_to JFK_Sq_1.

So the updates would have to performed on route basis, route being JFK-LHR.  So let's say we are doing JFK-LHR route, we zero the 4 components, and then process the set of combinations of JFK squres to LHR squares.  Anyway, you may have planning on doing it this way all along...

The concept of quality of connection affecting demand is great.  I guess where it fits within steps is in the square to square demand calculation.  So we might have this set of possible contenders for one of NYC and one of London squares (probably the worst case scenario):
JFK-LHR
JFK-LGW
JFK-STN
JFK-LTN
JFK-LCY
EWR-LHR
....
LGA-LHR
...
LGA-LCY
(total 15, could be more if we the squre is within range of smaller airports such as ISP, HPN)

So to figure out JFK-LHR demand for the square, we need to figure out what fraction of the set of possible direct routes our JFK-LHR route is.  If there is no connection of, say LGA-LCA, it should be possible to make that a zero.

Now, this is the worst case, but if we include the routes with 1 stop, the set will defnitely grow substantially

Quote from: sami on March 28, 2012, 10:18:03 PM
- The above demand figures are updated once or twice a game month for each airport with a rolling background calculation (or instantly in case of any events, or airport data changes). This is a tradeoff between balancing the calculation CPU usage, data storage size and playability. This way everything is calculated only at background, data storage is still within reasons and any changes in the demand will be gradual to players (= if a player enters to another airport overlapping your airport, the demand will shift to that airport over time, if he is "much better" than you.. or other way around). My only concern is how to make the player-made changes to affect the shift in demand fast enough (like opening/closure of a route, major change in pricing ..etc) - these should be seen in a game week or less, not in a game month.

- Actual pax demand distribution is then another module, that checks the apt-to-apt demand figure and uses it as a baseline for the distribution of passengers. For first test version we could actually even use the present demand allocation module, and then move to next version that can handle connections etc. (demand storage in this format poses on problems to it)

- Also some thought must be given on how the data is displayed to players. We naturally will keep the airport to airport style route planning search still, but if there are many airports overlapping some demand, how would that be shown so that it is clear. ("demand from X to Y is 500 pax, but it includes 200 pax that can be flown from Z to Y" .. ?!?)

..This is just the rough baseline, but comment if you wish. Posting it here just in case someone figures something essential or an idea on how to do it smarter (my brains are overheated ....)

As far as representing the demand graphically, for JFK-LHR route, there are a lot of values that can be shown, that may need to be considered:
- local demand allocated to this airport: what we are calculating
- base local demand: demand between JFK-LHR absent of any flights, where the square demand is split just based on distance of squares to airports
- maximum potential local demand: if all passengers of all JFK squares to all LHR squares use JFK-LHR route
- potential pax from connecting flights (might be too difficult to figure out, and would be huge potentially), so we may just as well skip it.
(each one of these would have the 4 components).

- actual number of local passengers flown on average for last week
- actual pax from connected flights
- total actual pax: total of actual local + actual connecting

Supply is another story, and how to show it.
- direct route supply: sum of flights on JFK-LHR - easy enough to figure out
- neighboring airport direct route supply: Looking at all of JFK squares, what other airports could JFK squares be served by?  We get one set for JFK, another set for LHR, so we sum the supply of all combinations (minus JFK-LHR).  Still straight forward, but we are back to a lot of calculations just to show the demand screen
- connecting, 1 stop supply: yet another set of flights.

Of all of these, some may be too difficult to implement.  Differences in values may be too great that we may need to use logarithmic scale (if the graphing software supports it).  Monday - Sunday demand display may have to be discarded if some of this other useful data is going to be shown.

I will try to think of ways to display it in next few days....

Variable catchment area:

It may be useful to have a variable catchment area.  This could be independent of airport "size" as it is currently defined in the system.  It could depend strictly on number of passengers flown.  The system could have a simple function of:

Catchment radius = Function of (Passengers flown from the airport).

The system could have a minimum of say 50km as a base, and every airport would start with that.  Than, as the airport grows (as far as passengers served), the radius could grow to potentially to 200km or even 300 km for the busiest airport (not sure if the picture around Helsinki is radius of 200km or diameter.  This way, with radius of airports with very low number of passengers would stay very small, the system will not be wasting too much time calculating square to square demand of squares that may never really end up being connected by supply.

And since this would be a very simple calculation for the catchment area radius (and the table of AirportIDs to SquareIDs) it could be updated as part of every round of updates.

It might be useful for playability as well.  The system would not start with astronomical demand and no supply.  The demand would build up as the catchment area grows, as more passengers is brought in through connecting flights, and as the catchment areas grow, there would be more overlap, and more indirect competition as the game progresses.

It would be a great way to make the game world more dynamic.  Also, with airport growth, there could be some way to grow slots as well, to make that area dynamic as well.  The game could start with number of slots that is lower than current start, and then grow with number of either pax or take offs and landings.

Quote from: JumboShrimp on March 29, 2012, 01:29:05 AM
Variable catchment area:

It may be useful to have a variable catchment area.  This could be independent of airport "size" as it is currently defined in the system.  It could depend strictly on number of passengers flown.  The system could have a simple function of:

Catchment radius = Function of (Passengers flown from the airport).

The system could have a minimum of say 50km as a base, and every airport would start with that.  Than, as the airport grows (as far as passengers served), the radius could grow to potentially to 200km or even 300 km for the busiest airport (not sure if the picture around Helsinki is radius of 200km or diameter.  This way, with radius of airports with very low number of passengers would stay very small, the system will not be wasting too much time calculating square to square demand of squares that may never really end up being connected by supply.

And since this would be a very simple calculation for the catchment area radius (and the table of AirportIDs to SquareIDs) it could be updated as part of every round of updates.

It might be useful for playability as well.  The system would not start with astronomical demand and no supply.  The demand would build up as the catchment area grows, as more passengers is brought in through connecting flights, and as the catchment areas grow, there would be more overlap, and more indirect competition as the game progresses.

It would be a great way to make the game world more dynamic.  Also, with airport growth, there could be some way to grow slots as well, to make that area dynamic as well.  The game could start with number of slots that is lower than current start, and then grow with number of either pax or take offs and landings.

This sounds/feels like a pretty good way to make the game more dynamic/variable.  It might be worth considering "letting go" of the logical geographical (country) restrictions (people will not come overseas from Estonia to Helsinki!) because while this may not represent reality, it will add another dynamic factor and will probably make for easier algorithms for the code.

If nothing else, this would certainly be a good starting point for at least 1 game world as a test.

Regards

Richard

Quote from: sami on March 28, 2012, 10:18:03 PM
System will check the specs of each airport that can use each given square; airport will be given a score based on the desirability (distance mainly) and airlines serving to it (if we have a direct connection from the airport to our desired box -> good score, if we have one-stopover connection -> less points ... if no service at all, show still some interested passengers as "demand" if there is no other alternative..  some other factors like images and avg. prices are possible factors too). Result will be Y/C/F/X(cargo) breakdown in pax demand, and this is the figure that is also shown to players.

I think it is useful to have some zeros, some elimination of useless things to calculate over and over, to get smaller sets back from querries.  So if no connection, no demand to allocate for the route.  So if there is no direct or 1 stop way to go from LGA to LCY, the point value could just be multiplied by zero, so allocated demand for the route would be zero.  If we store some guideline demand figure (that I called "base local demand", "maximum potential local demand") to show to players.  But the allocated demand would be zero for routes at the start of the game until there is an actual flight.

Quote from: sami on March 28, 2012, 10:18:03 PM
My only concern is how to make the player-made changes to affect the shift in demand fast enough (like opening/closure of a route, major change in pricing ..etc) - these should be seen in a game week or less, not in a game month.

If the background calculation goes down the list all of the routes stored, and the target is to update the routes once per month, once the route is processed a date can be stored on the route as far as when to recalculate the route.  Let's say next day to process = current date + 28.  If a player schedules a route (assigns it to an aircraft), the next day to process could be set to current day.  And the day would not advance until all the routes with next process date = current date are not processed.  So the responce to a new route creation would be "instant" or equal to AWS 1.3.  Same should be done for any re-assignment of aircraft.

Pricing changes?  I would ignore those and only use them the next time the route comes up naturally (within a month).

As far as the price, if I understand it correctly, it would be in 2 places:
1. - background calculation to allocate the square demand to airport to airport routes
2. - allocation of the above airport to airport demand to individual flights on the route serving the demand.  In this step, the responce would be instant (= AWS 1.3).  Shifting of demand in 1. as result of price change would be slow.

Quote from: Riger on March 29, 2012, 02:10:41 AM
This sounds/feels like a pretty good way to make the game more dynamic/variable.  It might be worth considering "letting go" of the logical geographical (country) restrictions (people will not come overseas from Estonia to Helsinki!) because while this may not represent reality, it will add another dynamic factor and will probably make for easier algorithms for the code.

If nothing else, this would certainly be a good starting point for at least 1 game world as a test.

Regards

Richard

I agree.  The only "catch" is that there used to be the iron curtain, and such travel (Estonia to Helsinki) would not really happen a lot.  But that could easily be deferred to much later in the process.

As far borders, let's say Slovakia to Austria, that I cross often, it is completely meaningless now, and probably 1/3+ of Slovakian pax use Vienna airport, especially for LH flights.  And the "catchmet" area of VIE airport is easily 200 km into Slovakia (in addition to ~50km from VIE Schwechat from the border)...

BTW, not that I would want to complicate things, I think the catchment area for LH flights > catchment area for SH flights...

The cross border thing ... I've thought it so that at first all border crossings are disabled. Then we can ALLOW them one by one (country by country) by setting the first possible year and country pair.

This is easiest this way since a box that overlaps two countries is already defined twice in the database, and has unique population figure for both countries. So calculationwise I do not have to separate anything to get the border closed. To get it "opened" it needs another round of checking.

(= simple)

Sounds good so ....  Lets Go !!

;D

idk if i brought this up or not.

I think there should be tweaks for certain destinations to reflect real life routes.

Routes that come into mind for me personally are ATL/IAH/MIA-MGA.

irl Delta flies 1x from ATL, UAL 2X from IAH and AA 2x from MIA. AA used to use a mix of 738's/A300's (until 2009) and then 763's until last year. Now its all 738's  ;D

I was on the DAL service in 2009 and it was full bothways. I suspect the UAL/AA flights were the same (along with the TACA/Copa Connections)


Ik alot of the pax are connecting to go to other destinations via those 3 hubs , and potentially just flying to MIA because of the large Latino Population in florida, but it raises a question about the numbers for countries that have routes like that :s

Idk im kinda rambling but the point is that there should be minor tweaks to reflect real life load factors on certain routes like this, especially to destinations in the Carribean and Latin America IMO.

Edit: I can not view the City Editor either. I was curious to see what demand for certain places was  ;D

I had an idea for passenger connectivity:

Using my current DOTM3 airline, I am HQed in Toronto and have a base in Vancouver.

I use CYYZ as European gateway for Transatlantic, and CYVR as the Asian/Australasian gateway. However there is decent demand from Vancouver to Europe and vica-versa.

Therefore, rather than calculate all potential routes and connections possible, my idea is to create a "virtual route" between Vancouver and Toronto which transfers the passengers and instructs them to go to Europe via Toronto. Therefore all pax demand from CYVR will be transferred to CYYZ (just for me) as my passengers are connecting, provided that I provide enough seats for the spoke flight (this demand goes up).

This may effect competiton as we are all fighting for the same demand, so how about X% of passengers are transferred to my route with that number depending on the normal competition statistics. Treat the hub flight as a tech stop and use connection time into account of flight time, compare it to the direct route then I will take a certain amoutn of passengers from the direct route. If no competition then all pax will have no choice than to route with me (standard LF calculations apply).

This would be strenuous as it would have to have a route made for each airport to fly to through connections (but no more work than making a non-stop route). Of course at first it is limited to your own bases as a first stage to keep calculations simple, but eventually it can be expanded to alliance bases and regional flights to feed long haul flights from non bases.

Just an idea, please let me know your thoughts.

Quote from: alexgv1 on March 29, 2012, 04:22:42 PM
This would be strenuous as it would have to have a route made for each airport to fly to through connections (but no more work than making a non-stop route). Of course at first it is limited to your own bases as a first stage to keep calculations simple, but eventually it can be expanded to alliance bases and regional flights to feed long haul flights from non bases.

Just an idea, please let me know your thoughts.

Well, hopefully the passenger connectivity will be automatic, calculated by the system, rather than player manually creating all the combinations...

At first, just 1 connection only limited to player's own flights would be good enough, later expanded to the alliance.

When you create a route the system will show you all potential connections within your network, automatically. You can tick and choose the ones you wish to sell tickets to (default = all), and adjust prices if you wish. (or later)

Simple.

For pax calc each connection shows like a regular flight, having extra stop.

Connection thresholds would be for example, only one stop (2 consecutive flights max) and connection leaving no earlier than 60mins from arrival and no later than 4 hours. Would prefer to keep these as fixed values.

Actual flight data stats/info will be shown like they are today, with perhaps added by data of amount of connecting pax share, or smilar. But still very simple too.

Quote from: sami on March 29, 2012, 07:13:04 PM
When you create a route the system will show you all potential connections within your network, automatically. You can tick and choose the ones you wish to sell tickets to (default = all), and adjust prices if you wish. (or later)

I am not sure about this part (the user input into what is connected and prices).  It may be too overwhelming for the user.  It should be done automatically by the system, and the connections the passengers actually chose to fly would largely depend on price and duration (described below).

BTW, are you planning on storing the possibilities in some tables?  I guess it might be necessary...  Looking at the number of combinations for 1 hub, n destinations, I think it is going to be 1 + 2 + 3 + .... + (n-1), so something like (n-1)^2 / 2 or if each direction is considered as separate, (n-1)^2

Quote from: sami on March 29, 2012, 07:13:04 PM
Simple.

For pax calc each connection shows like a regular flight, having extra stop.

Connection thresholds would be for example, only one stop (2 consecutive flights max) and connection leaving no earlier than 60mins from arrival and no later than 4 hours. Would prefer to keep these as fixed values.

Actual flight data stats/info will be shown like they are today, with perhaps added by data of amount of connecting pax share, or smilar. But still very simple too.

As far as prices, my understanding of current pricing is that it is = a constant for taking off + some rate per nm flown.

Maybe the connecting flight price should be calculated the same way, that is, one single constant for taking off, not 2.  As a result, the planes will be more full in general, but if they are carrying a lot of connecting passengers, the revenue per passenger will be slightly less.

If we keep the distance based on miles flown between A-Hub-B, rather than distance AB, that alone would discourage passenger flights where A-Hub-B >> AB, since the price would be too high, compared to their expectation for AB.  The more A-Hub-B looks like a stright line, the more the flight look like a direct flight pricewise, except with longer duration.

Any news on when we can get started on inputting data?

regards,

NC

I've been on holiday, and have not worked on this for a while. But I am still in process of building a test version of the calculations to see how much CPU time it would take. Before that is done and found doable there's no sense in spending time in data entry yet.

The latest game engine had the large changes on the way the demand is distributed, but also on how the demand data is stored on the server ( https://www.airwaysim.com/forum/index.php/topic,41747.0.html ). It was one of the pre-requirements for work on this feature. I would hope that last bugs of that new system have been ironed out now (airport transfers etc), so next thing I am working is the country specific economies (based on GDP data). Data is collected but all the country splits and combinations (like Germany and CCCP ..etc) make it difficult again.

Here's one ex-CCCP country. The GDP does have a direct relationship to air travel volume in that country and with this feature we can have real boom or depression periods for each country or continent. Realworld data is the baseline but in the future nothing would prevent making up these figures for random economic events too.

Looking forward to this.

Please, make this happen ;)

------
I remembered today a game that I LOVE, which you probably already know: (open)TTD...

In case you don't, it's a game where you have to transport pax and cargo from point A to B...

The game has a pretty big community, which developed the game a lot, and one of the development in progress is the creation of specific destinations for the pax and cargo generated in the game...

So, instead of connecting A to B, you would have to connect A to C and D and E, and all other required destination by the cargo...


Perhaps (IDK if they did a good job in programming, or if the principles in there are applicable here -since it's another game-, or if they are actually behind you), some of that work could be applicable here, or some programming ideas could be applicable, since it's a similar job. (providing cargo with specific destination, and the capability to find the better path to it). And, as you will be able to see, they have been developing it from several years now...

I'll leave the links (this is all done in "open" language, so it should be viewable and understandable)...

http://www.tt-forums.net/viewtopic.php?f=33&t=41992

http://www.tt-forums.net/viewtopic.php?f=33&t=54253


Greets !

Pax and cargo in TTD have no destination preferences as such (well, for cargo you just move them to another factory that accepts that type of goods...). You just open a station in the middle of the city and same in another two cities and tou can transport pax between them however you like...

(unless it has recently changed, doubt it?)

Actually, there is two mods for OpenTTD that do that:
http://www.tt-forums.net/viewtopic.php?f=33&t=41992&start=0 (http://www.tt-forums.net/viewtopic.php?f=33&t=41992&start=0) (CargoDist, divides cargo between the destinations available)
http://www.tt-forums.net/viewtopic.php?f=33&t=54253 (http://www.tt-forums.net/viewtopic.php?f=33&t=54253) (YACD, divides cargo between all destinations)

Quote from: sami on November 19, 2012, 08:09:56 AM
(unless it has recently changed, doubt it?)

They did change it (not officially)... that's the reason I made the post :P

The two links I provided, refer to two projects (add-on/scripts) which try to provide pax and cargo with specific and unique destinations, and the ability to find the better path to the destination thru the network you build...

So, those scripts, changed OpenTTD, from a Point to Point game, to a multiple destination one (the same thing you are doing here)...

Quote from: Absolutis on November 19, 2012, 01:57:20 PM
Actually, there is two mods for OpenTTD that do that:
http://www.tt-forums.net/viewtopic.php?f=33&t=41992&start=0 (http://www.tt-forums.net/viewtopic.php?f=33&t=41992&start=0) (CargoDist, divides cargo between the destinations available)
http://www.tt-forums.net/viewtopic.php?f=33&t=54253 (http://www.tt-forums.net/viewtopic.php?f=33&t=54253) (YACD, divides cargo between all destinations)

Exactly, those are the links I posted...

OTTD pax with destinations have been in development for several years. Last time i tried it was not very good. Very slow progress indeed.

What about simutrans ? Passenger/cargo logistic point-to-point with changing means of transport and time/routing calculation. Don´t really know if source is open.

Simutrans graphics sucked the hell out of my mind... played it for an hour, than put away LOL :P


OTTD basically has no destinations indeed, making it way too easy, but as mentioned there are mods to help out :) - when do we see these things [mods] come out for AWS? "Customize your GW ;D "

OTTD remains the best offline game for transportation simulation in my eyes; but we are a long way from perfection, in both, AWS and OTTD, AWS is basically the online counterpart to OTTD... "Best game for [aviation] transportation simulation"... keep up the work on this, will really give it a boost of reality :)


Anyways, OTTD was a bit off topic...

How can we help to contribute to your "alpha testing" of the system?

cheers,
Jona L. [aka [SC] L.J. Gibbs]

Who was talking about graphics ? Topic turned into direction of calculating PAX/CARGO routing, something that obviously is to be dealt with if we turn to CBD and connecting flights, not if you personally like this or that game.

Yes well, anyway, I do not see the ottd really would apply here. Especially when they use a different language for programming and are also in similar "alpha" status with the feature.

Not to re-invent the wheel or anything but cannot see it really that useful.

By the way ..

About the airport transfers and geopolitical demand shifts, question ..

When a major change in airport's pax distribution happens, for example when Soviet Union collapses, or an formerly Intl airport of a city becomes a secondary airport, should the demand transfer or change overnight or gradually over months.

For example when CCCP collapses should the intl demand become available right away like now or increase bit by bit. For airport transfers inside the same city I think the best would be overnight switch of the figures and data.


(these are by the way one reason why this whole concept, and even the current demand concept is tricky - the current system should have nearly all airport transfer related bugs removed now, hopefully)

Should...but I can think of Auckland, Shanghai, and Narita off the top of my head that are still screwed up royally.

Once again, when the old airport transfers to new one, the demand levels are not necessarily the same ... (+ that is completely irrelevant to this thread's topic.)

Quote from: sami on January 25, 2013, 07:00:41 PM
Once again, when the old airport transfers to new one, the demand levels are not necessarily the same ... (+ that is completely irrelevant to this thread's topic.)

Sami,

If there airport change means automatic relocation of player bases, I would say overnight.  (and I don't really know which airport relocatin changes are automatic in AWS)_

If it is the Iron Curtain coming down, gradual change.

I say overnight. Make it swift and clear cut...


~ Though I say add an extra warning message for airports that change over to new ones (in the existing gameworld) before a user selects that airport at the airport selection screen. Make a "checkbox" they have to click to show they understand that an airport will change its demand makeup.

"Warning to user: xxxx/xxx will have an airport change during this gameworld. By checking this box you understand that its demand will be different when this switch over occurs. For better or worse..."

This should give people a better idea of what they are getting into.


Talentz

Overnight for an airport change, but with a 12 month exemption from the monopoly board would be best, I think. That gives the airline a RL week to go through their routes and restructure before their inbox gets flooded.

Checkbox at the start/message that you'll need to deal with an airport change would be a good thing. And if it's easy to do, when it's not a straight-up replacement airport, like Denver or Hong Kong, but instead a 2nd airport opening and the first remaining just as large but domestic like Tokyo, a checkbox to pick between staying at the original or moving to the new one.



For the Soviet Union breakup, gradual would be much better. Start the change just before the first country breaks away, and have the routes changing to their post-breakup numbers, finishing at the point Russia becomes its own country. Otherwise you have things like St Petersburg-Kiev being 100 pax/day when its soviet-soviet, 0 when its soviet-ukraine, then 100 again when its russia-ukraine. Coupled with the new anti-monopoly rules, and anyone in a soviet airport that isn't SVO will have many routes pointlessly forced to close.

Quote from: JumboShrimp on March 29, 2012, 01:29:05 AM
It may be useful to have a variable catchment area.  This could be independent of airport "size" as it is currently defined in the system.  It could depend strictly on number of passengers flown.  The system could have a simple function of:

Catchment radius = Function of (Passengers flown from the airport).

For the current test scripts, this was built earlier. The airport catchment area is a variable (monthly updated) value between 50 and 250 km, based on the number of passengers the airport has transported during the current game year (or previous year in case of january). Catchment happens only in the same country where the airport is - so far.

However; the 250 km may be too large for some countries, if you see the image below, where we have a 250 km ring around LHR .. goes all the way up to Manchester. (almost; as it does not catch fully the square where Manchester is, but very close to it anyway)

Is that too much already? Should we try to factor the density of the airports in the country somehow perhaps, and in this case (UK has many suitable airports) the range for catchment would be smaller, let's say 175 km. Or is this already too much of fine tuning?

With this catchment depicted LHR would have a population catchment of 37 490 382 people (static database, 2010/2011 population figures). Naturally the further away the box is from the airport, the less it would attract people.


Second snap shows catchment of London City (LCY) which was calculated as 160 km.

(the actual process of generating the demand between the city-data squares is difficult. So currently I am testing and working on the distribution of the passengers and demand etc... but the new UI/layout work has been and is a priority)

Another small example from the case of overlapping airports.

In the image below we see Western Finland. It has three airports, Vaasa (VAA) - Kokkola (KOK) - Seinäjoki (SJY) . Each will have a 50 km catchment range and each of them will reach to catch the one lone square in the middle, marked in blue.

Well, firstly there's the need to calculate the destination where they wish to travel from that blue square. There are some 65 000 people living inside that blue area, and we'd need to calculate how often and most importantly where they wish to travel. This is the separate, most difficult, process. Let's skip it for now and assume from that square 100 people wish to travel to capital Helsinki every day. How would the people in the blue square choose their airport of departure?

This process would be kept rather simple preferrably...

Each airport cathing this square (the 3 mentioned) will also have a "desirability factor" for the people of this square. Currently this is simply calculated from the distance between the airport location and the centerpoint of the (blue) square. When distance is longer this factor is smaller. It is easy to take here into account also factors like airport size (size class or pax transported) if needed. Let's assume the desirability factor for each airport is "50/100" for the people of blue square...

The most simple solution would be that the 100 people going to capital are simply distributed according to the desirability factor. So each airport would then have demand to Helsinki of 33 people (since each airport has equal factor for this example).

Problem however is that if there are no flights from Kokkola to Helsinki for example. Naturally people would then drive to Vaasa for that rather than not fly. ..and this is were it goes complicated.

Basically the system would have to somehow take into account the actual routes and schedules of the players when it allocates the true demand between airports. With possible connections I am afraid this gets too heavy to calculate, so some more elegant solution would be preferrable.


Whatever the calculation solution, this is shown to players in something as follows:

- There would be two demand figures: current airport demand, potential area demand. Each is accessible normally by choosing dep and arr airports, and the system then combines this data of squares into similar display as currently, but two different figures:

   - Airport demand is the current actual demand based on what airport people currently choose in the area.
   - Potential area demand is the demand from the whole airport catchment area, ie. best case scenario when all people in the region choose this airport as dep point to fly to the chosen destination.


In our practical example as follows:

- If there are no flights from either of the three airports the demand from each airport to Helsinki would be 33. (if taking into account just this one square - for the sake of the example!)

- If I'd fly from Vaasa to HEL and there are no other airlines on this route (to any of these airports), I would first receive the 33 pax, but gradually it would move towards the full 100. In that case Kokkola-HEL would display airport demand (KOK-HEL) as zero, but potential demand as 100. (disregarding CI/RI effect etc. here!)

- If another airline would start KOK-HEL after I have acquired full demand (100) for Vaasa-HEL route; the demand would gradually start to shift back towards the even distribtion (since in this example the airports were equal in desirability).

...however this style of demand display has its problems, as players opening/searching routes may be put down by the display of zero demand and would prefer to choose the Vaasa-HEL instead - although they'd have 100% same chance of success in the KOK-HEL route. Could there be other options for this displaying then?

..as mentioned, how this gradual shift is actually done without crashing the servers, is yet to be solved.

How are country borders going to work in this model?

For example, I live in Bratislava but my "home" airport is Vienna - located in different country (Austria vs. Slovakia), but about 50 minutes from my home by car. In fact, I believe that Vienna airport serves more passengers from Bratislava then Bratislava airport. But prior to November 1989 (Iron Curtain fall) people were generally unable to use Vienna airport for obvious reasons. So in 1989 border plays huge role (as people can't cross it easily), in 1995 it might have some small role (people can cross it with no problem, but still there are passport controls, etc.) and in 2008 it doesn't matter at all (they don't even have to stop on border).

Will this be somehow modeled? For begging, I'd say that there could be three kinds of borders:
- Closed (such as Iron Curtain - people can't cross it)
- Opened (people can move freely, but they need passports, there are passports checks and it may cause them some delay - they will cross it, but will slightly prefer not to)
- Schengen (system wouldn't take such border into account, people would cross it with no problem)

There is some problem with opened border, because there's still too large difference between crossing border between two EU countries (of which one is not in Schengen, such as France/UK) and countries with very tight border checks (such as Mexico/US).

By default each border is closed, and with separate rules the cross border movement can be allowed or partly allowed (ie. 50% movement only, when there are slow border checks etc like in past). That's rather simple in the overall scheme.

I think the easy answer is that using squares on the map is just not going to work.  The more accurate way to break up the world into regions is to create triangles using the 3 closest airports and then determining "desirability" for the passengers in said triangles based on the three nearest airports.  This is how it works in the real world.  I live in Asheville (AVL) and within a 2 hour drive I can fly out of CLT (US Airways hub), GSP (Southwest/Allegiant focus city), or AVL (Allegiant focus city, regional jet service to connect at a hub).  My destination drives my decision.  I can get a direct flight from GSP to Chicago, Baltimore, Fort Lauderdale etc. out of GSP, but if otherwise I can drive to CLT to get a direct flight or pay out the nose to fly out of AVL and connect somewhere.  A better example would be EWR/LGA/JFK where you have a very dense triangle of people that could be compelled to use any of the airports and a 250km radius would just be ridiculous.

On top of this, isn't the whole point of city-based demand to ignore existing airport hubs?  For example, St Louis is a major US city, but there is no airline with a hub there.  I should be able to setup a hub in St Louis and generate as much demand as someone basing at MSP (a comparable Midwestern city) where a hub already exists IRL.  Therefore, London Heathrow should not end up being one of the busiest airports in the world because players should be able to setup hubs at the "reliever airports" around London that could get just as large as LHR in the real world, slots permitting.  The US with airports everywhere will be crazy competitive (and fun).  This would also solve the "I drive from Bratislava to Vienna" situation, because it doesn't matter what country your in when using triangles.  You can't tell me people don't cross over into Hong Kong and Singapore to catch a flight, despite international borders.

Quote from: LemonButt on March 13, 2013, 01:59:24 AM
You can't tell me people don't cross over into Hong Kong and Singapore to catch a flight, despite international borders.

Agreed, but the Iron Courtain before '89 (in wich area 2 of 3 of the current GWs run) is a whole different thing than China|Hong Kong... so at least that would have to be in it.

Just asides that, while speaking about the Iron Courtain.... West GER --> Berlin (THF and TXL only) was a pretty big demand, unlike how it is in pre-'89 games, where it is also very low, while demand West GER -> East GER should be completely 0 where it is something 50-ish usually.

Wrong topic, sorry about that, but anyways...

cheers,
[SC] Jona L.

Quote from: sami on March 12, 2013, 07:19:17 PM
For the current test scripts, this was built earlier. The airport catchment area is a variable (monthly updated) value between 50 and 250 km, based on the number of passengers the airport has transported during the current game year (or previous year in case of january). Catchment happens only in the same country where the airport is - so far.

However; the 250 km may be too large for some countries, if you see the image below, where we have a 250 km ring around LHR .. goes all the way up to Manchester. (almost; as it does not catch fully the square where Manchester is, but very close to it anyway)

I think the system should constantly adjust what percentage of the pax from each square would belong to LHR for example.

In the UK, with a ton of airports, the percentage of the square that would belong to LHR would be relatively small.

But if you take Samo's example, of Vienna airport, and say a country of Slovakia, which has no LH airport, people from as far as 250km routinely catch flights in Vienna (perhaps Budapest or Krakow).

This is more of a case for LH travel than SH travel, when choices are limited.  There might also be some sort of friction (cost) associated with square distance from the airport, so that SH connecting to a larger LH hub would not be unfairly disadvantaged vs. "other means" within the catchment area.  Connecting 250km SH flight might be $75, but getting to the airport by other means may be $75.

Quote from: sami on March 12, 2013, 08:03:35 PM
Another small example from the case of overlapping airports.

In the image below we see Western Finland. It has three airports, Vaasa (VAA) - Kokkola (KOK) - Seinäjoki (SJY) . Each will have a 50 km catchment range and each of them will reach to catch the one lone square in the middle, marked in blue.

Well, firstly there's the need to calculate the destination where they wish to travel from that blue square. There are some 65 000 people living inside that blue area, and we'd need to calculate how often and most importantly where they wish to travel. This is the separate, most difficult, process. Let's skip it for now and assume from that square 100 people wish to travel to capital Helsinki every day. How would the people in the blue square choose their airport of departure?

This process would be kept rather simple preferrably...

For sake of simplicity, I would shift most of the calculations to the airport level, away from square to square level.

A square would just have the demand represented as a scalar, aggregate of passengers, broken down into SH, LH / YCF.  I think we should be ignoring square to square demand that would just blow up the system

Now these 3 airports would be trying to earn the business of this square.  At the start, each airport would have 33% of the square's business - square's affinity to the airport.

Now shifting the center of attention to the airport.  Airport aggregate demand would be just a sum of the demand of the squares within it's catchment area, taking into account each square's affinity.

So at the airport level, we now have again a simple aggregate demand broken into SH/LH, YFC.

Next, we would calculate all of the airport to airport combinations.  Using the aggregate demand, borders relations etc. we would end up with airport to airport demand, that could fit right into the current system.  Except, it would not be hard coded, it would be calculated, and then recalculated at desired intervals.

Perhaps, we should ignore pax connectivity for now, to get something going quickly.  Using all of the current pax allocations system, we can process flights.

At the end of the month, we get pax totals (as the system is currently tracking).  We compare the actual flown pax totals, and compare them to airports aggregate demand.  Comparing the demand vs. supplied demand, we get a new variable (single number), that is the ratio of these two, representing how well the airport is serving its demand.

Going back to 3 airports in Finland, they may start with 10%, 10%, 0% pax served.  We take these percentages and use them to change the affinity of the disputed square.  We started with 33/33/33.  We move to 34/34/32.

We take this new affinity of the squares, and change the aggregate demand of the airports.  And we recalculate the airport to airport demand.

As far as demand display, airport to airport, UI does not change, everything stays the same.  This is a greatly simplified approach, keeping the vast majority of the system as is.

The dynamic variables would be changes of the catchment area, as the airport serves more passengers, and ever changing affinity of individual squares within the catchment area.  The distance of square from the airport would affect the affinity.  A local airport within the square would never quite go to zero in affinity.  A local airport serving high percentage of pax within a very small catchment are would still be a viable business proposition.

As far as the work involved, the tasks I foresee are:
- Completing the crowdsourcing of the squares within countries, this just to get the ratios of squares within countries.
- massaging the crowd sourced data, applying country's population and GDP, assuring reasonableness of the square data.
- airport aggregate demand would be derived from squares.  Initial catchment areas would be derived from current airport size, but far smaller than the maximum catchment radius.  That will have to be earned.
- each airport will have its aggregate demand from the initial calculation above.
- we get the global aggregate demand (sum of all airports), and calculate the airport's percentage of this global demand.  This is again a single variable per airport.
- if we look at HEL in particular, and we know that JFK is 2% of global demand, we know that 2% of HEL's LH pax will be going to JFK and we know how many LH pax are originating in HEL.  So we get a numerical representation of HEL-JFK demand.  We save it for a month, and then recalculate again.
- country relations would modify the previous step

All of the steps above have a finite level of complexity, as far as I can tell.

I think the variable catchment area and squares affinity are a close enough proxy for the square to square demand.

Once this is in place, and fine tuned and put into production (actual live game worlds), a more complex step of pax connectivity could be built on top of it.  I think there is more complexity in pax connectivity than in building this City Based Demand.  And this City Based Demand will be new and different enough to keep all the players glued to AWS.

Of course, this new, dynamic world should not have RL hard coded slot levels.  The slots should start lower and grow organically, based on demand, so that the new hubs will be where successful players establish them.

Yes, it would of course immensly help in the volume and number of calculations, if we'd leave out alltogether the aspect of "X people from this square wish to fly to square Y - how do they get there" (as that would mean scouting the routes and connections etc).  (..of course here the demand would move over time to the airport that has some service, but this does not take into account if airport 1 has service only to some remote airport, while airport 2 has services directly to their desired city/square - airport 1 would still show request for the flights there, even though in reality everyone would go to airport 2... ..but it's simplified)

So instead of doing a list of all the squares (destinations) people would fly from this single square (approx 10000 values), we'd have only 1 set of values per square which is "how many people will depart from this square" (three parts in that data: holidaymakers, business pax and visiting family etc. (+cargo)).

However this approach, when it's converted to airport-airport demand in next step, would then mean that the global city and box data is rather useless compared to all the effort..

But have to think. I am pondering the different options and making calculations of what is feasible on this. Would of course like to include as much of aspects and data into it as possible, but the calculation amounts get limiting very quickly - and on the other hand even if it isn't that complicated would anyone even notice.  ;D

Quote from: sami on March 13, 2013, 09:11:04 AM
Yes, it would of course immensly help in the volume and number of calculations, if we'd leave out alltogether the aspect of "X people from this square wish to fly to square Y - how do they get there" (as that would mean scouting the routes and connections etc).  (..of course here the demand would move over time to the airport that has some service, but this does not take into account if airport 1 has service only to some remote airport, while airport 2 has services directly to their desired city/square - airport 1 would still show request for the flights there, even though in reality everyone would go to airport 2... ..but it's simplified)

So instead of doing a list of all the squares (destinations) people would fly from this single square (approx 10000 values), we'd have only 1 set of values per square which is "how many people will depart from this square" (three parts in that data: holidaymakers, business pax and visiting family etc. (+cargo)).

Yes, it is a simplification, and it would not get us the fine grained results, such as Airport A is serving HEL demand and is getting pretty much all of that demand from the disputed square, while Airport B, which has a flight to LHR, would get most of the disputed squares pax going to LHR.

But I think it is close enough approximation, to get this part done and move on to pax connectivity, which will deliver more value to the players.

The problem with square to square is not only determining (storing?) the demand, but also who is supplying it and how the airlines are competing for it.  Let's say a square that covers Manhattan, New York City to some central part of Los Angeles.  Manhattan is going to be in the catchment area of 5+ airports, and LA square will be in catchment area of say 4+ airports.  So we have to check 5x4 airport combinations how this 1 square to square is served.  If that is not enough, when we have pax connectivity, it will explode to perhaps 1000+ flight combos for this single square to square.

If we have connecting pax complexity on top of square to square complexity, we will probably reach a dead end.

The best thing about this simplification is the relative ease of implementation, and relatively modest computational requirements.

Quote from: sami on March 13, 2013, 09:11:04 AM
But have to think. I am pondering the different options and making calculations of what is feasible on this. Would of course like to include as much of aspects and data into it as possible, but the calculation amounts get limiting very quickly - and on the other hand even if it isn't that complicated would anyone even notice.  ;D

The immediate effect is that the legacy hubs disappear overnight.  ATL will likely not be the worlds busiest airport, LHR issues will probably disappear.  LHR will be less of a Trans-Atlantic hub and its demand will be disbursed.

Airports will rise and fall in significance, depending on how well they serve their passengers (with growing / shrinking catchment areas, changing square affinity).

But most importantly the system will have the correct data in preparation for the next stage, pax connectivity, which will be something the players will definitely notice.  The game play is about HQs and building hubs.  Hubs are about connectivity, which is missing.

Another thing we will have is world that is flexible, responsive to player actions.  In one game world, maybe CLT will become the busiest airport (with connecting pax), in another, maybe PHL or AMS.

More idea on the subject:

I would still keep the demand pinned to the airport to airport pairs.  I think the system already has it, and it would be good to keep it that way.  The question is how to populate this table of airport pairs and demand.

1. simple, granular, square has affinity to airport(s) while in catchment areas of these airports.  Affinity changes and all of the square's demand (all destinations) shift to one airport or another.  Once per month (or even more often), the table of airport pair demand is updated.

2. finer grained - a continuously running process will keep recalculating square to square demand and supply (in a fashion to be determined later).  Supply, and from which airport pair the supply was provided will affect where (to which airport pair) this demand will be pinned.  Result of this process will again be pinned to airport pair table, for a period of a month, for example.  So the end result will be the same.  The same airport pair table will be updated.

I would ignore the "potential" demand.  Too much to store, probably too slow for on-demand web site pop-up.  Let the players figure it out on their own.  We would always be looking at "current", what is currently pinned to the airport (airport-pair demand table).

Since the result of both approaches would be the same, the order of getting things done could be:
1. Simple, granular City Based Demand
2. Passenger connectivity
3. Finer grained City Based Demand, taking into account square to square supply/demand.

This way, we will be looking only at finite level of complexity at the time.  And the one with the most unknowns will be last.

If the approach is to always pin the demand to airport pairs (for fast user access, fast pax allocation processing), that will be the common denominator all 3 steps will have.  We will just be (at every one of these steps) figuring out how to populate and use this data.

Help wanted in the data input!

Read more here: https://www.airwaysim.com/forum/index.php/topic,46511.0.html

Sorry to bring a dead topic back to life but I have a few questions regarding this city based demand.

1. What will be the major difference between it and the current system and
2. What will happen to quirky airports like Baku, Tashkent, Vanuatu, Guam, which all have higher demand than IRL. Will these airports become 'normal', meaning no more ULH and LH business?

Quote from: Dasha on November 23, 2013, 08:32:16 AM
Sorry to bring a dead topic back to life but I have a few questions regarding this city based demand.

1. What will be the major difference between it and the current system and
2. What will happen to quirky airports like Baku, Tashkent, Vanuatu, Guam, which all have higher demand than IRL. Will these airports become 'normal', meaning no more ULH and LH business?

1. The current system has large airports based on real life airlines.  Atlanta is not the largest city in the world, but it has the largest airport in the world because Delta decided to put a hub there.  The new model will have demand to/from Atlanta based on the population, industry, etc.  This means cities like London will have the demand distributed across all airports in the catchment area, not just Heathrow.  It also means cities that aren't a hub become a lot more viable, such as St Louis, Tampa, and New Orleans.

2. There is a setting for islands (I'm part of the city data collection team).  Islands with no other transportation options will get a healthy boost--you can't drive from Taipei to Hong Kong.  Guam will probably be nowhere near as busy until connecting pax are modeled since it is a hub IRL.  On the LH front, the good news is the pax should be distributed.  That means instead of basing at an airport like Nice and only having 400pax longhaul demand to a small handful of major hubs, you'll have 150pax longhaul demand to a bunch of major cities instead.  It effectively means there will now be demand between any two points on the map instead of those decided IRL by airline hub placement.

I guess you will have to wait until the results of this new calculation show up. Amsterdam is a different case than Atlanta, ii is the central airport of a country.Of course demnd numbers won´t be as high as now. Especially if connecting travel will be coded and you would have to make it a hub with your passengers, like in real lfe.

Which isn't correct because the main reason Amsterdam is so big irl, is because of connecting passengers. If that's not scheduled, Amsterdam will be reduced to nothing in the game.

What is not correct ? Maybe you didn´t read it correctly. If connecting traffic will be coded, all numbers to now existing hubs will be much smaller than used. You will have to expand numbers by connnecting traffic organized by your airline. How can you be so sure about any special airport number, do you lead this project and know so much more details than everybody else ?
We don´t even know if and how connecting traffic will be realized and how that affects basic demand between any two airports, but complaining already started !

I'm just saying that IF you simply look at how big a city is and the demand from that city and not the airport, which is how I understand from you how it's going to be done, I think you get wrong numbers. That simply means that the biggest cities have the highest demand and that smaller cities will have almost no demand, meaning that an airport like Amsterdam in the game will basically be useless because Amsterdam has less than a million people. The strength of that particular airport is the connecting passengers, not every singly Dutchy flying six times a year :)

You still don´t seem to catch my point. First , it´s not pure inhabitant count of the closest city, calculations will be very complicated in the way every airport attracts not only the neighbourhood, but also those living more distant to it, giving PAX the choice to use more than one airport. Also the economy of the area and the country of every airport will be considered, giving Amsterdam a better hand than especially Atlanta, which is just one big city of many. It is intended to leave it to the players where they open hubs, connect a lot of their flights and so (as in RL) generate a growth on PAX and airport facilities through the mass of changing PAX. So Heathrow and Atlanta won´t be the biggest airports of any world anymore, maybe it will be AMS (for Europe) and Nashville for America, because the biggest game airlines build their hubs there. All airports will start small and will only grow if airlines decide to use them.And giving those opportunities to the players every gameworld will be truly unique, not necessarily depicting lived reality but creating a new. So there can´t be "wrong" numbers unless the base calculation works with wrong numbers in the beginning.

Okay now I understand it.

So in theory, Vanuatu could become the biggest airport in the world?

I didn´t hear of any relevant industry that would push Vanuatu into the first line of airports serving business travellers nor would it be able to host a dense network of local and international lines by geografical position alone. So my answer would be no. Base demand between the centers of economy will determine the logical position of potential hubs, so the world will not turn into a complete fantasy playfield. Since I am not in the development team I am combining the little information that could be obtained through the forums during the last years. I can´t predict how the new demand model will work precisely .

Quote from: exchlbg on November 25, 2013, 01:39:57 PM
I didn´t hear of any relevant industry that would push Vanuatu into the first line of airports serving business travellers nor would it be able to host a dense network of local and international lines by geografical position alone. So my answer would be no. Base demand between the centers of economy will determine the logical position of potential hubs, so the world will not turn into a complete fantasy playfield. Since I am not in the development team I am combining the little information that could be obtained through the forums during the last years. I can´t predict how the new demand model will work precisely .

I'd have to agree with this based on what I know.  However, airports that are geographically centered such as Cincinnati, St Louis, or Oklahoma City could end up being huge.

Quote from: exchlbg on November 25, 2013, 01:39:57 PM
I didn´t hear of any relevant industry that would push Vanuatu into the first line of airports serving business travellers nor would it be able to host a dense network of local and international lines by geografical position alone. So my answer would be no. Base demand between the centers of economy will determine the logical position of potential hubs, so the world will not turn into a complete fantasy playfield. Since I am not in the development team I am combining the little information that could be obtained through the forums during the last years. I can´t predict how the new demand model will work precisely .

Reading the last several posts, if I can interpret what is intended here....

Proximity to a large population (not the population of the city alone), as a proxy for economic activity, will play a determinant in the potential maximum size of an airport.  Perhaps trade restrictions between countries would mitigate that crossover (e.g. East vs West Germany) but open trade helps (e.g. Amsterdam).  Rather isolated cities (e.g. Vanatu), would have limited upside.

Therefore, cities like St Louis, etc can have a pretty large upside, in a fashion similar to Atlanta (irl).

Is this all correct?

I believe so.  To give an insight on the data collection, the world is broken up into approx 60nm x 60nm blocks.  Each block is assigned values based on population, infrastructure, industry, etc.  That data will be fed into airports to determine pax demand.  How large the catchment area is I'm not sure, but I'd say it will fade as the radius gets larger.  So the home block = 100%, 1 block out will be 80%, 2 blocks 50%, 3 blocks 25%, 4 blocks 0%...or something similar to this.  The idea being people will drive 2 hours to the airport, which is what really happens IRL.  I live in Asheville, NC for example and will drive 1 hour to GSP, 2 hours to CLT or TYS, or 3 hours to ATL to get the best price and/or a direct flight.

Once connecting pax are implemented, I assume it will be based on opportunity cost.  If flying from NYC to LAX is 3000nm then a pax will connect in an airport if it doesn't make the trip longer than 3500nm with the connection, for example.  This means NYC-STL-LAX could compete with the NYC-LAX routes/demand etc.

sami has IMO thought of everything in terms of city-based demand factors.  Each box has parameters for whether or not it is populated, whether it is an island, industrial activity level (relative to country average), business activity level (relative to country average), tourism level (relative to country average), and the holiday months/seasons.

Thanks.  Sounds like an exciting addition!  ;D

You do mentioned 2 hours drive...not sure if that is just a notional number or if that is the actual plan.  The catchment area might cover a larger area where there is some spread between airports is some thinly populated areas.  Might it be dynamic in that sense? 

An example is North Platte, Nebraska (just to pick one), which is 3-4 hours from several larger airports:  Denver, Omaha, Cheyenne, and Lincoln.  IRL, those people would be travelling pretty far to fly.  Not much population in the town itself, but considering the swath of land covered, like droplets of rain, they can accumulate.  Or, perhaps that is already accounted for by some other factor?

Still, whatever it is, it will be an interesting dynamic to play under.

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?

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.

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

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 :D

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.

Quote from: [SC] xyeahtony on December 29, 2013, 02:35:18 PM
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

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)

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.

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

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

Quote from: gazzz0x2z on June 27, 2014, 06:57:18 PM
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.

Quote from: gazzz0x2z on June 27, 2014, 06:57:18 PM
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.

Quote from: sami, the boss on June 27, 2014, 07:24:45 PM
That's already modelled in current games, though partly incomplete perhaps.

Cool.

Quote from: sami, awesome on June 27, 2014, 07:24:45 PMThe pic in previous post is not related to this, it's for local data/demand.

That's awesome. Potential will be probably wonderful.  :)

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)

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.

Quote from: sami on June 28, 2014, 02:56:22 PM
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.

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

Quote from: Murphry on August 15, 2014, 07:37:07 AM
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

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

Quote from: Murphry on August 15, 2014, 11:00:31 AM
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.

I have some issues with this... Especially in regards to cities with teo or more airports.

Went to open pdx-MDW, a real life route served at least daily.

Well i cant even fill a 737 sized plane daily. Meanwhile, ord-pdx has 500 pax a day.

It just seems weird that demand is not spread evenly between two major airports.

Quote from: Monk Xion on September 05, 2014, 02:07:18 PM
It just seems weird that demand is not spread evenly between two major airports.

Why should it be even? Makes absolutely no sense ..

I would rather fly to Paris than to Moscow for example. ;D (Both are quite major airports...)

Quote from: sami on September 05, 2014, 03:06:26 PM
Why should it be even? Makes absolutely no sense ..

I would rather fly to Paris than to Moscow for example. ;D (Both are quite major airports...)

But they aren't two airports in the same city which ord and mdw are.

Ah, didn't catch that but still the same idea applies, since I would bet most businessmen would rather travel from London City than Heathrow (if they could..). Call it differences in airport appeal & service. So far it's static and players cannot affect how the demand switches between airports but it's different story in the future.

But to get back to topic, even in the new planned systems, the two or more airports in the same city won't ever be identical in terms of demand.

Small progress report; I am working on this every now and then and bit by bit.

Still working on the base country data, but I believe it should be done now (a test is running for the next days). In other words the whole basis of everything is in the country's population and their purchasing power (GDP). This population is then in these smaller squares (for which separate data was collected by the community), and in order to make everything work in the long run from 1950 to 2030 that data needs to update itself and work properly.. It sounds easy but it isn't with all the countries merging and breaking up and so forth, but it should be done now.

Eventually the news and interface would also have economy predictions based on all this data, so your boffins will tell you how the economy (read: pax demand) will develop in Papua New Guinea next fiscal year .. So you can plan ahead.  :P   (but this is something for later .. once this gdp/population base data works properly I will move on to the airport/square level things again)


= Just a small "dev's blog" type of post to let you know I am doing something even though it looks like I am not.  :laugh:

Further "blogging" ..  :P

As already discussed in the past each airport will have a catchment radius around the airport, and this determines which cities (squares) that airport can serve to. The catchment area is a simple range ring around the airport and it is dynamic. The size of the ring will be based on the new airport size classes (more here: https://www.airwaysim.com/forum/index.php/topic,21347.msg268408.html#msg268408).

With the smaller airports it's 50 km, and can extend to up to 200 km from the airport (these figures can be adjusted later).

The calculation is based on the new airport size classes. When the game starts the airport size classifications will be so that the 'infra class' will be from 1-5 and corresponds the current airport size classes, and the 'traffic class' (1-10) will be based on the real-life size/stats of the airport (the highest 1% of all airports will be in class 10, the next 5% in class 9 and so forth). So for example LHR will be infra 5 and traffic 10. A bit smaller airport such as Stuttgart would be infra 5 and traffic 9 (or 8 ). As mentioned in the other thread the traffic class level lives/changes according to how players transport passengers from that airport and it can move freely (step by step, updates 2x yearly) between 1-10. And the infra class level can grow over time when airport expands (not modelled yet).

So initially when each game starts the max range for even the largest airports such as LHR will be about 100 km. The calculation formula is based on these two class levels so that the traffic class has 75% weight and infra class 25% (again may be changed if needed).

When the game starts the catchment area range is updated monthly, and it is based on the same values but creates a bit higher values, so a 5/10 airport would have about 180 km range then. The changes in the catchment range happen step by step, so if the previous was 100 and new calculated is 200 it would take 4 months to change since the max catchment range change per month would be +/-25km to avoid sudden big jumps.

Okay so there we have the circle radius of each airport. On top of that we add the data (in progress) of cross-border travel of citizens. As mentioned by default people will not cross borders, but with a separate manually coded list we can make that happen. If an airport is right next to the border, it's radius extends to the other country, but by default nobody will come from that other country; but once the settings are done it works too.  ...but this takes quite a bit of work!


This airport square catchment stuff is being tested at the moment in the background of a couple of live games since it needs to be made sure it works. On top of everything else the possible changes in geopolitical status of countries need to be considered, and I would suppose the easiest is just to trigger a hard reset type of calculation for those airport/countries involved?

One more update on the subject related to the previous post.. (This has been shown before, but just posting again since it's nearly finalized now and shortly in active testing.)

The catchment range of each airport (prev. post) translates into list of squares the airport can catch (these are the squares with the detailed data about business activity etc.). In other words the area and cities this airport serves.

This list of squares catched by each airport is updated on the background, once a month. As you see from previous post the catchment range of the airports can change, and these changes will in turn affect the number of squares the airport can catch. So the airport's "area of influence" is dynamic.

There are a few rough edges here since we are here moving the circular range ring into the square boxes. The system works it out so that naturally the box where the airport is located is catched fully. Any adjacent squares are catched only if large enough area of that range ring intersects with the area of that square. Example is attached; it's a small airport in the Solomon Islands that has a 50 km catchment range ring. While the range ring itself goes over 4 different squares it will actually catch only two of them (the two lower ones), since the ring isn't large enough over the two other squares.

The second pic shows the catchment area of LHR when it is at maximum, 200 km. (There's still a bit of work in progress about how the partially catched boxes are treated.)

The cross border travel settings are also checked here to determine what percentage of the people, if any, that airport can catch from a square from another country. Example pic #3 shows a sample dataset for one country; the 0.2 factor there means that pax from Iran for example have a 20% chance of going to fly from an airport located in Afghanistan - naturally given that such airport exists and catches the square in Iran. The cross border data settings is just a layer on top of everything else and it should be quite smart this way, after all data is collected there. Currently it's still hugely incomplete. (On top of these basic settings we could then later on even model temporary changes in these settings using the events module. ..but don't see that necessary; just a possibility.)


EDIT: The last (4th) pic shows the cross border thing in action. Using the previously discussed Austria/Slovakia example, I've set (as a test) that people from Austria can cross to Slovakia's airports. And here's how Bratislava would look like .. It has a radius of about 120 km and the two leftmost green boxes belong to Austria, and people from Vienna could then come to this airport too. (note; Czech and Hungary were not set for this example, so that's why they are empty) ... Collecting all this data is a BIG task though. But essential in making it work properly.


Anyway, once the squares it can catch have been figured out the system needs to calculate that airport's relative "score" for each of those squares. This means that how likely the passengers from that square are to use this particular airport. This is still work in progress but involves distance to the airport and other factors - so people who need to drive from very far away are for example less likely to come to this airport.

For now the tests are running to make sure the base data updates itself correctly and the catchment ranges/squares work as intended.

All this is most likely fully invisible to the end-user .. although that info could be presented to them too as "nice to know" stuff.


(Again the possible troublespots here too are the changes in geopolitical environment and airport relocations. Needs to be tested / coded later on.)



Also, minor changes in regards of previous post. The catchment radius will change more slowly when the game is new. When the game is less than 180 days old the max change of radius is +/-10 km per calculation round, and +/- 20 km when it's less than 365 days old and +/- 25 km per round after that. Catchment radius calculation is done once every month. ..so it takes a bit longer for a big airport to reach the max radius when a new game world starts, creating slower demand growth.


edit; added fourth pic.

Looks great Sami!

Any idea how this will be implemented?Such as on only new game worlds?

Quote from: sami on September 27, 2014, 02:21:41 PM
(Again the possible troublespots here too are the changes in geopolitical environment and airport relocations. Needs to be tested / coded later on.)

These should be sorted now on a technical level for the airport catchment ranges / catched squares. There are the following airport opening / relocation / change events possible, and the system will react as follows:

* A new airport opens with no previous airport in the area
     - Nothing special involved here, apart from demand re-calculation triggered. (like it currently does too)
     - The new airport will start with a catchment range relevant to it's size, with the largest initial range in that case being about 100 km.

* A new airport opens and an old airport closes at the same time
     - The new airport will inherit the 'traffic size class' level from the old airport, but 'infra size class' will be initially fixed (the same as the current 'size class' value).
     - The new airport's catchment range will be in the 85%-115% range from what the previous airport was (depending on the size of the new airport).
     - And the catched squares for the new airport are recalculated based on the data above.
     - Demand re-calc triggers again for the new airport too. (like currently)

* A new airport opens while an old airport moves to be a secondary airport
     - Same as the previous step, with the exception that the old airport's size classes and catchment ranges will have a bigger drop (if such happens to that airport).

* Geopolitical changes such as country's breakup from an union
     - The events trigger the recalculation of the catchment ranges / catched squares of all airports in that country. Because this will then model the changes in any border crossing rules; ref. for example break up of the Soviets.
     - However demand is not recalculated but it instead shifts gradually towards the new values over the following months. This is to avoid too heavy sudden changes and calculations (= calculating a whole country in one go).


Again, all this is not very relevant but has to be done. The main thing in relation to this is now to collect all data on these border crossing possibilities, but that's something for later. It's been technically done and proved now.

Quote from: CarlBagot on September 27, 2014, 08:30:24 PM
Any idea how this will be implemented?Such as on only new game worlds?

Well it's hard to say really yet at this point.

(I mean technically it's not a big trouble, all this stuff shown so far is already running in all live games (for testing purposes) but the main point is that the demand figures will be 100% different in 100% of the routes .. so a big pain for players basically. Some gradual shift could work, but .. not sure)

One more picture for fun ..

Since it's much easier to figure out if everything works properly I built a small tool to visualize the airports, the squares they catch, and the catchment ranges. Here's how New Zealand looks like in a test game from 1950s that's been running a while.

Green = is catched by some airport, red = not.

This picture visualizes quite well one of the basic ideas of this new system in planning. Many airports overlap each others and with some expansion for example the Hamilton's airport can reach Auckland and drive some of the people there instead.

The user interface's airport info page would probably have a small additional data box about all this (but nothing like this pic), and it would tell the user 1) catchment range area, and 2) number of people catched by the airport. Just for reference on what kind of area that airport is expected to serve. However not sure if that's of any use since people from different squares will have different probabilities of coming to this particular airport.

Looks nice and so on, but doesn't do anything yet.

I'm curious about the "blank" areas in island nations like the NZ example above, or for example Japan or Cuba. If they fall outside the catchment area of every airport available to them, are they considered less likely to travel at all? (which kind of makes sense, actually)

And what happens if, for example, a region of northern Japan were to fall outside the catchment area of every Japanese airport but within the area of a Russian airport? They are obviously not going to swim to Yuzhno to fly to Los Angeles. A land border crossing is one thing, crossing the Soya Strait takes a bit more effort.  (I'm not suggesting northern Japan will fall into this category, just curious about the possibility.)

Quote from: tvdan1043 on September 29, 2014, 06:50:27 PM
I'm curious about the "blank" areas in island nations like the NZ example above

A red square not catched by any airport is simply omitted. (a blank area with no red/green square is an unpopulated area and omitted)

...


Then on to some considerations / thoughts of the system ..

Item 1
As previously posted we now already have the airports tied to the squares, and that is fully dynamic how they react.

One thing to do there is to test/code the airport vs. square "score". In other words, if many airports share a square we need to distribute the pax from these squares to the airports. This is something that's highly debatable, since studies on this matter give different data.

Generally speaking the passengers would prefer the nearest airport, however studies show that while they do this they still actually prefer the alternative larger airport that would be farther away compared to a small airport nearby (given that all other variables remain the same), since they think that larger airport has better services and better chances of re-routing etc. in case of problems (however they also think that larger airport is more prone to delays). (ref. a study made in University of Leeds for example)  So there's no clear method for this, and just a matter of choosing some combination.

If we use a simple method it would be simply a function of distance, airport size and the number of routes perhaps. However one main issue here is that this doesn't take into account the destinations at all. Example: if we have square X from which 100 people wish to travel to square/airport Y, and square X is catched by two airports (A & B) which both are identical in terms of the "score" (for the sake of example). This means that how it would work, in the current plans, is that airport-to-airports demands A-Y and B-Y will be the same (50 pax; since the square related score for departing pax from square X is the same for both). But the problem is that if only route A-Y exists and is flown, then naturally all 100 passengers would move to A-Y and leave the B-Y demand as zero since there's no other option. All logical so far ..

Technically this poses a challenge since the square to square demand figures cannot be stored (too many). So perhaps, as discussed, one approach could be that first we calculate the baseline airport to airport values where each "airport vs. square score" is calculated purely on distance & airport size. Let's say 65% emphasis on distance and 35% of airport size class (50% traffic class / 50% infra class)  .. (though these numbers can be debated). This is the initial setting also when a game starts. Naturally if a square is catched only by 1 airport, then it would catch the entire population regardless of the distance to that airport since people don't have any other choice (and this is mainly in remote areas where there aren't too many airports).

And when game starts and routes start to appear, the system would then take into account the actual service and routes by players to shift this demand to make the people "smart". However this is a slow process and is not able to react immediately. If for example my airline flying B-Y will close down the route (while another airline is flying A-Y at the same time) it would take up to a game month for the people to move to the A-Y route instead. In an ideal system each individual passenger would be "smart" and switch right away but it's not possible. Another thing that needs to be measured here are the prices (etc.) of the available flights; and again the issue is the slow reaction (think of the B-Y airline dumping prices and gaining all the demand, and then raising them through the roof and he'd still have the whole demand available before the system is able to update the data).


Item 2
Passenger destinations.

So far we already know how many passengers will depart from each square in total (based solely on data of each square and country - no relation to airports in this part yet at all). A major thing to be worked on next are the destinations. So we need to know where the guys wish to fly from that square, and this is one of the most important parts here.

Most of the data needed for this on country and square level is collected now,  and this will be transformed into actual values.

One big change is that the Y/C/F class thing will be gone and it will be replaced with passenger types who have different purposes of travel. The main division is still three classes; leisure, business and VFR (visiting friends & relatives), with the addition of cargo (separate stuff). The three classes are roughly ~30% each, but there are huge differences in this for each country and airport, so again no reference material or study can fully give a proper baseline for this. Generally speaking though in rich countries the leisure level is higher and in poor countries it's more business-oriented flying. The VFR is then highly represented on routes where countries share close links, such as France and Algeria for example (immigrants..) - we already have a good database of these country relationships (but could be expanded even further).

Each of these pax types will have different preferences then. A leisure traveller cares just about the price and business traveller just about the schedule, if we exaggerate quite much. If we'd wish it to be even better each group could be divided into sub-groups (such as urgent business, non-urgent business etc.), but I think that's too complicated already. And according to the pax preferences you can then sell different products to them (seat quality etc).

So step 1 is to finalize the pax type calculation for each square; what kind of people depart from that location.

After this is done, the destinations need to be figured out. And naturally each pax type will have a different preference. Usually most leisure travel happens within own continent, about 80% of international tourists are from the same region (region=e.g. Europe) (ref: UNWTO Tourism Barometer), while business/VFR may be more of a mix of short/longhaul more. Though the proportion of longhaul leisure flights does increase once we go more into the future.

Each country will be given a countrywide values for industrial, business and tourism activity. The first two are most likely combinations of existing data (GDP related) since it's been impossible to find any suitable sources for that, and the tourism activity data has been just gathered (however it only takes into account international overnight tourist stays). All this data is then counted (just in the process of working with this) and on top of that is added the country-level data on the squares (that has been collected together). These combined values, added with some distance based data & info on country relations, will then give a single 'desirability score' for each square, for each passenger type separately.

..and that should be how we arrive to figures on where the people wish to go from each square. One possible problem spot is domestic air travel, especially in the small island nations.

Once all that is known this is then moved to airport level and it should be quite close to completion. Easier said than done though.

Looking forward to it  ;D


Just curious for Item 1, are you intending to show catchment demand instead of airport demand for route planning? Since if  airline Z is the only one flying at airport A if we continue with calculating route oversupply from the airport any other airline from airport B or C would never be able to start the route.

That's a good point.  The demand should reflect both the "current" demand and the "catchment demand".  If current demand is low, but catchment demand is high, I assume that charging lower fares will increase demand (PAX will switch the low fare airport) as well as increasing supply (more options).

As for the different PAX types, a couple questions: I assume that each type (leisure/business/etc) has different propensities for F/C/Y so not sure how the different classes will work.  How do you know how many seats to config in each class if you just have information on PAX type?  Retrofitting planes is not cheap.  I assume that implicit in this new approach is that by offering "cheap" C fares, some Y PAX will be able to move to C class, whereas right now the allocations are relatively fixed.

Second: How will connecting flights work versus direct flights?  Right now there is a huge advantage to direct flights.  However, in RL people (and leisure in particular) will connect to save some cash.  That's why in the US there are large hubs in places that don't generate nearly as many PAX as the traffic data suggest (ATL, etc.).  How will connecting versus direct be evaluated in this framework?  It seems to me that the settigns should be such that the hub and spoke method works well for lesiure PAX, but worse for business PAX so it depends on the population your airline is trying to target.  That would allow for more strategies to be employed by players.

Third: Does this mean that seat type (and other amenities which i assume will be added over time) will have a much larger impact on business PAX but nearly no impact for leisure PAX?  Again, I think this is a good chance allowign for more business models to be successful (similar to the recent changes in basing)

Just wondering if cargo should have a larger catchment area than passengers. Looking at Europe, an Airline such as CargoLux only serves a few airports in the region as trucks  are the predominant short hop mode for cargo.

Status update

- Slow progress here too, working on this every now and then.

- Finished the first "technical demonstrator" of the basic calculation process which converts all this data and all these figures into plain and simple airport to airport demand figures, which is the desired end result. All of the possible variables and systems should be now incorported into the calculation, but many sub-functions/calculations are still missing (just giving static testing values), so the results are still nonsense, but the baseline concept is done now and it's a matter of finishing the functions that calculate the destinations for the demand for example.

- Cargo calculation possibility is also added on technical level; so there are four "travel classes" that the system calculates (cargo and the three passenger types mentioned earlier).

- In my last post I discussed (item 1) about how to distribute the passengers from a square to multiple airports. This is now done for the initial part of the game (= no routes, no airlines): If a square is catched by many airports they each get their share of the passengers departing from that square. The pax sharing "score" is calculated based on airport's distance from square center (50% weight), airport's traffic size class (35%) and airport's infra size class (15%); added with any settings about the probability of border crossings between nations (data pending). So at the start of the game there's a small bias towards the larger airports already to reflect a more real-life situation. Once the game starts going the score is then also relative to the routes/services offered by airlines, but this is a completely another matter to work on (it extends this basic calculation).

- So once each airport gets his share of departing passengers from each square it catches, the system then proceeds to calculate where the passengers want to go. This is still work in progress to get proper figures, but works already on dummy figures. This will take into account the data of each country and each square in the world, added with data about geopolitical relations and such (like I previously posted). To ease up the calculations this data is translated into airport-level data sets at this stage (airport to airport, instead of airport to squares) based on the properties of squares the airport catches. So we'll then calculate these together and it brings us to airport to airport demand, which is the baseline demand.

- This demand figure can be then worked in a similar manner like in current games (utilizing the current game's codesets); ie. making sure there are no sudden big changes etc, and after that it's stored and will be displayed to the users like in the current interface (apart from the different pax classes).


=> Short summary:
The work is still in progress with the first and fully static model of the system, and it's the first and most difficult thing overall here. Once it's done the minor part related to it is to make the demand shift between airports according to services the players offer. But the hardest part is to make this fully new data to generate proper and logical figures, as the new system does not have anything to do with the current/old airport based system and NO part of it or no data of it is being used in the new system.



Edit, addition:

In my previous message I discussed shortly about the "purpose of travel". This has been now finalized on square level. Like I posted it will have three passenger types, following the normal international standard of travel classification. Leisure travel, visiting friends and relatives and business travel. There's also a small "others" segment in many stats but it usually has a share of <3% so it's irrelevant.

In AWS each passenger departing from a square will have a purpose of travel. This will be a complete change to the current system and will allow us to build more dynamic service and ticketing system in the future (see my previous post).

The system now calculates how many of different pax types depart from each square, based on the details of that square. Simple system, and shortly stated, the richer area the higher the relative percentage of holiday travellers flying out from there. In poor areas the disposable income is smaller and majority of the travel will be business oriented.

And each of these three groups will then have their share of people who seek premium, and people who seek the best price etc. Consider holidaymakers .. Majority of them is after for the best price (will choose a cheap Y ticket) and only a small part is willing to pay a lot for good service. But for business travellers the share of people paying more for schedules/good services&seats is relatively much higher.

Any chance for adding connecting passengers?  That's likely another nightmarish coding endeavor, but would be cool if connecting pax (and possibly feeding alliance members via code share) were added to the game.  Someday in the future, perhaps!

Status update

Worked with this again for some time. The item under works is still the first and completely static version of the new system.

Otherwise it's all pretty much planned, but the issue of passenger destinations is still unsorted and the one giving most trouble. Since this new system will have absolutely nothing in common with the current/old system, also the destination calculation will be completely new. In other words the "where the people from this airport wish to fly" bit.

The basic data based on countries and the data squares provides the baseline but it seems that it will still give way too inaccurate results which is the problem here, and more data collection might be needed.

Let's take holiday travellers as an example (one of the three passenger types in the new model). We know already how many holiday travellers depart from each data square, and we know which airports "pick them up" for departure. => We know how many local people depart from each airport.  We also have a global data on tourism, so we know that in a global scale for example France is the number #1 tourist destination. And inside France we have the squares that give out the usual tourist destinations so basically we should able to divide the data into proper destinations.

However after working with this it seems that at least for this passenger group the square's 8 level (-6 to +6) system is not accurate enough, since for example Paris and Bordeaux area are both assigned a +6 on tourism, while in reality Paris would be higher. So basically this means that person's travel desire is the same to both of these places. And it's a bit worse effect in very large countries .. But it's not practical to start changing the square data anymore.

The second and perhaps the bigger issue is to make the destinations work in a logical way and somewhat similar to real life. If we take holiday travellers from Sweden as an example. Currently the system calculates that an airport in the Ukranian area would be their 5th largest destination. Why? Simply because #1) Ukraine is (or in real life "was") a large holiday destination, ranking 12th in the world in the number of foreign tourist visitors (lots of visitors in the Krim area for example), and #2) because that airport is relatively nearby Sweden (80% of holiday travels happen on the same continent, ~<1500 nm). But compared to real life it makes no sense at all, since Swedes don't visit there but fly to Spain for example. But with the current data the system cannot know of this at all. There's some country vs. country relation data, but only on a general level and not for all countries. So in order to make this work properly, each and every country would need dataset on these relations (sort of "where would the people like to go"). This data would then supplement this calculated data, and in this example for example assign a "0.1" factor for the Ukraine.  ...but getting all this data is rather difficult, but on the other hand a must.

However has to be noted that with these current (test) values and factors, the number #1 destination for those tourists Swedes is Palma de Mallorca, so that's rather accurate .. But as you see, without the detailed country relation data there will be a very large number of these oddball destinations.

Another issue is longhaul holiday travel, does not work at all yet, but I'm currently working on that.


This tourism data is probably the most difficult one to tune properly, business travels are easier.


So in summary. System works, but it's not giving very good values so far.

How to proceed: I'll look into tuning this destination thing a while more, but then I will probably move forward to the next thing and come back to this later (just so that the "full" system could be tested in action, and then just tuned later).

Good with an update on it Sami, sounds to be long way to the goal line, but good with progress.
Sounds to be som rather big bumps still left on the way.

That's a big job, it seems. Cultural fit is as important as tough to make.

Quote from: sami on November 25, 2014, 02:20:17 PM
However after working with this it seems that at least for this passenger group the square's 8 level (-6 to +6) system is not accurate enough, since for example Paris and Bordeaux area are both assigned a +6 on tourism, while in reality Paris would be higher. So basically this means that person's travel desire is the same to both of these places. And it's a bit worse effect in very large countries .. But it's not practical to start changing the square data anymore.

Scale it up by population of the destination square?

Quote from: sami on November 25, 2014, 02:20:17 PM
The second and perhaps the bigger issue is to make the destinations work in a logical way and somewhat similar to real life. If we take holiday travellers from Sweden as an example. Currently the system calculates that an airport in the Ukranian area would be their 5th largest destination. Why? Simply because #1) Ukraine is (or in real life "was") a large holiday destination, ranking 12th in the world in the number of foreign tourist visitors (lots of visitors in the Krim area for example), and #2) because that airport is relatively nearby Sweden (80% of holiday travels happen on the same continent, ~<1500 nm). But compared to real life it makes no sense at all, since Swedes don't visit there but fly to Spain for example. But with the current data the system cannot know of this at all. There's some country vs. country relation data, but only on a general level and not for all countries. So in order to make this work properly, each and every country would need dataset on these relations (sort of "where would the people like to go"). This data would then supplement this calculated data, and in this example for example assign a "0.1" factor for the Ukraine.  ...but getting all this data is rather difficult, but on the other hand a must.

However has to be noted that with these current (test) values and factors, the number #1 destination for those tourists Swedes is Palma de Mallorca, so that's rather accurate .. But as you see, without the detailed country relation data there will be a very large number of these oddball destinations.

Maybe each country could have top X country destinations for its citizens.  It would be just a scalar, 1.0 default if country is not specified in the country to country table.  Eventually replaced by a some factor derived from the country to country table.

This way, this particular item would not be a showstopper, since a good way to address it would already be planned, and eventually implemented when data is gathered.

Another thing that may be useful is a long term event "war" for a country when it is fought on its soil, based on historical facts, and it would dramatically reduce holiday travel.  And that could also go to this single factor.  Say from 1.0 to 0.50.

Or another factor, say Olympics or World Cup that would increase it from 1.0 to say 2.0

Been looking through the thread and think many of these ideas will be good for airway. Sami and the airway sim are doing a good job despite challengers which could arise. Are there any dates when some of these feactures will start to be added to games ? I do also have a question too. Has there been talk about the opinion of a cargo airline and commercial airline when you are creating your airline ? I have had a look but didn't seem to find anything.

Getting there Sami.  Been reading through as it's a subject I have a keen interest in.
I appreciate all you have achieved so far, just a couple of tweaks that might help:-

Seems to me each airport needs a 'Seating Plan' (based on the aircraft system you use) so LHR will be more first and business class than Gatwick (Tourist).  But this factor can be influenced by the services provided.  If all/most Gatwick First (or Business) traffic is being moved while LHR's is not, then Gatwick will expand (new terminal or upgrade to meet the through flow like real world).
On the long games it is possible for Gatwick to be the major airport for London (why not, it's better placed, just needs another runway and a couple of terminals).

Regionally (in my area) Exeter and Southampton are doing well, while Bournemouth lost a major holiday carrier (2009? soon after building a new terminal) and is struggling but is still a bigger airport and longer runway than Southampton EGHI. 

Stanstead is a lovely airport to use, needs another runway, Gatwick is still trying to find itself due to mismanagement and miss design, LHR is at 100pc capacity.  Rumours are Luton will have a second runway soon (land purchased) driven by the London demand. 
Manchester currently runs at 60pc capacity (flights) but in 5 yrs the new high speed rail link will make it a viable alternate to LHR.

The New London Airport should already be just north of Oxford on the old USAAF base of Upper Heyford which is near where phase one of the new high speed rail link. Unfortunately it's gradually becoming a housing estate - such is the planning on the UK.  Why no 'invented' airports?

On the longer games it's up to you whether the game reflects the real world, or accepts that the real world isn't perfect either.
My suggestions are to help game airports grow in relation to their level of capacity and service (quality) would allow those serving a major centre to develop naturally which will help Gatwick airlines to compete with LHR.

And finally an airport upgrade always leads to an increase in airport 'Landing Charges'.  LHR has 6 terminals now, 3 when I first went there in the 60's.
And, sorry - Can my airline take an investment in my First Airport to help it grow traffic and capacity?

loving the game - and your efforts to keep it growing.

QuoteSeems to me each airport needs a 'Seating Plan' (based on the aircraft system you use) so LHR will be more first and business class than Gatwick (Tourist).  But this factor can be influenced by the services provided.  If all/most Gatwick First (or Business) traffic is being moved while LHR's is not, then Gatwick will expand (new terminal or upgrade to meet the through flow like real world).

Isn't this one of the things CBD is going to improve, allowing any airport that has London within its catchment area to pick up this business, why would we need a 'seating plan', it defies the point of having a more flexible system. If you are going to hard code first/business demand whats the point in changing to CBD.

Heya Sami, is there anything I or anyone can help you with getting this done  :)?

I mean this sincerely.

Haven't worked on this for a while, since I've focused on other things .. Planned a bit so that cargo would be possibly the first thing that is actually tried out in any test games .. but let's see.

The data is collected. ..for passenger travel side, the actual destination calculation is giving me grey hairs still (= how to calculate smartly where passengers will want to go from a certain location; cannot use the old code there).

Quote from: sami on April 05, 2015, 02:38:27 PM
Haven't worked on this for a while, since I've focused on other things .. Planned a bit so that cargo would be possibly the first thing that is actually tried out in any test games .. but let's see.

So that means we will see cargo soon? Very well.... can you already give some previews?

Will that work only with specific cargo planes?
Will there also be Cargo using spare payload on regular (PAX) flights?
Is cargo also as time sensitive as passengers, or can night slots be used as IRL?
How will cargo demand be displayed? Will that call for a reintroduction of the good old demand bars?

Thanks ahead :)

cheers,
Jona L.

If cargo will be introduced in this game then belly cargo would be a nice add on. It would give the player an opportunity to generate extra cash and transport cargo without having to operate cargo only planes.

Quote from: sami on April 05, 2015, 02:38:27 PM
The data is collected. ..for passenger travel side, the actual destination calculation is giving me grey hairs still (= how to calculate smartly where passengers will want to go from a certain location; cannot use the old code there).

As far as square to square demand, it should come from the geographical data connected, using the population, GDP etc.  The system does not have to store this data, just know how to calculate it at any given time.

As far as how they get there, I suggested earlier splitting the task to 2 independent tasks, in order to manage complexity:

1. pin the square to square demand to airports (resulting in familiar airport to airport demand)
2. allocate airport to airport design using much of the same existing logic

1. pin the square to square demand to airports

This could be done asynchronously.  The allocation of square to square demand to airports (as far as which airport pair to pin the demand to) would (after initial default allocation) depend on availability, quality and capacity (supply of flights) between the airport pairs.  Also, how well this pinned demand is being served.

2. allocate airport to airport design using much of the same existing logic

Except, it needs to be enhanced by introducing connecting flights - which, IMO, is the most challenging part (from programming standpoint), and also most rewarding to the players.

In theory, Step 1. could be done independently, a game world could run with just Step 1 being completed, and Step 2 could use all of the existing code (assuming the existing system already has the demand stored in database in form of airport to airport demand).

No, technically it's already all done pretty much (and in a way you described there too). The main issue I am having (and what I wrote there) was figuring out the destinations from each square. The best way to figure _where_ the people from each square wish to go, in order to make it realistic ..

Quote from: sami on April 05, 2015, 02:38:27 PM
Haven't worked on this for a while, since I've focused on other things .. Planned a bit so that cargo would be possibly the first thing that is actually tried out in any test games .. but let's see.

The data is collected. ..for passenger travel side, the actual destination calculation is giving me grey hairs still (= how to calculate smartly where passengers will want to go from a certain location; cannot use the old code there).

I think there are some fundamental questions that need to be answered before you can even attempt to do the algorithm to distribute pax demand.  Let's take 3 airports in Los Angeles, Chicago, New York.  Let's assume an airline is flying NYC-LAX and charging $200.  Another airline is flying NYC-CHI and CHI-LAX and charging $150 for both flights.  If a pax goes NYC-CHI-LAX then how much is the ticket?  $200 or $300?  If you force an airline to sell it for $200, they are missing out on $100 in revenue that could have been earned by not allowing connecting flights.  If the airline is getting $200, they shouldn't be because the direct flight is $200--they should be charging something less than $200 for the inconvenience of connecting.

I don't think you can setup a pax demand algorithm without first setting up business plans, the simplest form being 3 options: Traditional hub/spoke with connecting pax (like Delta), Focus City airlines that will use multiple legs for a single flight number so they would have 3 routes with 3 prices being LAX-CHI, CHI-NYC, and LAX-CHI-NYC (like Southwest), and then strict point to point carriers where there are no connections and you pay per leg (like Allegiant).

Once you have these 3 business models in place, you can create a master database for routing with 3 columns: departure-arrival-connection.  There should be limits on connections, such as the next flight must depart within 4 hours to be considered a connecting flight.  Then it's just a matter of populating the database as flights are created.  For the hub/spoke model every permutation would be added within 4 hours and a discount rate could be added to each leg for connections for simplicity.  So if 2 legs are $100 each and a 20% discount (modifiable by the player) for connecting flights you'd have a $160 ticket instead of a $200 one.  For the focus city model a player would have to explicitly add LAX-CHI-NYC as a separate flight number and/or use ABCBA routing where it would be implicit where you can assign price values for those 2 leg flights.  For the point to point carrier, they'd simply have each route added.

Once you have the database setup, it's just a matter of pulling the flights where departure= and arrival= the specified values.  You are already using a haversine equation for distance, so you just need to modify it to get the angle of the two legs (between 0 and 180) versus the angle of a direct flight (180).  You can then use that value logarithmically to start penalizing connecting flights with extreme connections.  For example, flying NYC to LAX is a 180 degree flight.  Flying NYC to LAX via CHI has maybe a 150 degree angle.  Flying NYC to LAX via Moscow, Russia is going to have an extreme angle of maybe 20 degrees.  The traffic would be distributed across these flights, but the Moscow flight would be penalized exponentially compared to the Chicago flight.  Additionally, since these numbers would remain static, you could add them to the database so they don't have to be calculated each time.  Then it would just be a matter of calculating each flight's pax ratio/value against a sum() of the matching rows.

Quote from: LemonButt on April 24, 2015, 10:48:43 PM
I think there are some fundamental questions that need to be answered before you can even attempt to do the algorithm to distribute pax demand.  Let's take 3 airports in Los Angeles, Chicago, New York.  Let's assume an airline is flying NYC-LAX and charging $200.  Another airline is flying NYC-CHI and CHI-LAX and charging $150 for both flights.  If a pax goes NYC-CHI-LAX then how much is the ticket?  $200 or $300?  If you force an airline to sell it for $200, they are missing out on $100 in revenue that could have been earned by not allowing connecting flights.  If the airline is getting $200, they shouldn't be because the direct flight is $200--they should be charging something less than $200 for the inconvenience of connecting.

Let's say the default ticket price (to keep things very simple) is $100 to take off + $1 per mile   And distances as follows:

JFK-ORD = 600nm, $700
ORD-LAX = 1600nm, $1700
JFK-LAX = 2000nm, $2100

Then full JFK-ORD-LAX would be 2200 nm and $2300

I think what can come into play is pricing.  On dense, competitive routes, player can chose to lower than default pricing (as a formula derived from default), in order to drive more traffic into its hub, making the route more viable pricewise, even accounting for transfer inconvenience.

If the player sets price of both ORD-JFK and ORD-LAX at 80% of default, resulting in total price of $560 + $1360 = $1920, which is less than $2300 default price, and some price conscious customers could chose to go this route, assuming everybody at the direct flight is charging $2300 (or there is no capacity left on the direct flights).

But majority of people connecting would be doing so because there is no direct flight.  There are no direct flights that can connect a vast majority of the demand square in the world.  If one lives in, say Albany, NY, there may only be a 10-15 destinations you can fly to (I am guessing) and everywhere else, you have to connect.  If a person wants to go from Albany, NY to Split, Croatia, it will take 2 connections (not sure if it is viable to model more than 1 connection in the system).

Quote from: LemonButt on April 24, 2015, 10:48:43 PM
I don't think you can setup a pax demand algorithm without first setting up business plans, the simplest form being 3 options: Traditional hub/spoke with connecting pax (like Delta), Focus City airlines that will use multiple legs for a single flight number so they would have 3 routes with 3 prices being LAX-CHI, CHI-NYC, and LAX-CHI-NYC (like Southwest), and then strict point to point carriers where there are no connections and you pay per leg (like Allegiant).

If a user has to manually price all the combinations, than the system would be a complete fail, and there would not be any point to even build it, since the tedium user setting up pricing would take 95% of play time, and fun part of play would just not be there.  Even existing manual pricing for all AB flights to an absolute value is a fail, as is, since nobody has the time to do it.

The pricing would have to be automatic, based on formulas (if player choses to tinker with the formulas), or default as the system currently has.

As far as connection taking place (passengers transferring flights) it would be completely automatic, the player would not have to do anything.  So player would not have to set up his airline any differently than he currently does.  Passenger connections would offer new strategies (to take advantage of the feature), if player choses to pursue these strategies, but it should pretty much all be invisible to the player, especially a new player.

Quote from: LemonButt on April 24, 2015, 10:48:43 PM
Once you have these 3 business models in place, you can create a master database for routing with 3 columns: departure-arrival-connection.  There should be limits on connections, such as the next flight must depart within 4 hours to be considered a connecting flight.  Then it's just a matter of populating the database as flights are created.  For the hub/spoke model every permutation would be added within 4 hours and a discount rate could be added to each leg for connections for simplicity.  So if 2 legs are $100 each and a 20% discount (modifiable by the player) for connecting flights you'd have a $160 ticket instead of a $200 one.  For the focus city model a player would have to explicitly add LAX-CHI-NYC as a separate flight number and/or use ABCBA routing where it would be implicit where you can assign price values for those 2 leg flights.  For the point to point carrier, they'd simply have each route added.

I don't think the player strategy should drive the set up of database.  The database should be able to cover all situations regardless of player strategy.

All there is to figure out is how demand from airport A to B is allocated.  The system (I am assuming) will have a table of all AB airport pairs.

Now, suppose there is a demand of 100 pax from NYC squares to SPU (Split, Croatia).  The system will have a table that will have 3 choices:
JFK-SPU
EWR-SPU
LGA-SPU

Based on some magic (examining supply and its attractiveness), it allocates:

JFK-SPU: 70 pax
EWR-SPU: 25 pax
LGA-SPU: 5 pax
(subject to periodic re-allocations)

Let's go ahead with only the JFK-SPU, 70 pax demand, that is now pinned to these 2 airports. 

Nobody flies direct (and even if somebody did, alternatives would have to be considered).  To allocate this demand, the system will have to look up viable combinations, ranked from best to worst (based on number of variables).  Let's say, there are flights with connections exist (are being flown):
JFK-LHR-SPU (l10x JFK-LHR, 1x LHR-SPU, resulting in 10 combinations)
JFK-FRA-SPU (4x JFK-FRA, 2x FRA-SPU, resulting in 8 combinations)
JFK-CDG-SPU
JFK-MUC-SPU
JFK-VIE-SPU
and maybe 10s more.

The system can rank them, and store them in a table.  So for JFK-SPU pair there would be several flight combination candidates for this table.  As far as how many of possibly endless combinations the system stores, the system can limit them based on the pax demand between these airports.

So for example, for 70 pax, between JFK-SPU the system will store top 10 combinations.
For 25 pax demand between EWR-SPU, the system would store 4 combinations.
For 5 pax demand between LGA-SPU, the system would store 2 combination.

Or whatever works.  The system would have to re-evaluate the candidates periodically.

Then, back to JFK-SPU, it is just a matter of allocating the pax between the 10 connecting flight possibilities.  The same table that keeps the list of candidate connecting flights can also keep a tally of how successful they were on the pax allocation.  Let's say there is a top flight combo:
JFK-FRA, Airline XY, 8pm flight, flight #XY001 connecting to
FRA-SPU Airline XY, 12noon flight XY301

This flight was allocated and flown 30 pax.  The row with a combination XY001, XY301 (related to airport pair JFK-SPU) would store this figure of 30 pax. Or it can be used as a running average for past 7 days with a formula:
(old value * 6 + 30 pax) / 7

So we would have 10 records of these with various allocations.  In order to keep the flight combinations fresh, the system can keep top 70% of these 10 (=7) and replace the bottom 30% (=3) and do so periodically.

This can also be used to re-allocate the demand between JFK, EWR and LGA, based on successful completions.  From the above table, we would know that the sum of the 10 flights connecting JFK-SPU completed flights of 60 pax (of available 70).
Sum of EWR-SPU was 25 (of available 25)
Sum of LGA-SPU was 0 (of available 5)

Based on this, the system would reallocate NYC pax demand, shifting demand away from LGA-SPU, with the benefit going mostly to EWR-SPU.

Quote from: LemonButt on April 24, 2015, 10:48:43 PM
Once you have the database setup, it's just a matter of pulling the flights where departure= and arrival= the specified values.  You are already using a haversine equation for distance, so you just need to modify it to get the angle of the two legs (between 0 and 180) versus the angle of a direct flight (180).  You can then use that value logarithmically to start penalizing connecting flights with extreme connections.  For example, flying NYC to LAX is a 180 degree flight.  Flying NYC to LAX via CHI has maybe a 150 degree angle.  Flying NYC to LAX via Moscow, Russia is going to have an extreme angle of maybe 20 degrees.  The traffic would be distributed across these flights, but the Moscow flight would be penalized exponentially compared to the Chicago flight.  Additionally, since these numbers would remain static, you could add them to the database so they don't have to be calculated each time.  Then it would just be a matter of calculating each flight's pax ratio/value against a sum() of the matching rows.

I see what you are trying to say here, and it seems like a good way to select candidate flight combinations to be considered.  And my recent flight (using frequent flyer miles, on the cheap) would never make it into your candidate database, based on the angles.  Yet, United Airlines (Star Alliance) offered this to me as the cheapest flight (using fewest miles) during peak travel week:
LGA-TOR-SXM
SXM-PTY-JFK
:)

Quote from: sami on April 24, 2015, 10:38:41 PM
No, technically it's already all done pretty much (and in a way you described there too). The main issue I am having (and what I wrote there) was figuring out the destinations from each square. The best way to figure _where_ the people from each square wish to go, in order to make it realistic ..

I don't think there would be a problem with somewhat generic allocation, that can be further fine tuned by country to country relations.  Let's say USA-Canada would way above average relations, or Germany-Turkey (due to immigrant population).  So the country to country relation of USA-Canada might be 150%, modifying generic value of 100 for the Canadian to USA squares.  As far as where, within these 2 countries, some of the values collected for squares, as far as business, industrial, tourist destination would take care of that.

Then, the distance between the squares would be a factor.  Let's say there is a sweet spot of 700nm (or whatever) that is the most popular distance flown.  So the squares around that distance would get a bonus, and squares that are, say 70nm or 7000nm apart would be receive less than average demand.  The distance can be a function that is called, and it can be fine tuned.  I don't think the system has to perfectly match the real world.

Quote from: JumboShrimp on April 25, 2015, 03:11:55 AM
I don't think the player strategy should drive the set up of database.  The database should be able to cover all situations regardless of player strategy.

Then the answer to "how much does this flight cost" needs to be answered.  Also, I am assuming that the existing database is an SQL table with one column for departure airport and one for arrival airport.  In order to determine whether a connecting flight is even possible you'd have to overwhelm the database with SELECT queries, or at least index lookups which is going to be intensive even with the most efficient queries.  For JFK to LAX:

SELECT flight FROM database WHERE dep='JFK' and arr='LAX'

for each player (100+), go through a loop to determine if there is a connecting option:

+ SELECT flight FROM database WHERE dep='JFK' and arr!='LAX' (could return hundreds of rows)

+ SELECT flight FROM database WHERE dep!='JFK' and arr='LAX' (another few hundred rows)

Then you'd have to find figure out which connecting airports are possible, likely with an inner join or similar which is going to use temporary database tables and write to disk anyways.

So from a database engineering/infrastructure standpoint you can execute hundreds to hundreds of thousands/millions of queries to determine connecting pax which is going to remain relatively static and only change when routes are created or just crunch the numbers once and setup a database that will give you the answer with a single query. This is why setting a connecting flights database makes sense.

From an algorithmic standpoint, the function that spits out actual pax distribution is going to require inputs, which are going to rely heavily on price and time/distance or as I'm proposing, angle as it eliminates many other variables such as tech stops, aircraft speed, layover time, etc.  I'm not advocating micromanaging and setting every routes price, but if you set the price of JFK-ORD and ORD-LAX as being $150 each and you only get $200 in revenue because the game decided to connect a pax for $200 instead of 2 pax for $150 each it makes it extremely difficult to actually have a pricing strategy because you don't even know what your pricing.  Same goes with connecting pax pricing--an airline should be able to set the discount level as part of their pricing strategy where a connecting pax pays the price of both legs minus the % discount.  For hub/spoke it would be all connections, for point to point it would be no connections at all, and for focus cities it would be a hybrid where the only connections allowed are those a player explicitly allows (i.e. JFK-ORD-LAX would only be allowed if they explicitly say they will allow connections, which would be at the price of both legs minus the discount %).

Additionally, pax connecting wouldn't be solely because there is no direct flight.  I live between Atlanta and Charlotte.  It's usually far cheaper to drive to Charlotte and connect in Atlanta then fly directly to Atlanta from my home airport.  I just looked at Google Flights and flying from my home airport to Atlanta to Las Vegas is $810.  If I fly from Charlotte to Atlanta to Las Vegas it is $416--a direct flight from Charlotte to Las Vegas is $714.  Those are huge discounts.  In a typical game world the LAX-JFK route would be oversupplied, but that doesn't mean people aren't willing to connect in Chicago at a lower price.  Obviously leisure travelers are more price sensitive than business travelers, but even business travelers have their limits when it comes to price and opportunity cost of connecting--there should be some price point where pax overall will be more likely to connect in ORD than fly direct.

I don't know what the database stats or capacity looks like, but I own/operate a company that uses big data and with connecting flights we're talking about millions of potential combinations and if it isn't setup correctly in the beginning there could be an astronomical amount of resources needed to make it work.

Quote from: LemonButt on April 25, 2015, 05:18:03 PM
Then the answer to "how much does this flight cost" needs to be answered.  Also, I am assuming that the existing database is an SQL table with one column for departure airport and one for arrival airport.  In order to determine whether a connecting flight is even possible you'd have to overwhelm the database with SELECT queries, or at least index lookups which is going to be intensive even with the most efficient queries.  For JFK to LAX:

I will post my thoughts on database design and maybe some SQL later (I am very rusty, but used to be good at it).  But in general, the goal is to limit the result sets to something that's manageable.  Here is the rank of the size of the result set based on player conditions:

- allow connections between any players (the biggest set, probably too big to work with)
- limit connections to airline within alliance + manual player code shares (this should be the goal of the design, should be manageable)
- limit connections to airline within alliance (simplified and smaller than above)
- limit connections to within a single airline (smallest result sets)

Code sharing should be automatic.  If 2 airlines agree to a code share, the system will automatically make all of their flights code shared.  This takes the lease amount of player management.  This should automatically apply to airlines within the same alliance.  A player can selectively negotiate a code share with another player, not within the alliance.

Quote from: LemonButt on April 25, 2015, 05:18:03 PM
Then the answer to "how much does this flight cost" needs to be answered.  Also, I am assuming that the existing database is an SQL table with one column for departure airport and one for arrival airport.  In order to determine whether a connecting flight is even possible you'd have to overwhelm the database with SELECT queries, or at least index lookups which is going to be intensive even with the most efficient queries.  For JFK to LAX:

SELECT flight FROM database WHERE dep='JFK' and arr='LAX'

for each player (100+), go through a loop to determine if there is a connecting option:

+ SELECT flight FROM database WHERE dep='JFK' and arr!='LAX' (could return hundreds of rows)

+ SELECT flight FROM database WHERE dep!='JFK' and arr='LAX' (another few hundred rows)

Then you'd have to find figure out which connecting airports are possible, likely with an inner join or similar which is going to use temporary database tables and write to disk anyways.

As I said, my SQL is a bit rusty, but figuring out the connecting flights should be relatively easy, with something like:

SELECT some fields
FROM flights as flights1
FROM flights as flights2
WHERE
  flights1.origin = "JFK"
  flights1.destination = flights2.origin AND
  flights2.destination = "LAX" AND
  flights1.player.allianceID = flights2.player.allianceID   // putting restriction that only connection within alliance is possible
ORDER BY
  SomeFunctionToDetermineTotalTime (flights1, flights2)

The SomeFunctionToDetermineTotalTime would be able to determine things like flight arriving at 9am, connecting flight departing at 8am would actually add 7 days to the total time, and would of course go across week boundaries, to know that Monday is after Sunday.

This will get you a nicely sorted list of candidates.
 

Quote from: LemonButt on April 25, 2015, 05:18:03 PM
So from a database engineering/infrastructure standpoint you can execute hundreds to hundreds of thousands/millions of queries to determine connecting pax which is going to remain relatively static and only change when routes are created or just crunch the numbers once and setup a database that will give you the answer with a single query. This is why setting a connecting flights database makes sense.

Agreed, but, IMO, the records in the database do not have to span the universe (all possibilities), they can be transient, based on the feedback loop I described in the previous post, where the flights combinations that result in no pax being carried will get thrown out and replaced with new candidates from the SQL statement above.

Quote from: LemonButt on April 25, 2015, 05:18:03 PM
From an algorithmic standpoint, the function that spits out actual pax distribution is going to require inputs, which are going to rely heavily on price and time/distance or as I'm proposing, angle as it eliminates many other variables such as tech stops, aircraft speed, layover time, etc.  I'm not advocating micromanaging and setting every routes price, but if you set the price of JFK-ORD and ORD-LAX as being $150 each and you only get $200 in revenue because the game decided to connect a pax for $200 instead of 2 pax for $150 each it makes it extremely difficult to actually have a pricing strategy because you don't even know what your pricing.  Same goes with connecting pax pricing--an airline should be able to set the discount level as part of their pricing strategy where a connecting pax pays the price of both legs minus the % discount.  For hub/spoke it would be all connections, for point to point it would be no connections at all, and for focus cities it would be a hybrid where the only connections allowed are those a player explicitly allows (i.e. JFK-ORD-LAX would only be allowed if they explicitly say they will allow connections, which would be at the price of both legs minus the discount %).

Pricing can start by simply adding the sum of the prices of the legs, later can be improved by a player customizable formula for pricing, or even later, a pricing overlay can be built.

Quote from: LemonButt on April 25, 2015, 05:18:03 PM
Additionally, pax connecting wouldn't be solely because there is no direct flight.  I live between Atlanta and Charlotte.  It's usually far cheaper to drive to Charlotte and connect in Atlanta then fly directly to Atlanta from my home airport.  I just looked at Google Flights and flying from my home airport to Atlanta to Las Vegas is $810.  If I fly from Charlotte to Atlanta to Las Vegas it is $416--a direct flight from Charlotte to Las Vegas is $714.  Those are huge discounts.  In a typical game world the LAX-JFK route would be oversupplied, but that doesn't mean people aren't willing to connect in Chicago at a lower price.  Obviously leisure travelers are more price sensitive than business travelers, but even business travelers have their limits when it comes to price and opportunity cost of connecting--there should be some price point where pax overall will be more likely to connect in ORD than fly direct.

I think the actual pax allocation is going to be the most challenging part.  In the current system, you have a pair of airports that have demand, you have a set of flights that provide supply, and it takes one pass in how to allocate this demand to supply, and you are done with the airport pair.

In the scenario of connecting pax, the demand part remains simple, but the supply is complicated.  The supply of a flight JFK-ORD is used for direct flight, but it can also be used for 10s of other connecting flights.

I am a bit at a loss how this can be approached.  I think I had a post here a year or more ago, talking about various buckets, but it will take more than one pass, I believe to get the pax allocation done. 

Basically, the capacity of an aircraft is going to be used for number of routes (direct plus connecting flights) where the second route does not know how much of the capacity was allocated already.  I guess it could be done in one pass, until the capacity is filled up, but that may not be ideal from the supplier POV (player) who's aircraft may fill up with pax from discounted connected routes

Quote from: LemonButt on April 25, 2015, 05:18:03 PM
I don't know what the database stats or capacity looks like, but I own/operate a company that uses big data and with connecting flights we're talking about millions of potential combinations and if it isn't setup correctly in the beginning there could be an astronomical amount of resources needed to make it work.

As I said, only if the system keeps all of the combinations of routes would the system blow up with too much data.  I don't remember exactly, but there are about 2000 airports, so are already a number of airport combinations (2000 + 1999 + 1998 + ... 1) = 2000 * 2000 / 2 = 2 million, some of which may not be viable or have anybody flying to these airports (reducing the number greatly).

Each one of the airport pairs has a number of possible connections between them to an appropriate number, and not store all the combinations.  For example, if a JFK-ORD flight pretty much always gets filled to the capacity from the direct flight, there is no capacity left, this particular flight would get knocked out from pretty much all of the connecting flight possibilities, through the feedback loop I described in the previous post.

Quote from: JumboShrimp on April 28, 2015, 12:16:09 AM
I am a bit at a loss how this can be approached.

The main point of setting up the connecting flights database as I described solves this.  You calculate the angle of every connecting flight and divide by 180 degrees (the angle of a direct flight) and call it the angle quotient.  You could raise it to an exponent to get the exponential effect.  Then it's just a matter of a simple "SELECT SUM(quotient) FROM database WHERE..." and then you do a "SELECT quotient FROM database WHERE..." and allocate pax proportionally.

Example:

JFK to LAX is 100 pax demand

direct flight = (180 / 180)^2 = 1.00
connect in Chicago = (150 / 180)^2 = 0.69

The sum is 1.69.  Then you just send 1.00/1.69 = 59% or 59 pax direct and 41% or 41 pax through Chicago.  This of course assumes everything else is equal (the influence of price etc).

The caveat being the only way those flights through Chicago get into the database are if they are automatically added as connections for a hub/spoke or explicitly added by a focus city carrier.  As I stated before, you may not want connecting pax because it makes it near impossible to have a pricing strategy if you don't know what you're pricing.  The database/system I described would create the lowest load possible on the database as the values are static and don't need to be calculated on demand and the flights can be added in real time as they are added versus in processing batches which limit the IOPS and keeps resources free for other processes.  The long SQL statement you built involves creating temporary tables and sort indexes that have to be created on demand which is resource intensive and it goes back to the fact those values are static--they don't change.  A flight connecting in Chicago is always going to have (most of) the same connection values so crunching the numbers longhand every game day would be a waste of resources.  And the database wouldn't have to check for every single possible route (2000 factorial), but would just have to do a simple loop that would further save resources:

SELECT DISTINCT(departure) FROM database

foreach departure: SELECT DISTINCT(arrival) FROM database WHERE departure='departure'

This means the only flights getting processed are the flights that exist.  I assume the current system sets all traffic for routes to zero and then just calculates pax allocation in this manner.  And hard disk space is cheap--I seriously doubt storage is the constraint sami is facing, but compute resources.  In the end, the simplest system is going to be the least resource intensive and least prone to bugs.  When you break it down, connecting pax is actually very simple if you don't overthink it.

For pricing, I'd suggest a simple 2-tiered model - players should set a separate "point to point" price and a "connection" price for each flight.

So for fly XY001 from AAA-BBB, there would be a price (let's say $80) for passengers flying AAA-BBB, and a separate price (let's say $50) for passengers flying AAA-BBB-CCC or ZZZ-AAA-BBB. If the airline wants to incentivize connections (to increase loads on that particular flight or other flights in the airline's network), they could set a lower price for connecting passengers. If the airline would rather focus purely on point to point traffic, they could set the connecting price at exactly the same as point to point price.

To calculate the fare for AAA-BBB-CCC, all the system would need to do is add the connecting passenger price for AAA-BBB and BBB-CCC.





As far as passenger allocation, I think distance is fairly irrevant. What matters more is timing and price. If flying JFK-LAX via MIA takes less time than JFK-LAX via ORD (e.g. due to the way connections are timed or due to the speed of the airplane), then passengers would prefer the shorter connection. If flying JFK-LAX via MIA is half the price of JFK-LAX via ORD, passengers would also prefer that flight. Basing allocation on geographic information like distance or the angle doesn't reflect how passengers actually make decisions when choosing flights.



As far as creating a database of connecting possibilities, every time a new flight is scheduled, the system can go through and compile all the possible connections with that flight. A "possible connection" could be defined as any flight departing within 4 hours of arrival, or any flight which arrived 4 hours or less before departure.

The system could then store the top connection possibilities for each route pair. For example, lets say the fastest option on BOS-YVR is 8 hours. The system could store all possible connections that take 12 hours or less (1.5 * 8 hours). That arbitrary factor could increase/decrease depending on demand.

Quote from: BobTheCactus on April 28, 2015, 05:03:53 AM
For pricing, I'd suggest a simple 2-tiered model - players should set a separate "point to point" price and a "connection" price for each flight.

So for fly XY001 from AAA-BBB, there would be a price (let's say $80) for passengers flying AAA-BBB, and a separate price (let's say $50) for passengers flying AAA-BBB-CCC or ZZZ-AAA-BBB. If the airline wants to incentivize connections (to increase loads on that particular flight or other flights in the airline's network), they could set a lower price for connecting passengers. If the airline would rather focus purely on point to point traffic, they could set the connecting price at exactly the same as point to point price.

To calculate the fare for AAA-BBB-CCC, all the system would need to do is add the connecting passenger price for AAA-BBB and BBB-CCC.

Or even better, AAA-BBB can be defined as 100% of default for direct flights and, say 80% of default for connecting price (to get away from the insanity of absolute, non-inflation adjusted prices the current system has).

Quote from: BobTheCactus on April 28, 2015, 05:03:53 AM
As far as passenger allocation, I think distance is fairly irrevant. What matters more is timing and price. If flying JFK-LAX via MIA takes less time than JFK-LAX via ORD (e.g. due to the way connections are timed or due to the speed of the airplane), then passengers would prefer the shorter connection. If flying JFK-LAX via MIA is half the price of JFK-LAX via ORD, passengers would also prefer that flight. Basing allocation on geographic information like distance or the angle doesn't reflect how passengers actually make decisions when choosing flights.

Again, agreed.  The geographic information, angle of connecting flights, makes absolutely no difference to a possible passenger.  Let's say a passenger is going from Albany, NY to LAX, connecting in one of NYC airports creates highly unfavorable "angle", yet it is perfectly fine, maybe even preferable way for most pax to fly, since there are probably more frequent flights, less time waiting for connecting flight.

Quote from: BobTheCactus on April 28, 2015, 05:03:53 AM
As far as creating a database of connecting possibilities, every time a new flight is scheduled, the system can go through and compile all the possible connections with that flight. A "possible connection" could be defined as any flight departing within 4 hours of arrival, or any flight which arrived 4 hours or less before departure.

The system could then store the top connection possibilities for each route pair. For example, lets say the fastest option on BOS-YVR is 8 hours. The system could store all possible connections that take 12 hours or less (1.5 * 8 hours). That arbitrary factor could increase/decrease depending on demand.

I think, the time to wait for possible connection is also something that should not determine if a flight combination is a good candidate.  Far more relevant is the total time the flight it takes, from departure to arrival.  How much of that time is spent in the airplane vs. at the gate waiting for connecting flight is irrelevant.

JFK-LAX via MIA may get a very quick connecting flight, yet it can still takes more time than a far longer flight via DEN, LAS with time waiting for connection for more than 8 hours.

The SQL pseudo-code I posted will give you a neatly sorted list, mostly affected by total time, without taking into consideration the time it takes to wait for connecting flight.

Quote from: JumboShrimp on April 28, 2015, 06:25:09 AM
I think, the time to wait for possible connection is also something that should not determine if a flight combination is a good candidate.  Far more relevant is the total time the flight it takes, from departure to arrival.  How much of that time is spent in the airplane vs. at the gate waiting for connecting flight is irrelevant.

JFK-LAX via MIA may get a very quick connecting flight, yet it can still takes more time than a far longer flight via DEN, LAS with time waiting for connection for more than 8 hours.

The SQL pseudo-code I posted will give you a neatly sorted list, mostly affected by total time, without taking into consideration the time it takes to wait for connecting flight.

I guess my phrasing wasn't very good, but that's exactly what I meant. The system should figure out the fastest possible routing (from initial departure to final arrival) and store all other flight possibilities that come within a reasonable time difference.

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

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.

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?

Quote from: BobTheCactus on April 28, 2015, 02:16:26 PM
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.

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.

Quote from: Frederik on April 28, 2015, 03:54:22 PM
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.

Quote from: Frederik on April 28, 2015, 03:54:22 PM
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.

Quote from: Frederik on April 28, 2015, 03:54:22 PM
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.

Quote from: Frederik on April 28, 2015, 03:54:22 PM
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.

Quote from: Frederik on April 28, 2015, 03:54:22 PM
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.

Quote from: JumboShrimp on April 30, 2015, 01:54:11 AM
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.

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

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?

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!

Quote from: DannyWilliams on August 26, 2015, 05:21:51 PM
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 (http://airportthai.co.th/corporate/en/invester-relations)

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.

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.

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?

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.

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.

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

Quote from: Mr Yoda on March 16, 2016, 11:02:36 PM
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?

Quote from: JumboShrimp on March 16, 2016, 11:11:48 PM
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/

Quote from: Mr Yoda on March 17, 2016, 10:48:48 AM
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.

Quote from: sami on March 16, 2016, 11:54:27 AM
...the whole idea of the city based demand is that players could potentially make this small city airport grow too...

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.

Quote from: gazzz0x2z on March 17, 2016, 01:48:17 PM
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.

Most of the demand it has will be shifted to other airports, if no one has a base there.

Quote from: Mr Yoda on March 17, 2016, 10:48:48 AM
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.

There are 10s of flights to Canada from LGA.

Maybe the airports (in general) could have a flag "International" to specify if the airport has customs / immigration facilities.

Quote from: JumboShrimp on March 17, 2016, 02:16:55 PM
Most of the demand it has will be shifted to other airports, if no one has a base there.

Of course, but will it happen? Will people go there anyways? I was not asking about the game mechanics(though your answer seem to fit with what Sami said). I was wondering about the player's behaviour. Will they all jump on airports with the most slots? Will they spread out? Will some of them try alternate strategies? It will be interesting, at least.

In current GW4, the Heathrow-Charles-de-Gaulle line is overcrowded with A320. Because slots in Heathrow are so costly, it would make no sense outfrequencing them with regional jets. now, imagine it switches to city-based demand. A clever smaller player may try to land a few ejets between LCY & Beauvais. And steal some of the demand. Maybe.

Which leads to another question : how to make all this readable to the player? When I was attacked on the Fuerteventura-Las Palmas line, it was easy for me to see it. I adjusted my pricing and schedules accordingly. But when 2 other airports are involved, how can the player sense he is under attack?

It will be interesting to see.

And to all these comments that "this airport doesn't have this or that, and that's why a route cannot be flown" .. Airports will have NOTHING to do with the route demand. There are no differences on what's a "domestic" and what's "international" airport and so forth. It will depend on what the players wish to do.

Quote from: gazzz0x2z on March 17, 2016, 02:28:05 PM
Which leads to another question : how to make all this readable to the player? When I was attacked on the Fuerteventura-Las Palmas line, it was easy for me to see it. I adjusted my pricing and schedules accordingly. But when 2 other airports are involved, how can the player sense he is under attack?

You can see on your route the current demand and the maximum demand. If they differ much, or the gap between them grows, you know some other airport is stealing it. I could possibly add a small info section that would have links to the other airports' route planning pages on the competing sectors (but that might not always be accurate so might not too..).

Comments on how to display the demand figures in a nice way?

The data what needs to be displayed:

a) Potential full demand (3 classes)
b) Current demand (3 classes)
c) My supply (3 classes)
d) Other airline supply
( e) Temporary demand, from events )

The current chart format starts to be a bit unclear with all this data already. The charting application is also causing limits to how it can be displayed... 

But let me know if you have any thoughts.

Possibly dropping the "potential demand" bar alltogether and showing it as a sort of trendline in the background only (as that full demand potential is rarely reachable completely; it happens only when this airport catches ALL demand from the adjacent airports on this route-pair .. so basically almost never).

Quote from: sami on April 14, 2016, 11:18:17 AM(.../...)Possibly dropping the "potential demand" bar alltogether and showing it as a sort of trendline in the background only (as that full demand potential is rarely reachable completely; it happens only when this airport catches ALL demand from the adjacent airports on this route-pair .. so basically almost never).

I like the idea. But it won't be rare for airports alone in their catchment area, I guess. Bermuda comes to mind

Maybe leave out the separate column for potential demand and add a bar on top of the current demand in a contrasting (blue in this case?) colour...
Though this works for me too

Quote from: sami on April 14, 2016, 11:18:17 AM
Possibly dropping the "potential demand" bar alltogether and showing it as a sort of trendline in the background only (as that full demand potential is rarely reachable completely; it happens only when this airport catches ALL demand from the adjacent airports on this route-pair .. so basically almost never).

I would also like to see the supply from the other airports, which is now just too many bars for one screen.

I think it would be the best to split between 2 screens and a link to switch between them.

Default would be the pinned airport to airport info.  In most cases, that is identical to Total.  One indication - single bar - on this page, indicating percentage of total that this page represent would be all that is needed.

Quote from: JumboShrimp on April 15, 2016, 03:16:31 PM
Default would be the pinned airport to airport info.  In most cases, that is identical to Total.  One indication - single bar - on this page, indicating percentage of total that this page represent would be all that is needed.

Not sure if I quite undersood?  (the last part especially)

Quote from: sami on April 15, 2016, 08:40:15 PM
Not sure if I quite undersood?  (the last part especially)

View 1.

What I meant is that the default view should identical to what we see now in the current version, but in the new system, it would represent demand Airport to Airport demand, that is currently pinned to the airport pair.  The only difference would be additional single bar indicating what percentage of Total demand we are looking at.  The height of this bar should be equal to the height of the highest bar on the bar graph.  The full length would represent 100%, and within it, a shorter bar would indicate the actual percentage.  This would make it easy on the eyes.

So the only addition is a single bar (not 7 day bar) that would represent percentage of Total Demand (***).  IMO, 99% of the time, this is all the user needs to see.  The percentage tells you in very simplified way what the Total demand is, without creating too much clutter and confusion.


View 2.

If the player wants to see details on the Total, there would be an icon/link to click to switch to Total Demand and Total Supply View (including all combinations of airports. serving the catchment area.

If I am not being clear, let me know, I will try to draw it.

(***) Side note:

I am not quite sure how the data is modeled, and how easy it is to figure out the Total Demand.

The Total Demand should represent the Total Demand of catchment area to catchment area.  All the squares in one catchment area to all the squares in the other airport catchment area.  I am not sure how readily available that info is, and how quickly it can be retrieved.

The pinned demand of all the combinations of the airports may be slightly inaccurate.  For example, if we have:
- Airports A and B, 50 miles apart
- Airports X and Y, also 50 miles apart.
- Distance between AB and XY is 1000 miles.

Airports A and B have slightly different catchment areas.  If we just sum the pinned demand (for quick retrieval), we may be slightly overestimating the Total Demand,.  The catchment area of A+B is greater than A, X + Y is greater than X.  So the total demand of A+B to X+Y would be more than Total Demand of Catchment area A to B.

I think the Total view will require some work and fine tuning.  And rather than this being a show stopper, we could get off the ground and testing without the very detailed Total View.  All we would need to get started is some quick and dirty calculation to figure out the Percentage Bar in View 1.

Another note on the Total Demand View (and why it should be separate view):

It would be helpful to see all the combinations of airports it represents.  So for example, NYC to Dallas would represent:
JFK-DFW
JFK-DAL
LGA-DFW
LGA-DAL
EWR-DFW
EWR-DAL

switching to the Total view should list these combinations as links, so that the player could examine them in detail.

The problem with the chart system is that I cannot for example make a chart that has the total demand as one series and then Mo-Su weekdays in separate series in the same chart. That's why the total demand is currently shown for every weekday (which is unnecessary). At least with this multi-series stacked chart that is used ..

That's why probably the best would be to show the total potential demand as a horizontal line spanning through the whole chart instead of a bar, I think that's doable.  http://www.fusioncharts.com/charts/  &  http://www.fusioncharts.com/charts/msstackedcolumn2d_1/


The total potential demand is calculated in the demand calculation sequence. It simply sums up everything that the airport can catch and saves it to database. Showing the other nearby airport data could be possible too - system would just look what squares this airport catches, and then looks up any other airport catching any of these squares and shows their data.

Quote from: sami on April 16, 2016, 09:14:11 AM
The total potential demand is calculated in the demand calculation sequence. It simply sums up everything that the airport can catch and saves it to database.

That's excellent.  So getting a percentage pinned to the airport pair should be easy.  I think all the player needs to know is that there is more demand than he is looking at (the pinned airport to airport demand)

Quote from: sami on April 16, 2016, 09:14:11 AM
Showing the other nearby airport data could be possible too - system would just look what squares this airport catches, and then looks up any other airport catching any of these squares and shows their data.

How about this idea:

A new chart that would include the percentage of total demand (let's say JFK-DFW) that I was talking about originally, but in addition all the other airport pairs that are serving this Total Demand between JFK-DFW.  This could be a horizontal bar chart showing following info:

JFK-DFW 35%
LGA-DFW 25%
EWR-DFW 20%
JFK-DAL 10%
LGA-DAL 5%
EWR - DAL 5%
HPN - DFW 3%
ISP - DFW 2%
etc.

Each could potentially be a link to the supply demand chart between these airports.

I'd like to see what the total potential demand looks like as a trend line. If it works well then simplest would be to go with that.

Total Potential demand will not change very much.  Some 3% growth...

I think a more interesting would be a trend line of how the Total Potential demand is allocated between airport pairs.  That has a potential to have some swings as players add flights, bankruptcies etc.

In other words the Total Potential Demand between catchment areas surrounding, say JFK and DFW will not change much, but if another player adds flights between LGA and DFW, the demand that is pinned to JFK-DFW will go down, demand pinned to LGA-DFW will go up.

Seems to me we just need to see City Demand and Supply as that shows the need for more flights (seats).  A blue line (reach for the sky) above the supply columns seems fine as an indicator that there is more demand or not.

Special events could then be a red line above the blue line (red letter days with explanatory text of dates and level of demand as currently) but this short term demand can be met in two ways by airlines, a hike in prices or provision of extra seats.

I don't think the demand should be shown between airport pairs, but within city pairs...

Players can ask their marketing deparment to estimate the demand between "London and Paris" and that should be shown in the charts.

Then how that demands splits between different airports should be the players job to figure out.

If your same priced flight out of Stansted gets half LFs than your flight out of Heathrow, then players should figure that out, just as they figure out why 2am flights are empty while 9am are full...



Sadly, that won't happen if the system is not dinamic. RL demand don't switch from airports "gradually", they just go to "edreams.com" or "priceline.com" and book the best fare in relation to "price, airport, time, etc, etc".


Proposal: everyday the system has a city pair demand (not airport, but city). Then it searches between all possible direct flights + connections, and assign demand according to how the system scored the flights (more points to direct 9am flights out of close to the city airports, less pointg to connecting flights out of far airports; more points to cheap flights, less to expensive, etc)

HND-SFO getting no demand as all is unrealistic as hell given the airport pair is served by 777 double daily in real life.

Quote from: qunow on November 15, 2016, 08:25:49 AM
HND-SFO getting no demand as all is unrealistic as hell given the airport pair is served by 777 double daily in real life.

When the demand was designed in AWS (2006?), it used the available data of that time. HND has recently opened to international traffic.

Argentina also has an awful domestic demand, unlike RL. But that is probably due to the lack of official statistics at that time.

Quote from: ArcherII on November 15, 2016, 02:10:52 PM
When the demand was designed in AWS (2006?), it used the available data of that time. HND has recently opened to international traffic.

Argentina also has an awful domestic demand, unlike RL. But that is probably due to the lack of official statistics at that time.

Actually, for data in AWS, do they take the data at one point of time (2006) and then extrapolate the data to 1960-2030, or are they matching the demand over time? Like would you get reduced traffic to Iran after Iranian revolution, reduced traffic to Japan after bubble economy failed, or reduced global traffic after 9/11, reduce in traffic in former USSR countries after USSR collapse, or huge boom in traffic in recent years in China/Dubai or in 1980s in Mexico?

Quote from: qunow on November 16, 2016, 09:36:24 AM
Actually, for data in AWS, do they take the data at one point of time (2006) and then extrapolate the data to 1960-2030, or are they matching the demand over time? Like would you get reduced traffic to Iran after Iranian revolution, reduced traffic to Japan after bubble economy failed, or reduced global traffic after 9/11, reduce in traffic in former USSR countries after USSR collapse, or huge boom in traffic in recent years in China/Dubai or in 1980s in Mexico?

That change in demand is coded after the "event" system, which I believe overrides the demand system up to that point, and then goes back to normal...or not.

Quote from: ArcherII on November 16, 2016, 01:33:57 PM
That change in demand is coded after the "event" system, which I believe overrides the demand system up to that point, and then goes back to normal...or not.

I am asking/talking what's used as normal in the game. Like for a game start in 1960/1970/1980/1990/2000/etc., are their baseline start level from historical economic data at the time or?

Quote from: qunow on November 17, 2016, 01:29:02 PM
I am asking/talking what's used as normal in the game. Like for a game start in 1960/1970/1980/1990/2000/etc., are their baseline start level from historical economic data at the time or?

No, it's an interpolation from the baseline demand. 1960's would be a 20%-ish of 2006 demand I guess.

Quote from: ArcherII on November 17, 2016, 02:07:55 PM
No, it's an interpolation from the baseline demand. 1960's would be a 20%-ish of 2006 demand I guess.

That mean, before KIX open, Osaka won't have any international pax?

Quote from: qunow on November 17, 2016, 10:38:32 PM
That mean, before KIX open, Osaka won't have any international pax?

In that case, there's some kind of split between both airports. Before KIX opens, Itami is having domestic and international traffic.

I've been waiting for years to restart playing. Still nothing about connecting passengers?

Quote from: diskoerekto on January 29, 2019, 03:21:59 PM
I've been waiting for years to restart playing. Still nothing about connecting passengers?

not yet. i would really like to see a "AWS development-pipeline-thread", but Sami is a bit greedy when it comes to giving away infos ;)

i inquired and got the reply that IFE and such eyecandy is the "next thing", even before CBD. although i do not think that CBD and connecting passengers are in the same development... but then again, not sure ;)

CBD and connecting pax were always regarded as part of the same development, at least it was always discussed under the same (this) thread. Now that we have CBD for cargo, I'm assuming we might have CBD for pax any time soon, and after some eye candy connecting pax?

Every once in a while I come to forums to check if it's already implemented, and find my account deleted of inactivity. I create it again, check and go away for a few more months :)

Cargo is running under CBD.

Maybe connections could be implemented for cargo first ...

Or will be implemented along with pax CBD.

so, no timeline or anything and no reply from Sami  :(

it's me again (the previous poster is me) asking about CBD for pax and connecting flights (or 6th freedom)