LOWI RTT/TULSI/UNKEN/OBEDI SID D136A Wpt

Navigation Data General non MSFS data
1

In the current nav data, and it’s been like this for a while, a wpt on the RTT/TULSI/UNKEN/OBEDI SID is coded (D136A) that does not exist in NavDataPro or the real data. The problem with this waypoint is that it messes up the path aircraft should take.

D136A is on the RTT3J or any other conventional climb out out of LOWI via RTT /TULSI/RTT/UNKEN/OBEDI). The track of the SID should be on radial 063 outbound of OEJ and when passing 9500ft DCT RTT

1086×760 629 KB

While the SID is graphically on Jeppesen’s and Austrocontrol’s chart drawn as passing RTT, that’s actually not true because you would only pass, if you have not yet crossed 9500ft. (https://eaip.austrocontrol.at/lo/220909/Charts/LOWI/LO_AD_2_LOWI_9-1_en.pdf)
What is weird about the current coding is that while there is a FA fix-to-altitude fix for the 9500ft, there is also a redundant course-to-fix to D136a resulting inconitnuing to fly on radial 063 of OEV, which is the opposite of what it should do, which would be turning to RTT. The results are unflyable turns for the mentioned SIDs to and after RTT if possible don’t read the chart, which is unofrtunately common.

As I said previously, this D136A does not exist in NavDataPro which has it coded the following way

SID:010,2,RTT3J,RW08, , , , ,    , ,   ,CI, , , , , ,      ,    ,    ,0780,    , ,     ,     ,10000, ,   ,    ,   , , , , , , , , ;
SID:020,2,RTT3J,RW08,RUM,LO,P,N,N   , ,   ,CF, ,KPT,ED,D, ,      ,0010,0010,0660,0020, ,     ,     ,     , ,   ,    ,   , , , , , , , , ;
SID:030,2,RTT3J,RW08,DOEJ,LO,P,C,E   , ,   ,TF, , , , , ,      ,    ,    ,    ,    ,+,04800,     ,     , ,   ,    ,   , , , , , , , , ;
SID:040,2,RTT3J,RW08,OEJ07,LO,P,C,E   , ,   ,TF, , , , , ,      ,    ,    ,    ,    ,+,06700,     ,     , ,   ,    ,   , , , , , , , , ;
SID:050,2,RTT3J,RW08,OEJ07,LO,P,C,E   , ,   ,FA, ,KPT,ED,D, ,      ,0010,0010,0640,    ,+,09500,     ,     , ,   ,    ,   , , , , , , , , ;
SID:070,2,RTT3J,RW08,RTT,LO,D,B,NE H,L,   ,DF, , , , , ,      ,    ,    ,    ,    , ,     ,     ,     , ,   ,    ,   , , , , , , , , ;

vs Navigraph

010,2,RTT3J,RW08,D245H,LO,P,C,E   , ,   ,DF
020,2,RTT3J,RW08,RUM,LO,P,N,E   , ,   ,TF, 
030,2,RTT3J,RW08,OEJ,LO,P,C,E   , ,   ,TF, 
040,2,RTT3J,RW08,D063G,LO,P,C,E   , ,   ,TF
050,2,RTT3J,RW08,D063G,LO,P,C,E   , ,   ,FA
060,2,RTT3J,RW08,D136A,LO,P,C,EY  , ,   ,CF
070,2,RTT3J,RW08,RTT,LO,D,B,E   ,L,   ,DF, 
080,2,RTT3J,RW08,RTT,LO,D,B,EE H,R,   ,HA,

Why is this coded, why is the DF leg required after the fix to altitude wpt is already included and can this be removed from the RTT climb outs and RTT3J SID?

Win 10, XP11/12/MSFS (supposedly also P3D and others)

2

Hi,
the codings between the different source provider are different and can´t be really compared against each other. The reason is, that it´s possible that some lines will be “corrected” manually and/or due specific regulations (coding rules) in each company. So, I can comment only on our data.

I have made a screenshot and have marked the two waypoints which you´re mentioned:

image
image1129×919 136 KB

Both charts, Jeppesen and the charts from the AIP, shows very clearly a left turn back to RTT. Therefore I can´t reproduce your comment that this is not true. When this is really the case, please inform Austro-Control about this mistake because our data are based on their data.

Anyway, there is no direct way between D7.0 OEJ (D063G) and RTT, you should follow heading 063 and continue to 9500ft, and thats important because 063 is south of the NDB and when you look on the MSA, this is an important altitude (at least south of RTT).

image
image1084×184 83.4 KB

Now the “course to fix” line to D136A (which is a PBD waypoint = RTT136/1 NM) is important and correct so far + the information that this fix must be reached at 9500 ft - after that the left turn to the RTT NDB and hold or continue.

The loop on the ND is an implementation issue or only a view issue, because RTT and the D136A waypoint are only 1 NM away and possible therefore the strange path. When you possible look on LittleNavMap, which are also using our data, you see the correct path:

image
image1736×1107 199 KB

So, I assume it´s more an internal view issue. I´m also pretty sure, that when you fly this, that this will be flown correctly but I can´t see any data issue.

Hope that helps,
Richard

3

Hi Richard,

While it is correct that the drawing by little nav map of what is intended matches more or less the graphical depiction of the chart, it does not actually represent the textual description of the SID or the graphical if you look closesely.
The wpt D136A is in no way or another mentioned in any document nor is passing RTT in any way a requirement. The turn has to happen when passing 9500ft (which is also a wpt in the nav data (of NavData pro, yours and real world databases), whether that is before or after RTT does not matter. The contiunous flight on the radial outbound is therefore not matching with the chart graphically or textually as the turn by your navdata does not happen when passing 9500ft but when passing D136A.

maybe you can explain why flying past RTT is required in this procedure, I don’t see a reason why it would be, nor a chart that would require a flypast regardless of altitude.

Regards,
Jakob

4

This is what it should look like (and would, if D136A would be removed)


from your LNM screenshot: a turn a 9500ft to RTT from the calcualted 9500ft pt as required by the SID

RTT3J

5

From the AIP Austria:

image
image1283×880 180 KB

I´m not sure, what you see here …
heading 063 and after that turn left to RTT NDB

image
image1323×613 39.2 KB

Also you read in the AIP "Calculation of the SIDs is based on an all engines operative minimum net climb gradient of 3.3% (205 ft per NM). When you fly the direct route between the airport to the RTT NDB you will see that you´re reaching a maximum of 5400 ft with this climb profile

This waypoint is a safety waypoint, either to be sure, that you really reach the 9500 ft in this area and secondly not to overshot in the german airspace. This waypoint is absolutely valid and correct.

If you don´t think so, please report this to Austro Control. Thanks for your help.

Cheers,
Richard

6

Hi Richard,

I fear we are talking past each other. I am in no way questioning the waypoint based upon reaching 9500ft to initiate the turn towards RTT. This is clearly correct and already in Navdata of all providers, as also shown in your LNM screenshot.

I am questioning a virtual waypoint (D136A) to whom no reference is made in any document that makes aircraft continue on radial 063 beyond 9500ft until passing RTT!

There is no reference to this and neither NavBlue nor NavData Pro nor others have this pseudo wpt included - not even Austrocontrol that you quote here although there is no mention of D136A or equivalent wpts in it.

Regards

7

… but it is coded from Jeppesen in this way. Every provider can create his own waypoints (according the ARINC standard naming conventions), when the provider feels it´s necessary for quality or safety reason. Not all waypoints (specially PBD or pseudo waypoints) are part of any AIP.

And again, please stop comparing the provider … all have their own coding standards but follow the ARINC424 standard rules - it´s like a dialect in a speech.

Cheers,
Richard

8

I feel the need to compare this to other providers point out that what has been programmed here is not following the SID and actively working against it and not realistic as in following the real procedure as intended by Austrocontrol.
And maybe this wpt configuration can be reocnsidered or reported to jeppesen?

9

No, because as I have now shown you in several answers this is a correct PBD waypoint and correct coded according the AIP Austria.

Cheers,
Richard

10

sorry Richard but you have in no ways done that. There is not a single reference (especially not in the AIP) to a mandatory flyby of RTT regardless of altitude. Every document you quote and show mandates a turn at 9500ft, regardless of the position in relation to RTT!
And while you dislike comparisons, every other navdata provider solves it without a mandatory flyby.

11

Last comment to this from my side:

image
image1338×619 40.2 KB

Read the yellow marked line again - you must follow the LOC OEJ 065/063 up to 9500 ft …

When you now look on your Lido chart, you see the D7 OEJ with 6700+ ft and a follow up altitude with 9500+ ft. Also you see the distance of 2 NM right? … that mean you need a climb rate of 1400 ft / NM … but what, when you can´t fly this climb rate due the aircraft type, the weight, weather conditions, … ?

Right, you need more than the 2 NM to reach this altitude constraint … so also on the LIDO chart - 6 NM to RTT NDB, that means you have in total 6 NM to reach the 9500+ ft what also means a climb rate of 460 ft / NM … both values are partly far away from the minimum climb rates 205/290 ft per NM what is the base of the calculation according the AIP (read my notes before).

In other words, the LIDO chart shows exactly the same pattern but LIDO expect the altitude earlier (before RTT NDB). Ok, now we calculate with the minimum climb rates according the AIP (from OEJ 7 on, its easier). In the AIP we have 205 ft / NM - now, when I start from OEJ 7 at 6700ft with a climb rate of 205 ft / NM, I need approx. 13.6 NM to reach it, right?

And now, look where you would be reach the altitude?

image
image1920×921 174 KB

Yes, behind RTT and thats exactly what the AIP chart shows, what the Jeppesen shows, (and also the LIDO chart). Both expect the point later and not before. The PBD waypoint D136A is a safety waypoint to be sure to reach the 9500 ft before the 13.6 NM, like as an “expedite climb to 9500ft”, when possible but that depends on the type of aircraft and on several other factors.

There is no difference in the charts and also not in the coding - the Jeppesen coding (also the charts) seems only more on the safer side because you get a few NM more to reach the altitude. The Lido coding (also the charts) expect, that you reach this altitude far before - but as I have shown now the reaching-altitude point is variable and can move forward as also backward and with this moving the flightpath will be changed.

There is no error in the data, nor in the charts - the Jeppesen coding is differ but absolutely correct according the AIP Austria.

Have a nice day
Richard

PS: and when I´m super accurate I must calculate with 290 ft / NM as a minimum because you must need this till OEJ 7 … and the distance is approx. 10 NM and thats nearly in the area of this D136A waypoint

image
image1528×746 231 KB

12

and this quote is exactly why I do not understand the reasoning for D136A because it contradicts it

RTT3J

You keep trying to explain to me that instead of turnign when passing 9500ft (which is what the text you conveniently highlited shows, and what I drew as red line) you turn at a pseudo wpt that noone uses and that is nowhere mentioned in any document but Navigraph NavData.

The result is that the left turn does not commence when passing 9500ft (whenever that may be!) but only when D136A is passed, which is not only not what the AIP says but is also wrong and unnecessary, as the 9500ft turn point is coded as “FA” hence moving dynamically depending on performance and adapting the turn, not? The whole purpose of the FA is destroyed by the mandatory fly by, making it completely useless!

While you are absolutely correct that by just climbing on the minimum gradient you will cross 9500ft after RTT, why does the FA point not allow for that sufficiently in your opinion, and why is everyone forced on an unnecessary detour by the SID that every addons struggles with?

13

Hi Richard,

It has been two days since your last reply and I’d hate for this topic to be closed, ignored and shrugged off.

As we have established, if only flying the min climb rate, a turn to RTT on radial 063 from OEV will happen after passing RTT. My question in regards to Navigraph’s current coding of the SID therefore is

  1. why is there a mandatory flyby of RTT regardless of altitude
  2. why is the fix to altitude not the only wpt outbound 7DME OEV prior to RTT
  3. why is there no fix to altitude after D136A to allow for a turn based on actually reaching 9500. The current coding would turn the plane right after D136A regardless of actually reaching 9500ft, which would by climbin with min gradient also not fulfill the SID’s requirements

Regards

14

… because Jeppesen has coded this in this way.

Cheers,
Richard

15

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