Representation of Redesignation Procedures

[Chris Pawley]

Hello

As we tend to do two different things in our updates, I thought it was worth discussing. Additionally, some controllers might be interested/have an opinion.

I wanted to breifly discuss what we do when SIDs and STARs are redesignated in AIRAC updates.

 

Option 1:

Archive the old procedure (typically with a #) and add a complete new procedure.

BLAHH1G updated -> #BLAHH1G

Create BLAHH2G

ANTHR2H withdrawn -> #ANTHR2H

Pro:

All old procedures correctly displayed in case of old NavData

Con:

Cumbersome sectorfile containing lots of out dated procedures

Longer loadtimes in boot up

May be difficult to reclear someone who filed the wrong procedure

Lack of distinction between old and withdrawn procedures

 

Option 2:

Archive old procedures where there is no longer a procedure with that name. Renumber/resequence updated procedures.

BLAHH1G updated -> BLAHH2G

ANTHR2H withdrawn -> #ANTHR2H

Pro:

Smaller file, less loading time

Con:

Aircraft with the old procedures may fly in an unexpected manner when cleared on a new procedure.

 

I personally prefer and thought we were using option 2, but willing to discuss and find out if there is merit in following option 1.

 

Chris.

[Johan Grauers]

Number 2 I would say. 

[Connor Faulder]

2 makes much more sense 

[Peter Lockwood]

I think 2 is more logical

[Matthew Moy]

I would go with Solution 2 as well.

[Alex Ashley]

Solution 2 is a lot better in my opinion - however for the Sector File I normally do solution 1 because that's what Harry always liked me to do.

[Oliver Rhodes]

Method two seems better to me, although I wonder if there could be merit in following method one where there are particularly noticeable differences in procedures?

[Harry Sugden]

The convention I always used (which Jamie had previously been using) was similar to option 2 in that completely renamed/removed procedures were 'hashed'. In addition, for STAR changes where:

• the number designation changed;
• the letter designation (at the end) remained the same;
• the 'name' (i.e. the TIMBA in TIMBA3F) remained the same;
• BUT the initial fix changed...

...we would also 'hash' the old version.

Example 1

When the TIMBA2F was redesignated TIMBA3F at Gatwick, the STAR was changed from commencing at LYD to KONAN, so it was important to keep both versions (in case someone's route ended at LYD, and they didn't have the new STAR).

Example 2

If a fix is added to the STAR, causing its (numerical) designator to change, but the start fix has not changed, then there should only be a need to keep the newer version (since auto-selection by EuroScope will not be affected).

---

The additional question is when to remove these 'hashed' versions. The TIMBA2F > TIMBA3F change at Gatwick occurred last year for LAMP1a, so when is appropriate to remove the 2F entries?