Initial inspection
This flight looks like this in Charts:
And this is MSFS:
So far so good, as far as I can see! Same procedures, same waypoints and same route.
It is worth noting that MSFS does not simplify their “route pills” by showing the procedure names, instead showing the waypoints that they are made up of. For example, TEETO, JAAZZ and FITZY are all part of the approach:
But MSFS displays them as separate route items in their pills:
The result should be the same, regardless. You can tell by the colorization of the route in the world map that MSFS is aware of the types of each part of the route, from departure to approach (blue, green, magenta).
Visual anomalies
However, when you dig into the difference between a file exported from Navigraph Charts and MSFS, things get weird quickly.
First and foremost - I started this flightplan in Navigraph Charts, and exported it for MSFS. I then loaded this PLN file into MSFS, and all procedures were correctly identified - as they should, since we follow the PLN specification. This was shown in the previous section.
But when comparing the routes side by side, we can clearly see a difference. Let’s start with the visual part and then the technical stuff!
Exported from MSFS:
Exported from Charts
Based on the first look, you might assume that our flightplan is missing waypoints. At least it looks that way right? Well, if you zoom in (and check the technicals, shown later) you can see that our plan does pass by the same exact waypoints. But they are not highlighted! When you zoom in, you can see the labels of these waypoints too! Here are two examples:
Now, how come this is the case? Let’s take a deeper look!
Analyzing the PLN file differences
To begin with, let’s see what MSFS does to our PLN once it is loaded into the simulator. To do this, I loaded the PLN that was just exported from Navigraph Charts and loaded it in the world map, then immediately exported it again. This resulted in a new PLN file, which I will now compare to the original!
Below is the diff between these two files. You can also see it here if you prefer to see a side-by-side comparison over a unified view.
Full diff
<SimBase.Document Type="AceXML" version="1,0">
<Descr>AceXML Document</Descr>
<FlightPlan.FlightPlan>
<Title>KALB to KMHT</Title>
<FPType>IFR</FPType>
<RouteType>LowAlt</RouteType>
- <CruisingAlt>16000</CruisingAlt>
+ <CruisingAlt>16000.000</CruisingAlt>
<DepartureID>KALB</DepartureID>
<DepartureLLA>N42° 44' 56.76",W73° 48' 7.20",+000285.00</DepartureLLA>
<DestinationID>KMHT</DestinationID>
<DestinationLLA>N42° 55' 58.08",W71° 26' 8.52",+000266.00</DestinationLLA>
<Descr>KALB to KMHT created by Navigraph</Descr>
+ <DeparturePosition>19</DeparturePosition>
<DepartureName>ALBANY INTL</DepartureName>
<DestinationName>MANCHESTER BOSTON REGL</DestinationName>
+ <AlternateName>AlternateName</AlternateName>
<AppVersion>
<AppVersionMajor>11</AppVersionMajor>
<AppVersionBuild>282174</AppVersionBuild>
</AppVersion>
- <ATCWaypoint id="KALB">
+ <ATCWaypoint id="Albany Intl">
<ATCWaypointType>Airport</ATCWaypointType>
- <WorldPosition>N42° 44' 56.76",W73° 48' 7.20",+000285.00</WorldPosition>
+ <WorldPosition>N42° 44' 56.82",W73° 48' 7.13",+000279.00</WorldPosition>
+ <SpeedMaxFP>-1</SpeedMaxFP>
<RunwayNumberFP>19</RunwayNumberFP>
<ICAO>
<ICAOIdent>KALB</ICAOIdent>
@@ -27,87 +31,86 @@
</ATCWaypoint>
<ATCWaypoint id="SMYTH">
<ATCWaypointType>Intersection</ATCWaypointType>
- <WorldPosition>N42° 30' 16.56",W73° 53' 5.86",+000000.00</WorldPosition>
+ <WorldPosition>N42° 30' 16.56",W73° 53' 5.86",+004400.00</WorldPosition>
+ <SpeedMaxFP>-1</SpeedMaxFP>
<ArrivalFP>ROZZE2</ArrivalFP>
<RunwayNumberFP>6</RunwayNumberFP>
<ICAO>
- <ICAOIdent>SMYTH</ICAOIdent>
<ICAORegion>K6</ICAORegion>
+ <ICAOIdent>SMYTH</ICAOIdent>
</ICAO>
</ATCWaypoint>
<ATCWaypoint id="QUINZ">
<ATCWaypointType>Intersection</ATCWaypointType>
- <WorldPosition>N42° 46' 23.52",W73° 3' 0.52",+000000.00</WorldPosition>
+ <WorldPosition>N42° 46' 23.52",W73° 3' 0.52",+015350.00</WorldPosition>
+ <SpeedMaxFP>-1</SpeedMaxFP>
<ArrivalFP>ROZZE2</ArrivalFP>
<RunwayNumberFP>6</RunwayNumberFP>
<ICAO>
- <ICAOIdent>QUINZ</ICAOIdent>
<ICAORegion>K6</ICAORegion>
+ <ICAOIdent>QUINZ</ICAOIdent>
</ICAO>
</ATCWaypoint>
+ <ATCWaypoint id="TIMECRUIS">
+ <ATCWaypointType>User</ATCWaypointType>
+ <WorldPosition>N42° 46' 34.96",W72° 59' 35.63",+016000.00</WorldPosition>
+ <SpeedMaxFP>-1</SpeedMaxFP>
+ </ATCWaypoint>
<ATCWaypoint id="LUCIC">
- <ATCWaypointType>Intersection</ATCWaypointType>
- <WorldPosition>N42° 47' 24.05",W72° 44' 34.66",+000000.00</WorldPosition>
+ <ATCWaypointType>User</ATCWaypointType>
+ <WorldPosition>N42° 47' 24.05",W72° 44' 34.66",+016000.00</WorldPosition>
+ <SpeedMaxFP>-1</SpeedMaxFP>
<ArrivalFP>ROZZE2</ArrivalFP>
<RunwayNumberFP>6</RunwayNumberFP>
- <ICAO>
- <ICAOIdent>LUCIC</ICAOIdent>
- <ICAORegion>K6</ICAORegion>
- </ICAO>
+ </ATCWaypoint>
+ <ATCWaypoint id="TIMEDSCNT">
+ <ATCWaypointType>User</ATCWaypointType>
+ <WorldPosition>N42° 47' 31.71",W72° 42' 16.00",+016000.00</WorldPosition>
+ <SpeedMaxFP>-1</SpeedMaxFP>
</ATCWaypoint>
<ATCWaypoint id="FLYZZ">
- <ATCWaypointType>Intersection</ATCWaypointType>
- <WorldPosition>N42° 48' 13.41",W72° 29' 25.20",+000000.00</WorldPosition>
+ <ATCWaypointType>User</ATCWaypointType>
+ <WorldPosition>N42° 48' 13.41",W72° 29' 25.20",+013450.00</WorldPosition>
+ <SpeedMaxFP>-1</SpeedMaxFP>
<ArrivalFP>ROZZE2</ArrivalFP>
<RunwayNumberFP>6</RunwayNumberFP>
- <ICAO>
- <ICAOIdent>FLYZZ</ICAOIdent>
- <ICAORegion>K6</ICAORegion>
- </ICAO>
</ATCWaypoint>
<ATCWaypoint id="FYSHR">
- <ATCWaypointType>Intersection</ATCWaypointType>
- <WorldPosition>N42° 49' 14.09",W72° 9' 14.19",+000000.00</WorldPosition>
+ <ATCWaypointType>User</ATCWaypointType>
+ <WorldPosition>N42° 49' 14.09",W72° 9' 14.19",+009400.00</WorldPosition>
+ <SpeedMaxFP>-1</SpeedMaxFP>
<ArrivalFP>ROZZE2</ArrivalFP>
<RunwayNumberFP>6</RunwayNumberFP>
- <ICAO>
- <ICAOIdent>FYSHR</ICAOIdent>
- <ICAORegion>K6</ICAORegion>
- </ICAO>
</ATCWaypoint>
<ATCWaypoint id="ROZZE">
<ATCWaypointType>Intersection</ATCWaypointType>
- <WorldPosition>N42° 49' 45.26",W71° 59' 32.85",+000000.00</WorldPosition>
+ <WorldPosition>N42° 49' 45.26",W71° 59' 32.85",+007450.00</WorldPosition>
+ <SpeedMaxFP>-1</SpeedMaxFP>
<ArrivalFP>ROZZE2</ArrivalFP>
<RunwayNumberFP>6</RunwayNumberFP>
<ICAO>
- <ICAOIdent>ROZZE</ICAOIdent>
<ICAORegion>K6</ICAORegion>
+ <ICAOIdent>ROZZE</ICAOIdent>
</ICAO>
</ATCWaypoint>
<ATCWaypoint id="PNARD">
- <ATCWaypointType>Intersection</ATCWaypointType>
- <WorldPosition>N42° 49' 53.92",W71° 55' 40.36",+000000.00</WorldPosition>
+ <ATCWaypointType>User</ATCWaypointType>
+ <WorldPosition>N42° 49' 53.92",W71° 55' 40.36",+006700.00</WorldPosition>
+ <SpeedMaxFP>-1</SpeedMaxFP>
<ArrivalFP>ROZZE2</ArrivalFP>
<RunwayNumberFP>6</RunwayNumberFP>
- <ICAO>
- <ICAOIdent>PNARD</ICAOIdent>
- <ICAORegion>K6</ICAORegion>
- </ICAO>
</ATCWaypoint>
<ATCWaypoint id="TEETO">
- <ATCWaypointType>Intersection</ATCWaypointType>
- <WorldPosition>N42° 48' 47.15",W71° 42' 27.41",+000000.00</WorldPosition>
+ <ATCWaypointType>User</ATCWaypointType>
+ <WorldPosition>N42° 48' 47.15",W71° 42' 27.41",+004050.00</WorldPosition>
+ <SpeedMaxFP>-1</SpeedMaxFP>
<ArrivalFP>ROZZE2</ArrivalFP>
<RunwayNumberFP>6</RunwayNumberFP>
- <ICAO>
- <ICAOIdent>TEETO</ICAOIdent>
- <ICAORegion>K6</ICAORegion>
- </ICAO>
</ATCWaypoint>
- <ATCWaypoint id="KMHT">
+ <ATCWaypoint id="Manchester">
<ATCWaypointType>Airport</ATCWaypointType>
- <WorldPosition>N42° 55' 58.08",W71° 26' 8.52",+000266.00</WorldPosition>
+ <WorldPosition>N42° 55' 58.10",W71° 26' 8.70",+000250.00</WorldPosition>
+ <SpeedMaxFP>-1</SpeedMaxFP>
<ApproachTypeFP>ILS</ApproachTypeFP>
<RunwayNumberFP>6</RunwayNumberFP>
<ICAO>
We find that quite a lot happened. Let’s summarize!
-
The cruising altitude has been modified from
16000to16000.000. -
The departure runway was added as an extra
<DeparturePosition>tag -
An invalid/unused
<AlternateName>with a default value of…AlternateNamewas added
It is even mentioned as deprecated in their own documentation. -
A couple custom waypoints called
TIMECRUISandTIMEDSCNTwas added to mark specific phases of the flight. -
LUCIC,FLYZZ,FYSHR,PNARD,TEETO- a majority of the waypoints that make up the arrival, were all stripped of their role asIntersections. This means that they are no longer treated as navaids, but as coordinate-based custom user waypoints. -
Some waypoints had their coordinates (
<WorldPosition>) changed as well.
Conclusion?
I don’t know if any of these changes that MSFS did would cause any issues for you while flying. It does not look like it! However - I can see a few issues that we could look into!
-
Using this plan as an example, we have issues with the departure procedure. This is because the specification (found here) wants us to define the departure procedure on any and all waypoints included in the procedure. In this case, that is a problem because the first waypoint in the flightplan is both the end of the departure and the start of the arrival at the same time - not a super common scenario, and not a case that has explicitly documented solutions.
We can investigate this and see if we can find a reliable solution, but it is not straightforward. MSFS sometimes works around this by injecting made-up waypoints to act as placeholders, but it’s not the prettiest thing to see either… -
When loading this PLN, or any PLN for that matter, back into Charts - the approach transition is lost. This is caused by the fact that it is not actually ever specified in the PLN file! However, we could do the same thing that MSFS seems to be doing in this case - looking at the last waypoint in the route and trying to find a matching approach transition based on that.
Both of these are edge cases that we have so far barely realized ourselves. I will add them both to our bug tracker!
Bonus answers
This is not true. If you set the Cruising Altitude to a value below 18 000 in the flight options, your flight will look like my example in this post, which is:
...
<FPType>IFR</FPType>
<RouteType>LowAlt</RouteType>
...
Likewise, if you set the Flight Mode to VFR - the exported file will instead use the type.
If this does not work for you, your flight is not being saved correctly. Feel free to open a new, dedicated topic in that case, and we’ll look into that!
The screenshot you provided looks totally crazy, and that is because this is your theoretical route:
KALB ALB7 SMYTH <enroute waypoints, all part of ROZZE2> SMYTH ROZZE2 KMHT
Lots to unpack here but most importantly:
-
SMYTHis in there twice. One time as the departure transition, and one time as the arrival transition for some unknown reason. This causes an abrupt jump back and fourth, sort of like:
ORIGIN -> SMYTH -> ENROUTE -> SMYTH -> ARRIVAL (Same as enroute) -> DESTINATION -
All the waypoints that make up the arrival are in there twice, once as explicitly added “enroute” waypoints, and then again as part of the
ROZZE2arrival. This adds to the above issue.
The ZIP file you uploaded contains a PLN file, but it is completely empty - containing only the origin and destination airports but nothing else. Unfortunately, I can’t see how that file caused the mess that is shown in your screenshots!
If that flightplan was exported by MSFS, then something went terribly wrong somewhere. Here is the same route, same procedures etc. exported directly from MSFS without Navigraph Charts involved:
FROM-MSFS-KALB-KMHT.PLN (7.4 KB)
Try loading this one into Navigraph Charts! You will find that it works just fine, albeit with the exceptions mentioned in my conclusion in the earlier section.
We don’t recalculate anything based on your situation, no. When you open the panel, we check the simulator to see if it has loaded any flightplan, and if it has - we ask you if you would like to load that flightplan. We don’t make any modifications - if you got the TEETO transition then that is what the simulator believed that you had loaded.
What are you comparing to in this sentence? I’ll see if I can clarify why that is important!
If you import a PLN that has been exported from MSFS into Navigraph Charts, you will always get a “Final” approach transition - the reason is mentioned in the conclusion.
However, if you import the flight directly from the simulator inside of the panel - you do get the correct transition since the simulator (and our panel logic) does not use the PLN format at all, instead having access to much more data.
This could very well be the reason why you saw these changes!
I hope some of what I have written here is of any help in understanding the situations you have seen.
If you have any follow-up questions, or you would like to add things that I have missed in my analysis, feel free to do so!
Kind Regards,
Malte