Calculation and Display of Sector Progressions

[erikquinn]

Overview

For consideration of when we go at this problem, some thought should be put into the ideal way to display the information before we go building anything. And a good starting point is actually what Jeremy has done in his own tool (see https://discord.com/channels/757323458609938513/1483215159894872279/1496251368783085810).

Provide Raw Sector Progressions

The thing that makes it inherently difficult to determine sector entry/exit times is that we don't know which aircraft will be in which vertical stratum(s) at what time. In the context of providing local facilities with the ability to obtain estimates of when to expect traffic in their airspace, Jeremy's solution was actually pretty brilliant:

• don't bother sorting through anything yourself, since you won't have the local knowledge required
• calculate and display the progression through "airspace" of different "types", regardless of the aircraft's altitude or airspace's altitudes, and let the local staff look at the ones relevant to their queries (they may have multiple different queries anyway)
  • FIR/ARTCC: geometry that divides only entire FIRs from each other (source: vatspy-data-project)
  • TMA/TRACON: geometry that includes only approach controls (source: simaware-tracon-project)
  • Sector (Low): geometry that includes only low sectors (comprehensive coverage)
  • Sector (High): geometry that includes only high sectors (comprehensive coverage)
  • Sector (Super-Hi): geometry that includes only super-high sectors (sparse coverage, as they don't exist many places)

By comparison to the lower sections, the above is something we can provide without requiring any input from the users. We can provide meaningful data where we previously could not have, because now it will be properly contextualized. The cases where we had traffic transiting the "wrong" sectors before, will now be something they can SEE and understand both WHETHER it's incorrect and WHY, etc. This frees us of any need to either hide data (on concerns of it being misleading) or to go through a laborious process of building stuff like the plan outlined below to provide the participants with data that's already been "cleaned and prepped" for them, so to speak. If we at least label the dirty data correctly, they can fish out how to look at it to determine everything they will want to know.

Dynamic Calculation of Sector Progression

Now, in the context of dynamically calculating sector progressions along event routing, it's obviously not as cut and dry... but we should be able to set it up to get some really good results without too too much work. Here are some thoughts on an ideal implementation:

Independent Sector Type

• FIR/ARTCC: geometry that divides only entire FIRs from each other (source: vatspy-data-project)
  • desired behavior: regardless of any other airspace the aircraft may be in, do a simple comparison of position against the provided boundaries to calculate entry/exit times.

Interrelated Sector Types

• TMA/TRACON: geometry that includes only approach controls (source: simaware-tracon-project)
  • desired behavior: require user to explicitly specify which TMA/TRACON facilities each route uses. Calculate entry/exit times only for those specified. While route is "in" a TMA/TRACON, do NOT include this portion of the route in the "High Sector" progression.
• Sector (Low): (source: PERTI Low)
  • desired behavior: require user to explicitly specify which Low Sector(s) each route uses. Calculate entry/exit times only for those specified. While route is "in" a low sector, do NOT include this portion of the route in the "High Sector" progression.
• Sector (High): (source: PERTI High)
  • desired behavior: User NOT required to specify in facility progression. Except as specified in the sector reassignment (see below), begin with a simple progression of the route through the "high" airspace geometry, excluding portions of the route determined to go through underlying TRACON or Low sectors.
    • As a result of this, the calculation of "high" progressions should happen last... TRACON, then Low, then High.

More Sector Types (we should ignore these for now)

• Sector (Super-Hi): Some research needs to be done to figure out if there's any real need for this. In all cases within the US I know of, the High boundaries would suffice for planning purposes, and distinguishing a "high" from a "superhigh" is usually only an altitude difference, and not often different boundary geometries. If nothing else, would be reasonable at first pass to just completely ignore these.
• Supercenters: These are not super common anyway and implementation would turn messy very quickly. Recomment to be handled via Sector Combination instead (see below).

Route-Based Sector Reassignment:

In cases where a specific route may have routes cross one sector, but continue to be worked by the prior sector (or in rare cases, sometimes for the 3rd sector to work the portion of the route in the 2nd sector, thus reassigning the "middle" airspace "forward" instead of "backward"). Common use case with routes like these is to either delegate airspace or handle via automated point outs. To support this:

• User can specify ZDC59=ZDC58 to specify that a progression through ZDC59 should NOT be counted as "passing through ZDC59" at all, and the distance spent within ZDC59 should be considered to be distance spent within ZDC58. This MUST be route-specific, even if it means the user must enter it many times. If it's a permanent reassignment of an entire sector to another one, that would be handled via "User-Specified Sector Combinations" in the section below.
• Also common to have slight discrepancies in airspace boundaries between different sources (ie changed locally, sometimes temporarily for CTP, etc), and the simple reassignment this way can provide the relevant output.

User-Specified Sector Combinations

To contextualize the times, since not every sector will be open, to make this information most useful, the user needs to be able to specify how sectors are planned to be combined together. This might include any combination of Low, High, Superhigh, Supercenter, or TRACON airspace. Thoughts on implementation:

• Unsure what kind of UI would be best for this, whether a "drag and drop onto another sector to create groups" or a text-based solution (less flashy, but likely actually more convenient for the user?)
  • Example: customUserSpecifiedSectorGroupName: [list of sectors using proper names found in geojson]
    • ZDC-PHAPPLE: ZDC18,ZDC19,ZDC58,ZDC59,ZDC12,ZDC10,ZDC54
    • ZDC-S: ZDC36,ZDC38,ZDC16,ZDC34,ZDC35
    • ZDC-W: ZDC32,ZDC52,ZDC37,ZDC03,ZDC04
      • will probably want to enforce some sort of FIR-level prefix? this may interfere with supercenters etc though 🤔

Scope of this Mega-Issue

This likely needs to be split out into separate issues, as the implementation is spread out across multiple products:

• Route Planner: for entry of facility progression
  • we also need to show the users (tooltip?) what they do and do not need to enter in the facility progression. Maybe rename it to Low, Terminal, and Sector Reassignment? (but ideally less gross and more intuitive 😅)
• Simulator: for actually calculating all of this 💩
• Simulator Graphs: for displaying all of this 💩
• Slot Planner: only if the constraints remain here, though I'd argue they don't belong there and should be moved anyway... so TBD I guess

Screenshots of Jeremy's Implementation