Nothing to add, exactly what I meant. There is a request to show the required L/D on the airport labels instead and we would want to make this configurable anyway. I don't think it would be too hard to also provide an additional option to differentiate between the two options I mentioned in the last post.
Turbo 2011/11/22 Sascha Haffner <s_haff...@yahoo.com>: > Hi Tobias, > > thank you ... I can only support your suggestion. > > You probably meant it, but just to make it clear the Arrival Altitude would > include: > - Height above ground of the selected waypoint also displayed in the > waypoint label > - Considering, wind, bugs, MC setting or at least safety MC setting (and > even the recently discussed degradation % value) > - Also considering safety altitude? (for me not neccessary, I can decide > depending on the situation if 0m, 200m or even 500m arrival altitude is > safe). > - Considering, also flight around terrain, airspace, but configurable on/off > > Any thoughts? > > Sascha > Von: Tobias Bieniek <tobias.bien...@gmx.de> > An: > Cc: "xcsoar-user@lists.sourceforge.net" <xcsoar-user@lists.sourceforge.net> > Gesendet: 12:06 Dienstag, 22.November 2011 > Betreff: Re: [Xcsoar-user] XCSoar 6.2.3 released > > Hi everyone, > > I think I found one possible cause of the confusion. We are not > seperating the two values properly and I actually noticed that before > on some other occasions in the code itself. We should at least start > to use the right names for both values and I would propose the > following: > > Arrival Altitude: The altitude that you would arrive at the airfield > assuming a pure glide to it without circling involved and thus no > circling drift. > > Required Altitude: The amount of altitude that is required to reach > the airfield. This would include the circling drift since you actually > need to climb this altitude because otherwise you wouldn't reach it. > This value however should strictly have the opposite sign, so I'm not > quite sure if it's the right name for it. Required Altitude is also a > little ambiguous since it could also mean the actual altitude on which > you should leave the next thermal if you want to reach your > destination. I'm open for suggestions here. > > Once these terms are defined properly, we (the developers) should > revisit the source code and check whether they are used properly. I > can't think of a better solution so far than making the displayed > numbers configurable, but I'm open to suggestions. The traffic on the > mailing list about this topic should be a simple indicator that this > is an important topic and that there are plenty of opinions about it. > > Turbo > > > 2011/11/22 Sascha Haffner <s_haff...@yahoo.com>: >> Hi, >> >> the intensity and length of our discussion shows that people feel strongly >> about the respective way of calculating AltRequired because they each >> "feel >> safe" when they see the expected values according to their experience and >> their routines. Therefore there is no right or wrong way of calculating / >> displaying this, just different ones and I would be happy if XCSoar would >> acknowledge both ways. >> >> As for myself I prefer the way the LX, Cambridge etc. instruments >> calculate >> the AltRequired to a single waypoint and I use XCSoar the same way Scott >> described, but that is not the point - it would be best to find a solution >> and I have to admit, I can't (yet) suggest a clean and elegant one. I can >> see John's point, that making XCSoar configurable in that way might >> confuse >> newcomers, but I can't think of an alternative. >> >> To summarize things: The altreq. value shown on the glide bar and the >> labels >> is computed differently since the new solver was introduced with vers. >> 6.1.x. I believe. The last stable vers. using the old solver was vers. >> 6.0.10. The new way seems to lead to fast dropping values of altreq. >> shown >> in the glide bar when wrongly circling in a lift to weak to compensate for >> the drift while circling, which is scientifically correct, but is >> different >> from hardwired computers (e.g. Cambridge, LX etc.). >> >> Now getting back to a possible solution. Please correct me if I am wrong, >> the glide bar is intended to show the total altreq. for the complete task >> and therefore helpful when in competition. The altreq. displayed next to >> the labels Max Kellermann explained recently to me are calculated >> differently by separate solvers considering flight around terrain, >> airspace, safety MC, wind etc. (vers. 6.1.x and newer). Therefore one >> experiences slight difference in the altreq. values displayed in the glide >> bar and on the labels (when above glidepath). If XCSoars already uses >> different methods for glide bar and labels, couldn't we make the glide bar >> configurable for a) task mode (as implemented in 6.2.3) and b) abort mode, >> meaning a task to a single (final) waypoint, showing the same value as the >> label shows and using the "old" method. So if below glide path the label >> would show "not reachable" while the glide bar would show the e.g. >> -500feet >> below glide path. How one gets above glide path is up to the pilot and >> his >> decision whether to circle, chance an outlanding or hope for lift during >> straight flight etc. >> >> Any thoughts for solutions? And many thanks to the developers for their >> hard work and for following and allowing this discussion. >> >> Cheers, >> Sascha >> >> >> Von: David Lawley <davidlaw...@hotmail.com> >> An: tangoei...@gmail.com; m...@duempel.org >> Cc: xcsoar-user@lists.sourceforge.net >> Gesendet: 2:10 Dienstag, 22.November 2011 >> Betreff: Re: [Xcsoar-user] XCSoar 6.2.3 released >> >> My only comment is i was perfectly happy with the behaviour of final glide >> in 5.2, everytime it predicted the final glides perfectly. >> >> Storm in a teacup methinks! >> >> Dave >> >>> From: tangoei...@gmail.com >>> Date: Mon, 21 Nov 2011 19:11:09 -0500 >>> To: m...@duempel.org >>> CC: xcsoar-user@lists.sourceforge.net >>> Subject: Re: [Xcsoar-user] XCSoar 6.2.3 released >>> >>> >>> On Nov 21, 2011, at 5:48 PM, Max Kellermann wrote: >>> >>> > On 2011/11/21 23:40, Evan Ludeman <tangoei...@gmail.com> wrote: >>> >> Sorry John, no sale. We need height relative to glide slope at a pilot >>> >> selectable Mc setting for final glide. If that's being eliminated in >>> >> preference wind dependent height of climb required, that's a poor >>> >> choice. >>> > >>> > What XCSoar shows is not the height relative to the glide slope. >>> > >>> > What XCSoar shows is how much you need to climb to reach your goal. >>> > >>> > The height relative to the glide slope is a theoretical number that is >>> > of no practical use for a glider, even if it might be appealing to >>> > calculate it, and even if it gives you the illusion that it is useful. >>> > >>> > Max >>> > >>> >>> I disagree, rather strongly. >>> >>> 30 miles out on final glide, 500' below glide slope, I am not looking for >>> a thermal to center and circle in, I am looking for enroute lift to get >>> up >>> to a comfortable final glide. The height below glide slope is preferable >>> to >>> height required to climb (in circling). I'm rather astonished to find out >>> about how XCS is doing these calculations, I didn't know this but in >>> retrospect it does explain (perhaps) some of the discrepancies I have >>> noted >>> between XCS and my C-302/303. As previously noted, I always go with the >>> 302/303 as primary reference for final glide. >>> >>> This whole conversation completely astonishes me. I never suspected that >>> anyone doubted the utility of height relative to glide slope for final >>> glide. >>> >>> It appears to me that there are some who are out to put "all the brains >>> in >>> the box". That's an interesting intellectual and software engineering >>> challenge to be sure, but it's not what I am interested in. I am solely >>> interested in aids to my situational awareness. I find height relative to >>> glide slope to be such an aid. Height required to climb given an assumed >>> thermal strength... not so much. >>> >>> -Evan >>> >>> >>> ------------------------------------------------------------------------------ >>> All the data continuously generated in your IT infrastructure >>> contains a definitive record of customers, application performance, >>> security threats, fraudulent activity, and more. Splunk takes this >>> data and makes sense of it. IT sense. And common sense. >>> http://p.sf.net/sfu/splunk-novd2d >>> _______________________________________________ >>> Xcsoar-user mailing list >>> Xcsoar-user@lists.sourceforge.net >>> https://lists.sourceforge.net/lists/listinfo/xcsoar-user >> >> >> ------------------------------------------------------------------------------ >> All the data continuously generated in your IT infrastructure >> contains a definitive record of customers, application performance, >> security threats, fraudulent activity, and more. Splunk takes this >> data and makes sense of it. IT sense. And common sense. >> http://p.sf.net/sfu/splunk-novd2d >> _______________________________________________ >> Xcsoar-user mailing list >> Xcsoar-user@lists.sourceforge.net >> https://lists.sourceforge.net/lists/listinfo/xcsoar-user >> >> >> >> >> ------------------------------------------------------------------------------ >> All the data continuously generated in your IT infrastructure >> contains a definitive record of customers, application performance, >> security threats, fraudulent activity, and more. Splunk takes this >> data and makes sense of it. IT sense. And common sense. >> http://p.sf.net/sfu/splunk-novd2d >> _______________________________________________ >> Xcsoar-user mailing list >> Xcsoar-user@lists.sourceforge.net >> https://lists.sourceforge.net/lists/listinfo/xcsoar-user >> >> > > ------------------------------------------------------------------------------ > All the data continuously generated in your IT infrastructure > contains a definitive record of customers, application performance, > security threats, fraudulent activity, and more. Splunk takes this > data and makes sense of it. IT sense. And common sense. > http://p.sf.net/sfu/splunk-novd2d > _______________________________________________ > Xcsoar-user mailing list > Xcsoar-user@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/xcsoar-user > > > > ------------------------------------------------------------------------------ > All the data continuously generated in your IT infrastructure > contains a definitive record of customers, application performance, > security threats, fraudulent activity, and more. Splunk takes this > data and makes sense of it. IT sense. And common sense. > http://p.sf.net/sfu/splunk-novd2d > _______________________________________________ > Xcsoar-user mailing list > Xcsoar-user@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/xcsoar-user > > ------------------------------------------------------------------------------ All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity, and more. Splunk takes this data and makes sense of it. IT sense. And common sense. http://p.sf.net/sfu/splunk-novd2d _______________________________________________ Xcsoar-user mailing list Xcsoar-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/xcsoar-user
