Jump to content

COPX feature request


Daniel Klepp
 Share

Recommended Posts

I've been working a lot with COPX lately, and it's not always easy. My experience is that the rules often conflict with how ES predicts the aircraft descend/climb path.

 

Wouldn't it be nice if the SECTOR1:SECTOR2 part of the COPX line would override and force eursocope to consider the next controller in the COPX instead of the next predicted controller?

 

I've been thinking and i cant come up with any downsides to this suggestion..

C1/INS

Director of Norway FIR

Vatsim Scandinavia

Link to comment
Share on other sites

At the moment achieved by the 'GUEST' function, but I agree, it would be nice to set the next sector (note sector, not controller) in stone for certain routes.

 

Do people like the 'GUEST' feature? There's an agreement in the UK that could involve any of 5 position identifiers having an aircraft transferred to them whilst it's in a third party's airspace (who will never speak to the aircraft) - that means I have to define 5 guests, whereas a forced agreement could remove this need?

ATC Examiner, VATSIM UK

No nonsense controlling Twitch - HazControl ✈️

@HVatsim

Link to comment
Share on other sites

  • 4 weeks later...
Wouldn't it be nice if the SECTOR1:SECTOR2 part of the COPX line would override and force eursocope to consider the next controller in the COPX instead of the next predicted controller?

 

I've been thinking and i cant come up with any downsides to this suggestion..

 

What happens if the selected next point jut cuts a bit, so the new FP goes in a way that does not cross SECTOR2 at all?

Gergely.

EuroScope developer

Link to comment
Share on other sites

  • 6 years later...

Hello everyone,

Lately I am dealing with a lot of COPX issues and have some suggestions that might improve the definition of COPX/XFL and next Sector.

Would it be possible to change the logic behind the defined COPX/XFL a bit? 

It would be nice if the defines COPX/XFL would be layed in stone and are NOT changed if coordinating a new FIX.  

What I mean is if a DCT is requested, the SI and XFL changes based on the new waypoint and predicted path.

As far as I know in RL a DCT can be requested without the defined XFL and Next Sector changing. 

A feature like that would be very useful for controlling because it can be quite confusing for controllers if the LoA COPX and XFL is displayed correctly and the a new DCT gets requested and the XFL gets deleted and the Next Sector changes.

Wouldn't it be better, you can request a DCT and the XFL and Next Sector remains as defined unless changed manually?

I would like to hear your thoughts on that.

 

Kind regards

Chris Gutierrez

Nav Department RG Bremen (EDWW) Germany

Link to comment
Share on other sites

Hello, 

In the RL system where ES is based on it's also only possible to use fixes as condition points. Some other systems use condition lines. This is a much better approach. This means that you can add conditions to a line that traffic is passing. Even the direction of the crossing can be in the condition.

This solves the problem of removed fixes in a route, directs and it's much easier to handle in the dataset. 

An examples can be this:

CondLine001 is for traffic destination XXXX runway in use is XX, line crossedbfrom east to west, trajectory is pushed to FL70, XFL is FL80 and next sector is XXXX_APP. 

E. 

Edited by Erik Wachters
Link to comment
Share on other sites

and Condition lines are a lot more useful because of the flexibility. Meaning if you coordinate something reasonable, it will still be caught by that line, and if you really go overboard with the direct a new sector will be add to the sequence.

Link to comment
Share on other sites

Very Interesting

 

we have been discussing this internally and the method you mentioned Erik might be possible to implement with a Plugin but right now it's just a thought 

 

Thank you for the insight in how some other systems work. I feel this approach is better for complex airspace like Germany, Belgium etc. 

Do you know if Maastricht uses a similar approach? They have some interesting instructions sometimes, for example EHAM inbound DCT to ARTIP descend FL260 and be level 55NM prior to ARTIP. Seems like the system shows them where exactly the FL needs to be reached based on DCT given and profile, I presume.

 

Chris

Link to comment
Share on other sites

yes we do use this approach with MADAP.

Chris, the restriction is not given by the system, we do that because we have a restriction at NORKU, which is descending FL260 crossing NORKU FL280 or below (to comply with the STAR), and a line from ARTIP to NORKU is 55NM. So to simplify, we give DCT ARTIP and the restriction FL260 55NM before :)

Link to comment
Share on other sites

  • 4 weeks later...

Please sign in to comment

You will be able to leave a comment after signing in



Sign In Now
 Share

×
×
  • Create New...