Bug description: The flight plan files saved by MSFS 2024 have changed compared to the legacy format. The cruise altitude is wrong (for example, 1.3 million feet when flying from Munich to Rome), the departure and destination airports are not in the Waypoint List and all Waypoints are missing the geographical location data (WorldPosition). This makes it impossible to use these files in apps that want to do GIS related processing.
Repro steps: Generate a flight plan on the EFB and save it to disk
That definitely sounds like either a PLN serializer bug or a bug with the EFB planner app itself.
They are now in their own elements, to separate them from the enroute segment of the plan, as in a proper ICAO standards flight plan.
Waypoints that are navigational data facilities will not include positions any longer in the new format. The issue with including positions is that these locations can shift over time, and thus create a problem in which the data can therefore be bad or in conflict with itself (the file indicates a fixed facility but in a different location than it currently is in the navdata), and it isn’t clear the intention of the PLN file.
As such, only custom lat/lon waypoints will include this WorldPosition element. If you need the locations of navigational facilities, you should look them up with the JS or SimConnect facility API (or otherwise reconcile them with your own nav database if that’s how the program works) to get their current positions.
as far as I know, the facilities and waypoint IDs themselves can change over time, as do the procedures. A .pln file can always only be a snapshot of a certain point in time. I don’t see the point why they shouldn’t have geo coordinates. If MSFS expects trouble with the coordinates, it could just ignore them when a PLN file is imported.
Traditionally, PLN files were used (by me at least) as a medium of transferring routes between the sim and other apps. These other apps (like flight planners or ATC) don’t necessarily have access to SimConnect and the scenery API. Now the pln files are nothing more than a MSFS internal asset and can only be used for this one purpose - from my point of view that is a real loss of inter-app functionality.
They don’t need access to either of those, as long as they have access to some nav data (which pretty much any ATC or flight planning system must have). The sim ICAO identifiers are the same structurally as the identifiers in standard ARINC data, in that they identify the type of the facility, the region the facility is in (matching the ARINC region codes), any associated airport, and the alphanumeric ID.
There’s nothing proprietary or modified about those identifiers that make them unique to MSFS; in fact, given any standard nav data you can quite trivially use these identifiers to look up those facilities and get their locations.
Doing it the way we’ve done it now improves transferability between applications, because each application can easily look up the location of the facility in its native navigational database as opposed to having to rely on the provided location.
But that was actually the benefit - because one could rely on the data being exactly the same as in the sim. Imagine for example an app that wants to display your current flight in Google Earth. In the old days, you just exported the flight plan, parsed the geo data out of it and built a KMZ from that. Now this same app effectively has to export the flight plan, then parse the procedures and the waypoints, query all that from the scenery API, and only when all these queries and subqueries from queries are complete, it can think about building the target format.
I’m sorry, but I find it really hard to see this as an improvement. Not that this should concern you, I just wanted to voice my feelings about this new logic. I can work with it of course, but it has made a very simple task massively complicated. Which as a programmer I can’t really appreciate, sorry.
I won’t pretend to be an expert on this, but isn’t a flight plan only valid inside the AIRAC cycle that it was made for? And that the waypoints are static inside the same cycle? It feels like this should be the case, so all associated actors (flight planning to FMC) are on the same page?