Re: [Flightgear-devel] --metar and --enable-real-weather-fetch
John Denker wrote: On 05/24/2009 02:58 AM, Torsten Dreyer wrote in part: Step #2 Add an option --metar= - this implies --disable-real-weather-fetch and set scenario to METAR - make the metar string editable in the weather_scenario dialog This option needs some changes in the logic of real-weather-fetch and scenario usage. Ideas and comments are welcome. If I play in someone elses sandbox here, please complain! As the saying goes, it's hard to make anything foolproof, because fools are so ingenious. Let's consider the following scenario: Suppose some ingenious user specifies --metar=$whatever --enable-real-weather-fetch in that order. Things get iteresting because Torsten's code uses the metar/data variable for one purpose, and ties a Nasal listener to it ... while Erik's code uses the same metar/data variable for another purpose, and ties some c++ functions to it. This can't be good. Error messages are generated, but not the sort that typical users will benefit from. I was under the impression that setting --metar disables real weather fetch. Is the specific problem with the ordering? Another suggestion: If the --metar and --real-weather-fetch options really are incompatible, this ought to be mentioned in the user documentation, not just in some email in the archive. And there should be runtime checks that enforce the requirement, -- no matter the order in which the options are specified -- and misuse should result in user-friendly warnings. I'm currently updating the Manual section that lists the command-line options. This was quite out of date (as was the --help --verbose text). I'll ensure that the Manual mentions that these options are incompatible. In any case, the documentation for --metar would benefit from an _example_ of its proper use. As the saying goes, an ounce of example beats a ton of BNF. I believe --metar= 012345Z 0KT 99SM CLR 59/M01 A2992 is a correct and useful example ... but somebody should double check. Thanks for the example - I'll include it in the docs. My only comment is that I thought the temperature was in centrigrade (at least it is in the UK), so 59 would be quite hot (plus we use different altimeter units). -- This SF.Net email is sponsored by the Verizon Developer Community Take advantage of Verizon's best-in-class app development support A streamlined, 14 day to market process makes app distribution fast and easy Join now and get one step closer to millions of Verizon customers http://p.sf.net/sfu/verizon-dev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] --metar and --enable-real-weather-fetch
On 12/20/2009 12:54 PM, Stuart Buchanan wrote: I believe --metar= 012345Z 0KT 99SM CLR 59/M01 A2992 is a correct and useful example ... but somebody should double check. Thanks for the example - I'll include it in the docs. My only comment is that I thought the temperature was in centrigrade (at least it is in the UK), so 59 would be quite hot (plus we use different altimeter units). Good catch. That's why we check these things. Metar temps are centigrade, even in the US. I should have said: --metar= 012345Z 0KT 99SM CLR 15/M01 A2992 Sorry. The altimeter setting is unambiguous; the alternative to A2992 is Q1013 with a Q (short for QNH). Similarly if the SM is left off, the visibility is in _meters_ (not km). I trust FG can parse the metric and non-metric items in all combinations (although I haven't checked). = As a separate issue: With rare exceptions, the largest visibility you will see reported in a metar is 10SM (in the US) or (meters, elsewhere). This is a problem for real-weather fetch, because the _reported_ visibility can be significantly less than the _real_ visibility. I have tried to think of a heuristic to solve this problem, without success. Sometimes a report of 10SM means 10SM and no more, but sometimes it means unlimited visibility. In TAFs you sometimes get a forecast of P6SM which is French for plus que 6SM i.e. more than 6SM. But this does not apply to metars and doesn't solve the problem. The FG scenery looks nice when the visibility is unlimited. It would be a shame to stumble into a situation where typical users were stuck with 10SM visibility instead of the really real visibility. This is no problem for a manually entered metar; I can enter 99SM no problem. It's just a problem for real weather fetch. The bold solution would be to map 10SM and meters to unlimited visibility ... but I'm not bold enough to recommend that. Any suggestions? -- This SF.Net email is sponsored by the Verizon Developer Community Take advantage of Verizon's best-in-class app development support A streamlined, 14 day to market process makes app distribution fast and easy Join now and get one step closer to millions of Verizon customers http://p.sf.net/sfu/verizon-dev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] --metar and --enable-real-weather-fetch
As a separate issue: With rare exceptions, the largest visibility you will see reported in a metar is 10SM (in the US) or (meters, elsewhere). This is a problem for real-weather fetch, because the _reported_ visibility can be significantly less than the _real_ visibility. I have tried to think of a heuristic to solve this problem, without success. Sometimes a report of 10SM means 10SM and no more, but sometimes it means unlimited visibility. [...] The FG scenery looks nice when the visibility is unlimited. It would be a shame to stumble into a situation where typical users were stuck with 10SM visibility instead of the really real visibility. [...] The bold solution would be to map 10SM and meters to unlimited visibility ... but I'm not bold enough to recommend that. From a users viewpoint, 10SM on a monitor looks like less to the eye than 10SM looking out the window. It would be a disservice to the scenery to run the risk of unlimited visibility being presented as 10SM. IMHO there is no choice other than the bold solution- anything reported as 10SM = unlimited, and 9.99 and less is actual. Peter Brown Sent from Smooth Water Sports, your Malibu Boat Dealer -- This SF.Net email is sponsored by the Verizon Developer Community Take advantage of Verizon's best-in-class app development support A streamlined, 14 day to market process makes app distribution fast and easy Join now and get one step closer to millions of Verizon customers http://p.sf.net/sfu/verizon-dev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] --metar and --enable-real-weather-fetch
* Peter Brown -- Sunday 20 December 2009: IMHO there is no choice other than the bold solution- anything reported as 10SM = unlimited, and 9.99 and less is actual. And so guaranteeing the lowest possible frame rate? Sounds like a truly bad idea. The whole thing has been discussed before. (Threads Flying over an island and Estimating visibility). Thomas FOERSTER announced that he'd use some Bayesian analysis to get a formula from various available parameters, such as temperatures, air pressure etc. http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg15710.html http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg15843.html http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg15851.html In any case, if someone writes a heuristic, then this does *not* belong into SGMetar but FGMetar. Unless the weather subsystem is the next which is going to be ruined ... m. -- This SF.Net email is sponsored by the Verizon Developer Community Take advantage of Verizon's best-in-class app development support A streamlined, 14 day to market process makes app distribution fast and easy Join now and get one step closer to millions of Verizon customers http://p.sf.net/sfu/verizon-dev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] --metar and --enable-real-weather-fetch
I'll take a look at those links, thanks. My impression is that a good percentage of users are not to the point of using metar, and apparently may use unlimited all the time. I don't know if there is any data to support that, but I've not seen a low frame rate outside of ksfo. Of the other hand its a way to weed out the gamer... Just thoughts I'm sure were considered before. Peter Brown --Original Message-- From: Melchior FRANZ To: flightgear-devel@lists.sourceforge.net ReplyTo: FlightGear developers discussions Subject: Re: [Flightgear-devel] --metar and --enable-real-weather-fetch Sent: Dec 20, 2009 4:38 PM * Peter Brown -- Sunday 20 December 2009: IMHO there is no choice other than the bold solution- anything reported as 10SM = unlimited, and 9.99 and less is actual. And so guaranteeing the lowest possible frame rate? Sounds like a truly bad idea. The whole thing has been discussed before. (Threads Flying over an island and Estimating visibility). Thomas FOERSTER announced that he'd use some Bayesian analysis to get a formula from various available parameters, such as temperatures, air pressure etc. http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg15710.html http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg15843.html http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg15851.html In any case, if someone writes a heuristic, then this does *not* belong into SGMetar but FGMetar. Unless the weather subsystem is the next which is going to be ruined ... m. -- This SF.Net email is sponsored by the Verizon Developer Community Take advantage of Verizon's best-in-class app development support A streamlined, 14 day to market process makes app distribution fast and easy Join now and get one step closer to millions of Verizon customers http://p.sf.net/sfu/verizon-dev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel Sent from Smooth Water Sports, your Malibu Boat Dealer -- This SF.Net email is sponsored by the Verizon Developer Community Take advantage of Verizon's best-in-class app development support A streamlined, 14 day to market process makes app distribution fast and easy Join now and get one step closer to millions of Verizon customers http://p.sf.net/sfu/verizon-dev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] --metar and --enable-real-weather-fetch
I had looked at some research papers at that time, which were about estimating visibility from other, measurable factors. I stopped when Thomas announced his solution. My original idea was a simple formula, based on the idea that: - visibility is derived from humidity (high humidity - low visibility due to water drops) - higher temperature decreases visibility (molecule movements) - higher wind speeds decrease visibility (more dust blown up) - higher AGL increases visibility (no dust) - smog was hard to estimate, as there was no reliable way to find out if there are bigger cities nearby (checking for distance of next airport with concrete runway of a certain minimum length might work); ground material might have an influence, but isn't very reliable All that would have to consider that METAR is weather at station level. This wouldn't have to be very accurate. Simple variability was already an improvement, while randomness was not acceptable (same weather should yield same visibility for MP or sync'ed machines). * Peter Brown -- Sunday 20 December 2009: Of the other hand its a way to weed out the gamer... One of FlightGear's main goals is realism, not to weed out *any* kind of user. Maybe you are wrong here?! m. -- This SF.Net email is sponsored by the Verizon Developer Community Take advantage of Verizon's best-in-class app development support A streamlined, 14 day to market process makes app distribution fast and easy Join now and get one step closer to millions of Verizon customers http://p.sf.net/sfu/verizon-dev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] --metar and --enable-real-weather-fetch
I was not suggesting that FG did want to weed anyone out, but as someone new to the list, I'm gaining knowledge and a better viewpoint with each discussion. I appreciate your response Melchior, and I hope you don't take my responses as being arrogant. Peter --Original Message-- From: Melchior FRANZ To: flightgear-devel@lists.sourceforge.net ReplyTo: FlightGear developers discussions Subject: Re: [Flightgear-devel] --metar and --enable-real-weather-fetch Sent: Dec 20, 2009 5:18 PM I had looked at some research papers at that time, which were about estimating visibility from other, measurable factors. I stopped when Thomas announced his solution. My original idea was a simple formula, based on the idea that: - visibility is derived from humidity (high humidity - low visibility due to water drops) - higher temperature decreases visibility (molecule movements) - higher wind speeds decrease visibility (more dust blown up) - higher AGL increases visibility (no dust) - smog was hard to estimate, as there was no reliable way to find out if there are bigger cities nearby (checking for distance of next airport with concrete runway of a certain minimum length might work); ground material might have an influence, but isn't very reliable All that would have to consider that METAR is weather at station level. This wouldn't have to be very accurate. Simple variability was already an improvement, while randomness was not acceptable (same weather should yield same visibility for MP or sync'ed machines). * Peter Brown -- Sunday 20 December 2009: Of the other hand its a way to weed out the gamer... One of FlightGear's main goals is realism, not to weed out *any* kind of user. Maybe you are wrong here?! m. -- This SF.Net email is sponsored by the Verizon Developer Community Take advantage of Verizon's best-in-class app development support A streamlined, 14 day to market process makes app distribution fast and easy Join now and get one step closer to millions of Verizon customers http://p.sf.net/sfu/verizon-dev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel Sent from Smooth Water Sports, your Malibu Boat Dealer -- This SF.Net email is sponsored by the Verizon Developer Community Take advantage of Verizon's best-in-class app development support A streamlined, 14 day to market process makes app distribution fast and easy Join now and get one step closer to millions of Verizon customers http://p.sf.net/sfu/verizon-dev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] --metar and --enable-real-weather-fetch
On 05/24/2009 02:58 AM, Torsten Dreyer wrote in part: Step #2 Add an option --metar=arbitrary handcoded METAR - this implies --disable-real-weather-fetch and set scenario to METAR - make the metar string editable in the weather_scenario dialog This option needs some changes in the logic of real-weather-fetch and scenario usage. Ideas and comments are welcome. If I play in someone elses sandbox here, please complain! As the saying goes, it's hard to make anything foolproof, because fools are so ingenious. Let's consider the following scenario: Suppose some ingenious user specifies --metar=$whatever --enable-real-weather-fetch in that order. Things get iteresting because Torsten's code uses the metar/data variable for one purpose, and ties a Nasal listener to it ... while Erik's code uses the same metar/data variable for another purpose, and ties some c++ functions to it. This can't be good. Error messages are generated, but not the sort that typical users will benefit from. Possibly constructive suggestion: Rather than have one variable with two incompatible uses, why not have two variables. Rather than metar/data we could have metar/text or metar/manual (for the text of the manually-entered metar) metar/site or metar/id (for the ICAO identifier of the metar source) A split like this would make the code more understandable and more maintainable. Another suggestion: If the --metar and --real-weather-fetch options really are incompatible, this ought to be mentioned in the user documentation, not just in some email in the archive. And there should be runtime checks that enforce the requirement, -- no matter the order in which the options are specified -- and misuse should result in user-friendly warnings. OTOH it's not entirely obvious to me that these options are irredeemably incompatible. I can imagine switching in and out of manual mode at runtime, with metar/manual be actively used during manual mode, and being only a standby otherwise. In any case, the documentation for --metar would benefit from an _example_ of its proper use. As the saying goes, an ounce of example beats a ton of BNF. I believe --metar= 012345Z 0KT 99SM CLR 59/M01 A2992 is a correct and useful example ... but somebody should double check. -- This SF.Net email is sponsored by the Verizon Developer Community Take advantage of Verizon's best-in-class app development support A streamlined, 14 day to market process makes app distribution fast and easy Join now and get one step closer to millions of Verizon customers http://p.sf.net/sfu/verizon-dev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
