I am just trying out the Free Trial of SD.

Here in southern Germany I am unable to see the standard Airspace C starting at FL100.
I can see C starting at FL130 in the alpine area, but not the standard C in the flatlands.

Same goes with airspace E. Visible when the lower limit is off-standard (like 1000ft)
but not when standard (2500 ft).

What am I doing wrong? Thanks a lot!

(and yes, I have well planned a route high enough - currently FL150)

Hi Daniel. Where airspace spans an entire larger country (or most of it) we do not tend to show it explicitly in SkyDemon. That is why the blanket Class C above FL100 and Class E above 2500 AGL isn't shown in Germany.

Thank you Tim for this clarification.

Quite frankly, you should "tend to do that". At least with airspace C.

If I am flying VFR in FL120 from Austria to Germany, all well within airspace E, there will be a certain moment when I NEED to descend below FL100 or otherwise I HAVE to contact ATC. SD not showing this imminent airspace violation is - well - ridiculous.
(I tested it myself in simulation mode: Flying FL120 northward - all I get is an infobox "Exited Alpine Areo Class E", when instead, I just entered airspace C.)

Did you never hear any complaints about that? Might just be that all the pilots are still in jail ;-)

No, seriously: could you please consider adding airspace C at FL100 to your data base?

Thanks a lot,
Daniel

Sure, we will consider it. And to answer your question, yes, you are the first person to mention its absence in all our years of supplying our service in Germany. I don't think it's labelled explicitly on the German 1:500k DFS printed chart either, except in the margin.

Thank you, Tim.

And yes, airspace C @ FL100 is not in the chart. You have to study the AIP to know about this.

But then, this is the main reason why VFR flying in Europe is so cumbersome:
You can not rely on the chart only, you have to study the complete AIP for every country you are crossing.

I thought that the main purpose of SD would be to make flying more straightforward, so you (practically, not legally) do not have to learn the AIP by hearth. But that works only, of course, if ALL airspaces (that are relevant for VFR) are in your database.

Did you document it in some way what kind of country-wide airspaces you are omitting in each country? Because I know about the German airspace system, but I might miss something in the other European countries if it is not displayed by SD.

On the German DFS IACO 1:500000 chart there is a note saying "airspace information above FL100 not included". In fact there are several TRA's above FL100 which SkyDemon shows but the DFS chart does not.

No, we didn't. SkyDemon like other charts and products does not absolve the pilot from being aware of general country-specific rules.
The main purpose of SkyDemon is indeed to make flying more straightforward. And it does.

Tim, I agree with you in general. However, in this particular case I would expect SD to give me an airspace warning when crossing the boundary. This is simply because flying VFR I have been relying on SD to warn me of ALL pending airspace incursions. If there are individual cases in which SD doesn't issue a warning, I have to remember those separately which kind of defeats the purpose of SD.

Therefore, I agree with you, there is no point in representing a country-wide class C airspace on a cart. However, I agree with the poster that SD ought to warn me of pending incursions of such airspace.

-- Chris.

We will take note of this feedback and may include the blanket airspace in a future chart update.

Surely it should be included in SD. If you are planning a flight well below that level, dynamic airspace removal will hide the airspace anyway. And if you are above, you want to know about it (and hopefully SD will then also give you the right frequency to call for clearance).

Is it possible to get a VFR clearance into that airspace?

Yep, it's class C not A or B.

Yes, but authorities don't always allow transits of such airspace in every country, so I had to ask.

The main reason we omit such large country-wide airspaces at the moment is that they slow down the system. Not when drawing on the map (they are typically excluded from the map anyway) but as you fly, we need to check every second whether (and how) your flight intersects with these airspaces which typically comprise thousands of coordinates.

Having written the odd program myself, I appreciate what you say. However, rarely is the customer interested in the woes of the programmer. What the customer needs is a solution. How? "You'll figure it out", is what I heard most often.

-- Chris.

Very helpful. I am simply pointing out that if I implement this, the experience will get worse for just about every customer. This helps to explain why I have not implemented it.

I wasn't trying to be helpful just pointing out the expectation of your customers.

All I am saying is that airspace that requires an entry clearance is something most SD users expect to be warned about. Even if that airspace overlies an entire country at 10,000 feet (that's a reasonable VFR altitude, particularly in mountainous terrain). Climbing above 10,000 feet or crossing the German border at an altitude above 10,000 feet would have me in violation.

So if the standard way of checking for airspaces in SD isn't good enough for this, someone needs to be creative.


-- Chris.

Thank you Chris for pointing this out again!

I can only speak for myself (as a not-yet customer):
As long as SD only warns me about 95% of the relevant airspaces I will stick to my current solution and safe my money.

As you did not find Chrises "You'll figure it out" very helpful:

Obviously your software does not have any issues with thousands of airspaces in Europa that are currently NOT close to the coordinates of the airplane. I assume your software uses an algorithm that removes these airspaces in an initial step before checking for any airspace intrusions with the relevant (in close proximity) airspaces.

So why not split up the huge class C airspace in Germany in pre processing (NOT on the device)?
By breaking up these airspaces in maybe a frew dozen sub areas your software performance might be up again.

Hi,

the Situation presented by Daniel_KDF is sometimes a big problem. A problem that can ruin you. As a matter of fact I witnessed exactly what Daniel mentioned, on the Frequency of Munich FIS. Some Guy flew northbound in the area of Kempten, where the Alpine Class E Airspace ends. That pilot flew right into the C Class Airspace. The nice Lady on the Radio advised him on that and that he had do descent at once. It was a very hot day and everyone was flying very high that day. 
I am from southern Germany and was trained in that area north of the Alps, so I'm well aware of that airspace stepdown. You Can "see" it in the printed map and also in Skydemon, but only if you are aware of this circumstance.
You can produce the same problematic Situation if you fly from Austria to Germany in FL130 or higher, northbound. Again you will fly right into C airspace without warning. 
Skydemon does display the TRA's above FL100, for example EDR207B which is north of Kempten and begins at FL100.

I think the poses a big problem for pilots who are not aware of this airspace situation and Skydemon should warn you in the same trustworthy manner it always does.

Hello,

just a remark from another german customer who flies quite often in the Alps region.

I agree to the other guys explaining the problem with necessary descent from FL120 to below FL100 leaving the Alps E airspace.
I also would appreciate it if SD would warn if the plane enters a restricted/controlled airspace.

Of course preflight preparation should make aware of that, but neithertheless I think it would be great feature if SD could warn before maybe entering illegally another airspace.

But I also agree - if a country wide airspace would be bad for the performance / stability, than don't do it ;-)

Regards
Flip

Hi,
I am facing the same problem right now as the opener of this thead. Next month I will be flying to France for the first time. At the early time of planning I was not aware of the standard airspace structure in France. I just found by chance that several airspaces (even at lower areas, like E in Germany) are not displayed at all.

In my eyes, this is highly dangerous! Of course you say your software shouldnt be used as primary source, but lets be honest, why should I give you 100+ € per year if I need to use the map in flight anyway.

Attached you will find an simple planning from Munich to Innsburch at 14000 ft. Munich has a class C around it. But above FL100 theres just nothing! Somebody coming the opposite way from Austria in FL120 will think he's allowed to overfly Munich, because theres nothing above FL100.

You're able to put in a huge "Alpine Class C" in southern Germany, you're able to put in huge TMAs in Austria, you're able to put in thousands of smaller airpsaces all over Europe. I simply cannot imagine that theres a problem implementing the standard airspace structure of every country you cover.

I also must disagree with flip: If huge airspaces are slowing down your software, then it's your duty to work on your basic software!!! People are paying for this!

And, by the way: Wouldn't it be an idea to have the standard airspace structure of every country listed in the software somewhere? Something like the 10 basic rules of flying in France/Germany/Austria/UK/...

Right now I have a monthly subscription for testing, yesterday I was flying over the alps in 12000ft in my TMG. Knowing that some airspaces are missing makes me feeling really unsafe! Probably I won't be buying the full subscription until this issue is solved.

Best Regards,
Johannes König

tl;dr: Implement it! Software performace problems are your problems, not your paying customers ones. So you need to fix it!

As a new SD customer I absolutely agree. My reason to buy SD was that I needed a system when I cancel IFR and continue VFR and have f u l l situational awareness. If the VFR system lacks critical airspace information then it is useless.

Another question with respect to Restriction areas: Is this information also lacking for areas above FL100?? Tim Dawson please respond to this. In the past I have used skymap with the official ICAO chart - on this ICAO chart the full vertical dimension of the restriction areas is displayed. So skymap seems here - at least with respect to restriction areas - much better.

We include all airspace whose lower level is below FL195, with the current exception of "blanket" controlled airspace at higher altitudes covering entire countries, which (as I believe may have been mentioned earlier) we assume pilots flying at those altitudes are already aware of.

To my knowledge we are missing no airspace at lower levels in the entirety of Europe.

It is a great approach of focussing on the customer if you say to the customer that he should be aware of the incompleteness of your data instead of just providing a complete set of data customers could trust on. FL195 seems like a reasonable boundary to cut the data, but this implies that the data below FL195 is complete, which it obviously isn't.



Guys, seriously, this is not acceptable! Just think of the following: Given the hypothetical case that the standard airspace structure is comletely provided in SD. How high is the chance that theres a customer complainig that he doesn't need the standard structure because "he knows it anyway"? How high is the chance that you guys would post a press release saying: "We remove the standard airspaces because the people were annoyed of it".

This whole discussion is ridicolous. Your data is faulty and you deny to change it. It would be nice to see at least an approach to solving this problem. What about discribing the standard airspace structure somewhere in the app?

I can only re-iterate that FL100 or 10,000 feet MSL is not outrageously high when flying in Alpine regions. I certainly would expect SD to alert me to class C airspace infringements at that altitude. Whether I am familiar with German airspace structure or not is secondary. I bought SD because I want to rely on one piece of software for my cartographic needs and worries. This is no small matter to me, either.

In Hungary, for example, there is a blanket class C airspace above 9500 feet. It doesn't show in SD. What other airspaces are omitted in other countries? This really weakens my trust in SD as a VFR navigation platform.

You don't have to show that kind of blanket airspace on the map. But I would certainly expect to be warned when doing a "What's here?" on any point and I want to be warned before entering such airspace. And it also ought to show up in the certical cross section view. You could also show it as a warning under "Flight Details" such as you do with other issues.

-- Chris.

Chris, we do actually have that airspace. I guess you missed it.

Jo, we will take your feedback on board. However, if you do not like our current policy on the inclusion of blanket airspace on our charts, I suggest you use a different product. Most ICAO charts do not include it on the chart either; they instead include some notes or a diagram in the margin. Obviously, SkyDemon does not have a margin.

Regarding the comment about EDMU. You state that SkyDemon "basically says airspace G goes from GND to UNL". It says no such thing, you just assumed that because there isn't a label saying otherwise. I took a look at an ICAO chart for that area and there is no label saying otherwise at that point either. I hope you see the point, which is that blanket country-wide airspace is not usually described on a map. I do like the notion of having a little diagram or description elsewhere in the product but that is a potential future development.

Hey Tim,
sorry for being a little bit harsh in the first place. I was really confused when I was flying back from austria some days ago and the software didnt show me the beginning of Class C in FL100 near Munich. And the explanation given by you in this discussion earlier (performance issues) doesnt really satisfy. In my eyes, thats a rather lame excuse.

You're right, comparing Skydemon with the ICAO chart, theres no difference. However, the traditional chart does not have the side view at the bottom. And your side view is definitely wrong without standard airspaces. Also, I think that the map doesn't show it because it cannot be drawn on a top-down-view. But a software allows us to do this, so why not improve it?

My suggestion is as follows:
1. For the top-down-view, do not show the standard airspaces. Basically, handle them the same way you handle country-wide NOTAMs. Hide them.
2. Hoever, in the side view, these airspaces should absolutely be visible! The picture I've attached to the earlier post is so horribly misleading.
3. Also, people must(!) be warned when approaching a standard A/B/C/D/E, like in the example with the FL130/FL100 Germany Class C. Almost every border has an altitude where there is an E/G on the one side and an A/B/C/D on the other.

If this really brings up performance issues (I really cannot image why this should not be solvable), please add a switch to the software, something like: Show/Warn about standard airspaces.

Maybe it is an idea to show these airspaces only in planning mode? Performance shouldnt be an issue there.

My problem is not Germany, I'm from southern Germany so I know how the game works between Munich and Innsbruck. But I don't know the details of Poland, Czech, UK, and so on. And when tapping into any area, I want to know what the vertical classes are. At least up to FL195.

Tim, when I do a "long tap" on a point in the region of, say, LHFM I see no mention of the blanket Budapest class C CTA that starts at 9500 MSL in the "what's here?" window. What am I missing?

-- Chris.

You're missing the fact that we do not show that blanket airspace on the map. It's in virtual radar, it's in the flight details window if you plan a route through it, and it will show an in-flight warning if you approach it.

Jo, you state the performance issues resulting from the inclusion of large country-wide pieces of airspace in our calculations are our problem. You are correct, you just don't like how we have currently handled the problem, which is to omit the largest (most problematic) pieces of airspace from our data deliberately to keep a good general experience for the vast majority of our customers. I agree with you that our software would be better if these pieces were included, and I have planned some time in the future to see if there's any way we can mitigate the performance issues.

Do not underestimate the difference it can make including two 1,000 vertex polygons (that's the class C and class E) for Germany in our airspace hit-testing, which runs every time you change your route and every few seconds in flight. Anyone flying in the vicinity of Germany would be subject to this, which is many thousands of customers.

Tim, that's almost the solution I suggested in a previous post. If you now could just add the airspace to the list shown when you do a "what's here" I'd be a happy camper.

Greetings, -- Chris.

Just as an aside to Tim:

You might have already done this, but optimizing your hit testing algorithm might gain you some performance improvements. You do have an advantage about normal hit testing. Namely, you can assume that your point in question moves on a continuous line at a certain maximum speed. So a tiered algorithm -- giving you rough estimates blindingly fast whereas taking a bit longer if you want to know accurately -- might be beneficial. One might imploy a ranked list of airspaces that are most likely to change their status.

-- Chris.

We've been down that route, and there are numerous reasons why we need to perform the full hit-test every iteration, most of which boil down to the fact that we need to be absolutely certain (for safety) that everything is included. We can't even exclude airspace way above the expected trajectory, because such airspace (as has been requested here) is always drawn in VR for inspection even if you will not penetrate it. It is not practical to exclude a large piece of airspace from consideration just because it has been excluded or included in a previous iteration because our precise position relative to it (with any passed vertices or edges) must still be updated along with other results.

Inclusion in the What's Here menu would only work if we treated them the same as FIS boundaries, which I concede is possible (they are not included on the PC version because blanket tooltips are not a good UI experience). Even then, airspace clipping would ensure they were absent most of the time from that menu.

This discussion is getting a little technical; I'm happy to discuss the possible user experience for pieces of airspace like this but the implementation of our hit-testing is (as pointed out) our problem.

Hi Tim,
I don't see a problem of getting technical in this discussion. Both ckurz7000 and I want to help you to improve the user experience. Also, I have some background on programming and mathematical problems like efficient path finding and neighbor-detection in 3D-data.

To increase performance during flight, what about breaking down the airspaces into the FIRs?Germany Class C will be cut it into 3 pieces (EDMM, EDGG, EDWW). For Class E, it will be even more (e.g. Munich is divided in to South and North). Maybe this helps to improve performance.

Also, especially for Class C, im my eyes a perfectly precise drawing of the border is not necessary. It is probably possible to recude the amount of data points of the big airspaces to 25-50% without losing accuracy.

However, during planning, all airspaces should be listed in the context menu. At least, this should be possible to be activated by a switch.

Dividing the blanket airspace into FIRs is one way to make it easier, yes. We already significantly reduce the resolution of boundaries where they follow country borders; it is after this process has completed that we are still left with easily 1000 points in such a polygon.

The blanket Class E is not divided, I don't think. We already have the "islands" of class E where the lower level deviates from the country-wide standard. All we could do would be to add the blanket airspace, covering the entire country, whose lower limit is 2500' AGL (from memory). This bumpy lower limit is another reason that hit-testing will take a performance hit.

Actually one of the main reasons people use SkyDemon it that all airspaces are NOT drawn, for clarity. That is our dynamic airspace feature. Even if we did decide to include the blanket airspace under discussion, the class C would be clipped out of the What's Here menu (by design) for most people as it's higher than they will have selected for inclusion.

Hey Tim,
don't get me wrong: Dynamic removal of airspaces is a great feature of SD. Thats one of the things SD handles much better than a paper map does. Have a look at the north-eastern France area, on the map thats a huge mess.  However, in my eyes the "Whats here" menu should include all airspace data. Also, the virtual radar should show all airspaces, as long as they are within the upper and lower margin.

When I am planning to fly a certain track, I use the "whats here" to see the vertical layers. So I want all layers from GND to a reasonable altitude. In my case thats approx. FL130, but many people fly even higher. After I've checked the vertical layer, I choose my altitude to fly through there.

I can understand that a Class E with 2500 AGL needs a lot of performance to be calculated on the fly so I can understand you don't want to have that in your data. However, class C should absolutely be included. Flying from G into E is usually not a problem, but flying from G/E to C without clerance will cause more problems.

So, lets nail it down to three requirements I would want to see in the next SD release:
1. Add all(!) airspaces that need clereance to fly into (A/B/C/D) up to your altitude of coverage (FL195 i guess?)
2. Disable dynamic removal for the "Whats Here" feature.
3. The virtual radar must show all airspaces within its altitude range. The altitude range can be dynamically adjusted, of course.

In case you're fearing performance issues or an "overinforming" of the user, add switches for this. I would like to hear your opinion on this.

Virtual Radar already shows all airspace, it isn't subject to the clipping of the main map. So your item 3 is covered, I believe. Your item 2 I disagree with. The reason is that the What's Here menu is designed to show What is Here on the map. If something isn't drawn on the map, it really doesn't make sense to have it in the What's Here menu (because it isn't Here).

The root problem here is the absence in our data of a layer of airspace you need clearance to fly into. On that we are agreed. Whether we are able to do anything about that in a manner that is acceptable is the question. It is a nice notion of yours that we might be able to fit this into our already-crowded development schedule for the next release.

Thats exactly the point. I also want to quote your words from an earlier post:



For me, these two quotes don't work well together. I would appreciate to see this solved in the near future. Apart from that I want to let you know that the customer support here is absolutely outstanding compared to most other professional software.

Tim. I will refrain from getting too technical because I realize you have a team of professionals working on this and likely any solution I am going to propose will have been considered by your team anyway.

Regarding user experience. I much more frequently use the "What's Here" option than looking at the vertical xsection view. The reason being that the xsection view is pretty narrow and hard to read. Also, it shows only a rather limited altitude band. Therefore, if I want to know what airspace exists at a certain point I bring up the "What's Here" window and can easily read them all. In addition, tapping on one of the airspaces in the list will highlight it on the map.

The metaphor I use to interpret "What's Here" is: what exists around this point in reality. Not: what is here on the map. Therefore it irks me if "What's Here" does NOT show what is actually here but only what is drawn on the map. And I would guess that a goodly number of users use the "What's Here" window in the same fashion.

Greetings, -- Chris.

I think it's documented that the What's Here menu shows what is there on the map. It actually makes little sense to assume that it will also include stuff that isn't on the map, because there's no limit to those other possibilities, so personally I think the metaphor you used above is flawed.

Of course you assume that a goodly number of users use the software in the same fashion you do - everyone assumes that

When I talk to software engineers, I hear the sentence, "it's in the manual", frequently. But the manual is there to document the GUI not to justify it.

When using a map, people interpret the map as a representation of the real world. Therefore the question "What's Here?" is a question about the real world that uses the map as a "go between". If you want to ask about the map itself you ask "What's This?". This is an important distinction and demonstrates nicely how subtle and yet precise a GUI needs to be designed.

A second point is the general reluctance to accept that the "go between", i.e., the map, is NOT a faithful representation of reality. And by "faithful" I mean "representing all the items important to the user". Of course there is no limit to stuff that isn't on the map. But most of that other stuff the user neither cares about nor expects to be represented in the first place.

So you now have items that are important parts of the user's reality (like a class C airspace he is about to infringe) which are NOT on the map. And, further more, the most intuitive way to inquire about them by asking "What's here?" gives the wrong answer (from the user's point of view).

--Chris.

Tim,
the issue Chris is complaining about is exactly what I refered to as item 2 a few posts earlier:
2. Disable dynamic removal for the "Whats Here" feature.
Right now, there is no easy way to get the vertical airspace information for any given point. A user always must plan a route along that specific point and then vary the altitude until he knows whats going on.

When I plan a route and - for example - I have the choise to pass a certain restricted area in the north or in the south, I select a point in the north and check the vertical airspace layers. Then I do the same for the south and decide which way I fly and at which altitude.

Dynamic airspace removal on the map is a great feature, I said that already. However, the "Whats here" is basically a right-click menu. What will happen if dynamic removal will be deactivated? Probably 2-4 extra items will be listed. Nothing a user can't handle.

Again, just make a switch for it if you don't want to alter it for everybody: Disable dynamic removal for the whats here menu
Thats basically all we ask for.

Jo

That's interresting information. As I used "What's here" in order to have a look at what Airspace actually was there (between ground & upper level of SD). Seems I had it wrong (might be usefull to make that clearer in the documentation as well as it seems that I missed it). Might a solution not to have different behaviour between planning & in-flight ?
I think that for planning it would be usefull to know all airspaces that is at a certain point.
During flight I understand that it might only be usefull to have info on the airspace in the vincinity of where you are (I mean in hight).
This would solve the performance issue mentionned before.

There is already a switch for this. It's called the dynamic airspace feature, or "hide features above", and hopefully you already use it. If you regularly fly at FL100 then you will have changed this option appropriately, and therefore airspace you have said you're interested in will be displayed.

We will not be changing the What's Here menu to display stuff that isn't actually displayed on the map. It would often result in the list of stuff being many, many items longer than it currently is (we couldn't just stop at airspace; we'd need to include other aeronautical stuff the user had turned off like IFR waypoints, glider airfields, etc).

I've managed to make some small optimisations in the way we hit-test large pieces of airspace and will be publishing an updated Germany chart containing the class C in the next few days, so you'll be able to see it then. An update to the client software such that the airspace appears in the What's Here menu (assuming you have airspace that high turned on) will need to wait until the next release, obviously.

It's ok to list only features in the"whar's here" menu which the user didn't filter out himself. Therefore there shouldn't be that many more items to list.

Again, I consider it quite problematic if I can't get complete information about airspaces present at a particular point.

-- Chris.

Your statements are contradictory. The whole point of dynamic airspace is to filter out airspaces, so if you've set SkyDemon to not show airspace over 4000' (unless you actually plan a route there) for example you have told SkyDemon to filter it out, and it is quite correct not to show it in the What's Here menu since it's not shown on the map.

No, my reasoning is different. I argue not to show it in "what's here" if, and only if, the user opted not to show it. You, as I understand, don't show it because you have made an executive decision as provider of the software.

In my scheme, if the user decides to show airspaces above FL100, it would show up even if it still isn't depicted on the map. In your logic, as I understand it, it still wouldn't show up. So if the user asked SD to show all airspaces up to and including FL100, you don't comply and rather present incomplete information. This can result in very undesirable consequences when in flight.

-- Chris.

It seems we agree, then. I must have got hung up on the part where you wrote, "We will not be changing the What's Here menu". Sorry to belabour the point more than necessary.

-- Chris.

Hi Tim,
I've just downloaded the update of the German map data. Airspace C is now visible in the VR view.
Thanks for changing this, it's working really well. I also get the warning when coming back from the alps area flying towards Munich in FL120.
The "Whats here"-Menu does not show the airpsace class C, I assume this will change with the next update of the software.

Are there any other Class A-D airspaces still missing (e.g. in other countries)?

We will need to perform a review to make sure there are no others which need to be added, which we will do after the new Germany chart has been published and we are sure there are no downsides to our new inclusion of that airspace.