OpenRadar: Flightstrips-Bay

From FlightGear wiki
Jump to navigation Jump to search

Back to mainpage

Flightstrips-Bay with many flightstrips

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

Layout example without flightstrips
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:

Configure a section.png
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
column: the column of the flightstrip
altitude
callsign
distance: from ATC's local airport

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:

Configure a column.png
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 “<<”.

Configure sections.png
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 “<<”.

Configure layout.png
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:

Configure rules.png
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

Rules of layout traditional.png
These 3 rules define the rules set of layout traditional:
new
Controlled
Uncontrolled

Rule: new

Rule new.png
This rule matches if a contact is new or the flightstrip is not in any (other) column.

Rule: Controlled

Controlled (traditional).png
These 2 conditions grab the flightstrip from column 2 (uncontrolled) when it is controlled, but not from column 1 (interesting).

Rule: Uncontrolled

Uncontrolled (traditional).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

Rules of layout example.png
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

Rule ATC.png
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

Rule carrier.png
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

Rule car park.png
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.

Rule car drive.png
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

Rule dual copilot.png
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”.

Rule dual passenger.png
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

Rule PARKING.png
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.

Rule Taxi OUT.png
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.

Rule Taxi OUT stop.png
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.

Rule Taxi IN stop.png
This is the same as the previous except that columns 0 (TAXI IN) and 1 (stop) are handled here.
Rule Taxi IN.png
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

Rule emergency.png
This is again a simple rule which should be self-explaining.

Rule: controlled

Rule controlled.png
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

Rule Interesting DEP.png
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.

Rule Interesting APP.png
In contrast to the above rule, the new contact's distance must be above 90 miles to be considered an approach.
Rule Interesting OTHERS.png
All other new contacts are considered to be transits.

But you may move them manually into column APP or DEP.

Rule Interesting.png
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

Rule new APP.png
A new contact that is far away is considered an approach.
Rule new OTHERS.png
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.

Rule Uncontrolled.png
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.