Daniel Klepp Posted October 20, 2015 at 01:56 PM Posted October 20, 2015 at 01:56 PM 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 More sharing options...
Pavel Brodsky Posted October 21, 2015 at 05:49 AM Posted October 21, 2015 at 05:49 AM +1 please! Pavel Pavel Brodsky VACC-CZ Link to comment Share on other sites More sharing options...
Harry Sugden Posted October 26, 2015 at 07:16 AM Posted October 26, 2015 at 07:16 AM 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 More sharing options...
Gergely Csernak Posted November 22, 2015 at 04:05 PM Posted November 22, 2015 at 04:05 PM 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 More sharing options...
Chris Gutierrez Posted January 16, 2022 at 04:28 AM Posted January 16, 2022 at 04:28 AM 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 More sharing options...
Erik Wachters Posted January 16, 2022 at 09:45 AM Posted January 16, 2022 at 09:45 AM (edited) 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 January 16, 2022 at 09:46 AM by Erik Wachters Link to comment Share on other sites More sharing options...
Raul Ferraz Posted January 16, 2022 at 10:51 AM Posted January 16, 2022 at 10:51 AM 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 More sharing options...
Chris Gutierrez Posted January 17, 2022 at 11:33 PM Posted January 17, 2022 at 11:33 PM 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 More sharing options...
Erik Wachters Posted January 18, 2022 at 06:43 AM Posted January 18, 2022 at 06:43 AM (edited) Quote Do you know if Maastricht uses a similar approach? Yes,I'm pretty sure MADAP uses this approach 😉 BTW this line is actually a poly line. Edited January 18, 2022 at 06:52 AM by Erik Wachters Link to comment Share on other sites More sharing options...
Raul Ferraz Posted January 18, 2022 at 03:15 PM Posted January 18, 2022 at 03:15 PM 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 More sharing options...
Gergely Csernak Posted February 13, 2022 at 05:38 PM Posted February 13, 2022 at 05:38 PM The condition line is great idea that solves a lot of problems. I added it to my TODO list. 2 1 Gergely. EuroScope developer Link to comment Share on other sites More sharing options...
Recommended Posts