Luke Kolin Posted January 4, 2021 at 05:19 PM Posted January 4, 2021 at 05:19 PM What happened to the controller lat/long data in the v3 data feed? This seems like a step backwards. Cheers! Luke ... I spawn hundreds of children a day. They are daemons because they are easier to kill. The first four remain stubbornly alive despite my (and their) best efforts. ... Normal in my household makes you a member of a visible minority. Link to comment Share on other sites More sharing options...
Luke Kolin Posted January 6, 2021 at 08:06 PM Author Posted January 6, 2021 at 08:06 PM Bump? Luke ... I spawn hundreds of children a day. They are daemons because they are easier to kill. The first four remain stubbornly alive despite my (and their) best efforts. ... Normal in my household makes you a member of a visible minority. Link to comment Share on other sites More sharing options...
Martijn Rammeloo Posted January 6, 2021 at 09:15 PM Posted January 6, 2021 at 09:15 PM Just out of curiosity: why do you need it? Martijn Link to comment Share on other sites More sharing options...
Luke Kolin Posted January 7, 2021 at 03:28 PM Author Posted January 7, 2021 at 03:28 PM To determine controllers potentially in range of a pilot when flying, as well as plotting them on a map. Cheers! Luke ... I spawn hundreds of children a day. They are daemons because they are easier to kill. The first four remain stubbornly alive despite my (and their) best efforts. ... Normal in my household makes you a member of a visible minority. Link to comment Share on other sites More sharing options...
Koen Meier Posted January 7, 2021 at 03:38 PM Posted January 7, 2021 at 03:38 PM 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. Link to comment Share on other sites More sharing options...
Luke Kolin Posted January 7, 2021 at 11:29 PM Author Posted January 7, 2021 at 11:29 PM 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 ... I spawn hundreds of children a day. They are daemons because they are easier to kill. The first four remain stubbornly alive despite my (and their) best efforts. ... Normal in my household makes you a member of a visible minority. Link to comment Share on other sites More sharing options...
Luke Kolin Posted January 14, 2021 at 01:53 AM Author Posted January 14, 2021 at 01:53 AM 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 ... I spawn hundreds of children a day. They are daemons because they are easier to kill. The first four remain stubbornly alive despite my (and their) best efforts. ... Normal in my household makes you a member of a visible minority. Link to comment Share on other sites More sharing options...
Jordan Jolenaar Posted January 17, 2021 at 09:45 PM Posted January 17, 2021 at 09:45 PM 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. Jordan Jolenaar VATSIM Senior Developer VATSIM Network Supervisor [email protected] www.vatsim.net Link to comment Share on other sites More sharing options...
Luke Kolin Posted January 18, 2021 at 05:40 PM Author Posted January 18, 2021 at 05:40 PM 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 ... I spawn hundreds of children a day. They are daemons because they are easier to kill. The first four remain stubbornly alive despite my (and their) best efforts. ... Normal in my household makes you a member of a visible minority. Link to comment Share on other sites More sharing options...
Luke Kolin Posted January 29, 2021 at 08:25 PM Author Posted January 29, 2021 at 08:25 PM Bump. Cheers! Luke ... I spawn hundreds of children a day. They are daemons because they are easier to kill. The first four remain stubbornly alive despite my (and their) best efforts. ... Normal in my household makes you a member of a visible minority. Link to comment Share on other sites More sharing options...
Koen Meier Posted January 29, 2021 at 09:48 PM Posted January 29, 2021 at 09:48 PM Have you done what is suggested and send an email to vpdev. Link to comment Share on other sites More sharing options...
Daniel Neugebauer Posted April 7, 2021 at 01:31 PM Posted April 7, 2021 at 01:31 PM (edited) 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, 2021 at 01:32 PM by Daniel Neugebauer Link to comment Share on other sites More sharing options...
Luke Kolin Posted April 8, 2021 at 06:19 PM Author Posted April 8, 2021 at 06:19 PM Looks like the v2 feed went down as well... and I'm broken because the controller position got removed. 😞 ... I spawn hundreds of children a day. They are daemons because they are easier to kill. The first four remain stubbornly alive despite my (and their) best efforts. ... Normal in my household makes you a member of a visible minority. Link to comment Share on other sites More sharing options...
Andrew Dmitriev Posted April 12, 2021 at 12:39 PM Posted April 12, 2021 at 12:39 PM 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. Link to comment Share on other sites More sharing options...
Daniel Neugebauer Posted April 12, 2021 at 02:23 PM Posted April 12, 2021 at 02:23 PM (edited) 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, 2021 at 04:31 PM by Daniel Neugebauer Link to comment Share on other sites More sharing options...
Martijn Rammeloo Posted April 18, 2021 at 07:40 PM Posted April 18, 2021 at 07:40 PM 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. Link to comment Share on other sites More sharing options...
Mark Doyle Posted April 19, 2021 at 05:05 PM Posted April 19, 2021 at 05:05 PM Why not just hook up your servers to a DB with airport coordinates? Developer: vatsim.net | community.vatsim.net | estvacc.org Link to comment Share on other sites More sharing options...
Ross Carlson Posted April 19, 2021 at 05:11 PM Posted April 19, 2021 at 05:11 PM 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? Developer: vPilot, VRC, vSTARS, vERAM, VAT-Spy Senior Controller, Boston Virtual ARTCC Link to comment Share on other sites More sharing options...
Mark Doyle Posted April 19, 2021 at 05:32 PM Posted April 19, 2021 at 05:32 PM (edited) 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 April 19, 2021 at 05:39 PM by Mark Doyle Developer: vatsim.net | community.vatsim.net | estvacc.org Link to comment Share on other sites More sharing options...
Daniel Neugebauer Posted April 19, 2021 at 05:45 PM Posted April 19, 2021 at 05:45 PM (edited) 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 April 19, 2021 at 05:53 PM by Daniel Neugebauer Link to comment Share on other sites More sharing options...
Andreas Fuchs Posted April 19, 2021 at 07:02 PM Posted April 19, 2021 at 07:02 PM In Qutescoop the label-position is provided directly, no calculation needed: LON_N:London ACC(North):GB:53.4:-1:902 Cheers, Andreas Member of VATSIM GermanyMy real flying on InstagramMy Twitch streams of VATSIM flights and ATC Link to comment Share on other sites More sharing options...
Ross Carlson Posted April 19, 2021 at 07:15 PM Posted April 19, 2021 at 07:15 PM 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. 2 Developer: vPilot, VRC, vSTARS, vERAM, VAT-Spy Senior Controller, Boston Virtual ARTCC Link to comment Share on other sites More sharing options...
Mark Doyle Posted April 19, 2021 at 07:58 PM Posted April 19, 2021 at 07:58 PM 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? Developer: vatsim.net | community.vatsim.net | estvacc.org Link to comment Share on other sites More sharing options...
Ross Carlson Posted April 19, 2021 at 08:21 PM Posted April 19, 2021 at 08:21 PM 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. Developer: vPilot, VRC, vSTARS, vERAM, VAT-Spy Senior Controller, Boston Virtual ARTCC Link to comment Share on other sites More sharing options...
David Black Posted June 15, 2022 at 11:20 AM Posted June 15, 2022 at 11:20 AM I am joining this late, but I have developed a MSFS panel to show online ATC . I have been using both the vatsim V3 data feed and then looking for controller coordinates in the V3 transceivers feed baed upon a common callsign in both feeds. It works well most of the time , however sometimes the enroute controller doesn't show up in the transceiver feed - for examaple THAMES_APP this morning was in the main feed but not in the transceivers feed. If you search by Frequency (132.700) you find EGLL_N_APP - which has the incorrect location for Thames Radar (and the right information for Heathrow approach) Why is this happening, are controllers entering the wrong information when they logon? Obviously having the lat/lon against a center controller would sort this issue which is becoming more acute due to the sort of DQ issues above /DB Link to comment Share on other sites More sharing options...
Recommended Posts