City based demand

[ezzeqiel]

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 !

[Sami]

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

[Absolutis]

Actually, there is two mods for OpenTTD that do that:
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 (YACD, divides cargo between all destinations)

[ezzeqiel]

(unless it has recently changed, doubt it?)

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

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

Actually, there is two mods for OpenTTD that do that:
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 (YACD, divides cargo between all destinations)

Exactly, those are the links I posted...

[powi]

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

[exchlbg]

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.

[Jona L.]

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


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 "

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]

[exchlbg]

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.

[Sami]

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.

[Sami]

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)

[Zombie Slayer]

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

[Sami]

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

[JumboShrimp]

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.

[Talentz]

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

[Sanabas]

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.

[Sami]

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)

[Sami]

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.

[samomuransky]

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

[Sami]

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.

[LemonButt]

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.