ESE Files Description

From EuroScopeWiki
Revision as of 09:24, 9 August 2009 by Stephan Boerner (talk | contribs) (The Sector Subsection)
Jump to: navigation, search
Previous: Appendices Actual: ESE Files Description Next: Scenario File

ESE SDK Documentation

The standard sector file and position file does not provide enough functionality so a new format has been developed, called ESE. This file includes information about controller positions, callsings and frequencies in the POSITIONS section, standard departure and arrival routing in the SIDSTAR S section, additional static map elements such as FREETEXT and AIRSPACE section with the sector definition and auxiliary boundary information. This file is in addition to other resource configuration files. This file may be edited and created with any text editor and saved as a standard text file. It must then be renamed to the file name of the sector file plus the “.ese” extension. And it also must be placed in the same folder where your “.sct” file is as in EuroScope you can load the “.sct” file only and the “.ese” will be loaded automatically.

Freetext Section

This section provides additional map drawing elements. It provides the ability to display any ASCII character on the radar video map. The freetext section must be prefixed by this line: “[FREETEXT]” (without the quote marks). Freetext definition lines have the following format:

<latitude>:<Longitude>:[<group name>:]<characters>

The separator between each element is the “:” character. The coordinates of latitude and longitude are prefixed by the letter of the hemisphere and then the geographical coordinate. The format for the coordinate may be either the decimal format (eg. N013.32861) or in the degrees.minutes .seconds.decimals format (eg. N013.19.43.327). You can group the free texts using the group name. If you omit the group name then a *Default group* will be used. The character section may use any number of ASCII characters except carriage return. A finished line may look like this:

N044.34.6.524:E026.06.27.632:LROP texts:TORA-D/26L 2490m

A finished freetext section may look like this:

N044.34.37.952:E026.05.53.935:LROP taxiways:W
N044.34.34.336:E026.05.28.289:LROP taxiways:O
N044.34.6.524:E026.06.27.632:LROP texts:TORA-D/26L 2490m

Terminal Routing Section

This section contains the routing for the standard terminal procedures such as SID and STAR. It also contains the rules for assignment of those procedures by runways in use and the route end point/route start point. This section must start with the following line: “[SIDSSTARS]” (without quotes). The format of a routing line is:

<type of route (SID/STAR)>:<airport of destination/departure condition>:<runway related to that route>:<routing name>:<route points>

The lines priority is from top to bottom. The topmost line has most priority. The first line that completes all conditions will be chosen as the correct routing. The type of route can be SID or STAR and declares whether the next condition, airport, should be the departure or the arrival airport for that aircraft. The airport is declared as the full ICAO code for that airport. The next condition is the runway in use. Declare a new line for each runway that uses that respective routing. The name will be the name of the SID/STAR with the discrete identifier. The route will be declared by any FIX, VOR or NDB that makes part of the routing with spaces between each route element. An example of a routing, below:






The Positions Section

This section contains information about all recognized controller positions. It is used to recognize what controller is what position using information from the callsign and the frequency. This is a slightly modified POF file used before in ASRC and VRC. Users may simply copy that file and modify it accordingly. The format of the Position line is the following:

<name of position>:<radio callsign>:<frequency>:<identifier>:<middle letter>:<prefix>:<suffix>:<not used>:<not used>:
   <A code start of range>:<A code end of range>[:<VIS center1 latitude>:<VIS center1 longitude>[: ... ]]

The name of the position can be anything used to help in identifying the line inside the ESE file. Radio callsign shall be the official radiotelephony callsign that shall be used for that station. Frequency shall be in full with “.” as decimal separator. The identifier is used in many places in the software and may be as short as one character and as long as required. It is recommended to use a standard length. In ASRC/VRC and FAA systems the length of that ID is 2 characters. Prefix and suffix are the first and last parts of the callsign used to identify the position. A code ranges are used to preset the assignment A code ranges from which the system will assign the codes for a specific position. Optionally there can be some visibility centers defined for the position. One center can be defined by two parameters: latitude and longitude. There can be maximum 4 visibility centers defined (that is altogether 8 optional elements in the line)

Some examples of a finished Position section below:

ARGES_TOP:Bucharest Radar:121.170:AST:A:LRBB:CTR:-:-:5401:5477
ARGES_MID:Bucharest Radar:124.250:ASM:1:LRBB:CTR:-:-:5401:5477
NERDI_TOP:Bucharest Radar:122.020:NIT:N:LRBB:CTR:-:-:5401:5477
NERDI_MID:Bucharest Radar:125.150:NIM:4:LRBB:CTR:-:-:5401:5477
BUCHAREST_TMA:Bucharest Approach:118.250:TMA:-:LROP:APP:-:-:5401:5477
OTOPENI_S_CTR:Otopeni Tower:120.900:TOI:S:LROP:TWR:-:-:5401:5477
LHCC:Budapest Radar:133.200:BUD:-:LHCC:CTR:-:-::
LYBA:Beograd Radar:123.770:BEG:-:LYBA:CTR:-:-::
EUE:Eurocontrol East:135.300:EE:C:EURE:FSS:EURE:FSS:0200:0277:N050.54.1.002:E019.49.42.216:N042.40.42.169:E022.28.7.307

The Airspace Section

The airspace section is the section containing information about the sectors in the delegated area and auxiliary boundary information. To understand the Airspace section one has to understand the functions of EuroScope well. It has a first section prefix with SECTORLINE which defines actual broken line that is common for only two lateral sectors. Then the sector is built by two or more of these lines and then additional boundary information is added such as COP (Coordination Points).

Please also take a look to the Tutorial section that describes some steps how to define the sectors.

The Sectorline Subsection

Each sectorline piece is usually comprised of three sections. The first line/section is prefixed with SECTORLINE then ‘:’ separator and the name of that respective sectorline.


Then the declaration of that respective sectorline continues with an optional section prefixed with DISPLAY. It is used to declare when that respective border will be highlighted. More exactly, what sectors must be covered discretely by different controllers for that line to be highlighted.


The prefix is DISPLAY with the ‘:’ separator. The next item is the condition for the sector you are covering. In this case, for this line to be taken in account you must be covering MGT sector. NOTE: this sector is not from the POSITIONS section but from the SECTOR section which will be described next. Next are two conditions for which two sectors must be covered discretely for this line to be highlighted. In this case the sectors MGT and BUD must be covered by a different controller and you must be controlling sector MGT. It is recommended to create more lines, one for each case that should verify. Then the actual line must be declared using coordinates. Each coordinate point must be declared with the “COORD” prefix then followed by the LATITUDE and then the LONGITUDE.


A new COORD line will be made for each point making up the respective SECTORLINE. Make sure the end point of the SECTORLINE is common with the start point of the next SECTORLINE.

There is an easy way to create circle sectors without defining so many coordates that form a circle on the screen. Just use the CIRCLE_SECTORLINE definition. Using that you can make a circular sector around any object (FIX, VOR, airport), or a coordinate defined in the line. In the first version it needs three parameters: sector line name, center point name, radius. In the second version it needs four parameters: sector line name, latitude, longitude, radius.


Tips: A SECTORLINE is a border line which is common with only two lateral sectors.


Translated this means: the SECTORLINE has been assigned a name of BUDOP_LHCC. It will be highlighted when condition [you are controlling BPT AND BPT and BUD sectors are controlled by different controllers] or [you are controlling BPM AND BPM and BUD sectors are controlled by different controllers]. The sector line is created by two segments, created by 3 coordinates/points.

You have the possibility to define the sectorline display away from the sectorline definition. We found that sometimes it is far easier to define this when defining the sectors. So whenever you need just add a DISPLAY_SECTORLINE entry (after the sectorline definition). Its syntax is the same as DISPLAY except that you have to define the sectorline name at the beginning.


The Sector Subsection

This is the subsection where you define the limits of a sector and controller assignments priorities.


In the first line you declare the sector name and the vertical limits. Prefixed by SECTOR followed by the ‘:’ separator then the assigned Sector Name (MGT) then followed by the lower altitude limit in feet (34500) then the upper altitude limit in feet (66000). The next line is prefixed by OWNER and defines which controller will be recognized ad controlling that respective sector and their priority. After the ‘:’ separator will follow a list of position identifiers from the Positions section. The first has most priority and the last, the least priority. For example if MGT position is identified as online by the Positions table, the MGT sector will be assigned to it. If not it will move on to the next position, verify it and if it is open the sector will be assigned to the BPT sector. This line also defines which sector you will be controlling when you are online as a specific position. The alternate owner line (ALTOWNER) makes it possible to define an alternate order of the sector ownership. The alternate rules can be selected at the _Sector_Ownership_Setup_. Its syntax is the same as the OWNER line but needs a name in front. Next follows the Border sector in which you define which borderlines make up the sector. Make sure a borderline and the next borderline have the end/start points common so it will be able to create a continuous border. Also make sure that it is a closed border, that is, that the last line ends at the start point of the first line.

The order of the sectors in the file is extremely important. EuroScope will check if an airplane is inside a sector in the order defined in the file. Therefore the first match will be used and the rest is not tested at all. You can use this behavior and create overlapping sectors. But be sure that the smaller is earlier in the list.


All sectors are active by default and are used in your session. However you may define sectors that are not always used but just in some runway configuration. After the ACTIVE keyword you should define the airport and runway configuration. The sector will then be used only if the specified runway at the specified airport is active for arrival or departure. An example is the Traffic Director in Hungary. He has the role to move the planes from downwind to the final and is used only on real busy events. Because of its role he controls at the arrival end of the active runway. But as the runways have two ends we defined two Traffic Director sectors, but only one of them should be used in one session.


The GUEST line is a formal way to handle exceptions to the general roles. After the keyword you should define a position a departure airport (or a * for all airports) and a destination airport (or a * for all airports). When an aircraft is flying in this sector and its current owner is the controller defined in this line and the departure and the destination airport match the flight plan then the sector owner will be the current controller. This may be a special solution to a normal situation over Slovak airspace. Normally this area is controlled by Prague, but the arrivals from Austria is passed to Budapest Radar even the route crosses this sector for a while and never enters to the sector of Budapest Radar, but goes directly to the Approach. So the Bratislava sector has a guest controller, Budapest Radar. And all arrival traffic to LHBP will accept it and EuroScope will not show the frequency of Prague indicating a necessary handoff.


The DEPAPT and the ARRAPT can be used to activate airports for departure and for arrival depending on what sectors belong to you. If there are airports defined for the sectors whenever you controlling sectors are changed the active airports data is updated. And as a side effect the your METAR list might be changed also as they depend on the active airports.

The Coordination Point Subsection

This section defines the COP (COordination Points) used for coordination with adjacent sectors and ACCs. Here you can also add LOA (Letter of Agreement) details and EuroScope will show you’re the appropriate action based on the LOA for each radar track.



Each line defines a different set of conditions for a LOA point to be recognized. The first section defines the time of the COP you are declaring: a sector COP or a FIR COP. Use either the FIR_COPX or the COPX prefix. Next follows a previous point/departure airport rule. You can put in there any preceding point you want to use to filter out that COP line. Next is a departure runway rule. Next is the fix it applies on rule. Next is the next point or arrival airport rule. Then is the arrival runway rule. For any rules you want to bypass replace it with the ‘*’ character. After the routing rules comes a display rule: the preceding sector and the succeeding sector. If these two sectors are controlled by the same controller then the COP code line will be bypassed. Next are the LOA instructions, either descend to, or climb to altitude in feet. Lastly the name of the COP is declared as you want it to be shown, usually the name of the COP. The COP lines have a priority from top to bottom. So the topmost line that verifies all rules will be chosen even if lower is a more suitable line which should be chosen. Therefore place the lines with most rules at the top and the lines with least rules at the bottom.

Previous: Appendices Actual: ESE Files Description Next: Scenario File