Tutorial: Approach Legtype Definitions and Attached Picture

[jvile]

Q: When are intersections used in FSX? Are intersections an alternative approach in the real world? Is there a benefit to intersecting the IF over an intersection?

Is there a way to include 2 transitions both originating from MRB but one through the intersection at BEEZY and the other through the IF at LAUGH?

kagazi

We normally add a T_Waypoint at every intersection. This is so a line will be drawn on the GPS receiver from MRB to BEEZY to LAUGH as a Transition. FSX uses Waypoints for all intersections if you open the map mode and take a look.

You cannot have 2 Transitions from a single NAVAID such as a VOR, NDB or Waypoint. When you request a Transition from ATC it will tell you cleared direct to MRB and that transition must go through BEEZY amd then to LAUGH. If you had 2 Transitions from MRB then ATC would get confused on which one you were requesting (MRB to BEEZY or MRB to LAUGH)

We can play a trick on FSX and add a T_WAYPOINT on top of the MRB VOR and name it MRB1. Now that named Transition would be MRB1 and could then go direct LAUGH and ATC understands you intentions.

 

[jvile]

I have added the new runway 01L/19R to KIAD to the ADE grid. I now have 3 01/19 runways listed in FSX under "GO TO" which each have a L/R,C. Since this is about adding approach code I did not show how to add a new runway.

I have also added a new ILS with LOCALIZER, GLIDE SLOPE and DME for runway 19R. When I added the ILS to RWY 19R I made sure I uncheck the box that said Create ILS Approach since I am manually adding it from the approach chart. I filled in the proper boxes such as

Name is CAT III
IDENT is IISU
Freq is 110.75
Has Glide Slope
Has DME
Uncheck Enable Back Course
Uncheck Create ILS Approach

Its time to add the T_Waypoints that we see on the approach chart. Before we add the T_Waypoints we need to condition the runway start location. In the following picture I have made sure the Start Location and the Runway Heading agree. I also slewed my Cess172 down the runway in topdown view mode to be sure the alignment was correct.

I took the time to align the small GS symbol (as per Google Earth) by tweaking its placement. I went to the other end of the runway and grab the DME Transmitter and brought it back to the threshold of 19R. I use a guideline (length reads ft.) to find .2 of a NM from the threshold and placed the DME based on the Approach chart and Google Earth. Added the IM for the CAT IIIb.

Now it is a simple matter of slewing the Cess 172 backwards. I ascended to 4000 ft and slewed backwards until the DME reads 16 NM. I am on freq 110.75 so you can see the ILS CDI needle is centered.

ADE is connected to FSX so I right click on the Grid of the Approach Mode and it allows me to select and add a T_Waypoint. I Typed in a NAME which is BEEZY.

When BEEZY added itself to the GRID it is not exacly at the same location of the airplane symbol. Highlight the T_WAYPOINT symbol and right click the mouse button. A list comes up so select "Move to Aircraft"

In the next picture you now see that the T_Waypoint is at the position of the aircraft

Now slew the plane forward and stop at 11.3 NM. Right click again on the approch mode Grid and select add T_Waypoint. Fill in the box which this one will be NAMED and LAUGH.

Once again highlite LAUGH and right click the mouse then "Move to Aircraft" Continue slewing forward to the correct DME and add CLAYY and MULKY

Writing the Approach code for the XML is next.

 

[jvile]

I would like to break down each section (legtype) we add so you can understand what each entry (attribute) is being used for.

We have our ILS (LOC + GS + DME) on the ADE GRID for RWY19R. I previously stated and it should now be understood that the ILS is owned by the runway in FSX. That means it only serves one purpose. The purpose is so a User Planes radio can recieve the ILS signals and then see the LOC, GS and DME on the aircraft panel.

The first thing we want to do is add what is called an Approach Header. You will see that the Approach Header has nothing to do with adding any lines to the GPS Receiver but it is more about what you hear from ATC when they are issuing vectors to final approach instructions.

We select from the Menu Approaches |Add Approach

A new screen pops up and allows us to edit the boxes

We edit the box so it is what the Chart says as per this picture

From the above picture, when I have the ILS listed for RWY 19R and the FAF as MULKY / IAF as LAUGH we then hit the add block.

That will place the Approach Header into our Tree Window like so.

I use the KIAD Approach chart to fill in some additional information. The Approach altitude feet is 2700 ft and the published missed approach altitude is 5000 ft as per the chart.

If I click on the Approach Leg IF statement I see that the information is already entered correctly in this picture.

If we were to save the .ade and compile, at this point ADE would generate a XML code that looks like the following. I will add some remarks to each of the lines of code.

<Approach type="ILS" <<<<<<------ What ATC says based on type approach listed
runway="19" <<<<<<------ What runway ATC says is the active for your arrival
designator="RIGHT" <<<<<------ What designator ATC says if one exist
suffix="0" <<<<<------- no suffix
gpsOverlay="FALSE" <<<<<------- no GPS overlay
fixType="TERMINAL_WAYPOINT" <<<<<<------ MULKY is a T_WAYPOINT
fixRegion="K6" <<<<------- Region code that KIAD is sitting in
fixIdent="MULKY" <<<<<------ The final approach fix that ATC is looking at (see Below)
altitude="2700.0F" <<<<<<------ ATC will tell you and the AI Plane what to descend to for the final approach
missedAltitude="5000.0F"> <<<<<----- What ATC assigns as the missed altitude if you or the AI Plane goes around
<ApproachLegs>
<Leg
type="IF"
fixType="TERMINAL_WAYPOINT"
fixRegion="K6"
fixIdent="LAUGH" <<<<<<< The Type Leg "IF" statement that ATC is working with (see below)
/>
</ApproachLegs>
</Approach>

There are 2 mandatory fixes that ATC is looking at which are the IF (Initial Fix LAUGH) and the FAF (Final Approach Fix MULKY). When ATC is vectoring you or the AI plane to final it is calculating a + - 30 degree offset heading from the TRUE runway heading. That means the intercept angle heading will always be 30 degrees either side the TRUE Heading (based on your direction to the aiport).

Ideally ATC is targeting a intercept to final approach between the IF and the FAF. However that also depends if you are the only one flying to the airport or if other AI Planes are flying to the airport. If you are the only one flying to the airport then be on your toes because ATC is going to vector you to intercept final just outside the FAF (MULKY). If 5 AI Planes are also landing then you the User are slotted into the string of arrivals and you may end up on final 25 NM from the runway at 2700 ft.

When any plane such as your plane or the AI plane reaches the FAF that is a triggering point for the Tower to say "you are cleared to land" first come first served. At that precise moment the Tower locks down the runway so no departures can takeoff. If another AI Plane overruns you it is now out of sequence since you crossed the FAF first. That AI plane will be told to go around since it is not in the correct slot.

The final point here is the Approach Header has to be there for any type approach you write. It is the instruction phase for all arrivals (except VFR flights which use different rules) that you hear ATC saying. The Approach Header has nothing to do with drawing any lines in the GPS receiver and those lines come from the next set of legtypes we will add plus the missed approach legtypes.

 

[scruffyduck]

This value must be something we can see so I will be asking Jon to find a place that the XML runway heading can be displayed from our SDE Application Engine.

It is the heading given for the runway in the runway properties dialog

 

[kagazi]

Jim: I performed the steps you mentioned above exactly, with the exception of adding in CLAYY. I simply did not think I needed it so I left it out of the T_waypoints for the approach. Should I go back and add it in? Is there a benefit to having it (other than making it more realistic?) beyond not being able to be vectored to it?

I also added a T_waypoint at the runway start location and called it RW19R. I've seen them at other runway start locations and wondered if it was required. I see you have left it off so it must not be a requirement.

The approach altitude you have used is 2,700 feet. I see that the chart indicates this altitude if you are vectored to the approach by the ATC. I took this to mean two things; first, the 2,700 feet is shown at CLAYY, and I thought this referred to being vectored to the glide path at CLAYY; second, does the term assigned refer to original assignment (vectors to final) or any assignment? The approach altitude I used in my case was 3,000. I can change this to 2,700.

Thanks for the explanation on true vs. magnetic. In my case I was using magnetic since I was copying what was already being shown at one of the parallel runways. I used magnetic throughout, but I've now gone back and changed all to true.

I like the idea of an MRB1 to go along with MRB. In reality the planes landing at KIAD are given a lot of leeway and I witness different types of intersections. I'm thinking CSN1 on the opposite end as well. In both cases, the "fake" VORs would transition to and intersect the IF. I have the real VORs intersecting the INTS at BEEZY and CINNA.

I have other questions but I will wait for the remainder of the exercise as the rest are beyond what you've shown here.

 

[jvile]

Jim: I performed the steps you mentioned above exactly, with the exception of adding in CLAYY. I simply did not think I needed it so I left it out of the T_waypoints for the approach. Should I go back and add it in? Is there a benefit to having it (other than making it more realistic?) beyond not being able to be vectored to it?

Kagazi

CLAYY is a option and ATC does not know anything about it. A Pilot can use it with the GPS receiver to check his descent altitude over CLAYY to be sure he/she is on Glidepath.

I also added a T_waypoint at the runway start location and called it RW19R. I've seen them at other runway start locations and wondered if it was required. I see you have left it off so it must not be a requirement.

We do not do that for a ILS approach. The approach must terminate at the runway which will be a CF leg. There are approaches you will learn about in the future that have what we call a MAP T_WAYPOINT which is a T_WAYPOINT that sits very close to the runway threshold. These T_Waypoints are for other type approaches like VOR's where the missed approach starts at the MAP T_Waypoint and not at the end (Runway threshold) of the ILS approach.

Approach altitude can be anything you want it to be. If you want to use 3000 ft that is fine but remember we are also writing a code for the AI Plane. The further back you push the "IF" T_WAYPOINT the higher the hardfloor can be. You could make BEEZY your "IF and MULKY the "FAF" which then you could use 4000 ft. As we move closer to the runway we lower the hardfloor. If I used CLAYY as the "IF" and MULKY as the "FAF" then I would need a 1700 ft hardfloor.

REMEMBER the User plane must always be below the Glide Slope when it intercepts it. Example, I could not use CLAYY as the "IF" and 4000 ft for the hardfloor. I would be way above the Glide Slope. Common sense and a 3 degree slope angle is what we work with. We want ATC to get us down to the hardfloor and that must be before the turn to final and below Glide Slope. If you see that ATC is telling you to intercept the final at 3000 ft and that is above Glide Slope lower it to 2700ft or use a different "IF" that is further back from MULKY.

Thanks for the explanation on true vs. magnetic. In my case I was using magnetic since I was copying what was already being shown at one of the parallel runways. I used magnetic throughout, but I've now gone back and changed all to true.

ALL LEGS are magnetic. The runway heading is TRUE degrees. The approach code uses both in different places. The way the approach mode is set up, if you have a choice in the box window it is probably magnetic and we default to that. If there is no choice such as runway heading it is True degrees.

Jon and I are working on a better way to get a more precise runway and start location heading which will be more precise. Presently we only go to the tenth position in the runway property window of ADE which is not enough for other code I will be explaining.

I like the idea of an MRB1 to go along with MRB. In reality the planes landing at KIAD are given a lot of leeway and I witness different types of intersections. I'm thinking CSN1 on the opposite end as well. In both cases, the "fake" VORs would transition to and intersect the IF. I have the real VORs intersecting the INTS at BEEZY and CINNA.

You can make up as many Transitions as you like and ATC in most cases will honor your request through the ATC window. There will be cases that the Transition will not show up when attached to a ILS but will always show if attached to a GPS or RNAV approach.

 

[jvile]

Everything we have done up to now has been for both the User Plane and the AI Plane. The Approach Header and the first "IF" leg statement in our Tree was mostly for the ATC Engine and the AI Plane Engine. All the rest of the legtypes that we now add are purely for the GPS line draw and the USER Plane.

It is a very simple task to add additional legtypes to our Airport Header so the lines will draw in the GPS receiver. Everything we need is on the 19R Approach chart from my above post.

In this picture we right click the mouse on the R19R:ILS which is the header and we see that we can add additional approach legs.

After selecting add approach leg a new window opens which allows me to pick from a list the CF type leg. I fill in the proper windows and the first CF leg is MULKY which starts our line draw in the GPS Reciever.

I click on the add button and the CF leg goes into the tree on the right side. I highlite the CF leg to see the property's. You will notice the line that was added to the black grid is red.

The Approach Mode Editor has a built in Fault Finder Error Mode. Whenever a line is red we mouse over the line and the tooltip (outline box is also red) will tell us what the Fault Error is. In the tooltip it tells us the Course is not correct.

In the property window I fix the Fault Error for both the Course and Distance. The Red line turns to a Magenta color. The tooltip outline box is no longer red and the Fault Error is no longer listed in the tooltip box.

I add another CF leg in the same manner but this time from the list of Fix Type I select runway

As per the next picture when I hit the add button the CF leg goes into the tree and I highlite it to check the properties. Once again I fix the Fault Error as per the tooltip which shows the correct course and distance.

At this point the line draw is finished for the approach phase in the GPS display. We now need to look at the published missed approach and transform the wording into a GPS graphical display.

The missed approach says,

Climb on runway heading to 800 ft.and then climbing right turn to 5000 ft via AML VOR Radial 270 degrees to OLIVR Intersection /AML 20 DME and hold, continue climbing to 5000 ft in the hold.

My first order of business is to place a Terminal Waypoint named OLIVR at the intersection (based on radial and distance) of AML, CSN and LDN VOR's. FS does not have this intersection listed with a Terminal Waypoint so we must add one. The easist way to add a Navaid fix to FS is to look up the Lat/Lon location. Using AirNav the OLIVR intersection location is listed as

Identifier: OLIVR
Name: OLIVR
Location: 38-53-14.630N 077-53-22.020W

In the next picture click the mouse anywhere on the black grid and a menu will display. Select Add Terminal Waypoint.

The Waypoint property window will now be displayed. Using the information we took from Airnav fill in the windows. In the Lat/Lon location window make sure you have selected Set Manual and copy/paste the location coodinates in the proper Lat/Lon windows. ADE understands many different types of Lat/Lon formats and will convert to decimal when we click on the OK box.

The OLIVR intersection has now been added per a Terminal Waypoint to the KIAD Airport Navaid Database and you will see it 20 NM's west of the AML VOR.

Now we are ready to add the missed approach legs to the Tree on the right side of the approach mode screen.

I highlight the approach header at the top and then right click the mouse so I can add a missed approach leg. I choose from the list a CA leg and select Add. This places the CA leg into the Tree so I can open the property window. I set the Mag course of the runway to 191.0 degrees and the 800 ft that I am climbing to.



Now I need to turn and intercept the 270 degree radial from AML. That will be done by choosing a VI Leg and adding the 270 degree value as seen in the next picture



Once we have intercepted the 270 degree radial from AML we need to go to OLIVR so that requires a CF leg. In the following picture I add the missed approach CF leg using OLIVR Terminal Waypoint and opened the CF property to check if everything is there. Mag Course to OLIVR is 270 so I add it to the Course Degree box.



Now we have one leg left to insert in the missed approach procedure. The holding pattern is at the OLIVR Intersection which we added a T_WAYPOINT for. We are going to hold in a right hand pattern on a 090 degree heading as per the chart. The leg type will be a HM leg which is a Manual Termination type Hold. In the properties I set the hold to be R (Right hand) on a 90 degree heading using a time of 1 minute.



Save the project .ade file and compile. Place the KIAD Airport bgl in a active scenery folder. We start FSX and Go To KIAD RWY 19R and open the approach page. On the approach page is our line draw from the approach chart. In this picture the plane is approaching from the south and must fly outbound then a 180 degree turn to intercept the line draw.

 

[kagazi]

Jim: Thank you for the time you took to put together the tutorial. The tutorial (more of a walkthrough) was excellent; I have come to appreciate the power of ADE's approach code writing capabilities. As a beginner (capital B) I was able to easily follow the steps AND it was fun doing so.

I completed both ILS approaches (1L-19R) with transitions and missed approaches. I'm now looking over the RNAV approach plates; I look forward to the challenge, but I hope you don't mind me asking questions should I get stuck.

kagazi

 

[glottis]

great stuff thank you Jim
and as kagazi said, more like a walkthrough.....
do you think this should be made a Sticky?

 

[buedi]

Best practise...

I have one fundemantal Question when it comes to creating Approaches. Thanks to the explanations of Jim I now know that when creating Approaches you have to be VERY exact.
Luckily I have Charts and PDFs from Eurocontrol which list all Waypoints and Navaids with their exact geographical position. I now created them by entering the Lon / Lat values but then realized that my Airport is not aligned properly. I am working on EDJA and started with the Stock FSX Airport. One solution could be that I will just enter the Coordinates of the ARP, which should move my Airport to the correct location (I have the Airport location in Charts too). But then I see in the ADE Documentation that moving the ARP is not supported / recommended (or is this outdated?).

What is the best practise here? Would you move the Airport (when not within ADE, maybe in the XML?) or should I just align all the Waypoints as Jim describes by slewing the Airplane? Having the coordinates of all Waypoints is a good opportunity... if only the Airport would be in the correct position.
What do you think?

 

[jvile]

Many airports in the database are off by a degree or two. T_Waypoints that align with a runway you should use the slew method because they must be very accurate (in line with the runway).

Other T_Waypoints that are used for missed approach and Transitions I use the coordinates since their placement can be off a slight amount and it is not noticable. In some cases you will encounter a mag heading difference of 1 to 2 degrees but then again the entire world of FSX is not precise based on the Lat/Lon (close but not precise).

 

[buedi]

Thanks for your Reply. I will use the Slew method then for the one and only Waypoint in the ILS Approach to EDJA. For the others I will use the coordinates. I think I will have to follow your explanations a bit further and play around more until I get the ILS Approach of EDJA done since most of the Information on the Chart depends on DMEs and not on Waypoints. It´s such a small Airport and such a weird (for me) approach. I am sure with your Tutorials and my patience p) I will get it done... some time.

One question: In the Approach Charts of EDJA one of the two possible IAF is a DME. But since it´s a DME of a nearby Airport it is not included in my EDJA Airport in ADE. If I add it to my Airport I could use it as IAF in my ADE File. But then in FSX it would be double, or maybe moved a bit (depends on where it is located at the Airport where it belongs to). Should I just add a "fake" Waypoint instead and define it as IAF. But then I will have a Waypoint in my GPS which does not exist in Reality.

 

[scott967]

Jim: I performed the steps you mentioned above exactly, with the exception of adding in CLAYY. I simply did not think I needed it so I left it out of the T_waypoints for the approach. Should I go back and add it in? Is there a benefit to having it (other than making it more realistic?) beyond not being able to be vectored to it?

This approach can be used as either an ILS approach or a Localizer+DME approach. Assuming you also create the Localizer+DME approach, You would want to include CLAYY since a pilot would need to pass that point prior to descending below 2700F. Of course, if you do the Localizer+DME, you have to take account of the unnamed point that is shown as DME 1.0 from I-ISU on the profile view, but I think Jim promised to do that later .

The FAA allows a pilot with a properly installed and certified GPS to use the GPS "in lieu of" the DME, so the proper placement of the step-down fixes is important for a GPS user.

Also, FSX knows about the runway threshold point without having to create a T_Waypoint for it, It will always be formed as RWnna where nn is the two-digit runway number and a is the optional L/C/R designator.

scott s.
.

 

[kagazi]

Thanks Scott; I went back and added CLAYY after Jim's explanation. I also added ALL T_WPs on the opposite end. I figured better to have too much information in the event I ever needed to modify in the future.

When I get the chance I'm going to finish the RNAV (GPS) approach for 1L-19R.

I'm not sure how to begin the LOC/DME...I find the learning curve to be steep when it comes to writing approaches. It probably also helps to be a pilot (or have some experience with navigational charts etc.).

 

[scott967]

the RNAV approaches tend to be pretty straight forward, because the legs are TF and all the fixes/waypoints are named. But there are some special RNAV approach procedures with qualifiers such as RNP and SAAR and these often require RF legs which FS can't do (at least easily).

scott s.
.

 

[jvile]

Should I just add a "fake" Waypoint instead and define it as IAF. But then I will have a Waypoint in my GPS which does not exist in Reality.

buedi

This is eactly what FSX also does. They make up fake T_Waypoints which in reality are called conditoinal T_Waypoints since the line draw must work from a T_Waypoint. A Conditional T_Waypoint is unnamed and you see them as a 2 letter /number like IF13, FA13 or EH613, etc. throughout the FSX approach world.

If the "IF" is a DME value then place a conditional T_Waypoint. The "IF" T_Waypoint can be off center of the runway centerline a small degree. The FAF T_Waypoint must always be on center of the runway. I have even used my intials like JV314 as a conditional T_Waypoint.

 

[jvile]

kagazi

RNAV approaches are mainly Transitions off a STAR arrival.

Some RNAV's such as what I wrote for my FSX KATL are also GPS overlays as per the approach charts. My FSX KATL (AVSIM) readme describes how to file a FP by way of the STAR arrival and then get ATC to vector your plane to the RNAV arrival which then leads you to the "IF" of a ILS.

Use the GPS receiver to view the RNAV's for each airport.

 

[kagazi]

Thanks Jim, I will look at your EHAM, which I conveniently have located on my hard drive

I did attempt to finish the RNAV last night. Hard to say if I am completely correct/successful as it required me to add COCAV, PRISM, HIMRA, MULRR, SHNON and DRUZZ. I used http://www.globalair.com/airport/airspace_fix.aspx?letter=C to place them using the lat/lon given. May not be that accurate but I recall you saying that only the FAF, IF and possibly the IAF on the ILS beam needed to be precise to line the aircraft up with the runway.

I treated each of these at T_waypoints

I added a lot of transitions to 19R according to the charts I find more transitions/choices keeps the flying exciting.

I also added the missed approaches to each (olivr and MRB). For Olivr I used: CA, DF, VI, CF and HM. For MRB I used: CA, DF, VI, CF, VI, CF and HM. HM at Olivr was a R at 92 deg 4nm dist. and HM at MRB was L 292 deg 4nm dist.

They look correct on the GPS display. I flew the missed to Olivr and it worked. I was correctly vectored by ATC and the autopilot correctly followed the course. I still need to test MRB missed.

Jim: I used the RNAV examples at the parallel runways but I noticed that the transitions can begin with an IF statement. I used a header w/TF, TF, CF and in two cases header w/TF, TF, TF, CF. When would you begin with an "IF" in the transition?

By the way, the diagrams and definitions were a great help!

kagazi

 

[jvile]

Thanks Jim, I will look at your EHAM, which I conveniently have located on my hard drive

I did attempt to finish the RNAV last night. Hard to say if I am completely correct/successful as it required me to add COCAV, PRISM, HIMRA, MULRR, SHNON and DRUZZ. I used http://www.globalair.com/airport/airspace_fix.aspx?letter=C to place them using the lat/lon given. May not be that accurate but I recall you saying that only the FAF, IF and possibly the IAF on the ILS beam needed to be precise to line the aircraft up with the runway.

I treated each of these at T_waypoints

I added a lot of transitions to 19R according to the charts I find more transitions/choices keeps the flying exciting.

I also added the missed approaches to each (olivr and MRB). For Olivr I used: CA, DF, VI, CF and HM. For MRB I used: CA, DF, VI, CF, VI, CF and HM. HM at Olivr was a R at 92 deg 4nm dist. and HM at MRB was L 292 deg 4nm dist.

They look correct on the GPS display. I flew the missed to Olivr and it worked. I was correctly vectored by ATC and the autopilot correctly followed the course. I still need to test MRB missed.

Jim: I used the RNAV examples at the parallel runways but I noticed that the transitions can begin with an IF statement. I used a header w/TF, TF, CF and in two cases header w/TF, TF, TF, CF. When would you begin with an "IF" in the transition?

By the way, the diagrams and definitions were a great help!

kagazi

Most all Transitions are in fact T_Waypoints which means the airport owns the T_Waypoint and not the enroute database. In some cases as you will see with my EHAM that RIVER, ARTIP and SUGOL are all WAYPOINTS (enroute airways) which is also used as the IF of the Transition.

The nice thing about a missed approach is you can use many combinations of legtypes to get the same type leg draw. Be careful with a DF then a VI which when you load the approach in the GPS reciever you will get complete circles that should not be there.

When writing a RNAV I think you are complicating the leg types. A Transition ends at the IAF of a ILS. It is important to understand that the ILS is the fundamental approach code. Once it is in place any Transition ends at the IAF of the ILS. If I write the MRB Transition to RWY 19R ILS it simply looks like this

<Transition
transitionType="FULL"
fixType="VOR"
fixRegion="K6"
fixIdent="MRB"
altitude="4000.000F">

<TransitionLegs>
<Leg type="IF"
fixType="VOR"
fixIdent="MRB"
fixRegion="K6"
theta="0.00"
rho="0.00" />

<Leg type="TF"
fixType="TERMINAL_WAYPOINT"
fixRegion="K6"
fixIdent="BEEZY"
flyOver="FALSE"
theta="0.00"
rho="0.00"
magneticCourse="123.0"
altitudeDescriptor="+"
altitude1="4000.00F" />

<Leg type="TF"
fixType="TERMINAL_WAYPOINT"
fixRegion="K6"
fixIdent="LAUGH"
flyOver="FALSE"
theta="0.0"
rho="0.00"
magneticCourse="191.0"
altitudeDescriptor="+"
altitude1="3000.00F" />
</TransitionLegs>
</Transition>

What I have done is create the Approach Header so I can request the MRB Transition from ATC and they will honor it and tell me to fly direct MRB

Now I add the first "IF" which is a repeat of the airport header for the line draw.

The next leg is a "TF to BEEZY.

The next leg is a "TF" to LAUGH

At this point you already have the legs drawn from LAUGH to the runway for the ILS. You always end your Transition at the IF or IAF of the foundation approach. The internal code of the GPS Engine will attach the final TF leg of LAUGH to the rest of the line draw for the ILS.

You do the same when writing a RNAV approach. Write the approach just like you did for a ILS but use IF / TF legtypes. In some cases the RNAV approach will use the same T_Waypoints and missed approach as the ILS and in some cases you may need to add additional T_WAYPOINTs just for the RNAV.

Now add Transitions and attach them to the IAF of your RNAV approach. You do not have to write any further (my above example) since the Transition ends at the RNAV runway approach which is your IAF.

 

[kagazi]

Jim: Thanks for this explanation. I reviewed your EHAM file and realized what you have explained here. I did notice that in your EHAM approach for RW06 (the one I examined), there were TF T_Waypoint calls in the transitions that were missing in the list (and on the grid). Was this intentional? Are they located on another grid?

If I understood you correctly and for my approach to 19R, the IF is Laugh and the IAF is BEEZY; therefore, my transitions (ALL) should simply end with a TF at either the IF OR IAF. This would certainly simplify things.

I've noticed that FSX is very forgiving, which is a good thing.

When I first coded the missed at 19R I had a circle at the center of 19R When I reviewed the approach I realized that I was missing the heading with DF. By including the heading the circle disappeared.