Formula for calculating RDIS using data from Simbrief XML file

The SimBrief XML file fir_crossing elements do not specific DIS nor RDIS. An attempt at calculating these values resulted in a discrepancy between derived numbers and those shown by the SimBrief website. For example consider this segment of an OFP:

AWY                           FL   IMT   MN    WIND  OAT  EFOB  PBRN
POSITION    LAT      EET ETO MORA  ITT  TAS    COMP  TDV
IDENT       LONG    TTLT ATO DIS  RDIS   GS     SHR  TRP  AFOB  ABRN
FREQ
--------------------------------------------------------------------
J41                          400   329  .83 242/100  M49 -17.4 169.5
SCAWT       N3820.7 0001 ...  32   330  485    M014  P08
SCAWT      W09402.5 1639 ...  10  1481  471       2  333  ....  ....

J41                          400   337  .83 246/077  M48 -18.5 170.5
KANSAS CITY N3917.1 0009 ...  33   338  487    M014  P09
MCI        W09444.2 1648 ...  65  1416  473       0  298  ....  ....
113.25

J41                          400   337  .83 245/062  M49 -18.8 170.8
AGENT       N3936.6 0002 ...  34   338  485    M001  P08
AGENT      W09454.3 1650 ...  21  1395  484       1  306  ....  ....

MINNEAPOLIS FIR/UIR                                                 
-KZMP       N4010.9 0004 ...
           W09512.7 1654 ...  34  1361

J41                          400   300  .83 248/056  M48 -20.3 172.3
OMAHA       N4110.0 0009 ...  42   301  486    M003  P09
OVR        W09544.2 1703 ...  67  1294  483       0  308  ....  ....
116.30

Using a standard calculation resulted in these values:

KZMP1655
MINNEAPOLIS FIR/UIR - N4010.9 W09512.7
KZMP
(PREV->FIR): 37.0797
(FIR–>FIX): 63.7992
(PREV->FIR->FIX): 100.879
(PREV->FIX): 100.878

The SimBrief OFP indicates an RDIS at this point of 67 (not 64) and the distance to the FIR is reported as 34 (not 37). I would like to know how these values are calculated or if they could be added as elements to the XML file to simplify processing the XML into a Flight Plan.

For reference this is the equation that was used (in C++) to arrive at the distances posted:

distance = 3440.0647948 * std::acos(std::sin(deg2rad(lat1)) * std::sin(deg2rad(lat2)) + std::cos(deg2rad(lat1)) * std::cos(deg2rad(lat2)) * std::cos(deg2rad(long2) - deg2rad(long1)));

FWIW, I’ve been using the formula here in my own projects: Aviation Formulary V1.47 — specifically the “mathematically equivalent formula, which is less subject to rounding error for short distances”.

That being said I’ve never attempted to compare the distances produced this way to the simBrief navlog.

Regard,

Tim

Updated code to use Vincenty’s formulae with the same result. Not sure what equations (or presumptions) SimBrief is using to calculate the values that are in the OFP. It might be more than simple round-off error since using the time elapsed and converting to distance based on ground speed results in a similar discrepancy.

double SimBriefUtilities::great_circle_distance_vincenty(double lat1, double lon1,
                                                         double lat2, double lon2)
{
    const double sinf1 = std::sin(deg2rad(lat1));
    const double sinf2 = std::sin(deg2rad(lat2));
    const double cosf1 = std::cos(deg2rad(lat1));
    const double cosf2 = std::cos(deg2rad(lat2));
    const double dlambda = std::abs(deg2rad(lon1) - deg2rad(lon2));
    const double cosdl = std::cos(dlambda);
    const double sindl = std::sin(dlambda);
    const double c1 = cosf2 * sindl;
    const double c2 = cosf1 * sinf2 - sinf1 * cosf2 * cosdl;
    const double c3 = sinf1 * sinf2 + cosf1 * cosf2 * cosdl;
    // central angle
    const double dsigma = std::atan2(std::sqrt(c1 * c1 + c2 * c2), c3);
    return 3440.0647948 * dsigma; // statute miles
}

Another example:

DCT                          300   324  .82 242/033  M36 116.2  35.8
OSEPA       S2300.0 0043 ...  20   307  490    M016  P09
OSEPA      E00000.0 0241 ... 338  8070  474       3  531  ....  ....

                             300   326  .82 249/032  M33 113.7  38.3
ETP1        S2154.9 0014 ...  20   309  494    M018  P12
           W00131.7 0255 ... 115  7955  476       1  548  ....  ....

Distance between S2300.0 E00000.0 and S2154.9 W00131.7 is 106.93 nautical miles (not 115). This is a difference of 8 nautical miles. The question is does this mean the SimBrief generated OFP is incorrect or is there something that needs to be factored in other than a simple coordinate-to-coordinate distance calculation.

Maybe the navlog features the air distance?

Regards,

Tim

Hi all, the answer is simply that the SimBrief FIR distances were incorrect in some navlog formats. :slight_smile:

Should be fixed now I think.

Cheers,

Thank you! I truly appreciate this and it will help me wrap-up a project to create a nice way to view SimBrief information within X-Plane.

1 Like

If you notice estimated elapsed time differences that is my fault as I still am working on the code and it is incomplete.

Great, looks nice!

I’m not sure why I had the distances (incorrectly) coded the way I did previously, possibly it was an oversight but it’s also possible I did it this way to avoid discrepancies elsewhere.

Please let me know if you notice anything else that doesn’t match going forward!

Cheers,

I noticed that ETP2 is missing now for the same flight plan regenerated after the fix.

Hi, this is unrelated to the navlog fixes.

ETOPS scenarios are normally generated using current weather. On some days, certain airports will be suitable for diversion while others will not. Depending on which airports SimBrief chooses, you might have many ETPs or no ETPs at all.

If you need the ETOPS scenario to remain static across multiple days for your testing, you should expand the “ETOPS Scenario” option and click “Calculate”:

If you need to restore the Scenario you had a few days ago (with 2 ETPs), use the following options:

Note that the ETP points might still move around if you change your departure date, due to different winds aloft.

Best regards,

That is a useful suggestion. Thanks again for your help and ruling out an unintended consequence of the navlog fixes. It should have occurred to me that the flight plan conditions weren’t exactly identical. I will need to add some unit tests with some static XML files to ensure code integrity. There are so many possibilities: multiple FIR/UIR interspersed between fixes and ETOPS points for instance. In hindsight it might have been simpler to parse the OFP->text->plan_html XML element.

If an ETOPS point occurs just prior to a FIR/UIR crossing I presume it would still have all these parameters from the next fix unlike the FIR/UIR which will only have DIS and RDIS

 FL   IMT   MN    WIND  OAT  EFOB  PBRN
MORA  ITT  TAS    COMP  TDV
DIS  RDIS   GS     SHR  TRP  AFOB  ABRN

Apologies in advance for the scope creep as the initial query is already resolved.

Hi, yes it should. For example, given the following route:

KJFK/22R DCT BETTE DCT ACK DCT TUSKY N261A JOOPY DCT NETKI DCT BOFUM Q37 MALUD Q38 NUGRA NUGR1H EGLL/27L
AWY                           FL   IMT   MN    WIND  OAT  EFOB  PBRN
POSITION    LAT      EET ETO MORA  ITT  TAS    COMP  TDV
IDENT       LONG    TTLT ATO DIS  RDIS   GS     SHR  TRP  AFOB  ABRN
FREQ
--------------------------------------------------------------------
N261A                        370   077  .85 293/071  M57  23.1  13.1
JOOPY       N4830.0 0033 ...  20   059  485    P038  P00
JOOPY      W05200.0 0203 ... 276  2011  523       4  384  ....  ....

                             390   108  .85 257/032  M48  19.4  16.7
ETOPS       N5122.9 0045 ...  37   102  496    P030  P09
ENTRY      W04305.4 0248 ... 385  1626  526       2  307  ....  ....

                             390   108  .85 257/032  M48  16.7  19.5
ETP1        N5303.0 0033 ...  37   102  496    P030  P09
           W03544.7 0321 ... 288  1338  526       2  307  ....  ....

SHANWICK OCEANIC FIR                                                
-EGGX       N5214.7 0017 ...
           W03000.0 0338 ... 195  1143

                             390   108  .85 257/032  M48  11.8  24.4
ETOPS       N5448.4 0042 ...  37   102  496    P030  P09
EXIT       W02111.7 0420 ... 328   815  526       2  307  ....  ....

DCT                          390   108  .85 257/032  M48   9.5  26.7
NETKI       N5500.0 0028 ...  37   102  496    P030  P09
NETKI      W01400.0 0448 ... 250   565  526       2  307  ....  ....

SHANNON FIR/UIR                                                     
-EISN       N5427.8 0012 ...
           W01054.8 0500 ... 111   454

DCT                          390   094  .85 248/085  M51   6.9  29.3
BOFUM       N5332.2 0022 ...  20   092  494    P068  P06
BOFUM      W00530.0 0522 ... 199   255  562       5  344  ....  ....

Best regards,

Thank you very much for this nice example!

For what it is worth the project that prompted my initial query is closer to completion. There are some very useful tools available already except I wanted to make one that is a bit more like the SimBrief website without having to open a browser while running a simulator. I’ll probably get a tablet eventually for that purpose, though I still like this idea and will continue developing it.

1 Like

This topic was automatically closed 2 days after the last reply. New replies are no longer allowed.