This is the perfect route planning software if you are the only aircraft in the sky, and fuel is your only cost. The commercial solutions exist because they consider not only the winds and fuel costs in their optimization, but also known previously cleared ATC routings, altitude restrictions whether they are charted or only documented by letter-of-agreement, expected delays due to historical congestion, pilot and cabin crew pay, crew duty time limits (your more fuel efficient route may take longer and require an entire second crew), contracted lease, finance, insurance, and maintenance rates as these are also frequently paid by the the hour, and airport arrival curfew times. And probably a few more things too.
Also, you say nothing about incorporating ETOPS routing requirements into your application, and looking at the opentop source neither does it, therefore I assume this must mean this is the first time you have seen that acronym and therefore do not understand its criticality in determining aircraft routing. Might want to have your AI agent read this Wikipedia article, because your application generates many routes that are not legal to fly.
I find your comment unnecessarily harsh. I don't see a claim that the open source solution is better or a good solution for actual production use by airlines - it reads to me as a "here's how to use what's openly available" blog post.
(Also, Scikit-decide seems to be on the Github account of Airbus, so I assume they have at least some basic knowledge of how aviation works.)
I find it harsh but fair. The second paragraph reads:
"Firms like Jeppesen have offerings in this space, but Scikit-decide, together with a narrow- and wide-body fuel consumption model built by a professor at the Delft University of Technology and wind data from NOAA, offer an open source solution."
So this is being positioned as an open source alternative to commercial offerings, which clearly it is not. If instead he made the limitations clear from the outset, that this is just a demonstration of what he/the tools are capable of and that this is not in any way intended for real-world use, it would put the rest of the article into better context.
I also don't see how Scikit-decide being developed by Airbus gives OP any domain authority. I use open source tools from all sorts of commercial ventures, and know nothing about how they themselves use them, or what for.
I don't like to be that guy, but this doesn't read as a particularly well thought-through experiment... I don't think it's as effective an advertisement for OP's consulting as they may have thought, because it suggests an inability to think within relevant context.
The truth is that given the legal and ethical constraints available, routing is already relatively well-optimized in many places. (There are some places, like China's hybrid civilian-military airspace, where those constraints are extremely nasty and basically make the problem impossible to solve better than it is.)
Aviation tries to solve the fuel consumption problem by designing planes to use less fuel, rather than by flying more optimal routes. There is a massive effort in aviation pretty much all the time to try to use less fuel, for every reason from cost to environmental impact to the relative accessibility of jet fuel now and into the future. It's the reason engines have gotten physically larger; it's a big part of why we don't use supersonic jets anymore as well.
There's no hubris in identifying a problem, and fairly little in thinking you might be able to help solve it, but there's a good bit in imagining nobody else has done it.
I don't understand the negativity here. The author is not advertising themselves as a consultant for the aviation industry specifically - instead this blog reads as a neat demo on how to apply open source data-science tools to a concrete, by very complex problem. I found it both interesting and entertaining to read.
TFA is the aerospace equivalent of rolling your own crypto. Outsiders often don’t know what they don’t know, resulting in fatally-naive “solutions” to the problems.
I have a close family member who flys airliners. He routinely laments having to burn up thousands of pounds of fuel on the ramp to adjust changes to the landing weight projections by dispatch and from over fueling. The amount of waste in a single error (and they are not that infrequent) is enough to heat my house for a year… and I live within 200 miles of the arctic circle. I mean, burning 1000 gallons of fancy diesel once in a while is a rounding error for jetliner operations, but still, it’s absurd that that is the best solution.
Aviation is notoriously resistant to change. For both good and bad reasons. Look at how long it's taken to get leaded fuel on the way out for light aircraft operations.
It seems like there should be a solution to this though, either battery-electric or fuel-cell auxiliary thrust for ground operations and taxiing, or utilising tractors more to do the full aircraft ground movement, not just pushing back from the gate.
Unfortunately it's impossible to suggest such changes without getting a horde of aviation nerds thinking of reasons to tell you why something isn't possible, instead of imagining how it _could_ be possible.
So it's exciting to see companies like Heart Aerospace innovating in this area.
It's unfortunate the fuel can't be siphoned back out and used. I wonder why that is; I suspect if it were possible, it'd be happening.
Also worth noting, tangentially, though - the reason planes are fueled as they are is because if you run out of fuel in a car, you're just stranded. In an airplane, you're quite possibly dead. If you only load the plane with exactly as much fuel as it needs to get to its destination, you run the risk of not having enough to safely divert.
On the other hand, planes also have maximum landing weights, so a plane which must divert or land in an emergency often has to dump fuel for a while first. That's more unusual and not something you can easily plan for, but it's part of the problem too.
I can't see the fuel being able to be reused for aviation once it's been outside the stewardship of the fuel company, but how about draining it out and selling it or even giving it away - if for nothing else for CO2 reasons
I just had this happen on a flight yesterday. Exactly as you describe, extra fuel put the plane over weight, so we sat there letting it burn for an hour.
Nice idea, but this is not how flight planning works. The optimization algorithms that airlines use consider a broader range of variables than just fuel, since you also have cost per hour that the engine is running, cost per hour for the crew, and overflight fees for different airspaces.
And the output still has to be a valid flight plan route. You can't just file a flight plan for "I want this zig zag line at this altitude".
Commercial flight planning software does this optimization as well, but it only selects routes that are valid. For example you have to be at a certain altitude to go one way on a route and another altitude to go the other way. ATC can't do their job if you have planes pointing at each other in opposite directions doing 1000+ km/h.
If you look at the "optimal" path here looks completely unrealistic/pathological. How is it optimal to zig zag like this? The grid is clearly too coarse and that's possibly not the only issue: https://tech.marksblogg.com/theme/images/flight_planning/msr...
I think it’s not a great illustration; the map looks like mercator so the shortest path would be curved and closer to the green path anyway. the red line is not “as the crow flies”. It would be more fair to show deviation from the actual (great circle) shortest path. Also agree the grid seems coarse.
Are we looking at the same map? On the one I see, showing western and central Europe, the difference between a great circle and a loxodrome (straight line on a Mercator map) for an intra-European route would be barely visible. And the map is clearly not Mercator — France looks visibly "smashed". Looks like a simple x=longitude, y=latitude projection.
and this would work in real life too, if only we could all climb and descend entirely at pilot's discretion, direct enter enter and never have to worry about all of the other planes doing the exact same thing.
And never have to intercept certain waypoints when entering different classes of controlled airspace on the correct general heading to line up for a documented runway approach.
There's a bunch of other interesting flight path optimization work going on at https://contrails.org/.
It turns out contrails contribute to 2% of global warming power and is relatively easily avoided. The cost might be a bit more fuel consumption though.
This is highly impractical and it is evident that the author has no idea how IFR navigation and oceanic routes work. When flying on oceanic routes and even on land, you have to intercept certain waypoints and vectored into/around airspaces.
I hate to be discouraging, but maybe the author should make an attempt to understand navigation before cooking up something like this.
I have this for sailboat routing: https://leebow.dev/research/how-the-race-to-hawaii-is-won. It solves the optimal route for every Transpac and Pac Cup start since 2011, using each race's own verified wind data (ERA5). Then it compares that route to what the fleet actually sailed. It shows the median hours the fleet gave up, how often the optimal route even falls inside the fleet's own spread (16% of the time), and how much that pattern holds from year to year. A second figure runs the same solve across 108 routes over 70 years, so you can see how much the optimal route itself varies, not just one good example.
One difference from the OpenAP/scikit-decide setup: my router doesn't search a fixed grid with A*. It runs a continuous isochrone search that expands a fan of headings against the live forecast each step. That's closer to how routing is actually done for this problem, and it's what both the live product and the backtest above use.
Grepped TFA for "IFR", "NOTAM", "oceanic", "RVSM", "ETOPS", and "TFR". No results -> no point reading any further -- might as well ask my cat to opine on neurosurgery.
It will never work because you have too many human processes in the loop. This HN share by the author is selling the idea of consulting to obtain nominal efficiency on a well established process to human organizations who are structurally opposed to it, subject to human regulators who are structurally opposed to it, in an industry that is famous for aversion to change. Nice try drumming up clients, but realistically you're not going to move the mountain a millimeter on this one. Quicker to wait for AI airports, AI ATC and AI airlines than selling to humans at this point. 20th century humanity just about spitballed together a working system, but making it efficient is not going to happen on our watch. We would do well to admit it.
It's a by-word for expert systems with management conception as well as multi-domain comprehension these days. Reasoning through failures in one sensor domain with limited data from other domains within a fixed period following strict risk protocols at 3:01AM is the sort of thing AI would excel at versus humans.
Which are these "human processes in the loop"? We are talking about changing flight schedules, and I'm pretty sure that existing flight schedules are not developed by teams of people with pen and paper, but rather by powerful ILP solvers, because of (a) the immense value in optimising every aspect of them and (b) the myriad regulatory constraints that need to be met for, e.g., flight crew scheduling.
Aviation is one of the few industries where the largest regular (non-capital) expense is something other than labour, namely fuel. Anything that reduces fuel costs even a little is of obvious interest to every airline.
There are still the issues of coordinating flight paths to avoid collisions, and regulation (including international regulation). The former seems like a technical problem amenable to increasingly accurate approximations over time. I don't know about the latter, but I doubt it's as insurmountable as you imply. International air travel has been around longer than ILP solvers, meaning that at some point flight schedules were created by people. Now they're created by ILP solvers, and the regulatory environment successfully adapted to that change.
This is the perfect route planning software if you are the only aircraft in the sky, and fuel is your only cost. The commercial solutions exist because they consider not only the winds and fuel costs in their optimization, but also known previously cleared ATC routings, altitude restrictions whether they are charted or only documented by letter-of-agreement, expected delays due to historical congestion, pilot and cabin crew pay, crew duty time limits (your more fuel efficient route may take longer and require an entire second crew), contracted lease, finance, insurance, and maintenance rates as these are also frequently paid by the the hour, and airport arrival curfew times. And probably a few more things too.
Also, you say nothing about incorporating ETOPS routing requirements into your application, and looking at the opentop source neither does it, therefore I assume this must mean this is the first time you have seen that acronym and therefore do not understand its criticality in determining aircraft routing. Might want to have your AI agent read this Wikipedia article, because your application generates many routes that are not legal to fly.
https://en.wikipedia.org/wiki/ETOPS
Should I even ask if this application routes around areas that have been declared active war zones by NOTAM?
I find your comment unnecessarily harsh. I don't see a claim that the open source solution is better or a good solution for actual production use by airlines - it reads to me as a "here's how to use what's openly available" blog post.
(Also, Scikit-decide seems to be on the Github account of Airbus, so I assume they have at least some basic knowledge of how aviation works.)
I find it harsh but fair. The second paragraph reads:
"Firms like Jeppesen have offerings in this space, but Scikit-decide, together with a narrow- and wide-body fuel consumption model built by a professor at the Delft University of Technology and wind data from NOAA, offer an open source solution."
So this is being positioned as an open source alternative to commercial offerings, which clearly it is not. If instead he made the limitations clear from the outset, that this is just a demonstration of what he/the tools are capable of and that this is not in any way intended for real-world use, it would put the rest of the article into better context.
I also don't see how Scikit-decide being developed by Airbus gives OP any domain authority. I use open source tools from all sorts of commercial ventures, and know nothing about how they themselves use them, or what for.
I don't like to be that guy, but this doesn't read as a particularly well thought-through experiment... I don't think it's as effective an advertisement for OP's consulting as they may have thought, because it suggests an inability to think within relevant context.
The truth is that given the legal and ethical constraints available, routing is already relatively well-optimized in many places. (There are some places, like China's hybrid civilian-military airspace, where those constraints are extremely nasty and basically make the problem impossible to solve better than it is.)
Aviation tries to solve the fuel consumption problem by designing planes to use less fuel, rather than by flying more optimal routes. There is a massive effort in aviation pretty much all the time to try to use less fuel, for every reason from cost to environmental impact to the relative accessibility of jet fuel now and into the future. It's the reason engines have gotten physically larger; it's a big part of why we don't use supersonic jets anymore as well.
The efforts have been pretty sucessful: https://theicct.org/maximizing-aircraft-fuel-efficiency-desi...
There's no hubris in identifying a problem, and fairly little in thinking you might be able to help solve it, but there's a good bit in imagining nobody else has done it.
I don't understand the negativity here. The author is not advertising themselves as a consultant for the aviation industry specifically - instead this blog reads as a neat demo on how to apply open source data-science tools to a concrete, by very complex problem. I found it both interesting and entertaining to read.
TFA is the aerospace equivalent of rolling your own crypto. Outsiders often don’t know what they don’t know, resulting in fatally-naive “solutions” to the problems.
username checks out!
I have a close family member who flys airliners. He routinely laments having to burn up thousands of pounds of fuel on the ramp to adjust changes to the landing weight projections by dispatch and from over fueling. The amount of waste in a single error (and they are not that infrequent) is enough to heat my house for a year… and I live within 200 miles of the arctic circle. I mean, burning 1000 gallons of fancy diesel once in a while is a rounding error for jetliner operations, but still, it’s absurd that that is the best solution.
Aviation is notoriously resistant to change. For both good and bad reasons. Look at how long it's taken to get leaded fuel on the way out for light aircraft operations.
It seems like there should be a solution to this though, either battery-electric or fuel-cell auxiliary thrust for ground operations and taxiing, or utilising tractors more to do the full aircraft ground movement, not just pushing back from the gate. Unfortunately it's impossible to suggest such changes without getting a horde of aviation nerds thinking of reasons to tell you why something isn't possible, instead of imagining how it _could_ be possible.
So it's exciting to see companies like Heart Aerospace innovating in this area.
Back in the day I was questioning operational tankering in my organization,but to no avail.
Not in aviation anymore, but luckily that practice seems to be forgotten now?
It's unfortunate the fuel can't be siphoned back out and used. I wonder why that is; I suspect if it were possible, it'd be happening.
Also worth noting, tangentially, though - the reason planes are fueled as they are is because if you run out of fuel in a car, you're just stranded. In an airplane, you're quite possibly dead. If you only load the plane with exactly as much fuel as it needs to get to its destination, you run the risk of not having enough to safely divert.
On the other hand, planes also have maximum landing weights, so a plane which must divert or land in an emergency often has to dump fuel for a while first. That's more unusual and not something you can easily plan for, but it's part of the problem too.
I can't see the fuel being able to be reused for aviation once it's been outside the stewardship of the fuel company, but how about draining it out and selling it or even giving it away - if for nothing else for CO2 reasons
And meanwhile here I am feeling guilty when I eat a cheeseburger.
I just had this happen on a flight yesterday. Exactly as you describe, extra fuel put the plane over weight, so we sat there letting it burn for an hour.
Nice idea, but this is not how flight planning works. The optimization algorithms that airlines use consider a broader range of variables than just fuel, since you also have cost per hour that the engine is running, cost per hour for the crew, and overflight fees for different airspaces.
And the output still has to be a valid flight plan route. You can't just file a flight plan for "I want this zig zag line at this altitude".
Commercial flight planning software does this optimization as well, but it only selects routes that are valid. For example you have to be at a certain altitude to go one way on a route and another altitude to go the other way. ATC can't do their job if you have planes pointing at each other in opposite directions doing 1000+ km/h.
If you look at the "optimal" path here looks completely unrealistic/pathological. How is it optimal to zig zag like this? The grid is clearly too coarse and that's possibly not the only issue: https://tech.marksblogg.com/theme/images/flight_planning/msr...
I think it’s not a great illustration; the map looks like mercator so the shortest path would be curved and closer to the green path anyway. the red line is not “as the crow flies”. It would be more fair to show deviation from the actual (great circle) shortest path. Also agree the grid seems coarse.
Are we looking at the same map? On the one I see, showing western and central Europe, the difference between a great circle and a loxodrome (straight line on a Mercator map) for an intra-European route would be barely visible. And the map is clearly not Mercator — France looks visibly "smashed". Looks like a simple x=longitude, y=latitude projection.
I am not sure how this approach would integrate with the common use of navigating between known/mapped IFR navigation waypoints:
https://www.google.com/search?client=firefox-b-d&q=IFR+navig...
https://skybrary.aero/articles/waypoint
https://www.flyingmag.com/how-ifr-fixes-get-their-names/
and this would work in real life too, if only we could all climb and descend entirely at pilot's discretion, direct enter enter and never have to worry about all of the other planes doing the exact same thing.
And never have to intercept certain waypoints when entering different classes of controlled airspace on the correct general heading to line up for a documented runway approach.
There's a bunch of other interesting flight path optimization work going on at https://contrails.org/.
It turns out contrails contribute to 2% of global warming power and is relatively easily avoided. The cost might be a bit more fuel consumption though.
Fun fact, contrails contribute to global warming, but only at night.
During the day they have a cooling effect by reflecting/blocking some light.
The optimal is not to eliminate them entirely, but to create them only early in the day so that they dissipate by sunset.
https://www.transportenvironment.org/te-asia-pacific/topics/... acknowledges the difference between day and night but claims that the sum of the effects still results in net warming during the day.
The fuel consumption feels like the bigger problem since contrails last for hours vs co2 that lasts damn near forever.
They are roughly equal problems at the moment.
> Recent estimates show that contrails cause about the same amount of warming each year as all the CO₂ emitted by all flights from 1940 to 2018.
If we're measuring in terms of difficulty, CO2 is a much bigger problem than contrails.
Yes, contrails appears to be mostly solvable at a small cost in time and fuel and people have started to take action on that.
For most flights today though, if you only count the CO2 produced you're understanding the climate damage by about half.
It's one way to look at it I guess. CO2 is still the half of the damage that's way harder to fix.
Stop pretending corporate travel is essential.
This is highly impractical and it is evident that the author has no idea how IFR navigation and oceanic routes work. When flying on oceanic routes and even on land, you have to intercept certain waypoints and vectored into/around airspaces.
I hate to be discouraging, but maybe the author should make an attempt to understand navigation before cooking up something like this.
A plot of a larger sample of post-hoc known wind and other constraints over a regular service would help enormously to sell the idea.
One point at 45min faster and 25% less fuel is of course huge, but how does it map out over a year of routing?
I have this for sailboat routing: https://leebow.dev/research/how-the-race-to-hawaii-is-won. It solves the optimal route for every Transpac and Pac Cup start since 2011, using each race's own verified wind data (ERA5). Then it compares that route to what the fleet actually sailed. It shows the median hours the fleet gave up, how often the optimal route even falls inside the fleet's own spread (16% of the time), and how much that pattern holds from year to year. A second figure runs the same solve across 108 routes over 70 years, so you can see how much the optimal route itself varies, not just one good example.
One difference from the OpenAP/scikit-decide setup: my router doesn't search a fixed grid with A*. It runs a continuous isochrone search that expands a fan of headings against the live forecast each step. That's closer to how routing is actually done for this problem, and it's what both the live product and the backtest above use.
Good exercise but as useful as Google maps would implement "ignore traffic rules" option to save fuel.
Grepped TFA for "IFR", "NOTAM", "oceanic", "RVSM", "ETOPS", and "TFR". No results -> no point reading any further -- might as well ask my cat to opine on neurosurgery.
- a pilot
Anyone down to vibe code a competitor to ForeFlight?
This is pretty cool! https://github.com/airbus/scikit-decide
It's nice to see the scikit brand live on.
It will never work because you have too many human processes in the loop. This HN share by the author is selling the idea of consulting to obtain nominal efficiency on a well established process to human organizations who are structurally opposed to it, subject to human regulators who are structurally opposed to it, in an industry that is famous for aversion to change. Nice try drumming up clients, but realistically you're not going to move the mountain a millimeter on this one. Quicker to wait for AI airports, AI ATC and AI airlines than selling to humans at this point. 20th century humanity just about spitballed together a working system, but making it efficient is not going to happen on our watch. We would do well to admit it.
If you said automated instead of AI that would make sense to me.
But why would you want to use AI to control planes?
It's a by-word for expert systems with management conception as well as multi-domain comprehension these days. Reasoning through failures in one sensor domain with limited data from other domains within a fixed period following strict risk protocols at 3:01AM is the sort of thing AI would excel at versus humans.
Which are these "human processes in the loop"? We are talking about changing flight schedules, and I'm pretty sure that existing flight schedules are not developed by teams of people with pen and paper, but rather by powerful ILP solvers, because of (a) the immense value in optimising every aspect of them and (b) the myriad regulatory constraints that need to be met for, e.g., flight crew scheduling.
Aviation is one of the few industries where the largest regular (non-capital) expense is something other than labour, namely fuel. Anything that reduces fuel costs even a little is of obvious interest to every airline.
There are still the issues of coordinating flight paths to avoid collisions, and regulation (including international regulation). The former seems like a technical problem amenable to increasingly accurate approximations over time. I don't know about the latter, but I doubt it's as insurmountable as you imply. International air travel has been around longer than ILP solvers, meaning that at some point flight schedules were created by people. Now they're created by ILP solvers, and the regulatory environment successfully adapted to that change.
Manual processes: Most takeoff/landing processes, navigation waypoint input/confirmation/naming/registration, ATC, regulatory, ground service, gate allocation, boarding, cargo loading, radio, one could go on...
I'm not a pilot, but there are other pilots here, and their opinion is very close to mine: the post is BS.