X-Plane FMS file out of specification for place/bearing/distance

SimBrief Dispatch
#1

For example suing route from:

KAVL to KACY

VIEWS COLZI FAK237020 FAK BUKYY JAYBO SIE

In both X-Plane format variants, the place/bearing/distance waypoint is coded as follows:

11 FAK237020 39000 37.300509 -78.134912

11 FAK237020 DRCT 39000.000000 37.300509 -78.134912

Going by the specification at: Flightplan files - v11 .fms file format - X-Plane Developer

Row/line code 11 corresponds to a named fix, which it isn’t.

Since this seemingly hasn’t been brought up until now, I suspect It’s possible X-Plane’s default avionics will gracefully fall back to using the latitude/longitude coordinates, but the waypoint should ideally be coded as per the specification (presumably as a latitude/longitude waypoint with row/line code 28, since there is no specific code or other facility in the format to allow for composite waypoint definitions), so that it can be parsed by third-party software which may adhere more strictly to the published specification :slight_smile:

As a side note, the route_navigraph in the XML/JSON data is as follows:

DCT VIEWS DCT COLZI DCT FAK237020 DCT FAK DCT BUKYY DCT JAYBO DCT SIE DCT

…which Navigraph Charts cannot parse fully (gives an error relating to the place/bearing/distance waypoint too, and there is a “discontinuity” on the map in the application). It should probably be converted to a latitude/longitude for that field as well, provided Navigraph Charts does have some form of support for such waypoints?

Regards,

Tim

#2

Ping :slight_smile:

Regards,

Tim

#3

Looks like even latitude/longitude waypoints are coded as fixes, for example 250022N1700025W becomes:

11 25N70 DRCT 37000.000000 25.006111 -170.006944

At least in this case the legacy XP9/XP10 format codes those as latitude/longitude coordinates.

Regards,

Tim

#4

I think I’ve fixed it now. When you get a moment can you check and make sure they still import correctly in X-Plane as well as any add-ons you use?

Thanks! :slight_smile:

#5

Will do!

Regards,

Tim

#6

Forgot to mention, I’ve brought up the fix/bearing/distance waypoints with the Charts team. Ideally Charts should be able to handle them, but if for whatever reason it isn’t possible for now I’ll update SimBrief to send it as a Lat/Long to Charts instead.

1 Like
#7

So far, so good. One addon didn’t yet support lat/long fixes but will fix it soon. Someone brought something up that I’ll expand on in another topic.

Regards,

Tim

#8

OK so continuing here because I’m not sure of what title to use for a new topic.

So, on the route like the following:

KEYW KARTR CAPEN OZENA OXANA PENYT JOBOC GAYBL N29A CARAC PERLU JOOPY 51N050W 55N045W 58N040W 62N030W ELREX ELDIS BIRK

51N050W 55N045W 58N040W 62N030W were converted to fixes with idents 5150N 5545N 5840N 6230N, and, because these named fixes do exist, it worked. @Pilsner (not registered here, I think, not sure) on Discord thought it would be better that they be coded as such when possible.

There’s a caveat though: not all latitude/longitude waypoints have fixes in the X-Plane earth_fix.dat file (5150N 5545N 5840N 6230N are present, but 5153N 5547N 5849N 6231N are not, for example – I’m not sure if there’s an exact pattern as to which fixes are in earth_fix.dat or not, AFAICT it may possibly even vary based on region).

Further complicating things, Navigraph does include the additional fixes (5153N 5547N 5849N 6231N and the like) in the file user_fix_georef.dat (which can be used by X-Plane and addons), but Aerosoft does not.

So there are several possible options, I guess:

(1) (a) try and reliably figure out which lat/long named fixes exist in earth_fix.dat specifically, and auto-convert lat/long waypoints to named fixes when those waypoints are present in the route, implementing Pilsner’s suggestion

(1) (b) auto-convert all lat/long waypoints corresponding to integer latitude/longitude coordinates to named fixes (sometimes breaking compatibility with Aerosoft database users)

(2) go in the opposite direction, and instead auto-convert named lat/long fixes to custom latitude/longitude waypoints for maximum compatibility across different databases

(3) leave it as-is, when named lat/long fixes are used in the route string on the dispatch page, code them as such, when latitude/longitude coordinates are used instead (i.e. 51N050W format and similar) code them as latitude/longitude waypoints instead

Regards,

Tim

#9

Thanks Tim, I’m more inclined to go with option 3 since users can decide for themselves whether to use named fixes or custom lat/longs.

If coordinates are used in the route, currently I name them using ARINC shorthand format (i.e. 5150N) where possible, while keeping the waypoint type as “28”. For example:

28 5150N DRCT 37000.000000 51.000000 -50.000000
28 5545N DRCT 37000.000000 55.000000 -45.000000
28 5840N DRCT 37000.000000 58.000000 -40.000000
28 6230N DRCT 37000.000000 62.000000 -30.000000

Does X-Plane still load them as custom waypoints if they are named this way, or should I name them differently (FIX01, FIX02) perhaps?

#10

Does X-Plane still load them as custom waypoints if they are named this way

I didn’t do a deep check (see below) but I think you’re OK using the shorthand format.

It’s always hard to tell, because the default FMS and GPS, as well as some addons, seem to load .fms files just fine regardless of whether the waypoint type and its ident match (presumably, falling back to the latitude/longitude coordinates provided alongside each waypoint whenever an absolute match cannot be found – for example, it managed to load your fake named fixes previously).

Some addons (like the Hot Start Challenger) are more picky and revealed the inconsistencies in your original .fms output, but as far as default avionics go, to really know what waypoint types are being used under the hood, you have to walk through the waypoint list using e.g. a plugin and the XPLMNavigation API, or maybe re-export the route from the FMS and see what waypoint types it uses then (I use the default FMS so rarely I haven’t even tried the latter as I don’t yet know how).

However, given input like:

28 27N75 DRCT 39000.000000 27.002500 -175.011111
28 27N75 DRCT 39000.000000 27.000000 -175.000000
28 25N70 DRCT 39000.000000 25.006111 -170.006944
28 25N70 DRCT 39000.000000 25.000000 -170.000000

The first and third waypoints are not mapped to a named fix (i.e. default avionics as well as addons I have can all successfully tell them apart from the second and fourth waypoints, with non-zero distances between them and seemingly correct placement on the navigation displays). Hence my initial statement that using the shorthand format is most likely OK.

As I am writing this, I realized I only tried in-sim addons, and not external tools like Navigraph Charts, Sim ToolKit Pro or Little Navmap.

Navigraph Charts Desktop actually maps the custom waypoints with row code 28 to the named fixes associated with the shorthand notation. But it seems to ignore the row codes altogether, for example given this line:

28 PBD01 DRCT 39000.000000 22.970536 -163.366022

…Charts Desktop gives an error about the ident “PBD01” and features the usual discontinuity when the route contains an unrecognized waypoint. Thus it’s probably better to fix Charts than to change your naming convention since it won’t work anyway (TBH, I’m not sure Charts Desktop supports any kind of latitude/longitude defined waypoints at all, other than pre-existing named fixes – if it does, it’s not documented).

I will have to try STKP and LNM later.

Regards,

Tim

#11

It should also be noted, however, that the ident you use next to the type-28 waypoints actually gets loaded by the X-Plane 11 FMS and G1000 when importing the file (e.g. even PBD01).

1278×850 267 KB

#12

Haha, this is hopeless.

Input:

I
1100 Version
CYCLE 2003
ADEP PMDY
ADES PHNL
NUMENR 11
1 PMDY ADEP 18.000000 28.201483 -177.381308
11 ESOVY DRCT 21100.000000 28.267028 -177.191808
11 OKEZO DRCT 28600.000000 28.244514 -176.626183
28 27N75 DRCT 39000.000000 27.002500 -175.011111
28 27N75 DRCT 39000.000000 27.000000 -175.000000
28 25N70 DRCT 39000.000000 25.006111 -170.006944
28 25N70 DRCT 39000.000000 25.000000 -170.000000
11 DOGIF DRCT 39000.000000 23.258333 -163.855000
28 PBD01 DRCT 39000.000000 22.970536 -163.366022
11 CANON DRCT 39000.000000 22.801500 -162.616889
1 PHNL ADES 2500.000000 21.317828 -157.920264

Import in X-Plane G1000, then use MENU > Store Flight Plan to export it back. Result:

I
1100 Version
CYCLE 2201
ADEP PMDY
ADES PHNL
NUMENR 11
1 PMDY ADEP 31.000000 28.201483 -177.381302
11 ESOVY DRCT 0.000000 28.267029 -177.191803
11 OKEZO DRCT 0.000000 28.244514 -176.626190
11 27N75 DRCT 0.000000 27.002501 -175.011108
11 27N75 DRCT 0.000000 27.000000 -175.000000
11 25N70 DRCT 0.000000 25.006111 -170.006943
11 25N70 DRCT 0.000000 25.000000 -170.000000
11 DOGIF DRCT 0.000000 23.258333 -163.854996
11 PBD01 DRCT 0.000000 22.970535 -163.366028
11 CANON DRCT 0.000000 22.801500 -162.616882
1 PHNL ADES 13.000000 21.317827 -157.920258

…which is probably your original inspiration for the coding of latitude/longitude waypoints. Laminar not adhering, even loosely, to their own specification.

#13

Further notes about default X-Plane 11 avionics (GPS, G1000, FMS): on import, waypoint idents are truncated to the first 6 characters (i.e. idents as shown on the display/CDU); on export/save, they are truncated to 5 characters in the .fms file.

Even manually entered latitude/longitude waypoints (e.g. N2801W16502 in default FMS scratchpad) are saved as fixes (11 N28W1 DRCT 0.000000 28.016666 -165.033340). Only airports, NDB and VORs seem to get their dedicated row codes.

This is tiresome but at least we’re sort of kind of getting somewhere, I guess? :slight_smile:

#14

Thanks Tim. This is great information, I really appreciate it!

Sounds like SimBrief’s format is working now in most add-ons then? I can follow up with the Charts team about the .fms import, maybe something they can improve in the next version.

Cheers,

#15

Yes. It already worked fine in most addons because they are very forgiving, but with the recent updates it works well with the pickier ones too. I have yet to test LNM and STKP though, will keep you posted.

#16

Thanks Tim, sounds good!

#17

Little NavMap works fine with the new coding. Sim Toolkit Pro seems to go only by the idents but that’s their bug and it makes no difference if you use the old or new coding, so no regression here.

I did report the issue to STKP via their built-in bug reporting tool, BTW :slight_smile:

Cheers,

Tim

#18

Great, thanks for the update Tim!