search

fpw / avitab

X-Plane plugin that displays a tablet to aid VR usage
GNU Affero General Public License v3.0
299 stars 58 forks source link

Flight plan overlay phase 3 - procedures #193

Closed mjh65 closed 6 months ago

mjh65 commented 7 months ago

This adds functionality to decompose into waypoints any SIDs, STARs and Approaches named in the FMS. The waypoints for procedures are not present in the FMS - just the name, so the NavData database is queried to get them.

Note that

A SID/STAR can have 0, 1 or more entries in each of the runwayTransitions, commonRoutes and enrouteTransitions structures and the commonRoutes entries may be associated with runways too.
If a SID/STAR is specified in the FMS, associated runway and transitions are optional, and should be treated as don't care. If they are omitted, then Avitab should determine a common set of waypoints. This may be the same as a commonRoute from the database, particularly for the USA. But not always.

As a result of the above, code to attempt to linearly trace through waypoints (similar to the iterate method) was perceived as becoming an unreadable, bug-prone mess of multidimensional if/then statements. So the approach (no pun intended) here is to loop through all possible permutations of concatenated segments and check whether the permutation meets the constraints of the (possibly don't care) runway and transition in the FMS. This provides a more complete version of common waypoints and the code has a much cleaner flow.

As discussed over email, this is a mirror of https://github.com/fpw/avitab/pull/192, which I can manage while @dave6502 is unavailable. I may also submit further refactoring commits to simplify the SQL updates to follow.

mjh65 commented 6 months ago

Two further refactoring commits added to this branch. The first tidies the Route and RouteFinder classes and removes some of the slightly tangled interdependency by moving the RouteDirection structure into the Route class since this is where it most logically belongs. It is also renamed to Route::Leg since this is the purpose of the structure. The Route class now has no dependency on the RouteFinder, and contains all it needs to represent a route, whether it is loaded from a FMS file, or generated by the RouteFinder. The NAV world now provides an API for getting a RouteFinder instance. This is for future support of a SQL-backed NAV database, when the route finding algorithm will require a slightly different implementation. (There will also be some further abstraction to be made in the Route class components, since the future support of SQL will result in a different representation of node connections and procedures.)