- 240comments
- 178comments
- 39comments
- 205comments
- 185comments
- 83comments
- 13comments
- 111comments
- —discuss
- 113comments
- —discuss
- 93comments
- 41comments
- 11comments
- 118comments
- 1comments
- 307comments
- 4comments
- 392comments
- 12comments
- 2comments
- —discuss
- 156comments
- 31comments
- 306comments
- 211comments
- 59comments
- 74comments
- 67comments
- 9comments
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.
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 pretty cool! https://github.com/airbus/scikit-decide
It's nice to see the scikit brand live on.
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/
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?
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.