TopSky - Oceanic Data

[Paul McDyer (1304314)]

Hi Juha,

I came across another issue while controlling during CTP the other day. Once the plugin loaded the API clearance information from Nattrak it injected it all into Euroscope. This causes issues as they were all eastbound aircraft and on this side of the ocean, we don't care about the eastbound stuff, only westbound. 

Is there a way to make the plugin discard and eastbound clearances and only provide us with the westbound OCMs?

[Juha Holopainen]

Can you elaborate a bit on the issues? Clutter in the flight lists or something else? It might be possible to implement a simple filter such as destination longitude.

[Jonathan Fong (1308253)]

On 30/10/2023 at 09:29, Paul McDyer (1304314) said:

Hi Juha,

I came across another issue while controlling during CTP the other day. Once the plugin loaded the API clearance information from Nattrak it injected it all into Euroscope. This causes issues as they were all eastbound aircraft and on this side of the ocean, we don't care about the eastbound stuff, only westbound. 

Is there a way to make the plugin discard and eastbound clearances and only provide us with the westbound OCMs?

Are you sure the issue you're having is with TopSky? Not to speak on @Juha Holopainen's behalf but I don't think TopSky pulls from natTrak, you may be thinking of the VATCAN Bookings plugin (or some other local solution like the VATSIM UK plugin) that pulls natTrak data.

[Bernardo Reis (1096507)]

11 hours ago, Jonathan Fong (1308253) said:

Are you sure the issue you're having is with TopSky? Not to speak on @Juha Holopainen's behalf but I don't think TopSky pulls from natTrak, you may be thinking of the VATCAN Bookings plugin (or some other local solution like the VATSIM UK plugin) that pulls natTrak data.

The beta version of TopSky does pull data from nattrak. If you have the oceanic configuration, you can look at the OCM in the flight plan window as well as dedicated label and list items (OCL, mach, etc...)

Edited November 1, 2023 by Bernardo Reis (1096507)

[Bernardo Reis (1096507)]

Same happening with us. A filter of some sort would definetly be useful.

[Paul McDyer (1304314)]

Ye Bernardo has more or less summed it up with that screenshot. After logging on during CTP, TopSky then loaded all the OCM data. All aircraft exiting the ocean had an oceanic clearance, in theory and as far as logic goes, it did its job however, we do not care about eastbound clearances which were provided in north America.

Is there a way to tell the plugin to disregard all of the eastbound oceanic data? We (in Shannon anyway) only care about the westbound OCM date.

[Paul McDyer (1304314)]

Also in relation to the OCM date, I have raised an issue with the people who look after nattrak about how time restrictions are handled. You can see the github issue I raised here  - https://github.com/vatsimnetwork/nattrak/issues/95 and here - https://github.com/vatsimnetwork/nattrak/issues/94

I am yet to receive a reply about it but it would be great that when the time comes, TopSky would be able to handle it. I understand it may be hard to implement until they actually update the API 

[Juha Holopainen]

Looking at Bernardo's picture, the plugin at the moment probably doesn't crosscheck the destination of the flightplan to be the same as the destination in the oceanic clearance. Usually this won't cause issues but for very special cases, with an aircraft flying multiple legs with the same callsign, the oceanic clearance will be shown for all the following legs as well as long as the clearance remains in the natTrak data. I'll have to add that check.

Other than that, I gather the only issue is unwanted clearances being displayed, so adding simple "destination longitude" filter would be a sufficient mitigation, or am I not seeing the full issue here?

The <callsign>+<time> restriction type will first need to be added by natTrak, the plugin can't be coded to handle it without knowing the correct format. At the moment a "=1200" restriction is interpreted as "NBT 1200 NLT 1200". As the data also shows clearances with the restriction key having a null value, I can only assume that a restriction value like that being present actually means a restriction and the plugin should show it as such.

[Bernardo Reis (1096507)]

I think that destination longitude could solve the majority of the problems.

What sensible value would you suggest for Portugal and Ireland? I'm thinking about potential problems if the flight uses the T airways. For example GCTS-EIDW. The oceanic message would be of interest to Portugal but maybe not to Ireland. The opposite might be true as well.

What about the origin longitude?

[Bernardo Reis (1096507)]

Another option could be the offline definition of OANs.

In case it is not a known point it would create issues, but I think that for the majority of cases it would be a good compromise too.

Edited November 12, 2023 by Bernardo Reis (1096507)

[Juha Holopainen]

A list of OANs could work (easy to code but could filter out flights that are of interest), or an offline-defined set of coordinates forming a line that the flightplan must cross in a specified direction (much harder to code but could work better), or then something else. A longitude filter may or may not work well enough for the Tango routes and random routes to/from the Canaries and Madeira. You people who are seeing all the different ways flights are planned and which of them are of interest to you will probably have a better chance of forming an idea of a working set of conditions. I have zero experience of oceanic controlling and as such have a fairly limited grasp of what is needed to make sure all the necessary flights are shown and as many as possible of the unwanted ones would be filtered out. In many cases it's immediately obvious to a human observer that a certain flightplan either is or is not of interest to a certain controller, but putting all that decision making into code is a lot harder task as all the rules have to be set before seeing all the possible flightplans.

[Jonathan Fong (1308253)]

3 hours ago, Juha Holopainen said:

A list of OANs could work (easy to code but could filter out flights that are of interest), or an offline-defined set of coordinates forming a line that the flightplan must cross in a specified direction (much harder to code but could work better), or then something else. A longitude filter may or may not work well enough for the Tango routes and random routes to/from the Canaries and Madeira. You people who are seeing all the different ways flights are planned and which of them are of interest to you will probably have a better chance of forming an idea of a working set of conditions. I have zero experience of oceanic controlling and as such have a fairly limited grasp of what is needed to make sure all the necessary flights are shown and as many as possible of the unwanted ones would be filtered out. In many cases it's immediately obvious to a human observer that a certain flightplan either is or is not of interest to a certain controller, but putting all that decision making into code is a lot harder task as all the rules have to be set before seeing all the possible flightplans.

Could it be helpful to base the filter on something like track heading? E.g., TopSky could look at the aircraft's flight plan track (perhaps a weighted average based on distance of leg), and if it is between a certain defined set of track headings, then it will display the aircraft. An additional whitelist filter could be added as well for certain flight plan routes (or oceanic random routes, if it is possible to pull that from natTrak), e.g., the Tango routes, so that the plugin always displays data for aircraft filed on those routings regardless of track heading.

Not perfect, but as a rough method of filtering, I imagine it could work since most flight plan tracks stay within roughly the same direction throughout the whole direction of flight.

I would also add on a tangentially related note, as a BIRD controller and FE who will benefit from this feature, that this filter should be optional. BIRD deals with oceanic clearances going both East and Westbound, so we would likely have the filter turned off.

Edited November 12, 2023 by Jonathan Fong (1308253)