questions about adding waypoints, magvar and stuff (2024)

Hi all,

I would like to add new waypoints and terminal waypoints to the FSX navaid database. If that worked, I would go ahead and update approaches and might even add STARs.

In the process I'm running into many questions which I can't find answers for...

1.
How does your tool ADE scan the stock scenery for airports?
I might need that to get the airport definition to create terminal waypoints.

2.
Why does bgl2xml recalculate Feet to Meter for the approach altitude legs? If I compile the decompiled xml to bgl again, there might be a rounding error.

3.
I have current airac sources (EAD/SDO) for enroute intersections but it is missing the waypointRegion and the magnetic variation.

How can I aquire or calculate these values for a given position(lat/lon)?

I read about accessing the magvar.bgl for the magvar, but don't know how to do it.
Is the magvar value important for a enroute or terminal waypoint anyway?

Where can I find a definition for the FSX waypointRegion?

Thanks for any answers.

cu,
Stefan

I would like to add new waypoints and terminal waypoints to the FSX navaid database. If that worked, I would go ahead and update approaches and might even add STARs.

Click to expand...

We have been adding WAYPOINTS and TERMINAL_WAYPOINTS to the FSX database since FS9 was released. ADE does not do anything more then what the SDK has always allowed. Rather then place the WAYPOINTS and TERMINAL_WAYPOINTS in a XML by hand and compile, ADE does the TERMINAL_WAYPOINTS for us. To add WAYPOINTS to the FSX database you still have to do it with a hand written XML and compile.

FS9/FSX has never honored a STAR arrival at the Terminal Arrival environment. ATC and the GPS receiver only work for arrivals once you are being controlled by the ATC Approach Controller. The handoff to the Approach Controller coincides with what is available as per the popup ATC window.

STAR arrivals have to be embedded into the Flight Plan environment because the visual zone of any airport is a maximum of 108 NM's.

How does your tool ADE scan the stock scenery for airports?
I might need that to get the airport definition to create terminal waypoints.

Click to expand...

T_Waypoints are navaid fixes that are based on a Lat/Lon. They do nest in the airport records which means the airport owns them. When adding T_Waypoints you first must have the proper approach chart for a runway and then the airport that owns the runway. Now you place the T_Waypoint as per the Lat/Lon and nest it inside the airport elements of the XML.

Why does bgl2xml recalculate Feet to Meter for the approach altitude legs? If I compile the decompiled xml to bgl again, there might be a rounding error.

Click to expand...

I would have to ask why are you decompiling a ADE airport then compiling it back again. ADE is designed to work with a master .ade file unlike AFX or FSXP. There are many reasons why we work with a master .ade and a ADE airport should not require a decompile and then a compile back to a bgl. There is also no reason to use bgl2xml on a ADE airport. If by chance you need to look at the XML of any airport we have options that create a XML for you.

I have current airac sources (EAD/SDO) for enroute intersections but it is missing the waypointRegion and the magnetic variation.

Click to expand...

AIRAC is not a world standard and has nothing to do with the ARINC 424 standard that FSX elected to use which is based on the Jeppesen charting system and Rockwell Collins FMC Navigational Computers.

Is the magvar value important for a enroute or terminal waypoint anyway?

Click to expand...

FS9/FSX does not use the mag value in any type waypoint. Region codes are needed as per ARINC 424. Region codes are needed to specify a IF type leg fix so the line draw will show in the GPS receiver. FS gives us some data for Region Codes listed in the SDK.

There are list of WAYPOINTS compiled to a bgl such as the Airac010908.zip. The problem with these type Waypoint files is that they are all listed inside the FSdata tags and not the airport tags. That means they are all WAYPOINTS and duplicate many actual T_Waypoints as a WAYPOINT.

The Author of these AIRAC files try to force Waypoint existance into the ARINC 424 standard FS Navaid database and it just does not work.

ADE works with ARINC 424 which is the SDK compiler standard. You cannot force a non-standard navigational system like AIRAC into the database of FS9/FSX.

ADE is free. We have an approach mode that updates the world standard ARINC 424 for free. The ARINC 424 type database in FSX is free when you purchased FSX. The updating of the approach code in the world standard ARINC 424 is free.

How much of AIRAC is free to the users.

Hi Jim,

Sorry for my late response...

First I wanna thank you for answering my questions, it made some things more clear to me. On the other hand, I probably should have made myself more clear, I think you misunderstood me partly.

jvile said:

ATC and the GPS receiver only work for arrivals once you are being controlled by the ATC Approach Controller. The handoff to the Approach Controller coincides with what is available as per the popup ATC window.

Click to expand...

My update of the stock fsx navaid database to a more current level is directly intended for users of online flying networks like Vatsim. So the buildin ATC is not a big concern to me.

I know it is to scenery builder, and therefore for scenery tool developers.

STAR arrivals have to be embedded into the Flight Plan environment because the visual zone of any airport is a maximum of 108 NM's.

Click to expand...

I didn't run into this limit in my tests so far. So you suggests that this wouldn't work in the approach mode of the GPS?

I would have to ask why are you decompiling a ADE airport then compiling it back again.

Click to expand...

As I mentioned above, I never indended that.
I was toying with ADE merely to explore the bglcomp xml format. However, I tried to access the aproach editor, but couldn't find it actually. Could you give me hint?

AIRAC is not a world standard and has nothing to do with the ARINC 424 standard that FSX elected to use which is based on the Jeppesen charting system and Rockwell Collins FMC Navigational Computers.

Click to expand...

Thanks, I didn't know that. Anyway I used the term AIRAC only as a mean for a timeline (cycle). I have never seen real AIRAC or ARINC424 data anyway.

The Author of these AIRAC files try to force Waypoint existance into the ARINC 424 standard FS Navaid database and it just does not work.

Click to expand...

I know, and there are many duplicate and wrong waypoints in that GPS-Update.

How much of AIRAC is free to the users.

Click to expand...

Neither AIRAC or ARINC424 are free, but there are "affordable" AIRAC Cycles available for some FSX/FS9 Addon Aircrafts at navigraph.com. If you can point me to a "affordable" up-to-date ARINC424 source, I would be more than happy.

Thanks again for your post.

cu

Hi,

scruffyduck said:

The Approach Editor in ADE is present in version 1.39. This is a beta version available via this forum.

Click to expand...

Thanks for the info, found it. I like the tutorials, really helpful.

The adding approach tutorial raised a question, you added terminal waypoints like if18n or ff18n. I have seen other terminal waypoints refering to a runway like CQ27 etc.

Is there any standard or document about the naming scheme of these type of waypoints?

cu,
Stefan

teite said:

Hi,

Thanks for the info, found it. I like the tutorials, really helpful.

The adding approach tutorial raised a question, you added terminal waypoints like if18n or ff18n. I have seen other terminal waypoints refering to a runway like CQ27 etc.

Is there any standard or document about the naming scheme of these type of waypoints?

cu,
Stefan

Click to expand...

If the T_Waypoints you see resemble IF18N and FF18N then ADE used the Automated ILS approach mode when the ILS was added. There are 3 options when adding a ILS

1. No Approach code added for ATC
2. ADE adds T_WAYPOINTS and a fake type approach code so ATC understands the ILS exist
3. The Airport designer writes the ILS approach code based on current Approach Charts using the published IAF (IF) and FAF T_Waypoints.

Hi,

Apparantly I didn't make my point well again ... sorry english isn't my first language.

I was wondering how these approach related waypoints are defined. Its probably in the ARINC424, but i found quite a good explanation here:

http://www.flightsim.co.za/viewtopic.php?p=174954

Maybe it's useful for others too.

cu,
Stefan

Your link says

Not an expert, but there are essentially 2 kinds of waypoints: named
and unnamed. The named ones are easy. These are the 5 letter
pronounceable ones.

Click to expand...

That is not always true based on what Country you are flying in.

The following are all NAMED Terminal and waypoints for EHAM

waypointIdent="EH604">
waypointIdent="EH601">
waypointIdent="EH600">
waypointIdent="EH080">
waypointIdent="EH075">
waypointIdent="EH074">
waypointIdent="EH073">
waypointIdent="EH071">
waypointIdent="EH068">
waypointIdent="EH066">
waypointIdent="EH065">
waypointIdent="EH064">
waypointIdent="EH063">
waypointIdent="EH062">
waypointIdent="EH061">
waypointIdent="EH060">
waypointIdent="ROBIS">
waypointIdent="SONSA">
waypointIdent="NARSO">
waypointIdent="EH072">

The Approach chart tells you based on a symbol if the waypoint is named or unnamed not ARINC 424. When a waypoint is commissioned, studies are done to determine if the T_waypoint or waypoint gets defined as a named

Yeah I was wondering about that too.

So waypoints with the 5 letter name code (5LNC) and the other AAXYY/EH604 type (tactical waypoints?) are in fact NAMED waypoints.

Thanks for the clarification.

I found some useful documents about this topic here: http://www.ecacnav.com/content.asp?PageID=366

cu

Stefan

I have not studied much of the EUROCONTROL system since FS9/FSX decided on using Jeppesen and the AIRAC 424 specification as the main nav database.

It is really not important if a waypoint is named or unnamed since FS9/FSX does not use that data in the database. There are many parts of input to all the various FS Engines that are not used in the flyability of the simulator. Many parts of the XML are processed as XML but does nothing once it is handed over to the .dll files.

I can only assume that at one time ACES had plans to introduce a FMC that uses the data that is available in the complete nav database of FS. However, FS only extracts out of the total data available and what can be written in XML for just the GPS receiver, ATC and some AI plane control that is sent to that part of the simulator .dll's.

Hi,

Well, as fas as I know, you cannot define extra STARs or STAR legs to the approach. The user can choose a so called "transition" for an approach in the gps database, what to my opinion is misleading, as you can merely chose your initial approach fix.

I thought and tried, to hack the STAR incls transitions as a FSX-Approach Transition. The downside is, that you have to define all STARs which apply for the runway again in every approach all over.

cu

Bill

It depends on how the Country defines the term STAR. Many Country's that have small boundary's call a Transition a STAR arrival.

Here in the USA our STAR's normally start 250-350 NM's from the Airport. If we place the STAR toward the end of the FlightPlan then the GPS receiver and ATC honor the STAR. We also add the IAF of the Transition after the STAR which that is a full function of the GPS receiver and we couple that to the IF of the final approach course which again is part of the GPS receiver.

I write a lot of XML Transition approach code that can be called up in the GPS receiver and ask ATC through the popup window for the Transition. The approach phase of ATC will only show the available Transitions and not STAR arrival's. In most cases we have already missed the entrance to the STAR which would be under the Center Controllers command but the ATC window has no option for a STAR that far out.

You are correct the gps does read the encoded approach data and allows the simpilot to choose any of the available Transitions to the IF (intermediate fix) which then leads to the final approach course.

I have to test all the Transitions I write to be sure the IAF is still out in front of the plane when handed off to the FSX ATC Approach Controller (about 60NM's from airport). If by chance the user overflys the IAF of the Transition before the proper hand off time to Approach then we have a problem. If I ask Approach for the Transition I have already past it. ATC will clear me direct to the IAF which means a 180 turn must occur back to the fix and then another 180 degree turn to overfly the fix. Now ATC allows the Transition to the IF or IAF to be completed.

I have a small tutorial in my readme for the FSX KATL that I uploaded on AVSIM. It explains how to add a STAR arrival to the FP, the Transition and then final approach course that ATC understands with the use of the GPS. For my FSX KATL I rewote all the approach transitions to include the most current RNAV (GPS) approaches now in use at many airports. This gives the User Pilot the ability to file the FP with the STAR added and then ask Approach for the RNAV approach which then leads the user to the final approach course. "LOAD" and "ACTIVATE" will add the transition to the GPS which you know.

All of my FSX EHAM Transition approaches are also uploaded. I have the AI Planes flying the VORDME curved approach to rwy 24 while rwy 22 and the 18's are accepting AI Traffic also. For my FSX EHAM I also introduced the weight restriction runway code that FSX uses. Rwy 06/24 is a weight restriction runway and only AI /User planes that weight less then 76,000 lbs empty weight (aircraft.cfg) are told by ATC to use that runway for Dep and Arrival.

Since I am talking about what can be done that FS9/FSX did not do, my FSX KATL uses all 5 parallel runways simutanously which has never been done before. The most outer 2 runways are coded as weight restriction runways for dep's and arr's and the 3 inner parallel runways are used for much larger departures and arrivals. My EHAM is SP2 but my KATL needs a little update since it was designed under SP1a only.

After releasing my crosswind runway technique I went to work on finding the code for curved approaches. That led me to weight restriction runway usage and now multiple parallel runways in use. I have AI Planes flying what appears to be the STAR arrival from their entrance into the visual zone (108NM radius from airport) but have not released that in any of my airports yet. That code is not a slew mode like the seperation utilities but done by ATC commands.

One thing you find is the FAA charts might have a transition that starts at an IAF and goes to a common IF with other transitions. But there is also something they call a "feeder route" which starts at an Enroute fix or navaid. Some of these feeder routes look very much like what other countries use for STARs. I don't know any systematic way to look at FSX approaches, but I have looked at random airports around the world, and have yet to see a route on a chart labeled STAR that was coded as part of an approach. The closest was at EDDF which has a chart called "transition to final approach" which sort of looks like a STAR and is coded as transitions.

scott s.
.