Articles Development Featured

From Free Isochrones to Route Level Analysis

For CheckIn.com we intend to have an active exchange with our users, friends and the aviation network development industry. We have recently created a group on LinkedIn to promote such discussions. And this article is intended as a base of information of where Checkin.com comes from, our genome, instincts and lessons learned, giving you triggers to ask questions, discuss and voice your opinion in the group.

At the end we’ll even tell you how Checkin.com intends to add route level analysis to the existing algorithms. Being the result of discussion between the management of CheckIn.com with network planning friends in airlines, airports and consultants supporting our development.

And your feedback is expressly appreciated! Here on the post, in personal exchange or in our new group.

In the Beginning, there was a Light

Working with TIAS Consultancy on Route Feasibility Studies for more than 20 years now, in 2011, we directed our attention to the flawed and incomparable isochrones maps we had to use as a basis for our calculation of route potential.

The first challenge was to map isochrones. Needing one for the airport of Paderborn (PAD), we encountered discrepancy by the available tools calculating such drive times.

Then we found the “reach” to be not associated to any administrative boundaries allowing to associate a fixed population to the calculation. So we worked three weeks to associate drive times from the airports to municipalities in the catchment area using a mix between Google Maps to calculate the drive times and Microsoft’s offline-tool MapPoint shading the layers based on municipalities.

drivetime differences
This image shows the resulting layers with an overlay we used to compare using isochrones functions by MapPoint (violet) and Google (blue). Those comparisons we use to date (with meanwhile more than 20 different tools) to cross-check our results.

Being a rather logic process, we came to the idea to not do that individually, but collect the data, put it in a database and run it automatically. We quickly encountered the “cross border” challenge, deciding to do it right, we would have to cover Europe.

The beginning of a five year development…

Always Look at the Bright Side of Life

In order to understand our main constraint, we would like to first explain our main challenge, quoting our mantra (courtesy Richard Branson):

branson complexity
“Complexity is your enemy. Any fool can make something complicated. It is hard to make something simple.” [Richard Branson]

Our experience emphasizes the reality in this quote, that’s also well known as the “KISS principle: Keep It Simply Stupid“. When we started working on algorithms, we discussed the issue with a lot of experts, we had the support of some of the best brains for computer mathematics, we read a lot of publications. Our sincere thanks go i.e. to Benedict Mandel and MKmetrics publications on the issue. I recently met Benedict at a conference of the German airports association ADV and respect him greatly for his knowledge and the efforts they’ve put and keep putting into their work.

But countless discussions and meetings later with him and many other experts, we understood, why it took and takes those companies weeks to compile a “simple” isochrone analysis: “Complexity is (y)our enemy”.

All we received from those experts were extremely complicated formulae, very complex and difficult algorithms, all very time consuming not only in the conversion into computer algorithms, but also in the computing powers needed to run them. We quickly and more than once came to the point where we were told we would need Amazon or IBM servers to run them. We almost dropped the idea at first. And again. But then every time I recalled the aphorism about experts I keep quoting for decades now. Again. And again…

always listen to the experts
“Always listen to the experts! They tell you it is impossible and why you can not do it. When you know that: Go Ahead” [Lazarus Long]

So we understood that this was a dead end street, we couldn’t make the things more complicated, we needed to simplify. A lot. So then we started our famous maths challenge that brought us together with a mathemagician, a friend of a friend (and meanwhile a friend) working at IBM. He’s refreshing! Hearing about our problems he pointed us at the concept of what we now call “the scientific approach”. Scientists make things complicated, to make themselves feel important. They also try to cover, solve or hide away all those little aspects, that are in the end nothing but “statistical noise”. Okay, we didn’t end up with the first, simply algorithm either. Which worked exceptionally well and still is the initial algorithm we work with. We then add “fine tuning”, common rules to adjust the results. But we focus on the cases were we see the offset making those rules reasonable. Or where we need to cover for incorrect data, as we had it with some ferries. But all in all? We keep it simple and stupid. And such we can run the calculations in real time and we were able to overcome all those impossibilities
math challenge

The Road Travelled So Far

Since March 2016, we provide instant catchment area analyses at a fraction of the price the experts so far called for, boiling down the time you need to wait for it from weeks to seconds (minutes for the map sometimes) in the process. At a quality that so far proved that all those other complexities implied boil down to statistical noise.

Together with consultants, airlines and airports we compared their findings with ours. What takes a week or more for a single airport to analyze or just update the data, we can provide instantly “at your finger tips”. Processing not just the data for one airport, but currently 576 in Europe. And we are usually more accurate and realistic than the results they got so far.

samples

As our friends at ANNA.aero phrased it when we asked about the offsets between our analyses and the data provided in the Route Shop… That information comes from the airports and “may not be scientific”.

So we promised them to change that:

Free Isochrone Maps … Are You NUTS?

In September 2016 we now released version 2 of the dashboard, enabling the two airports display that is a vital step towards the route-level analysis we identified as mission-critical for our business model.

At the same time, having our promise to ANNA.aero in mind, we discussed the option to allow only ANNA.aero customers access to the isochrones maps. But then we questioned ourselves:

Since we came up with the tool and our analyses, we explained that we believe the classic isochrones to be useless. Except for Malta or other remote islands maybe where the population in the catchment area only has a single airport in reach. In all other cases, there’s competition that must be taken into account.

The isochrones are the first step in a complex analysis. To create them is difficult enough, but you can’t do sound calculations if you just have the isochrone map and the population of your catchment area. So we don’t give away anything but what you so far paid for – which in our own experience doing our own route studies was of no real use. A barrel burst. Nice to see and it looks good, but of no real commercial impact… So we decided to give our users these isochrones map and the access to the basic data for free. To all of them.

Screenshot CWL competitive

Oh. Did I mention? I doubt you find any other source of passenger statistics and seasonality level data more detailed than ours! Mostly we use Wikipedia (and yes, that’s a helluva work every year. Whereas we are still wondering about the number of discrepancies we find for a simple statistical value like a departing or arriving passenger when we compare with other sources! Airports, national airport associations, ACI, Eurostats, commercial or public sources like Wikipedia – we sometimes found as many as six or seven different numbers! And not just minor differences. But that’s another story and shall be told another time.

So we even solved that, usually taking the airport’s own figures. And we offer you more complex analysis. And the sound data to work from. And yes, we intend to add more.

Okay. That concludes the Story So Far, let’s take a look into the Crystal Ball ツ

Where Do You Want to Go Today?

detour

Now let’s look at Route Level Analysis. So now we added two airport display to the dashboard we can add, test and apply the route level algorithms we defined. Which we hope – if there are no unexpected setbacks – will happen later this fall.

So the question was asked, what we plan to do. And as we believe to be the only ones being anywhere close to be able to provide the quality and speed of data analysis needed, we think it’s rather logic what we plan to do.

So here we are. We have build a database for aviation traffic statistics. Currently we focused on national statistics and Eurostats, we intend to add other sources, but so far struggle to make a business case for one of the commercial data providers. We think we will come together, but not for the initial version.

In a conference call with consultants, airlines and airports being kindly on the call, we agreed that there is a lot of “individual” data, which includes ticket price levels, punctuality, ethnic population. Very often, that data is not available on a common pan-European level. Very, very often, not even on a regional level, like for the one airport and the neighboring airports. So we cannot apply a value to only a single airport in the equation. Sorry, that doesn’t make sense.

And we agreed that the CheckIn.com business model is to make standardized statistics and the resulting analyses instantly available. CheckIn.com also focuses on the catchment area. MIDT-like data on historic statistics about passengers flown, sometimes about fare levels achieved, load factors etc, are available from specialized companies. Their “shortfall” was that they took very generic assumptions how they apply to the catchment area.

garbageingarbageout

Or as we mentioned in the post about the Crystal Ball of Aviation Network Planning, we are not there to predict the future. But we intend to polish the crystal ball to give better insights! Sound, comparable statistical facts, instantly available, affordable to promote the use. What MIDT was 20 years ago for flown data, we now want to make “common use” on the where the “passenger” comes from.

So we intend to simply close that gap. And such we don’t compete. We complement their efforts! And it’s not “that usual crap”. This is new. And valuable.

But before we can add more fine-tuning to the catchment area, we have to add the ability to apply basic route level analysis, identifying the potential of passengers to accept a certain route. It’s a simple fact. We can currently sell 576 airports. How often? But if we add the route to the equation, we can sell 576 by 576 airport routes. And once we proof we can do this, we can see a cooperation at eye-level with one or more of the companies to improve their and our data.

That prerequisite for next level development cleared, the main question was, what we can do to make sound route level analysis available. It took us hours of discussion. Hours. Then we identified a common process applied to identify passenger potential.

If there is no historic data, the look goes to the neighboring airports. Usually in a step by step process. Then the airline takes that data and applies it “roughly” to the new route and “guesses” a potential. Oh…kay.

aviation planning crystal ball

So we came up with the following proposal.

  1. We check the route requested for historic data on our database.
  2. If no data, we check for historic data between the origin airport and the airports neighboring the destination airport, as well as the data between the destination airport and the airports neighboring the origin airport.
  3. If still no data, we check the neighboring airports on both sides, but that must be tested, we are afraid that may result in some “fuzzy logic” that may return unexpected results…
  4. Then we calculate on our historic data the catchment area of both airports and how much impact the flights had, what percentage of people in the catchment area flew. That will differ by size of airport and we came up with quite complex computations.
  5. Finally we apply the resulting impact to the requested route.

That approach sure has some theoretical shortcomings as we won’t consider the fare levels, frequency, if the flights were operated by network carriers (feeder flights?) or low cost carriers. But then we learned that today, that part of the analysis also comes later. And that those facts usually have surprisingly little impact to the forecasting done today by airlines (somewhere +/- 5%).

Being given results based on the above algorithm is considered vital results by our expert advisers. Better even. Given the implementation of those computations, it enables us a main new service our advisors early on asked us for:

The ability to compute a “top 10 destinations list” to look in more detail at a given airport…

branson reputation

We don’t post this to promote our future. We want involve our followers, personal and business friends working in airlines, airports or consultancies to give us early feedback in case we have overseen, oversimplified or if the approach has any flaws we need to understand.

Such we encourage you to join our group her on LinkedIn to discuss these and other ideas with us. And to follow our company page here on LinkedIn as well. If you did not yet, register now for free to access the CheckIn.com dashboard and data. And to buy the analyses where needed to apply them on your own route analyses.

And no. We don’t fear competitors. We know how much time we invested to make all that information available on a European level (+5 years). And even knowing about our detours, the fixing of data discrepancies was, is and will be the obstacle.

Okay. So what do you think. Please don’t swallow it. Please share your thoughts!

And if you don’t like something, tell us
but if you like it, go tell your friends!

0

Leave a Reply

Your email address will not be published. Required fields are marked *