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.
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.
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.
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.
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/
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.
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.
> 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.
For most flights today though, if you only count the CO2 produced you're understanding the climate damage by about half.
I hate to be discouraging, but maybe the author should make an attempt to understand navigation before cooking up something like this.
One point at 45min faster and 25% less fuel is of course huge, but how does it map out over a year of routing?
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.
It's nice to see the scikit brand live on.
But why would you want to use AI to control planes?
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.