[jvile]

"type=IF" Initial Fix or IF Leg. Defines a database fix as a point in space.

"type=TF" Track to a Fix or TF Leg. Defines a great circle track over ground between two known databases fixes.

"type=CF" Course to a Fix or CF Leg. Defines a specified course to a specific database fix.

"type=DF" Direct to a Fix or DF Leg. Defines an unspecified track starting from an undefined position to a specific database fix.

"type=FA" Fix to an Altitude or FA Leg. Defines a specified track over ground from a database fix to a specified altitude at an unspecified position.

"type=FC" Track from a Fix from a Distance or FC Leg. Defines a specified track over ground from a database fix for a specific distance. 

"type=FD" Track from a Fix to a DME Distance or FD Leg. Defines a specified track over ground from a database fix to a specific DME Distance which is from a specific database DME Navaid. 

"type=FM" From a Fix to a Manual termination or FM Leg. Defines a specified track over ground from a database fix until Manual termination of the leg.

"type=CA" Course to an Altitude or CA Leg. Defines a specified course to a specific altitude at an unspecified position.

"type=CD" Course to a DME Distance or CD Leg. Defines a specified course to a specific DME Distance which is from a specific database DME Navaid.

"type=CI" Course to an Intercept or CI Leg. Defines a specified course to intercept a subsequent leg

"type=CR" Course to a Radial termination or CR Leg. Defines a course to a specified Radial from a specific database VOR Navaid.

"type=RF" Constant Radius Arc or RF Leg. Defines a constant radius turn between two database fixes, lines tangent to the arc and a center fix.

Note: While the arc initial point, arc ending point and arc centerpoint are all available as database fixes, implementation of this leg type may not require them to be available as fixes.

"type=AF" Arc to a Fix or AF Leg. Defines a track over ground at specified constant distance from a database DME Navaid.

"type=VA" Heading to an Altitude termination or VA Leg. Defines a specified heading to a specific Altitude termination at an unspecified position.

"type=VD" Heading to a DME Distance termination or VD Leg. Defines a specified heading terminating at a specified DME Distance from a specific database DME Navaid.

"type=VI" Heading to an Intercept or VI Leg. Defines a specified heading to intercept the subsequent leg at an unspecified position.

"type=VM" Heading to a Manual termination or VM Leg. Defines a specified heading until a Manual termination.

"type=VR" Heading to a Radial termination or VR Leg. Defines a specified heading to a specified radial from a specific database VOR Navaid.

"type=PI" 045/180 Procedure Turn or PI Leg. Defines a course reversal starting at a specific database fix, includes Outbound Leg followed by a left or right turn and 180 degree course reversal to intercept the next leg. A Maximum excursion Time or
Distance is included as a data field.

"type=HF, HA, HM"  Holding in lieu of Procedure Turn (HF) for Approach Procedures and Mandatory Holds (HA, HM) in SID/STAR and Missed Approach coding. The HA, HF, and HM Leg Types define a holding pattern in lieu of procedure turn course reversal or a terminal procedure referenced mandatory holding pattern at a specified database fix. Leg time or distance is included as a data field. The three codes indicate different path termination types:

HF = Single circuit terminating at the fix.
HA = Altitude Termination
HM = Manual Termination.


Flyover Waypoint is used for the ending leg of all SID (DP), STAR and Approaches including the threshold of the runway if "TF, CF" is used

Not required in FS9   

RF legs do require the flyover leg for the arc in the VOR, VOR/DME, NDB, etc. type approaches   

Waypoint flyby/flyover requirements:

Setting Position Two of the Waypoint Description field to T or F indicates a Flyover Waypoint; the fix in the record is to be over flown before flying the next leg. Absence of the T or F indicates a Flyby Waypoint; turn anticipation may be used to acquire the next leg.

FS9 uses False as the default tag

The coding requirement of the Flyby or Flyover condition.
The RF leg overflys the terminating fix in all cases.
The RF Leg is to be used only in the following cases:
The CF leg is available as a leg type in RNAV Terminal Procedures only when specifically called out in the government source documentation. When this is the case, the leg data will include a reference from which the magnetic variation for use in flying the CF Leg can be determined. This reference will be provided in the Recommended Navaid field of the procedure record.

Hope this helps with the definitions

[Lupo]

Jim

Thanks for the further clarification with the legs. I'm looking at adding some GPS approaches to DSM so I'll probably have some questions when I get into it.

Thanks again
John

[Mark Cherry]

jzax said:

Regarding flyover/flyby, I think I read somewhere that the only flyover point (if any) should be the RW or the MAP if it is coded, but I do not remember where, although it was a real-life document. It works either way of course in FS2004. I was just curious if there was a real-life rule here.

I'm not sure if I can answer that question with full authority on real world procedures but you've helped me to resolve a mystery which has been bugging me for a while.

For anyone who prides themselves on their landing skills, the last thing one wants or expects to see when already preoccupied with executing short finals (under manual control) is the ATC window popping up and inviting you to "Report Go-around". It's an affront, as well as being a distraction. I usually manage to correct and pull off a decent landing. :D

You know that you've truly fluffed it when tower gives you the ground handoff before the nosewheel's even down and you have your hands full, trying to apply reversers and respond to ATC in a timely way, all at the same time. It means you've missed the runway centreline and ATC thinks you've departed the runway. In a way, you have...

Anyway, the mystery solved is that of the MAP criteria.
For that window to pop up, I must either have flown through the MAP with the right lateral accuracy but at the wrong altitude - either too high OR too low - or else I was displaced so far to one side (crosswind landing, say) that I failed to meet the overflight condition with the required level of precision.

This might be expressed as an anglular error (axis points vertically when you hit the mark) such that you might get +/- 3 miles tolerance when overflying a flightplan waypoint at FL370 but only 70 ft either side at 250ft AGL.

Actually, that's more like Inner Marker spec and I've not encountered many Cat III ILS approaches in FS9 (I must be flying to all the wrong places). Needless to say, a 70 ft lateral error with about 0.1 NM to make a correction and a runway more likely to be 150' wide than 200', means I'm in serious risk of putting wheels onto the grass. You can get away with this in the sim but a real plane would plough a trench, at best breaking off a main gear leg and at worst diggin in, slewing around and careering off the runway completely. Compulsory go-around territory.

More commonly, you will see the MAP indicated on the approach plate as being at the Middle Marker. It would be nice if we could get the AI to start their go-arounds from here, once the runway is regarded as "in use" (by an approach which has passed the FAF) instead of running down a slower plane first.

Usually, the approach plate will have two figures above the MM symbol, in the side view. One for altitude (MSL) and one for height (AGL). That might be the altitude info you are looking for. If you don't have a side view, you're missing half the chart.

I have another use for overflight of a fix, which I think I'll post separately.

Edit: On second thoughts, I'll start a new thread as it might open up some interesting developments. When I'm done, I'll cross-link it to this thread, which will be needed for context.

[Mark Cherry]

Hmm, I can't seem to get into my previous post to edit it a second time.

Here's the link to the thread I started.

http://discuss.proje...92308#msg392308

In brief, it asks to what extent STARs and transitions can be modified in order to manipulate the AI and form them into a single stream before they are fed to the ILS intercept points, instead of them merging in the final approach path itself. Could it be achieved by making the distances from various spawn points to a common assembly point the same regardless of which direction they arrive from and which end of the runway is active?

[jvile]

YES !!!!!

I have done this as a test and the AI Traffic are vectored to the entrance point of the STAR out close to the border of the visual zone (108NM) one by one in a seperation order.

The problem is the various approach speeds of the AI Planes which causes the 7 mile seperation of each plane to decrease/increase prior to the turn to final outside the FAF. 

I used the MACEY 2 arrival which is the busiest STAR in the world for the test (NE KATL sector arrival). the STAR starts about 400 miles away but AI spawn at 108 NM from the airport. Regardles of where the AI spawn as long as they are from the WNW, N, and ENE ATC vectors them upward to the entrance (transition)  point of the MACEY 2 arrival that I have coded to be about 85NM from the airport. If I code further out then that the AI can disappear because they go outside the 108NM radius when tuning back onto the arrival STAR.

The string of pearls (aircraft) is not limited to 5 or 6 seperation points but as many seperation points needed to place multiple planes on the STAR heading.

[Mark Cherry]

Hi Jim,

this is good news. Seems like I was on the money with this idea... only you got there first!! <chuckle>.

Now, if it could be arranged that the 'end point' of the STAR can be placed so it is a shorter distance from there to ILS intercept #2 or #3 than to #1, then the traffic emerging from the 'pipeline' will go there, then fly in a straight line down the ILS course for longer, which gives more time for speeds to stabilise. This is useful because it means that, if anything is going to overtake the plane in front at all, at least it will have a chance to reach the 6 mile point first. That means it will be cleared to land first and will actually be permitted to land, rather than be sent around. If the overtaken plane is lucky, the runway might just be clear for it to land as well by the time it arrives at the threshold.

Additionally, by feeding to intercept #2 or #3, this leaves #1 permanently free for go-arounds to be fed into, since we can't do anything about the go-around coding. Although jumping into the queue may still cause some disruption, I think that the plane currently on go-around has an increased chance of being given its landing clearance ahead of the queue behind it, so at least it lands on its second attempt and a different aircraft gets sent around, if at all.

[Mark Cherry]

jvile said:

Always use BGLX180 to extract the airport header and not BGLAnalyze. However you must use BGLAnalyze for all the approach data that you copy out of the APnnnnnnnn.bgl. BGLX180 corrupts the approach data area. But then again BGLAnanlyze drops some other leg info that is needed.

Jim,

I recently installed BGLX180, BGLAnalyze (3.1) and Cooktop 2.5.
I have also applied the corrections to bglcomp.xsd, recommended in the readme.htm file for BGLX180.

I decompiled an APnnnnnnn.bgl file with BGLX180 and browsed the results but have not attempted any editing as yet. The approach info I was interested in looked okay, at first glance, but I still heeded your warning about its results and will only use the header info it produced.

So, when I went to use BGLAnalyze to do the second extract, so I could compare the results, it failed to do so, with the somewhat self-contradictory message :-  "Error: Compressed BGL file, uncompression failed, file not compressed".

The readme.txt did say it was for decompiling files from FS98, FS2000 and FS2002, with no mention of ability to provide XML output.

What version number of BGLAnalyze do I need for FS9 sceneries, please?

[jzax]

It should be NewBglAnalyze version 1, available in www.scenery.org

[Mark Cherry]

Many thanks, jzax.

Link provided 'n all!

[jvile]

Just as a precaution

Always use BGLX180 for the airport header due to the additional ASCII character set it decompiles which helps attach the airport to the right region code.

Each decompiler leaves out certain data.

BGLX180 does not decompile any default taxiway signs or additional exclusions if added to a new xml compiled bgl. In the approach data it omits the very important "CF" type 2 digit approach code which follows the "IF" coding. This causes all the GPS reciever white lines to disappear after compiling with the BGLComp compiler. The BGLComp compiler does not always check to see if 2 digit type codes are missing but only error checks what is missing nested in a 2 digit type code or structure design. 

The BGLAnalyze decompiler leaves out optional element statements which in some cases can corrupt the GPS receiver lines. Another problem is it (BGLA) corrupts the taxiway signs if you bring the originals up to a newly written xml and compile with the BGLComplier.

I decompile with both utilities. I then use Cooktop to do a split screen with both xml showing. I like the way BGLX180 formats the xml vs the way BGLAnalyze does it. I add back to the BGLX180 what is missing because it actually decompiles more of the optional approach data then the BGLAnalyze program. I just copy and paste from BGLAnalyze to BGLX180 and the 2 main areas of concern are the "CF" type codes which are completly missing and the VI which misses some elements.

Missed approach portion

BGLAnalyze says
<Leg type="VI"
turnDirection="L"
magneticCourse="350.0"

BGLX says
<Leg type="VI"
magneticCourse="350.00" />

The "VI" is also different in the Transistion approaches so I copy overwrite from BGLA to BGLX

just a few examples

[Mark Cherry]

Lupo said:

       altitude1="887.00F"    <------should this be 50ft above rw alt?

John,

I'm working on a completely different airport but I also saw this 50ft discrepancy in the extracted xml.

I have a feeling that this is, in fact, procedurally correct for real-world flying. Recall how the "aiming point bars" are actually paintec a few hundred feet away from the line across the runway, defining where the threshold begins. Similar to the way that takeoff distances in an aircraft handbook are quoted in terms of "distance required to clear 50' obstacle", presumably, one is supposed to be in the habit of crossing the threshold at no lower than 50' because of things like approach lighting mounted on tall poles, to be overflown, other aircraft holding short in the vicinity, airport fencing and so on. If a plane needs every last foot of available landing length to det down safely, it shouldn't be landing there at all.

Coincidentally, I think 50 feet is also the minimum AGL to which planes certified to fly a Cat III ILS are permitted to descend before either going missed or proceeding with the landing, if visual. Look for "MDA(H)" on applicable approach charts.

I've queried the altitudeDescriptor code "A" in the other thread. For now, I'm going to assume it means "at altitude".

[Mark Cherry]

jvile said:

Quote

4) Is there in reality a difference between a "waypoint" and a "terminal_waypoint"? I can't identify as such in the LEMD approach charts either, is it just a gimmick of FS2004?

Yes. Lets talk Terminal_Waypoint first. Any blue triangle symbol (excluding VOR symbols) seen with the GPS receiver are Terminal_Waypoints. If you add a waypoint to LEMD or I add one to KMSP it looks like this

<Waypoint lat="44.6666442129399" lon="-93.1793528787232" waypointType="NAMED"
magvar="-1.70" waypointRegion="K3" waypointIdent="SSTAR" />

That is a Terminal_Waypoint and will show up as a blue triangle. Why? Because it was nested under the Airport Header in the xml Approach data file we are writting and it specifically is owned by that airport IDENT code (<Airport ident="KMSP") ONLY !!! That Terminal_Waypoint is only used by KMSP for some type of NAVdata and in my case is the IAF for ILS RWY 35 and it is not shared with other Airport IDENT's.

A Waypoint which is the pink triangles (using the GPS receiver for viewing) is a shared waypoint for NAVdata and is not embedded under the Airport Header. A Waypoint is fixRegion="xx" specific which means it is in another scenery folder other then the APnnnnnnnn.bgl and can be used as a NAVdata intersection for multiple airports in that same Region Code.

You will see the same thing for NDB's. Some NDB's are Terminal_NDB's nested to a Airport Ident such as a outer marker beacon for a airport runway.  When you open AFCAD and look at NDB properties, if the Terminal Box at the bottom is checked by default and a Airport Code is in the Box that Terminal_NDB is in the APnnnnnnn.bgl under the airport header. If the NDB is shared or used for navagating from one point to another then the property box at the bottom is blank/no checkmark and ghosted because it is in another scenery folder for shared purposes.

Think Terminal_Waypoint = Not Shared with other airports
Think Waypoint = Shared with other airports 
 
I have never used a Region Coded Waypoint and don't think we can make one. Everything we make are Terminal_waypoints. You would probably have to decompile the file that houses all the Waypoints and then add a new one and recompile. I have not even tried to see if the BGLCOMP compiler schema understands this.

There are a number of useful upshots to segregating certain waypoints away from the main database and into 'owned by Airport KXYZ' status.

1) The frame rate impact is probably very minimal but 50-plus airport waypoints is still code to be executed on each and every pass at that particular airport's scenery subroutines and data to be held in memory. Therefore, just like the ramps and buildings, they should only be loaded and executed when required - coming into 'detection range' range of an airport. Similarly, you want them unloaded from memory ASAP when you've flown past an airport whilst enroute to somewhere else.
Presumably, to make the GPS map scroll, calculations are having to be done repeatedly on every item with respect to  lat/long to place it in its correct location. If your frame rates ever get low enough, you may even see it halfway through the process of updating itself, individual items shuffling into place at slightly different moments. There has to be a CPU overhead to all of this. I use FSTerrain, which enhances the ground mesh of USA/Europe but somehow the extra detail, from the crinklyness of the mountain ranges to the shallowest of river cuts across a flat plain gets into the GPS terrain display (5nm zoom or smaller) complete with relief-shading effects! A lot of processing power must be going into that little window. That's why I keep it closed unless absolutely necessary.

2) It adds a level of filtering to the GPS display and overhead map. Zoom out from 1mile scale to 35mile scale while at an airport and note that some fixes disappear before others. At long range scales, terminal waypoints which would heavily clutter the view of the airport symbol and its associated VOR and/or NDB symbol disappear but the enroute waypoints remain. Zoom out another level and the fix names no longer display but the triangles do, another level still and the fixes are reduced to tiny white dots. By 100nm zoom level, they're gone completely.

3) An authorship issue. A single database containing "all fixes" would have sparked off endless time-wasting team meetings where notes were compared to ensure the person writing one set of approach data didn't inadvertently use a fix which, IRL, is used by traffic at a neighbouring airport and another writer had used it as well. That would have resulted in conflicts between AI/AI (triggering nuisance radio chatter when you want to acknowledge your approach vectors) and AI/User (some users insist on flying with all crash-detects ON). Having one person write one airport and 'owning' the relevant set of fixes prevents any confusion and removes the need to consult. Error generation when an approach code segment can't find a specified fix because it's nested elsewhere will prevent inappropriate usage by another programmer.

4) Terminal NDBs are low-power transmitters with relatively short reception range. Enroute aircraft at 450+kts, passing directly overhead will only get reception of a 25nm NDB for about 7 minutes - not much practical use. A plane at 200 knots, low level, attempting to pinpoint an airport hidden by total overcast will get a lot of use out of it. Lack of reception on the frequency is information in itself, so 25nm range isn't quite as useless as it sounds.

Fewer reception overlaps with nearby airports means fewer unique frequencies are required to service a geographical region. Unoccupied frequencies are hard to come by, these days and already I see that the NDB frequency range is being used for an extra TWR/GND/ATIS/INF channel at some sizeable airports. That sometimes involves audio broadcasts on the same freq as a working NDB - probably very useful to GA pilots who could only afford (cost and/or weight) single-channel comms equipment. (Not implemented in FS... yet!)

Therefore it makes sense to also wait to load these into memory until in the airport vicinity, just like the terminal_waypoints objects. With FS9 ATC being what it is, you will get your vectors to the destination long before the NDB gauge flickers into action, so it's only remaining practical use is in the final approach procedure itself, rather than in helping someone unfamiliar with the local geography to arrive in the airport environs.

Actually, that thought has made me nostalgic for the FS days when you were left to your own devices and could genuinely get yourself lost looking for some obscure airfield out in the wilderness regions. The best map you had was the page of an atlas at 1:10,000,000 scale and you might have remembered to printout that list of navaids you'd downloaded. No choice but to keep flicking through the frequencies until you got some kind of signal, then (unrealistically) call up a menu to see what its name was. There was a navaid range-boosting utility once, which was great if you wanted to pick up Shannon VOR from 300nm away (true to life) but was indiscriminate, changed all navaids in a bgl to your chosen setting and made the outback flying that bit too easy. ATC vectoring has totally taken the last of the challenge out of cross-country GA on instruments.

[Lupo]

Hi Mark,

Looks like you have a solid grasp on the Terminal_Waypoints vs Waypoints!

I'm working on adding a GPS approach to KDSM and I've found that value at about ten feet off rw alt on one end of rw13 and 52F off rw alt at the other end -- not sure about why but it definitely is above rw alt on all the approaches for KDSM.

What?s puzzling to me is why it?s not close to fifty on all the approaches, which would follow on crossing the threshold at least fifty feet above the runway.

And you are correct on ?at altitude? for altitudeDescriptor="A"


John

[Lupo]

Jim,

I found  recommendedRegion="K3" in the PI legs at DSM. I thought that was the only leg type it was in but I found a CF leg tonite that has that in it. Is it required and if so, when?

Thanks,
John

[jvile]

John

Early on in this thread I believe that altitude value came up but I confused it with something else. I will explain how that altitude value is calculated once I know we are talking about the same element value.

<Leg type="CF"
        fixType="RUNWAY"
        fixRegion="K7"
        fixIdent="RW07"
        flyOver="FALSE"
        theta="253.6"
        rho="3334.45"
        magneticCourse="74.0"
        distance="10373.85"
        altitudeDescriptor="A"
        altitude1="85.00F"  <-------------- I think you mean this one which is the last "CF" of a ILS approach to a runway.

In order to calculate that value and where MSN gets it from read the following.

CAUTION-
Avoid flying below the glide path to assure obstacle/terrain clearance is maintained.

The published glide slope threshold crossing height (TCH) DOES NOT represent the height of the actual glide path on-course indication above the runway threshold. It is used as a reference for planning purposes which represents the height above the runway threshold that an aircraft's glide slope antenna should be, if that aircraft remains on a trajectory formed by the four-mile-to-middle marker glidepath segment.

Pilots must be aware of the vertical height between the aircraft's glide slope antenna and the main gear in the landing configuration and, at the DH, plan to adjust the descent angle accordingly if the published TCH indicates the wheel crossing height over the runway threshold may not be satisfactory. Tests indicate a comfortable wheel crossing height is approximately 20 to 30 feet, depending on the type of aircraft.

NOTE-
The TCH for a runway is established based on several factors including the largest aircraft category that normally uses the runway, how airport layout effects the glide slope antenna placement, and terrain. A higher than optimum TCH, with the same glide path angle, may cause the aircraft to touch down further from the threshold if the trajectory of the approach is maintained until the flare. Pilots should consider the effect of a high TCH on the runway available for stopping the aircraft. 


John

Look on current published ILS Jepp Chart and you will see the TCH is usually around 50 to 55 ft.
Add the TCH value shown on the published apprach chart to the runway TDZE foot value.

Example from above

TCH for runway ILS 7 Cat II or III at KJAX is 55 ft.
The published TDZE is 30 feet.
Added together is 85.0 ft. which is the altitude value used in the last "CF" code for RWY ILS 7 in my example above which is also 85.0 ft.