Copying over my comment from #1788:

I would also like to see the Margin Over Terrain info. I miss this info which was available in Winpilot. The way winpilot implemented it was simple: Whenever the margin was negative, in addition to the X on the glide bar, it also displayed a negative red number showing how much altitude is needed to clear the terrain. This provides critical information to make a go/nogo decision.

Is this going to be implemented in 6.5? This would be one of the highest priority on my wishlist providing crucial information to pilots flying over terrain, namely how much further they need to climb to clear the terrain. This info is already calculated in XCSoar (arrival altitude to any point on the map)so all is neededed is to display this number near the x on the map.

Replying to ramy:
xcsoar does not calculate a precise arrival height to any point on the map unless a point is explicitly selected. And that number on the X would always be your configured terrain safety height (always the same value). I also doubt the usefulness of that single value. A clearance of e.g. 200m on a ridge right next to you is a lot less critical than an also needed clearance (e.g. calculated at 220m) 20km away. That simple minimum "value" you proposed would show 200m.

I would rather like to see something which allows the see the margins for the complete map area and not a single point. A cross section view displayed as part of the map view could be a limited solution (straight line clearance only). I would prefer something like described in #2458.

See also #2180.

"xcsoar does not calculate a precise arrival height to any point on the map unless a point is explicitly selected."

This statement is factually incorrect. In order to find if an "X" should be displayed, XCSoar must calculate a precise arrival height to MANY points along the path/line that connects the glider and the selected target waypoint. None of these points has been explicitly selected. Then xcsoar compares the arrival altitude at each one of these points and the terrain elevation + margin at such point and the closest instance (if any) in which the arrival altitude is lower, gets the "X". If the arrival altitude is always higher along the path, then the "X" will not be displayed but still the points along the line are evaluated all the way to the selected waypoint.

All we are asking in this request is basically to save and display the Largest Negative Value encountered during these individual computations. This is already calculated anyways. This value represents the altitude gain required to clear the terrain to reach the selected waypoint.

Therefore, I recommend to take this feature back from the Wishlist into active development for version 6.5.

This feature is currently standard in ALL available soaring software, except XCSoar.

Replying to davida:

This statement is factually incorrect. In order to find if an "X" should be displayed, XCSoar must calculate a precise arrival height to MANY points along the path/line that connects the glider and the selected target waypoint.

Obviously you know the code better than me. Please point me to the source.

But as a hint: We have a reach polygon (a polygon whose internal area is reachable according the configured terrain safety margin) and that X is drawn at the place where a line extending from the glider to your target intersects that polygon. We never explicitly calculate the height profile on that line. That is a simplified explanation - in reality it is a bit more complex.

Sorry David, I didn't mean to cause your request to drop into wishlist... While I understand apf explanation why it may not be as simple as we hoped, I am surprised that XCSoar can not solve a problem which other less sophisticated flight computers already solved long time ago. Winpilot for example was able to provide this information for many years.
I think this enhancement worth an effort and should be much higher priority. Here is a real life example from few weeks ago to illustrate:
I spent nearly 2 hours on the other side of the ridge from my home airport in very weak lift trying to get high enough to make it back. During the whole time XCSoar was telling me that I had final glide home through terrain, but could not tell me how much I needed to climb to clear the terrain. I was committed to land in another airport until I could climb high enough to clear the terrain, but how high?? I was flying with the best soaring software in the world which could tell me almost everything except the most important piece of info. I had to guestimate and eventually climbed high enough that the X disappeared so I could make it back. This info is very tactical. If I only needed couple of hundred feet (as was the case in hindsight) I should keep trying, if on the other hand I needed 1000 feet or more it would have make more sense to land early enough to get an aerotow back.

Perhaps putting the number near the X may be misleading as the X is only the first point where terrain is encountered as apf says, a better place may be near the arrival altitude bar.

Thanks,

Ramy

Replying to ramy:

Sorry David, I didn't mean to cause your request to drop into wishlist... While I understand apf explanation why it may not be as simple as we hoped, I am surprised that XCSoar can not solve a problem which other less sophisticated flight computers already solved long time ago. Winpilot for example was able to provide this information for many years.
I think this enhancement worth an effort and should be much higher priority. Here is a real life example from few weeks ago to illustrate:
I spent nearly 2 hours on the other side of the ridge from my home airport in very weak lift trying to get high enough to make it back. During the whole time XCSoar was telling me that I had final glide home through terrain, but could not tell me how much I needed to climb to clear the terrain. I was committed to land in another airport until I could climb high enough to clear the terrain, but how high?? I was flying with the best soaring software in the world which could tell me almost everything except the most important piece of info. I had to guestimate and eventually climbed high enough that the X disappeared so I could make it back. This info is very tactical. If I only needed couple of hundred feet (as was the case in hindsight) I should keep trying, if on the other hand I needed 1000 feet or more it would have make more sense to land early enough to get an aerotow back.

Perhaps putting the number near the X may be misleading as the X is only the first point where terrain is encountered as apf says, a better place may be near the arrival altitude bar.

Thanks,

Ramy

Ramy,

Although I was indeed the one that wrote the ticket (so I guess it is "mine" in that sense) this is really for the benefit of all pilots, as you just experienced yourself. It just makes sense.

The scenario you describe that happened to you is exactly the scenario I imagined when I wrote it. It already happened to me a couple of times.

This is a no-brainer of a feature. I guess most pilots are not yet aware of this fundamental limitation of xcsoar.

I agree about the location of the value. An infobox and next to the X in the glide bar would be fine options to have.

Replying to apf:

Replying to davida:

This statement is factually incorrect. In order to find if an "X" should be displayed, XCSoar must calculate a precise arrival height to MANY points along the path/line that connects the glider and the selected target waypoint.

Obviously you know the code better than me. Please point me to the source.

But as a hint: We have a reach polygon (a polygon whose internal area is reachable according the configured terrain safety margin) and that X is drawn at the place where a line extending from the glider to your target intersects that polygon. We never explicitly calculate the height profile on that line. That is a simplified explanation - in reality it is a bit more complex.

Your explanation on how the X is drawn is not consistent with statements you have made on a different comment thread. Anyways, I wonder just how the polygon is calculated.....if not the way I stated but spanning 360 degrees at some discrete increments.

In any case, the implementation you described would not be very good since it does not seem to guarantee that the point in question will be a a vortice of the polygon. So the accuracy of the X would be needlessly compromised.

Let's drop the discussion about the technical side (I said the polygon is a simplification) for now which was all started because of the statement that everything is calculated already and one would simply have to display the value somewhere. The needed technical effort was not the main reason I moved this trac issue to the wish list.

My main objection to this feature request is something completely different in addition to the limited time the developers have:

I don't think that single margin is a useful value to the pilot for the evaluation of the situation and risks in the general case. It will probably work if the position with the minimum margin is the the only point on the flight path which could cause problems, e.g. a single ridge with terrain that does not become an issue on both sides. I have tried to explain that before (see comment 9). That single minimum value gives the false impression that the calculated position is always the most problematic one encountered on the intended path. But a second ridge further away with (currently) slightly higher margins which also has to be cleared in order to reach that safe landing point would not be used by xcsoar in the data presented to the pilot. With the simple terain safety margin clearing the first ridge might need a GR of 10, the second one a GR of 40. This could draw the pilot - thinking that the most problematic point can now crossed and flying over the first ridge - in a trap where he can neither fly back over the first ridge nor clear the second ridge (all it takes is a little bit of reduced performance). What we need to present to the pilot is information that allows a complete evaluation of the situation. For the reasons explained that single value does not allow that and can even lead to an dangerous underestimation of the risks (after all xcsoar said it is possible to clear the most problematic point).

The solutions I see which would present a bigger picture of the current situation are:

1. A cross section view of the planned path making it obvious where the problematic points are (only considering the straight path)
2. A GR based value which gives the GR needed to clear all obstacles on the path (also only considers the straight path but additionally needs a set "safe" target on the other side set by the pilot to base calculations on).
3. 1. or 2. based on a path proposal by our route planner
4. Something based on a refinement of the idea in #2458.

The solution is: The required altitude to clear the *whole* terrain. While the X is positioned at the first point, the number should, ideally, calculated to the most problematic point. I believe this is what Winpilot and all other software are doing. I think this is similar to your 2nd suggestion, but instead/in addition to GR provide the additional altitude required (taking safety margin and all other factors as usual) which can be calculated in the same manner (much more useful for pilot to know that he needs to climb 500 feet more than telling him the required GR to clear the terrain).
I took a quick look at #2458 and while I think it is a fantastic idea, if I understand it correct it will still not tell you how much you need to climb to clear terrain. This is a challenge we have in almost every flight in the mountain area in Western US.
Again, this challenge already addressed by most if not all other soaring software, so why not look at their implementation? I think XCSOar is often trying to be too perfect. Remember that perfect is the enemy of good.

Replying to apf:

Let's drop the discussion about the technical side (I said the polygon is a simplification) for now which was all started because of the statement that everything is calculated already and one would simply have to display the value somewhere. The needed technical effort was not the main reason I moved this trac issue to the wish list.

My main objection to this feature request is something completely different in addition to the limited time the developers have:

I don't think that single margin is a useful value to the pilot for the evaluation of the situation and risks in the general case. It will probably work if the position with the minimum margin is the the only point on the flight path which could cause problems, e.g. a single ridge with terrain that does not become an issue on both sides. I have tried to explain that before (see comment 9). That single minimum value gives the false impression that the calculated position is always the most problematic one encountered on the intended path. But a second ridge further away with (currently) slightly higher margins which also has to be cleared in order to reach that safe landing point would not be used by xcsoar in the data presented to the pilot. With the simple terain safety margin clearing the first ridge might need a GR of 10, the second one a GR of 40. This could draw the pilot - thinking that the most problematic point can now crossed and flying over the first ridge - in a trap where he can neither fly back over the first ridge nor clear the second ridge (all it takes is a little bit of reduced performance). What we need to present to the pilot is information that allows a complete evaluation of the situation. For the reasons explained that single value does not allow that and can even lead to an dangerous underestimation of the risks (after all xcsoar said it is possible to clear the most problematic point).

The solutions I see which would present a bigger picture of the current situation are:

1. A cross section view of the planned path making it obvious where the problematic points are (only considering the straight path)
2. A GR based value which gives the GR needed to clear all obstacles on the path (also only considers the straight path but additionally needs a set "safe" target on the other side set by the pilot to base calculations on).
3. 1. or 2. based on a path proposal by our route planner
4. Something based on a refinement of the idea in #2458.

The previous soaring software I used for many years, before xcsoar, had this terrain profile. Even more so, it elegantly displayed the profile alongside the moving map, so there was no need to switch pages. I can only tell you that I never used it. On the other hand, the margin over terrain ahead (that we ask for here) I used almost every flight, since I fly mostly in the mountains.

My conclusion is that the most useful item is the single quantitative measure we have been asking for. This comes from actual extensive flight experience, not theory. From the list of items you presented we really need item 2 but not as a Glide Ratio but as a margin in feet, readily visible on the main map and as an infobox, not on a separate page or view. This is what this ticket is about. A single and simple measure that tells us how many feet we need to climb now to clear all obstacles to the path to the selected destination.

Experienced pilots don't start on the final glide and forget what they are doing. They constantly monitor the glide for degradation or improvement and adjust accordingly. There can be 2 ridges ahead, but that is irrelevant since as soon as we clear the first one (if it was the limiting one), then the software provides a new calculation for the second one and we can make a decision at that point. As we continue to the second ridge, we keep tabs on the previous ridge to make sure we can make it back if conditions deteriorate going forward. In any case, it is the pilot's responsibility to have an alternate at all times if things don't go as planned.

Nothing precludes doing the terrain profile you mentioned to address the most general case, other than in my opinion the limited utility and developer time. I strongly believe the parameter we request here provides the most benefit for the amount of effort.