Controller location in v3 data feed

[Luke Kolin 10]

What happened to the controller lat/long data in the v3 data feed? This seems like a step backwards.

Cheers!

Luke

[Luke Kolin 10]

Bump?

Luke

[Martijn Rammeloo 13]

Just out of curiosity: why do you need it?

 

Martijn

[Luke Kolin 10]

To determine controllers potentially in range of a pilot when flying, as well as plotting them on a map.

Cheers!

Luke

[Koen Meier 25]

8 minutes ago, Luke Kolin said:

To determine controllers potentially in range of a pilot when flying, as well as plotting them on a map.

Cheers!

Luke

wouldnt it be better to have the sector coordinates for the controllor if it is an enroute station.

[Luke Kolin 10]

It would be exponentially simpler to just have the lat/long plus the range (which is already in the feed) and do a simple distance calculation rather than a lot more data pushed to the clients and a more complicated algorithm. I don't need perfect sector boundaries, just way to filter the ATC list.

Why was it removed?

Cheers

Luke

[Luke Kolin 10]

Is there any update or status from VATSIM on this? It's getting close to blocking a release of mine, or I'll need to code against the v2 data feed.

Cheers!

Luke

[Jordan Jolenaar 2]

Hi Luke,

There is a technical limitation that results in loss of ATIS data when there are too many connections (ATC/OBS/ATIS). Due to that limitation, we have removed the controller position field. This is not a limitation of the data server, but rather a restriction on how we get data from FSD.

If you have any more questions, feel free to drop an email to [email protected]

 

On a side note; apologies for the very late response.

[Luke Kolin 10]

Does that mean there has been a bug filed against FSD?

I'm not sure how adding lat/lon to a data feed for a few dozen controllers breaks things whereas that field for over 1,000 pilots does not. This is an important feature for me, and I'll need to stick to the V2 feed for now.

Luke

[Luke Kolin 10]

Bump.

Cheers!

Luke

[Koen Meier 25]

Have you done what is suggested and send an email to vpdev.

[Daniel Neugebauer 12]

It seems like there are two workarounds to estimate a controller position:

Known stations could be looked up from https://github.com/vatsimnetwork/vatspy-data-project.

Unknown stations could be estimated by their transceivers - it appears that transceivers are now public as they are listed in the API docs: https://api.vatsim.dev/#operation/TransceiverData Since controllers usually provide service by voice most unknown stations should be locatable this way. I'm a bit unsure about the details of that file, though... It seems like it has not been mentioned in these forums before and there also is no information about the update interval or usage policies. Maybe someone from the webservices team could shed some light on it?

Edited April 7 by Daniel Neugebauer

[Luke Kolin 10]

Looks like the v2 feed went down as well... and I'm broken because the controller position got removed. 😞

 

[Andrew Dmitriev 0]

Just to confirm that controllers' location is needed not only to Luke, but at least to me too...

It is sad when the feature I used for years just disappeared :(

Best regards.

[Daniel Neugebauer 12]

What about the transceiver "API"? I don't know if there are any policies attached to it (fetch intervals etc.) but I would assume that it can be used as part of a workaround to locate stations because the "API" has been made public.

Other than that, VAT-Spy data seems to have an acceptable data quality (some sectors are outdated or not recorded properly, but most seem to make sense). I get good results by matching callsigns from long (more precise) to short (less precise) - which is not what VAT-Spy currently does but it seems to already be on Ross' todo list. I index all FIRs, then UIRs and finally all airports by their normalized IDs and, if set, by their "callsign prefix". Additionally, I alias all Kxxx stations to xxx (unless something else is already registered with that callsign) because some US data is either incomplete or controllers log in using unpublished callsigns which omit the leading K from the station's ICAO code. This appears to find some reasonable location for almost all controllers (feels like 90-95%) although the locations are not completely accurate (there are some stations with multiple center coordinates; in my case I need to provide exactly one coordinate so I currently just average them).

... it would of course be much easier if the feed could get the fields re-added.

Edited April 12 by Daniel Neugebauer

[Martijn Rammeloo 13]

On 4/12/2021 at 4:23 PM, Daniel Neugebauer said:

What about the transceiver "API"? I don't know if there are any policies attached to it (fetch intervals etc.) but I would assume that it can be used as part of a workaround to locate stations because the "API" has been made public.

Other than that, VAT-Spy data seems to have an acceptable data quality (some sectors are outdated or not recorded properly, but most seem to make sense). I get good results by matching callsigns from long (more precise) to short (less precise) - which is not what VAT-Spy currently does but it seems to already be on Ross' todo list. I index all FIRs, then UIRs and finally all airports by their normalized IDs and, if set, by their "callsign prefix". Additionally, I alias all Kxxx stations to xxx (unless something else is already registered with that callsign) because some US data is either incomplete or controllers log in using unpublished callsigns which omit the leading K from the station's ICAO code. This appears to find some reasonable location for almost all controllers (feels like 90-95%) although the locations are not completely accurate (there are some stations with multiple center coordinates; in my case I need to provide exactly one coordinate so I currently just average them).

... it would of course be much easier if the feed could get the fields re-added.

Please note that one control position can have multiple transceivers, each with its own lat/lon.

[Mark Doyle 5]

Why not just hook up your servers to a DB with airport coordinates?

[Ross Carlson 173]

5 minutes ago, Mark Doyle said:

Why not just hook up your servers to a DB with airport coordinates?

Which airport would you use for a center controller?

[Mark Doyle 5]

26 minutes ago, Ross Carlson said:

Which airport would you use for a center controller?

The visual center of the polygon?

edit: I'm assuming you're talking about for labelling purposes. Otherwise why would you need this? How is the precise location of a CTR controller useful to a pilot?

Edited 19 hours ago by Mark Doyle

[Daniel Neugebauer 12]

Airport != Center/Radar/Area Control (aka FIR/UIR sectors)

While there are many databases on the Internet providing airport coordinates there are very few that will give you meaningful FIR/UIR information, especially in regards to VATSIM. As I've written above, the VAT-Spy database seems to be the easiest available and also the best (quality-wise) choice if you make some adjustments to the callsign lookup as compared to the actual VAT-Spy program. And if you want you do not only get center coordinates but also sector outlines - way more information than what is available from just performing calculations on transceiver positions. The data project is CC-BY-SA licensed so it should fit almost any license situation.

Even with the transceiver list I would still prefer VAT-Spy as a data source unless I am actually interested in the location of virtual AFV antennas. I guess comparing both data sources will result in some more or less noticeable differences depending on how equal the density of transceivers across the covered ground is for each sector.

Edited 19 hours ago by Daniel Neugebauer

[Andreas Fuchs 302]

In Qutescoop the label-position is provided directly, no calculation needed:

LON_N:London ACC(North):GB:53.4:-1:902

[Ross Carlson 173]

1 hour ago, Mark Doyle said:

1 hour ago, Ross Carlson said:

Which airport would you use for a center controller?

The visual center of the polygon?

This thread is about controller location being missing from the data feed. The data feed does not include polygons.

1 hour ago, Mark Doyle said:

edit: I'm assuming you're talking about for labelling purposes. Otherwise why would you need this? How is the precise location of a CTR controller useful to a pilot?

The answer to that question varies by application. Just one example would be an application that shows a list of nearby controllers, as the OP mentioned. Having some sort of location reference in the data feed would be helpful here, so that applications wouldn't have to also consume some other data source such as the VAT-Spy data or the transceiver data.

Since we're using JSON now, it would be great if an array of vis centers could be added to the controller objects, rather than just a single vis center as was available in the old feed.

[Mark Doyle 5]

41 minutes ago, Ross Carlson said:

This thread is about controller location being missing from the data feed. The data feed does not include polygons.

Yes.. So why ask about center controllers? Obviously you would not look up a center position in an airport DB?

[Ross Carlson 173]

21 minutes ago, Mark Doyle said:

Yes.. So why ask about center controllers?

Because people still want to know where center controllers are located.

21 minutes ago, Mark Doyle said:

Obviously you would not look up a center position in an airport DB?

That's right, hence my question.