Board index FlightGear Support Tools OpenRadar

Configuration of SIDs and STARs

OpenRadar is a standalone radar screen which connects to the FlightGear multiplayer servers. It is currently being developed.

Configuration of SIDs and STARs

Postby danielHL » Sun Nov 29, 2015 2:02 pm


I have a proposal for SID and STAR management in OR. I don't know if this goes a bit too far, but I would find it practical for the way I work with routes.

Would it be possible to get a fine grained control over which routes are displayed on the radar screen? Many Airports have various types of approaches or transitions available, depending on the time of day or aircraft type, congestion and everything. In the xml file we can already define a hierarchical structure of routes and give them names. In addition to the SID and STAR checkboxes for runways I sometimes wished for an additional route configuration button in the form of a tree like the routes are defined in xml. This way controllers could switch from showing normal STAR to more complex transitions if there is suddenly a lot of traffic.

t the moment I manage this by keeping entirely different sets of xml files, renaming them and reloading the config. I know this is a lot to ask and I would try it myself, but I'm really not a good programmer and the resulting spaghetti code would serve no one ;)

danielHL / GVA0387 / D-FMPW / (UA83DAN)
Posts: 54
Joined: Fri May 02, 2014 6:23 pm
Callsign: UA83DAN, GVA0387
Version: git
OS: Linux

Re: Configuration of SIDs and STARs

Postby wagnerw » Tue Dec 22, 2015 5:22 am

Sorry for the late reply, I am finalizing a maintenance version. I think about your proposal. And it is almost Christmas...

In general I am impressed how intensive you use the route feature. You must be working on a real complex airport. Could you please give me real world examples? I want to avoid misunderstandings. Maybe you can send me your xml files to see your problem by myself...?
Posts: 262
Joined: Tue Nov 06, 2012 8:35 pm
Callsign: D-W794

Re: Configuration of SIDs and STARs

Postby a-v-o » Wed Jan 20, 2016 1:17 pm

When I was creating routes from the charts I was also thinking about a more detailed way to switch routes on and off. There are already "hidden" switches in the xml-file: displayMode, activeStartRunways, activeLandingRunways.

How often do we use waiting loops. Actually it just happened one time to me that a pilot suggested to descend in a waiting loop. So most of the time, they can be switched off.
There are different charts e.g. for ILS or RNAV or transitions.
Within the 100 nm radius there are airways, which I want to switch on or off.

So I thought about an attribute "switches" in which the routes creator can define his own switches for his charts. The ATC then can switch these "layers" of routes on and off like the map layers (landmass, urban, lake, ...), instead of just "SID/STAR".
Code: Select all
<route name="HAM Waitloop" switches="STAR Waitloop">
<route name="STAR 33 ILS" switches="STAR RWY33 ILS">
<route name="STAR 33 RNAV" switches="STAR RWY33 RNAV">
<route name="STAR 33 MA" switches="STAR RWY33 MissedApproach">
<route name="N125" switches="EnrouteLOW">
<route name="UN125" switches="EnrouteHIGH">

would create the menu items: STAR, Waitloop, ILS, RNAV, MissedApproach, EnrouteLOW and EnrouteHIGH.
RWY33 can replace the extra tag <activeLandingRunways>33</activeLandingRunways>. It will be toggled in the same way by the runway settings.
switches would define an AND combination of the checked menu items.

This is just an idea to discuss.
Posts: 22
Joined: Wed Jan 20, 2016 12:34 am

Re: Configuration of SIDs and STARs

Postby wagnerw » Wed Jan 20, 2016 5:55 pm

I wonder, if defining the switches within the routes are the best way to maintain them. I would prefer it the other way around: define switches (one definition per switch) and the routes that are switched in a second xml attribute.

I have reworked the route switching in the most recent version, so the select-able routes are only those that are assigned to active runways. As a first step. In general, the code we are talking about, is executed in a high frequency (StandardRoute - isVisible): So we are talking about performance. If we define too much funtionality, or do it wrong, OR will be extremely slow.
My personal favorite is a tree like structure, displaying the available routes.
Posts: 262
Joined: Tue Nov 06, 2012 8:35 pm
Callsign: D-W794

Return to OpenRadar

Who is online

Users browsing this forum: No registered users and 1 guest