SIDs and STARs in FlightGear

[hladas94]

Hi,
simple question - how can I add SIDs and STARs to FlightGear? Is it even possible?

If it is, where can I download the AIRAC or how can I convert it for FlightGear?



Thanks,
Jimmy

[Tuxklok]

I assume you mean how to add them to the route manager? This is not something currently supported by the route manager, but is something being worked towards I believe. For now you'll need to download and read the SID/STAR charts and add the way points to the route manager yourself. Charts are available from many places online, such as airnav, skyvector, flightaware for USA...and can get high quality up to date European charts over at eurocontrol website but you'll need to register for free first. The route manager can save and load way points from a file as well, so you can save those SID/STAR way points and reload them later for convenience.

If your interested in an aircraft that has a more realistic FMS/FMC actually capable of loading and using SID/STAR have a look at the A380. It is the only FGFS aircraft I know of that has one currently.

cheers!

[Gijs]

As of Git/2.2.0 the route manager will support SIDs and STARs. You can download the files from http://www.navdata.at, then save it under Scenery/Airports/I/C/A/ICAO.procedures.xml (use the correct ICAO codes!). Next time you can load them through the route manager interface.

But, as said. This does NOT work with FG 2.0 or older AFAIK.

[HHS]

Don't work for me here with latest GIT....

[hladas94]

Got it!

It took me a quite longer while to find the xml files... But finally got it working!

Thanks a lot!

Just pick out the state you want, here is the link: http://www.navdata.at/php/sidstar/dl_states.php?addon=LDS767&state=United%20States

[redneck]

If we can use SIDs and STARs formatted for the Level-D 767, does that mean we can use entire flight plans downloaded off of www.simroutes.com for the Level-D 767 as well?

[HHS]

Indeed- the files for the Level767 works!

[redneck]

Oh sweet! I better create a folder just for routes, instead of dropping everything in FGROOT.

[Sealbhach]

, then save it under Scenery/Airports/I/C/A/ICAO.procedures.xml (use the correct ICAO codes!). .

So for EDDF that would be

Scenery/Airports/E/D/D/EDDF.procedures.xml

is that right?

.

[redneck]

Actually, it seems the plans on simroutes, even though they are also for the Level-D 767, do NOT work with FG. Oh well. So much for laziness. But I'll try out those SIDs and STARs.

Hmm, seems I'm missing some folders for the airports. Maybe I need to move up to one of the newer developer snapshots.

[HHS]

, then save it under Scenery/Airports/I/C/A/ICAO.procedures.xml (use the correct ICAO codes!). .

So for EDDF that would be

Scenery/Airports/E/D/D/EDDF.procedures.xml

is that right?

.

Correct!

[HHS]

@edneck: SID/STAR's are working, simroutes I never tried.

Now the aircraft developer needs to make use of the speeds given in SID/STAR as well!

[zakalawe]

Just noticed this thread, apologies. The XML loading code currently supports only the level-D 767 format, and all my test files were taken from the free-to-use navdata.at site - I didn't know about simroutes. If the simroutes files don't work, it's probably quite easy to fix (in C++) - unless there is something 'else' going on (I had some problems with our XML code not supporting certain XML character encodings, with some of the files from navdata.at use, for example). Can someone point me at some example Level-D files that don't work, and I'll see what's going on?

If you have a good, free, source of digital procedure data, in a documented format, then writing a loader is pretty easy - I only picked the Level-D 767 format because it was the clearest of those on navdata.at, and I wanted to get something working quickly! There's no problem to support multiple formats, just takes more time and coding.

[redneck]

Well, for one thing, the routes are formatted in like a CSV format rather than XML. That's the problem I'm seeing. I'm sure if we had something that could read a route file, determine its format, and then rewrite it into the correct XML format, we'd be all set.

[Tuxklok]

If you have a good, free, source of digital procedure data, in a documented format, then writing a loader is pretty easy - I only picked the Level-D 767 format because it was the clearest of those on navdata.at, and I wanted to get something working quickly! There's no problem to support multiple formats, just takes more time and coding.

Would almost certainly be better to focus on one format and make that the standard for fgfs, rather than chasing after multiple formats and trying to keep them all in sync and functionally equivalent. Whether that be Level-D, some other existing format, or something we created just for fgfs doesn't really matter I guess...as long as there are no copyright or license issues involved with using it and/or distributing the files.

cheers!