Separate "airport" from "sector"

[erikquinn]

Currently, everything that has to do with playing in a certain airspace is stored as properties of the "airport". But what about places where a single ATC facility is providing services to multiple airports? (aka just about everywhere)

Work should be done to move away from keeping things like navigational data (fixes/airways/procedures), video maps, etc under the airport, and make new classes called Facility and Sector which represents the given ATC facility and control position being simulated. For example, if I am working Miami Approach (consolidated to a single sector), I would work arrivals/departures to/from KMIA, KFLL, KOPF, KTMB, and others. My Sector within the Miami TRACON Facility has the stuff relating to my role in the simulation, and each of the airports are an Airport, which have their own runways and procedures defined within.

[erikquinn]

This morning I put some more thought into this. Here's what I'm thinking:

Facility
    └> SectorCollection
        └> Sector

In the following examples, we will use KSFO.

The Facility would be like the ATC facility we are emulating. This is NorCal Consolidated TRACON ("NCT"). It will have a collection of Sectors within SectorCollection that can be used, and will contain all information that is general to the area, but not specific to any particular sector.

The Sector will be each real-world (or simplified) sector are emulating. For example, SFO arrivals are handled by Area B of NCT, including the "Woodside", "Foster", "Boulder", "Laguna", "Niles", and "Cedar" sectors. Each has their own airspace boundaries, frequencies, etc.

In a given simulation, users can choose to work only a single sector within a given facility (perhaps Woodside, the 28L final sector), all the sectors of the facility combined simultaneously, or a combination of certain adjacent sectors (perhaps Woodside and Foster, the final sectors for the 28s).

---

And things will be divided up similar to this:

Facility:

• Fixes
• Airways
• SectorCollection

Sector:

• Airspace
• Frequency, Callsign, Position Symbol
• Scope Layout
• Airports to load

Airport:

• Instrument Procedures (SID/STAR/TRXN)
• Runways
• Taxiways
• Gates & Parking Spots

[willfrd]

This sounds awesome! So with this idea taxiways and stands are going to be implemented?

[erikquinn]

This sounds awesome! So with this idea taxiways and stands are going to be implemented?

Well that's a colossal undertaking in and of itself, where this is more of a reorganization that will be more conducive to having different controller roles and multiplayer, that sort of thing. But that is definitely the planned list of eventualities!

[willfrd]

Well that's a colossal undertaking in and of itself, where this is more of a reorganization that will be more conducive to having different controller roles and multiplayer, that sort of thing. But that is definitely the planned list of eventualities!

Cool! When this gets done I will have to update GCRR :-)

[kamikazestar]

This is solution that I'm looking for! Warsaw Approach is responsible for arriving and departing aircraft for two airports EPWA and EPMO, so this feature will solve my problem with correct implementation of that sector. I'm looking forward to this feature!

[erikquinn]

The ATC repository is being migrated to it's new home at https://github.com/openscope/openscope,
and thus, all issues are being closed. If this is still an issue with the latest version of the sim
(accessible at http://www.openscope.co), or is a feature you still think we are lacking,
please reopen the issue at the new repo.

Please note that the vast majority of these issues have been copied to the new repository, or else are covered by other issues created there. See the below screenshot for what it looks like when your issue is known in the new repo:

Thank you!

Closing this issue.