WIP.
The following standards are the result of ample experience creating Sectorfiles across the globe and tailoring them after real sessions. Our main goals are easy to access information, efficient use of space and avoiding cluttering.
Some of this guidelines might not be applicable in your case. Do not hesitate to contact us for suggestions or help.
The following criteria are mandatory for HQ airspace sectorfile contributions.
Should you like to help us improve any Sectorfile accross the globe, please get in touch!
Sectorfiles have to be packed as .zip files. As soon as the .zip is opened, at least one .isc file and the Include folder must be visible.
Inside Include folder, place a folder with all contents.
.isc file should make it easy for users to find the sectorfile. FIR / Airport ICAO code + name are usual good ways to make it easy to find. Sectorfile name for IVAO Downloads is defined at the Data Website.
We recommend organising contents into subfolders. This is just an example:
Example.isc | ||||
INCLUDE | ZZZZ | |||
ENR | Airways, fixes, VORs… | |||
AD | ||||
ZZZA | Airport GEO, Airport TFL, SIDs…. | |||
ZZZB | ||||
Changelog.txt |
Bear in mind that any changes to Sectorfile organisation should be followed by an update .upd file that removes files from their old locations.
Place changelog files inside your contents. Changelog files at the same level as .isc or even just inside INCLUDE, will only clutter user installations or be mistaken with other Sectorfiles´.
Minimum contents of a Sectorfile:
The ChangeLog.txt is a very important file, as it will help to manage and follow the update of a sector (No sectorfiles for HQ Airspace will be approved without a complete changelog edited !).
To ensure common edit and lecture of this file, please use the following .txt given : Changelog.txt
Here, don't forget to change “NAME”, by the name of the FIR you are working on, eg : “ANTANANARIVO”.
Then filed the date of released of your work and the AIRAC number used, eg “Date : 01/01/2024 - AIRAC 2313”.
Here, simply short all the files according to the actions done, use the complete file name for that, eg : “Added Files : - FMMM.artcc”.
Do not hesitate to use complete sentence, the goal with this part is to have a clear representation of every edit made, even minor. This will help ATC Advisor when checking the update, and for futur edition, to know what has been done in the past, eg : “ - Complete update of the ground at Antananarivo airport, adding gates and taxiways labels.”.
Let´s go section by section proving extra details.:
ATC file should not only include available ATc station and frequency but also the transfer list. Every unit should include all posible collaterals, both national and foregin for ease of use.
SID/STAR names should be complete (5 letters for WPT), alphabetically ordered, and where two or more procedures coexist for a point, ordered by preferential use. (Most used or preferential routing first). Why? fastest possible flightstrip filling taking advantage of autopredict.
E.g.: STARA1B arrival should be inserted as STARA1B and not STAR1B.
Additionally, procedures with special names can be their full name inserted: Rattenberg 4H (RTT4H) or KEYS SOUTH DEP
At airports where SIDs and STARs share the same designators, include DEP/DEPARTURE and ARR/ARRIVAL to help distinguish and avoid misrepresentations by Aurora.
At airports where SIDs and STARs are shared by different runways, feel free to draw them separately and include runway number: ASUKA 7 R31 or 31 ASUKA 7.
SID/STARs shall be built inserting waypoint/navaid names where available. To ensure they are highlighted and ETO. are displayed when ATCO needs them even with fixes hidden.
Auxiliary fixes such as FI35D or FTM48 can be ommited and replaced by coordinates to help declutter the Sectorfile. RNP waypoints such as SA498 shall be present and part of SID/STARs.
IAPs shall be inserted ordered by preferential use (Most used or preferential routing first). Without unnecessary items.
E.g.: VORZ35 should be used and not VOR Z RWY 15. Usual order: ILS, RNP, VOR, NDB.
Separating Initial, intermediate and final approach segments is discouraged unless there are several IAFs. Why?
There are two main functions for including IAPs: Visualization by ATCOs and flightstrip filing to obtain ETOs. If we separate IAPs into many different segments, not only we are cluttering the list and making everyhting harder to find. We are also denying the possibility to tag a traffic with the whole procedure and obtaining a clear picture plus time estimates.
Depending on usage and workload, you can choose to display all possible initial approaches under a single entry. Or you can draw the entire procedure from each different IAP like in the image above (APPROACH RWY.IAF: RNP 15.ARPED , RNP 15.MO420).
Visual approaches with prescribed tracks can also be included here.
We recommend drawing racetracks as part of the procedure. Holding patterns are usually better drawn together depending on configuration.
ZZZZ;11L:11R;WEST FLOW HOLDS;N044.20.10.104;E017.57.19.337;2;
Hold1
Hold2…
Missed Approach Procedures (MAPP) that end in a holding pattern shall have the holding pattern drawn at the end. This helps differentiate open-ended; fly heading 158º await ATC instructions type of MAPPs. Draw holding pattern at the end for correct estimates to MAPT.
Direction arrows and including holding WPT name are good practices:
N043.47.44.195;E017.45.12.039;
N043.47.51.216;E017.45.37.629;
EMKES;EMKES;10000+
//Arrow
N043.44.49.573;E017.50.14.949;<br>
N043.44.35.329;E017.49.55.974;
N043.44.30.538;E017.50.22.476;
We recomend extending airways beyond sector AOR, especially if they change track after exiting and can create conflicts. You can inlude MEAs and other info in labels.
FRA
In Free Route Airspace, you should include all FRA boundary wpts (Which might be beyond FIR). Pertinenet terminal waypoints inside FRA should also be included o ensure correct route display. Pertinent waypoints include SID termination; STAR start (or IAFs where no STAR used).
Avoid cluttering the sector with useless waypoints, so please delete all unnecessary.
If Airport.fcl is used, members are able to hide the polygons in Aurora but airport polygons will disappear if ATC.tfls are used and and ATC connects for the area covering the airport. Use Airport.tfl for coexisting airport and ATC TFLs. TFLs cannot be hidden using menu or pref bars.