Jump to content

GUEST Line in ESE file


Recommended Posts

I could need some help regarding the Norwegian Sectorfile...

 

The problem is as follows:

 

ENGM, Gardermoen, has two parallel runways (01L/19R and 01R/19L). Usual traffic movement is to let all departures take off from the left runway, and landing traffic on the right. 2500 ft above the airport Oslo TMA is located and the TMA is controlled by Oslo Approach. I guess it comes as no surprise that shortly after departure; all IFR traffic will enter Oslo TMA.

 

Oslo Approach is divided between a West and an East sector, and the sectorline basically goes from north to south through a point exactly midway between the two runways.

 

Please take a look at the SID chart for runway 01L:

 

http://www.ippc.no/norway_aip/current/AIP/AD/ENGM/EN_AD_2_ENGM_4-1_en.pdf

 

As you can see all departing traffic will first be climbing in the west sector of Oslo Approach (if you can imagine that north-south line between runways), and then departures on the SIDs TOMBO 5A, OMORO 1A, SUTOK 5A and GOTUR 5A will continue in the east sector where they will remain until they are transferred to Oslo Control (ACC).

 

Now this is not a big issue on an average day on VATSIM since both Approach sectors will be bandboxed into one position, however during events it is normal to staff two approach controllers and here is when the problem appears...

 

In real life all traffic will be handed over to the next logical app sector i.e. traffic on the OMORO departure will be handed over to the east controller, not the west. In VATSIM however traffic that should be handed over to the east sector is handed over to the west sector instead, since that is the first sector, after TWR, that the aircraft will enter.

 

The GUEST feature does not seem to be appropriate as I can only define destination airports. If I choose all airports then obviously I just transfer the problem over to the west sector who also shall have its share of traffic towards the west and south. If I want to define exactly what airports the rule should apply to I would have to enter basically all possible destinations that could be from the east sector of Oslo TMA...

 

No solution seem very appropriate and it appears that the GUEST feature is missing a function saying that if an aircraft will enter sector A, but sector B is the next after that, then sector A should be ignored...

 

Is there a way for me to let ES know, via the ESE file, that traffic on relevant SID should ignore handoff to the first approach sector, and go to the correct one instead?

 

Thank you

Link to post
Share on other sites
I can't exactly attempt to help you at the moment as I'm not entirely sure what you're saying, however:

 

Why is this such a big problem? What is the actual problem that hinders Oslo east/Oslo west when controlling?

 

Well the problem is that you are online as Gardermoen TWR, I have logged on as East Approach, and Harrison Ford has logged on West Approach.

 

Now you have a traffic with destination Stockholm Arlanda. It has been [Mod - Happy Thoughts]igned the SUTOK 5A SID and you want to hand it over to me. You place your mouse pointer over the tag and hit F4. What happens? Our friend Harrison Ford receives the handoff request and not me and here is where the problem lies... I want TWR to be able to automatically hand over to the correct controller in every situation.

Link to post
Share on other sites
I can't exactly attempt to help you at the moment as I'm not entirely sure what you're saying, however:

 

Why is this such a big problem? What is the actual problem that hinders Oslo east/Oslo west when controlling?

 

Well the problem is that you are online as Gardermoen TWR, I have logged on as East Approach, and Harrison Ford has logged on West Approach.

 

Now you have a traffic with destination Stockholm Arlanda. It has been [Mod - Happy Thoughts]igned the SUTOK 5A SID and you want to hand it over to me. You place your mouse pointer over the tag and hit F4. What happens? Our friend Harrison Ford receives the handoff request and not me and here is where the problem lies... I want TWR to be able to automatically hand over to the correct controller in every situation.

 

In the data tag you should be able to override who the handoff is made to.

Link to post
Share on other sites

In this situation I think you have to do a manual selection of the next controller as David says. It is also possible for Harrison Ford to offer the tower controller to hand off directly to East APP - he can do that through the tag as well on an individual basis.

Mike Pike

VATSIM-UK

 
Link to post
Share on other sites

In the data tag you should be able to override who the handoff is made to.

 

Yes, that is quite easily done, but there is a problem with this procedure:

 

The TWR controller will have to manually change the next controller on basically all flight (at least all has to be reviewed) in a perhaps busy environment, and this can easily lead to errors being made.

 

In this situation I think you have to do a manual selection of the next controller as David says.

 

Well... Even though it might be impossible in the current release, as advanced as ES now has become, I can't see that this can be a difficult procedure or option to be able to implement in a later release? It is hereby a feature request.

 

It is also possible for Harrison Ford to offer the tower controller to hand off directly to East APP - he can do that through the tag as well on an individual basis.

 

How is this done?

Link to post
Share on other sites

A simple solution is for TWR to NOT [Mod - Happy Thoughts]ume the aircraft, but just send them verbally to the correct frequency. This is how we normally do it in Sweden anyway - do you teach the TWR controllers in Norway to have aircraft [Mod - Happy Thoughts]umed when on the ground?

Martin Loxbo

Director Sweden FIR

VATSIM Scandinavia

Link to post
Share on other sites
A simple solution is for TWR to NOT [Mod - Happy Thoughts]ume the aircraft, but just send them verbally to the correct frequency. This is how we normally do it in Sweden anyway - do you teach the TWR controllers in Norway to have aircraft [Mod - Happy Thoughts]umed when on the ground?

I do not find that a solution. It's mere an avoidance of the problem and will not help similar issues on various ACC sectors.

 

I'm not a mentor so I do not know what they teach the students. As of today I think they teach the TWR controller not to [Mod - Happy Thoughts]ume aircraft, however I oppose that procedure very much! Gardermoen TWR track aircraft in the real world and I do not see why VATSIM controllers should do it any other way (but that’s a different discussion). As far as I know VACCSCA is working towards a new training directive telling the TWR controller to track and [Mod - Happy Thoughts]ume targets and when that directive is ready - I'd love to have the mentioned problem solved by then...

Link to post
Share on other sites

I too have found my self many times in the position were the easiest way (or, unfortunately, the only way) to define the next controller would be by the fix (or navaid) that the a/c crosses.

For now, the COPX is used only to show the level at which the a/c should be at a fix, if and only if the previous and the next sector are controlled by two different controllers (or am I mistaken). Why couldn't that rule be used to define the next controller?

For example, if the a/c goes from sector A which is controlled by me, to sector B, which is controlled by another controller, and the border is at the TheFIX, would it be possible to set the next controller in the TAG by the owner of sector B from the COPX?:

COPX:*:*:TheFIX:*:*:A:B:*:*:XNAME

Link to post
Share on other sites

The only workaround this in the present version is simply to offset the SIDs to the East. You will have to split the points from the Runway to the TWR/APP border for the East and West SIDs (so you will have two different points on the border) and then just make a little correction of the APP sectors, so that the border points to be in the correct sector.

Link to post
Share on other sites
A simple solution is for TWR to NOT [Mod - Happy Thoughts]ume the aircraft, but just send them verbally to the correct frequency. This is how we normally do it in Sweden anyway - do you teach the TWR controllers in Norway to have aircraft [Mod - Happy Thoughts]umed when on the ground?

I do not find that a solution. It's mere an avoidance of the problem and will not help similar issues on various ACC sectors.

I don't really see how the same problem comes into play in an ACC environment, although I'm sure it's possible. For TWR/APP work though, it can be even more complex. For example at ESSA there are two APP frequencies (ARR-W and ARR-E) that are used for departures, as well as a separate DEP frequency. DEP has no designated airspace, but operates in the same sector as ARR-W and ARR-E. A departing aircraft could be sent to either of the three frequencies depending on the RWY in use, and whether it was on a SID or radar vectors. Here the only practical solution is for TWR to not [Mod - Happy Thoughts]ume departing aircraft, unless TWR wants to "manual transfer" almost every aircraft.

 

It works similarly for arrivals where DIR, who is responsible for the final vectoring, operates in ARR-W/ARR-E airspace. Here we have a workaround with a small 'dummy' sector DIR created in the final approach area for the active runway. This way the sector sequence is correct (most of the time). In real life this is not how it works - instead the ARR-W/E controller has the aircraft [Mod - Happy Thoughts]umed even after transferring to DIR. The only way to see on the screen that DIR 'owns' the aircraft is that the ARR-W/E controller marks the label with the 'FREQ' function. Two different workarounds to what is basically the same problem - one in ES and one in the real system!

 

Even more OT below:

 

I'm not a mentor so I do not know what they teach the students. As of today I think they teach the TWR controller not to [Mod - Happy Thoughts]ume aircraft, however I oppose that procedure very much! Gardermoen TWR track aircraft in the real world and I do not see why VATSIM controllers should do it any other way (but that’s a different discussion). As far as I know VACCSCA is working towards a new training directive telling the TWR controller to track and [Mod - Happy Thoughts]ume targets and when that directive is ready - I'd love to have the mentioned problem solved by then...

Yes, for some reason they have enforced a ban on "tracking" by TWR in Norway. This ban was never enforced in Sweden. However, I think the background is from the VRC days when TWR would mostly work with strips, and then it made more sense for APP to just "release" the tag when handing over to TWR. With ES it of course makes more sense for APP to "transfer" to TWR and TWR to [Mod - Happy Thoughts]ume the label, if for no other reason that to have the correct state and colour of the label to avoid confusion.

 

In the end I guess it depends on what system you want to simulate though. As you know, in Sweden we simulate Eurocat 2000E - which can be done very well in ES, while in Norway you simulate NATCON - which is a bit further from the types of system that ES simulates best.

Martin Loxbo

Director Sweden FIR

VATSIM Scandinavia

Link to post
Share on other sites
  • 3 weeks later...

Edvin,

 

ES just predicts some points along the route and tests what sector they are in and who is the owner of that sector. If there is a point in the wast app sector then ES will suggest a handoff to there.

 

The only way I see is to modify the sectors a bit to ensure that no points along the route will be in west app sector. Just a slight change in the Oslo TWR west sector can ensure that. Extend its area a bit to the north to include the switching point between the west and eastbound departures. May be the top should also be changed a bit to be sure the profile is not leaving too early. If you not extend but just add a new sector to the north owned by west tower then that sector can be enabled when RW19 is in use.

Gergely.

EuroScope developer

Link to post
Share on other sites

Please sign in to comment

You will be able to leave a comment after signing in



Sign In Now
×
×
  • Create New...