Navigraph and simbrief data vs aip

Hello,

I hope that I’m posting in the right channel.

I just noticed an error with the route calculated by simbiref.
The flight is from LOWW to LFSB with the below route :
SOVIL DCT SITNI DCT BAGSI DCT MATIG DCT TRAUN DCT KONIN L856 AKABI UZ613 TRA T718 RIGVI

Accroding to the navigraph data the L856 is limited to FL120

But on the AIP side we can see FL660.

  1. https://aip.dfs.de/basicIFR/2022JUN16/pages/7FDB9A512F2A0206F48112286CA2D908.html

  2. https://aip.dfs.de/basicIFR/2022JUN16/pages/53CD7360C9D428E00A52437CBE41E8C8.html

Therefore, simbrief impose to be at level FL120 at KONIN and again to climb to FL380 at AKABI that cause a yoyo error on the IFPS.

However, with no change level, the IFPS passed with no error accordingly to the data published on the AIP.

Someone could explain me what’s going on here ?

This is an ongoing problem where the available FL’s depend upon direction of flight and the Jeppesen/Navigraph data imposes the lower restriction both ways.

From the AIP for L856:

  1. From KPT to TRAUN eastbound only
    available below FL125. 2. Between KPT
    and MANAL, flights at FL100 or below have
    to expect rerouting by ATC during times of
    activity within ED-R 141.

Personally I believe it would be better to implement the higher altitude, a restriction could then be imposed, at least in PFPX. Of course split availability would be the correct course of action.

EDIT: Looking back issue first raised in 2015

1 Like

Maybe we could dissociate the direction of flight by two distinct routes ?
Implement the higher altitude will cause simbrief to choose a FL >125 when flying eastbound, isn’t ?

1 Like

Hi,

I think the root cause is the ARINC data format doesn’t support different max altitudes depending on direction of flight. So when Jeppesen produces the ARINC records, they have to choose 1 maximum altitude to use. I’m sure they have their reasons for choosing the lower altitude versus the higher one.

There might not be anything we can do about this, but we are looking into it. SimBrief already ignores certain maximum altitudes when it’s obvious they are incorrect (for example, if the airway minimum is higher than the maximum, which happens in a lot of these cases). But it doesn’t catch this one unfortunately.

I’ve added a manual correction for this route at least (which should also affect similar routes), so it should be better now.

Best regards,

1 Like

Thank you for those comments and your input !

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