Jump to content

Creating sectors


Recommended Posts

Hey everybody,

 

I was just wondering - how many VACC's actually intend to create sectors? At first sight, to be honest I find the subject a little bit too complicated for the purpose. Also because the real world Amsterdam ATC system (AAA) does not have these features either. On the other hand, it's a pity not being able to use EuroScope's features to it's max without defining sectorlines and sectors. All in all, I find it a difficult decision Who is actually far in defining sectors for his VACC/FIR?

 

Best regards,

 

Mark Jansen

Director Dutch VACC

http://www.dutchvacc.nl

Mark Jansen

Director Dutch VACC

http://www.dutchvacc.nl

Link to post
Share on other sites

Hi,

 

Hungary is ready for sure . I also have created EuroControl East files. I know from letters that there are others also under construction.

 

What I can offer is to add a page to EuroScope site that contains references to all available SCT and ESE files. So that I ask every VACC to send me a link where their files can be downloaded from. I will put all these links into a central location.

Gergely.

EuroScope developer

Link to post
Share on other sites

Hi Gergely,

 

Would it be possible to have a simplified COP function, just based on the waypoint in the route? For example if the route is via TEBRO, there is an opportunity to create some COP lines for altitudes. For example: TEBRO GND-FL135 to EDDL_APP (DA) and FL135-UNL to EDLL_CTR (LL) without referring to complicated sectors? In this case we are at least able to use the COP features and display the next controller frequency/code in the tag.

 

Mark

Mark Jansen

Director Dutch VACC

http://www.dutchvacc.nl

Link to post
Share on other sites

Mark,

 

I think it is not possible. The coordination points are used to define some constrains when an AC is p[Mod - Happy Thoughts]ed between sectors/controllers. So for the COP definition you always have to define the sectors the points are between. The point is used only in case when the sectors have different owners. When you are controlling in CTR position and no APP, TWR etc. below you then the COPs between TWR and APP or APP and CTR are not considered as the whole route belongs to the CTR position and CTR is free to use them or not.

 

Because of that you can not use the COPs without sector definitions.

Gergely.

EuroScope developer

Link to post
Share on other sites

Hi there,

 

I am in the process of creating the ESE-file for Maastricht Radar at EUC VACC. I also do know that at VACC-SAG the team of "SAUSE" is creating ESE-coordinates for SAG-sectors. I think it will take another few days for us to come up with results, but once we got fully used to the format, it will be a quicker process. I estimate to release the first version of Maastricht tomorrow or very soon, definetely earlier than two weeks

 

EDIT: what we really need is a central database where all VACCs/ARTCCs deposit their latest sector-data, for the benefit of everyone, especially their neighbouring organizations.

Link to post
Share on other sites

Egypt VACC's ESEs are under construction.

 

I just done the important quick stuff to make me going using the software, but, I'm still defining sectors and all. At the same time, I'm trying to develop a tool, that would just extract the sector data from the .sct file and put it as sector data in the .ese file for use with the sector ownership features of ES.

 

Then, I'll work on a tool for the simulator sessions files.

Ali Abou-Zeid

866739.jpg

What Centreline??

Link to post
Share on other sites

Servus Gergely,

can you advise where those files are posted, I could as example use EURE_FSS files to control and explore the .ese inner works (Latest posted EURE sectorfile 0709 has no .ese). That would be helpful.

Thanks

Hi,

 

Hungary is ready for sure . I also have created EuroControl East files. I know from letters that there are others also under construction.

 

What I can offer is to add a page to EuroScope site that contains references to all available SCT and ESE files. So that I ask every VACC to send me a link where their files can be downloaded from. I will put all these links into a central location.

Regards, Opher Ben Peretz

Senior Instructor

APP_5106_LLBG.jpg

Link to post
Share on other sites
Excellent, thanks. Now a question: Using these EURE sectorfiles, why do I not see active sectors, connected as observer. Have I missed something?

 

Basically as an observer you don't have any active sectors and therefore every sector is inactive and you don't either see borders of active neightboring sectors.

 

If you however have chosen your primary frequency and station from the voice communication setup then you should see active area if it correctsponds with a defined position in the ESE position data AND the sector is not manned by an actual controller.

 

As an observed I'd recommend using the sector ownership menu to highlight a sector.

Link to post
Share on other sites

Opher,

 

Originally there was only the DISPLAY keyword for the sectorline definition. For me it was logical to define the attribute where the line itself is defined. But it needs a forward reference as the sectors are defined later only. That could cause some misunderstanding. Therefore I was asked to add the possibility to define the visibility attribute when defining the sector itself. So I have added the DISPLAY_SECTORLINE keyword. There is no difference while you use them, they are both stored in the same structure inside the program.

 

DISPLAY_BORDERLINE? - Actually we do not have such keyword.

Gergely.

EuroScope developer

Link to post
Share on other sites

Thanks Gergely.

On the last issue, a quote from the bottom of EURE .ese file:

SECTOR:LUKK:24500:60000

OWNER:EE

BORDER:UKLV_LUKK:UKBV_LUKK:UKOV_LUKK:LRBB_LUKK

DISPLAY_BORDERLINE:UKLV_LUKK:LUKK:UKLV:LUKK

DISPLAY_BORDERLINE:UKBV_LUKK:LUKK:UKBV:LUKK

DISPLAY_BORDERLINE:UKOV_LUKK:LUKK:UKOV:LUKK

DISPLAY_BORDERLINE:LRBB_LUKK:LUKK:LRBB:LUKK

Opher,

 

Originally there was only the DISPLAY keyword for the sectorline definition. For me it was logical to define the attribute where the line itself is defined. But it needs a forward reference as the sectors are defined later only. That could cause some misunderstanding. Therefore I was asked to add the possibility to define the visibility attribute when defining the sector itself. So I have added the DISPLAY_SECTORLINE keyword. There is no difference while you use them, they are both stored in the same structure inside the program.

 

DISPLAY_BORDERLINE? - Actually we do not have such keyword.

Regards, Opher Ben Peretz

Senior Instructor

APP_5106_LLBG.jpg

Link to post
Share on other sites

OK, it takes a while but I got most Israeli airspace sectorized and functioning, now:

I do not see border lines where already defined, example:

SECTORLINE:LLSC_HECC

DISPLAY:SUC:SUC:CAC

DISPLAY:HAG:HAG:CAC

DISPLAY:TLC:TLC:CAC

COORD:N029.24.39.550:E034.54.48.241

COORD:N031.49.42.892:E034.00.08.093

 

LLSC_CTR aliased SUC is Israel South Control

HECC_CTR aliased CAC is Cairo Control.

Cairo and I as South Control are on. South Control sector is highlighted, but the borderline (defined in default bordeau color) doesn't show. Would appreciate your helpful comments, and sorry for the trouble.

 

For Gergely, I have a more profound question:

In the real world all ATC positions are normally manned, and most ATCOs work one single position for years (until they become supervisors and then may occasionally occupy more than one position).

 

In contrast, in online networks like VATSIM, the situation is nearly opposite: not all positions are occupied near you when you are connected, and that status is dynamic. You may control in a number of positions in a relatively short time, meaning you memorize less and therefore need more cues from the system, compared to someone who spends his life in one position.

So to me as a VATSIM controller, it's more important to see adjacent active sectors occupied by others, than to see my own sector highlighted. I know that this is the purpose of the borderlines, but still would like to understand why we have our highlighting set logically opposite from what I believe would be helpful to our environment.

Regards, Opher Ben Peretz

Senior Instructor

APP_5106_LLBG.jpg

Link to post
Share on other sites

Opher,

 

I completely agree with you. In several cases we need other information than the real world controllers. This is why I created the sectorline display feature. To be honest it does not exist in the real system as there you should always find another controller next to you. And also there is no automatic sector allocation but a supervisor will decide which positions to be used and what sectors to be controlled by a position.

 

I can not see your whole ESE file, but more or less sure what is wrong here.

 

DISPLAY:SUC:SUC:CAC

 

You said that SUC is alias for LLSC_CTR. That will not work in this way. It is very important that here you should specify SECTOR names and not controller positions. The sectorlines are between sectors and not between controllers. In this way it needs less DISPLAY lines to be used as there can be many variations who controls the neighbor sectors.

Gergely.

EuroScope developer

Link to post
Share on other sites

The point is now clearer, I misinterpreted manual text, thanks. It means though that I have to create complete sectors for all bordering FIRs.

 

Opher,

I can not see your whole ESE file, but more or less sure what is wrong here.

 

DISPLAY:SUC:SUC:CAC

 

You said that SUC is alias for LLSC_CTR. That will not work in this way. It is very important that here you should specify SECTOR names and not controller positions. The sectorlines are between sectors and not between controllers. In this way it needs less DISPLAY lines to be used as there can be many variations who controls the neighbor sectors.

Regards, Opher Ben Peretz

Senior Instructor

APP_5106_LLBG.jpg

Link to post
Share on other sites
  • 4 months later...
At the same time, I'm trying to develop a tool, that would just extract the sector data from the .sct file and put it as sector data in the .ese file for use with the sector ownership features of ES.

 

Then, I'll work on a tool for the simulator sessions files.

 

Hi Ali, do you have this or some other tool ready for use. I wish I have it, manual editing is largely time consuming..

Best regards

Matey

Link to post
Share on other sites
  • 1 month later...

Gergely,

 

One question to the HU ESE file.

 

I note that you define the CTRWL and CTREL positions as covering the area from 10000:29500, and the APPE and APPW as 1000:19500.

This means that the APPE and W pertrude into the airspace of CTRWL and CTREL.

Is there any reason why you did not divide the CTRWL and CTREL into two; 10000:19500 covering the area outside of APPE/W and 19500:29500 covering the entire area (as currently).

 

How do you ensure that the program knows that if the aircraft is within eg. the APPE sector it belongs to APP and not to CTREL?

 

Edit: Now now note that the smaller shall simply be added first => case closed!

Regards

 

Stephen

BR

 

Stephen Slot Odgaard

VATSCA C3

 

P3D v 3.4: Jeehell A320, Chaseplane, AS16, FSFX Precip, PTA, and a lot of scenery...

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

Aloha!

 

In my sector I need to create a buffer zone, where aircrafts will change FLs from nonRVSM metric to RVSM feet (when they come), and back (when they live my airspace). Its 2 questions I have:

1) can be created zone filled by some color and I can be define this color? (in VRC it was REGIONS part in .sct2)?

2) can I have some message, visual alert, proposition of changing when aircraft enter this zone?

vaccua_baner.jpg
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...