OpenRadar: Flightstrips-Bay
The OpenRadar flightstrips-bay is used to organize the flightstrips of the corresponding contacts on the radar screen.
A ground controller would organize the flightstrips in a different way than a tower controller or an enroute controller.
This flightstrips-bay is highly customizable: It can be divided into several sections. Each section can have multiple columns. Rules and actions can add some "magic" to the flightstrips-bay, so that flightstrips move to the requested sections and/or columns.
Hardcoded Layouts
There are 2 layouts hardcoded into OpenRadar named "traditional" and "example".
Layout: traditional
There's only 1 section for the whole flightstrips-bay without a header. The section contains 3 columns:
| position of flightstrip | left | center | right |
| number of column | 0 | 1 | 2 |
| title of column | controlled | interesting | uncontrolled |
| enter-action | control | uncontrol |
A new flightstrip is put into the right column (2), because it is not controlled by me.
Each click left of the flightstrip moves the flightstrip a column to the left.
So one click moves the flightstrip into the center column (1), which will change the contact's color in the radar screen.
Another click moves the flightstrip into the left column (0): The contact is now controlled by me.
One click right of the flightstrip moves the flightstrip into the center column (1), which will change the contact's color in the radar screen.
Another click moves the flightstrip into the right column (2): This releases my control over that contact.
Layout: example
 |
There are 9 sections defined. In this chapter you find a description how this layout is used.
In chapter “Rules of layout example” is explained how the rules are set up for this layout. |
Section: emergency
When a contact squawks one of the emergency codes (7500, 7600 or 7700), then the corresponding flightstrip is moved to this section, until the contact has landed on the local airport.
Only 1 column.
Section: controlled
While a contact is controlled by me and isn't on the ground of the local airport, the corresponding flightstrip is placed in this section.
3 columns: APPROACHES, TRANSIT|PATTERN, DEPARTURES
Flightstrips can manually be moved to other columns.
Section: interesting
While a contact is controlled by any other (local or external) ATC, the corresponding flightstrip is placed in this section. As it is a controlled flight, a handover might happen.
3 columns: APPROACHES, TRANSIT|PATTERN, DEPARTURES
Flightstrips can manually be moved to other columns.
For a new contact:
- within 2 nm distance: the corresponding flightstrip is put into column 2 (DEP).
- above 90 nm distance: the corresponding flightstrip is put into column 0 (APP).
- others: the corresponding flightstrip is put into column 1 (TRANSIT).
Section: uncontrolled
While a contact isn't controlled by any ATC, the corresponding flightstrip is placed in this section.
For columns description see interesting (read TRANSIT as Other).
Section: ground
The primary conditions for this section are that the contact's distance from the airport is below 2 nm and it's altitude above ground level (AGL) is below 50 ft (imagine a local airport cylinder with 2 nm radius and 50 ft height above ground).
There are 5 columns defined to reflect different ground movement.
| TAXI IN | When a contact (corresponding flightstrip in one of the sections emergency, controlled, interesting or uncontrolled) matched ground conditions, the corresponding flightstrip is moved here while ground speed is 1 kn or above. |
| stop | Is contact's ground speed below 1 kn, the corresponding flightstrip is moved into this column. When it's 1 kn or above again, the flightstrip is moved to TAXI IN again. So the flightstrip can move several times between column TAXI IN and stop, until a contact reaches its parking position. The ATC can see which aircrafts are in movement and which are not moving. |
| PARKING | When a contact reached its parking position the corresponding flightstrip can manually be moved into this column, e.g. when pilot requests engine shutdown and/or close flightplan. For a new contact that matches ground conditions and isn't rolling the corresponding flightstrip is put here, too. |
| TAXI OUT | When a contact starts moving while the corresponding flightstrip is in column PARKING the flightstrip is moved into this column. |
| stop | Is contact's ground speed below 1 kn, the corresponding flightstrip is moved into this column. When it's 1 kn or above again, the flightstrip is moved to TAXI OUT again. So the flightstrip can move several times between column TAXI OUT and stop, until a contact is airborne. The ATC can see which aircrafts are in movement and which are not moving. If a contact just changed or corrected its parking position, the corresponding flightstrip can be moved into column PARKING again. |
An example for a standard arrival, parking and departure would look like this:
During landing the contact enters the local airport cylinder, so its flightstrip is moved from a flight section (probably controlled) into this section and column 0 (TAXI IN). While taxiing, it will stay there. When stopped at a holding point, it is moved to column 1 (stop). On continue taxiing it is moved back into colum 0 (TAXI IN) and when stopped at the parking position it will be moved again into column 1 (stop). After the pilot requested engine shutdown the contact is manually moved into column 2 PARKING.
With moving for pushback the flightstrip is moved into column 4 (TAXI OUT). Stop after pushback and the flightstrip is moved into colum 3 (stop). During taxiing to the runway it will be again in column 4 (TAXI OUT). Waiting on the runway for takeoff clearance will show the flightstrip in column 3 (stop) again. During takeoff, when contact gets out of the local airport cylinder the flightstrip is moved into one of the flight sections (probably controlled).
Section: dual
There are aircraft models that are used to simulate a copilot or a passenger of another aircraft. Maybe it's not a good idea to give one instruction to the pilot and a different instruction to the copilot to “separate” the assumed 2 flights. And wouldn't it be strange to give instructions to a passenger?
In this section you find the corresponding flightstrips separated in columns for copilot and passenger, so you can easily ignore these flightstrips.
Section: car
In the layout example there's only 1 car defined: FollowMe. There are more other ground vehicles in FG, e.g. a pushback, cars, motorbikes. The corresponding flightstrips ar moved into this section.
With the columns drive and park you can keep an eye on the movements on your airport.
Section: carrier
If your airport is near the coast line, maybe a carrier wants to offer service within your radar range. It might not be a good idea to tell the skipper to climb to 5000 ft. Carriers should be handled like ATCs.
Section: ATC
In this section you can find all ATCs in your radar range.
Configuration
Configure a section
Doubleclick into a section header opens a configuration dialog:
| auto visible | section is only visible if it contains at least 1 flightstrip, otherwise section header is hidden |
| show header | header bar with section name and column titles is visible |
| edit field | section title [ENTER to confirm] |
| show column titles | column titles are visible |
| select field | flightstrips in a section can be sorted by manual: no automatic sorting |
| ascending | otherwise descending |
| fields | for column titles |
| details | (see Configure a column) |
| + | add column |
| - | remove column |
| << | (see Configure sections) |
Configure a column
Click onto “details” besides a column to toggle the column details:
| paint level | if contacts in the radar screen are overlapping, then this paint level controls which contact is painted over the other. There are 5 levels: TOP, HIGHER, NORMAL, LOWER, BOTTOM use e.g. BOTTOM for uncontrolled flights or carrier or ground vehicles, TOP for emergency flights (The selected contact is always painted at top of all). |
| enter actions | when a flightstrip is moved into this column (of this section) an action can be executed |
| exit actions | when a flightstrip is moved out of this column (of this section) an action can be executed |
available actions:
| ControlAction | become the controlling ATC |
| UncontrolAction | release ATC control |
Configure sections
Doubleclick into the background of the flightstrip-bay opens a configuration dialog. You can toggle this part of the dialog with the button “<<”.
| list of sections | select the section to configure |
| up | move selected section up in list |
| down | move selected section down in list |
| + | add a new section |
| - | remove selected section |
Configure layout
Doubleclick into the background of the flightstrip-bay opens a configuration dialog. You can toggle this part of the dialog with the button “<<”.
| Layout | The complete layout of the flightstrip-bay can be saved into a file and loaded again. There are 4 categories for the filename: |
| default | default.xml |
| role | last 3 characters of the callsign, e.g. _TW.xml |
| airport | first 4 characters of the callsign, e.g. EDDF.xml |
| callsign | complete callsign, e.g. EDDF_TW.xml |
| load | load the selected file |
| save | save the layout into the selected file |
| traditional | load hard-coded layout traditional |
| example | load hard-coded layout example |
| rules | open rules dialog (see Configure rules) |
On startup of OpenRadar the layout is loaded depending on the callsign and the existing files. At first OR looks for a file with the complete callsign, then with the ICAO code of the airport, then for the role, finally for default and loads the first found file. If no file is found then a new default.xml is created from either traditional or example.
Configure rules
Rules are used to define some magic into the flightstrip-bay, as depending on the rules the flightstrips move into the defined section and column. A rule consists of a free chooseable name, condition(s) and action(s).
In the list of rules you see the priorities: the list is read from top to bottom and the first rule, for which the condition is matching, is used and no rule below this is tested. For example in the image below there's at top an “ATC” rule which handles all contacts that are recognized as ATCs (programs like OpenRadar, ATCpie, …). In the rules below this rules you can be sure that there is no ATC contact, so you needn't exclude them in each rule.
Doubleclick into the background of the flightstrip-bay, then click onto “rules” button to open this dialog:
| list of rules | select a rule to configure |
| up | move a rule up in list/priority |
| down | move a rule down in list/priority |
| + | add a new rule |
| - | delete the selected rule (beware: there's no undo) |
| Rule details | name of rule |
| Condition(s) | structured list of conditions; doubleclick to edit (see Configure condition(s)) |
| Action(s) | list of actions; doublecklick to edit (see Configure action(s)) |
Configure condition(s)
After a doubleclick onto “Condition(s)” you can edit existing conditions or if none is defined, chose a new condition. With the “X” button you can delete a condition.
Most conditions have a first selection field where you can select “NOT” to invert the condition result.
If the word “like” is in front of a text field, you can enter a regular expression. If you leave the field empty, it's the same as “.*” matching any text.
In edit fields for number or text it is necessary to hit ENTER to confirm entry.
Boolean conditions (AndCondition, OrCondition)
You can use them to combine several simple conditions. A group box with the title “AND” / “OR” groups the conditions together. In edit mode you'll always find a select field at the bottom of the group box to add another condition to the conditions list. You can use boolean conditions inside of boolean conditions to create very complex conditions sets. Be carefull onto which “X” button you click, it might delete the whole boolean condition though you just wanted to delete one of the conditions inside the boolean condition.
AnyCondition
Is true for all contacts, so no other rule below this rule is tested. You can use this for the last rule to ensure that all contacts show up in the flightstrip-bay or to disable some rules for testing.
Flightplan conditions (IFRCondition, VFRCondition)
tests the “Type” field in the contact's flightplan.
ATC conditions (AtcCondition, AtcLocalCondition)
| AtcCondition | tests the aircraft model for known ATC program identifiers like OpenRadar,… |
| AtcLocalCondition | additionally tests if the callsign starts with the ICAO code of the local airport. |
Status conditions (NewCondition, ActiveCondition, NegelectCondition, EmergencyCondition)
| NewCondition | contact / flightstrip is new (usually shown with green background color) |
| ActiveCondition | a contact is not active within a minute after having left radar range or multiplayer mode. It can be inactive, too, while FG is paused. |
| NegelectCondition | tests if contact is neglected. |
| EmergencyCondition | if squawk code is set to 7500, 7600 or 7700. |
Controller conditions (ControlSelfCondition, ControlLocalCondition, ControlNoneCondition, ControlOtherCondition)
| ControlSelfCondition | I'm controlling this contact. |
| ControlLocalCondition | Any other ATC at my airport is controlling the contact. |
| ControlNoneCondition | No ATC is controlling the contact. |
| ControlOtherCondition | In the text field after “like” you can put a regular expression for the ATC's callsign. |
Flightplan airport conditions (DestinationCondition, DestinationHereCondition, DepartureCondition, DepartureHereCondition)
| DestinationCondition | In the text field after “like” you can put a regular expression for the ICAO code of the airport. |
| DestinationHereCondition | tests the destination airport of the flightplan. |
| DepartureCondition | In the text field after “like” you can put a regular expression for the ICAO code of the airport. |
| DepartureHereCondition | tests the departure airport of the flightplan. |
Other flightplan conditions (SquawkCondition, CallsignCondition, AircraftCondition, ModelCondition)
| SquawkCondition | tests the contact's transmitted squawk code.You can set a range; for just a single code, enter the same into both number fields. |
| CallsignCondition | In the text field after “like” you can put a regular expression for the callsign of the contact. |
| AircraftCondition | In the text field after “like” you can put a regular expression for the aircraft code of the contact. The aircraft code is NOT visible on the flightstrip. You might find it in the file “aircraftCodes.txt” in the “data” folder of OpenRadar. |
| ModelCondition | In the text field after “like” you can put a regular expression for the model code of the contact. The model code is visible on the flightstrip. |
| ClassCondition | In the text field after “like” you can put a regular expression for the model class of the contact. The model classes can be found, added and defined in file “classification.txt” in subfolder “res/classification”. |
Flight status conditions (HeadingCondition, GroundSpeedCondition, AltitudeCondition, AGLCondition)
| HeadingCondition | tests the contact's heading. You can set a range. |
| GroundSpeedCondition | tests the contact's ground speed. You can set a range by entering values into both number fields or you can leave one field empty to set an open range (below or above). |
| AltitudeCondition | tests the contact's altitude. You can set a range by entering values into both number fields or you can leave one field empty to set an open range (below or above). |
| AGLCondition | same as AltitudeCondition, but the elevation of the airport is subtracted from the contact's altitude (= above ground level). |
Position conditions (DistanceCondition, DirectionCondition, RelativeHeadingCondition)
| DistanceCondition | tests the contact's distance from the airport. You can set a range by entering values into both number fields or you can leave one field empty to set an open range (below or above). |
| DirectionCondition | tests the contact's direction relative to the airport. You can set a range by entering values into both number fields or you can leave one field empty to set an open range (below or above). |
| RelativeHeadingCondition | with this condition you can test if a flight is heading towards the airport (maybe inbound) or away from the airport (maybe departure). The range for the angle is from -180° to +180°; 0° means straight towards the airport. You can set a range by entering values into both number fields or you can leave one field empty to set an open range (below or above). |
Flightstrip conditions (ColumnCondition, SectionCondition)
| ColumnCondition | tests the column of the flightstrip. A column is identified by its number; the leftmost column is 0. |
| SectionCondition | tests the section of the flightstrip. A section is identified by its title. In the text field after “like” you can put a regular expression for the title. |
Configure action(s)
After a doubleclick onto “Action(s)” you can edit existing actions or if none is defined, chose a new action. With the “X” button you can delete an action.
| MoveToAction | Enter a section name and / or a column number into the corresponding fields. |
| NoAction | This action can be used as a placeholder or with the AnyCondition (see there). |
Rules of layout traditional
 |
These 3 rules define the rules set of layout traditional: new Controlled Uncontrolled |
Rule: new
 |
This rule matches if a contact is new or the flightstrip is not in any (other) column. |
Rule: Controlled
.png) |
These 2 conditions grab the flightstrip from column 2 (uncontrolled) when it is controlled, but not from column 1 (interesting). |
Rule: Uncontrolled
.png) |
These 2 conditions grab the flightstrip from column 0 (controlled) when it is uncontrolled, but not from column 1 (interesting). |
Rules of layout example
 |
These are the names of the rules which define the “magic” for layout “example”.
Remember: The first matching rule from top to bottom is used. Therefore all non-flight contacts (e.g. ATCs, ground vehicles, persons) are handled first, then they needn't be excluded in the rules below. Then there are rules for the local airport ground movement. A rule for emergency flights and one for controlled flights. Interesting flights are defined by 4 rules. Finally 3 rules for uncontrolled flights. |
Rule: ATC
 |
This should be self-explaining.
OpenRadar identifies other ATCs by the model class that the programs sends. In all other rules below, there's no need to care for ATCs. |
Rule: carrier
 |
There are 2 carriers defined as sub-conditions to an OR-condition. So the condition is true if one of the sub-conditions is true.
More conditions can be defined for other carriers. |
Rules: car park and car drive
 |
In both rules there's only 1 ground vehicle defined: the FollowMe car.
You can replace the condition with an OR-condition and add several models for ground vehicles. The condition to identify the model and to check the ground speed are sub-conditions of an AND-condition, so both have to be true. |
 |
As all cars with a speed below 1 kn match the rule above, all other cars are driving and match this rule.
You could separate ground vehicles at your local airport from ground vehicles outside by defining a new section or column and appropriate rules. |
Rules: dual copilot and dual passenger
 |
In both rules there is an OR-condition predefined, so that more ModelConditions can be added.
In these two rules is, in contrast to the above names after “like”, a regular expression used. “.+” means that there must at least one character in front of “-copilot” or “-PAX”. |
 |
In Action(s):
While a section is always referenced to by its title, columns are addressed by their number. The leftmost column is 0. |
Rules: PARKING, Taxi OUT, Taxi OUT stop, Taxi IN stop, Taxi IN
 |
For all of these rules there is an outer AND-condition and the same 2 conditions which define a cylinder with 2 nm radius and 50 ft height above ground.
The third condition (a speed condition) is different. For PARKING and stop the ground speed must be below 1 kn. Then there is an OR-condition. For PARKING it defines that new flightstrips may appear here, if the other conditions are met. Also if the flightstrip is already in this column, then it should stay here. Without this condition the flightstrip would move to a taxi stop column. |
 |
For Taxi IN and Taxi OUT the contact's ground speed isn't below 1 kn.
New contacts taxiing on the local airport are put into column 4 (TAXI OUT). Flightstrips can also move from column 2 (PARKING) or column 3 (stop) to this column, when contact is moving. And again: If flightstrip is already in column 4 then it should stay there as long as contact is moving on the local airport. |
 |
Once a flightstrip moved to column 4 (TAXI OUT) it will be moved into column 3 (stop), when contact stops taxiing.
Again: It will stay in column 3 if it is already there. |
 |
This is the same as the previous except that columns 0 (TAXI IN) and 1 (stop) are handled here. |
 |
Finally all other contacts moving on the local airport are supposed to taxi in.
With this set of rules a flightstrip can move to the approprite column that matches best to its current status on ground. |
Rule: emergency
 |
This is again a simple rule which should be self-explaining. |
Rule: controlled
 |
In each action of the rules above section and column are defined.
In this action only the section is defined, but the column should be kept as it was. In the example the APP columns of the sections are all column 0 (the leftmost). If there is an uncontrolled flight in column 0 (APP) of section uncontrolled it will be moved into the same column 0 (APP) of section controlled after taking control of this flight. During takeoff the flightstrip is in column 4 (TAXI OUT) of section ground. As section controlled only has 3 columns the highest column number is 2, which is DEP. |
Rule: Interesting DEP, Interesting APP, Interesting OTHERS, Interesting
 |
Interesting means that there might happen a handover, so this flight must be controlled by any ATC. The regular expression “.+” is used, so that at least one character is required to match this condition.
If the contact is new and at the local airport, it's supposed to be a departure. |
 |
In contrast to the above rule, the new contact's distance must be above 90 miles to be considered an approach. |
 |
All other new contacts are considered to be transits.
But you may move them manually into column APP or DEP. |
 |
While all above rules handled new contacts, this rules keeps flightstrips in section Interesting as long as they are controlled by any ATC.
If you prefer double negative then you can replace the AtcOtherCondition by the condition “contact is NOT uncontrolled.” |
Rule: new APP, new OTHERS, Uncontrolled
 |
A new contact that is far away is considered an approach. |
 |
The flightstrips of all other new contacts are move into column 1 (Other).
Because departing flights should start on the ground of the local airport, there's no separate rule for departing uncontrolled flights. |
 |
As this is the last rule, the condition could also be the AnyCondition to catch all remaining contacts.
In the action you find again “maintain column” like in rules Interesting and Controlled. |