VATSIM London sectors to be shown correctly ?

[IttaiA]

Hi, 

 

Is there anychance to show VATSIM London sectors correctly ?

For now LON_C_CTR shows all of Southern london area. 

Updated sectors are:https://vatglasses.uk/ukireland/

Attached a screenshot.

 

[aivlasoft]

Sorry, but I cannot see anything on these screenshots because they are completely overcrowded. Could you please provide some screenshots where only the sectors are visible?

[d00nicus]

Ok, here are two screenshots - not London, but showing the same issue elsewhere, with  EFB2 is displaying a much larger block which is actually several much smaller sectors. Often this can result in you thinking you're flying into an area with coverage that you need to contact (which as happened to me last night) is sometimes not covered at all, or other times like shown below what is shown as single block is actually made up of multiple smaller blocks which are all online, which results in the mess of frequencies you can see at the bottom in the ATC Ribbon, many of which you will never come into contact with, but reduces the usefulness of the ribbon to almost zero when it occurs.

 

If any of these individual sectors logs off, EFB2 will still continue to show the same sized polygon on the map for coverage, despite the gaps which are accurately shown by VATGlasses (and other tools using the same API) - you can actually see this below - at the upper right, EFB2 is showing a sector that isn't actually online (and doesn't appear on VATGlasses)

 

It seems like EFB2 doesn't differentiate between individual sectors and the entire FIRs

 

It is not possible to get VATGlasses to hide the traffic, but I believe that the traffic shown in the screenshot included below is more than sparse enough compared to the original poster's sceenshots to clearly see the issue (helped in this case by the different sectors being colour coded, vs single colour in the original screenshots)

 

For EFB2 thankfully I was able to just disable traffic entirely.

 

 

 

EDIT:

I managed to get a screenshot showing London with less traffic, EFB2 shows the entirety of southern England as covered, VATGlasses shows the (correct) lower coverage. Each coloured section is also on a separate frequency.

[aivlasoft]

Thank you very much for these screenshots.

 

3 hours ago, d00nicus said:

It seems like EFB2 doesn't differentiate between individual sectors and the entire FIRs

Yes, that's correct. Unfortunately we do not have access to more detailed sector data. Any API which allows to get the current state is a good thing, but without having access to the underlying boundaries and sectors data it's almost useless.

 

[d00nicus]

Thanks for the fast response.  VATGlasses data for the sector boundaries is all on Github, and which they may be willing to allow the usage of on request?

 

For example https://github.com/lennycolton/vatglasses-data/blob/main/data/eg.json is the data for all of the UK boundaries

[aivlasoft]

Thank you for the link to VATGlasses. As far as I can see from the VATGlasses Webclient and the data on GitHub, this data does not cover the entire world, am I right?

Another thing which I realized is that this data is not only 2-dimensional (Lat/Long) it is also different regarding the altitude. While this is a good idea, EFB is not designed to depict altitude related data.

[d00nicus]

The data for the rest of the world is all in other files on the same Github repo - there might be a few gaps in remote areas, but the busiest ones are all covered. I wouldn't worry about the altitude part too much - it's rare to have the individual slices all staffed at once outside of large events - just getting the lat/long dimensions accurate would be more than enough, and would narrow it down to a manageable level whilst flying. VATGlasses themselves only ever show the altitude data in tooltips, there's no visual representation of it.

[aivlasoft]

Unfortunately the boundaries of certain sectors change at different altitudes, so it is not clear which boundaries shall be depicted. While I understand your point of view, I can only implement clearly defined requirements, and this is currently not possible, without rewriting major parts of the current implementation, as explained already above.

[d00nicus]

While it's disappointing to hear that it won't be getting changed in the immediate future, as a (now) retired developer myself I find your reasons for not doing it to be perfectly understandable!

 

Hopefully it can happen sometime in the future, but quite honestly that's about the only complaint I think I've found with EFB1 or 2 in the entire time I've been using it - so please accept my compliments on a fantastic piece of software!

[aivlasoft]

Thanks a lot for your words. When I was developing EFBv2 I would have had such 3-dimensional data available, but it wasn't. Therefore the entire development was done based on the 2-dimensional data. Although this data is now available, any kind of implementation would raise a lot of questions on how to do it. Just displaying the level where the aircraft is currently flying would not be good enough, because a pilot has always to be ahead of his airplane.

[d00nicus]

Just some passing thoughts, haven't really refined them yet. I'd assume if this ever happens it'd be in a much later version (if ever)

 

The best course that comes to mind is to show the current level, and say anything at +/- 1000  feet of that (potentially making that margin an option so the user can choose how ahead they want to be), based on if the aircraft is climbing or descending, with a slider to override the altitude being displayed if they wish it - that would let you limit the data on screen whilst still retaining the usefulness of the verticality.

 

In cases where the aircraft type is recognised, you can also use the estimated trajectory of the plane to filter out frequencies in the ATC list that the user will be either too high or too low for.