Peter wrote:
I don’t have SD but EasyVFR shows it correctly
SD shows it correctly, too.
I don’t think it is a database error – what you are looking at is the airspace around airway L612. This is Class A and is fully embedded within the London TMA stack starting at 5500ft. Not clear to me why it is shown on the chart nonetheless.
If you dig into the airspace classifier (within the FF app) you will see it is labeled “Airway”.
Below a picture of the AIP exert of this bit of airway between BOGNA and MID. The dimensions and vertical profile match.
Needless to say the whole layout of European airspace is still horribly executed within FF and it makes the whole thing incrementally confusing for VFR flight. Peter’s question is yet another good example of this. Trying to filter through the airspace stacks at that location is difficult and terribly presented by the airspace view within FF. See below:
Yes I am sure all these “mystery lines” are in the AIP; this is all a declutter algorithm problem. No 6.5k ft airspace should be shown above/within a 5.5k ft airspace, etc – obviously!
FF is a market leader in the US, so how does this work over there? Is their airspace data available in a machine readable form whose structure avoids these cases?
Peter wrote:
FF is a market leader in the US, so how does this work over there? Is their airspace data available in a machine readable form whose structure avoids these cases?
This particular case can’t happen in the US as controlled airspace (at least class E) extends down to at least 1200’ GND (or lower). Thus there is no need to specify airspace for “airways”. All ATS routes will always be fully in controlled airspace anyway.
The situation is similar in many other countries, e.g. Denmark, Germany, Sweden, in that there is never any controlled airspace specifically associated with ATS routes.
In this algorithm, one needs to classify the 3D shapes into categories (airspace classes) and then blend them vertically.
I thought this algorithm, for determining which object is in front of which, was perfected in the 1960s, by the pioneers of “AI”. All computer games have been doing it since for ever.
The fact that this is airspace, airways, whatever, should not be relevant.
Yes. I am afraid that there is nobody working for FF who really really (really!) understood the airspace structures of all the various European countries. And indeed the UK is the worst example, with different types of airspaces taking up the identical airspace volumes.
They simply took all the AIP data, threw it all into a machine and out came the result, after which they launched the product (at full price). Now, they are collecting user feedback and slowly iron things out, but still struggle, because nobody understands the nitty gritty details of the various countries and their airspace designs.
When will FF be able to declutter a certain “altitude channel” in-flight and a different channel in planning mode, like SD has done since forever?
On the topic of airway airspace embeded in a TMA, one has to ask if this level of complication actually brings anything, or is it CAA people making up s**t to justify their own existence (sorry for the language).
Arne wrote:
On the topic of airway airspace embeded in a TMA, one has to ask if this level of complication actually brings anything, or is it CAA people making up s**t to justify their own existence (sorry for the language).
From the point of view of AIP editors at least, it simplifies things as the controlled airspace associated with the airways is implicit and doesn’t have to be mentioned separately.
I think that is a legacy for UK airways going to CIs? most of them were probably used to be lower than the CAS on top of them? (mainly used by Islanders/Cummuters to fly to Jersey/Alderney in sub-FL80 altitudes and they may had few notams when they are active or cold)
I don’t get it. The algorithms for blending 3D shapes were perfected in the 1960s.
Whether something is an airway, TMA, CTR, or whatever, is irrelevant.
