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.