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.
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.
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.
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.
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.
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.
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.
The fuel consumption feels like the bigger problem since contrails last for hours vs co2 that lasts damn near forever.
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.
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.
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.
This is pretty cool! https://github.com/airbus/scikit-decide
It's nice to see the scikit brand live on.