Re: [Flightgear-devel] METAR loading rules
The metar realwx controller checks every 60 seconds for a station reporting metar and loads that data if the station id has changed since the last check. It also rechecks the metar every 15 minutes for the unchanged station. Okay, so every 60 seconds, the controller * determines what the nearest station given current location is * if that station has changed and is closer than 10.000 miles, a METAR is retrieved * if that station has not changed, but 15 minutes have passed and the station is closer than 10.000 miles, a METAR is retrieved * otherwise no METAR is fetched * and wait another 60 seconds This means that if I use a 1/distance^n interpolation and have one weather station, a second one always has a weight factor of 1/2 when it appears... which explains why my winds jumped so suddenly before I started to fade new stations in with a time-dependent weight. But that's actually good, because on a transatlantic flight this means I will get to know the destination weather hundreds of miles in advance, so there is ample time to gradually bias the offline weather system into the right pattern. Thanks a lot! Cheers, * Thorsten -- Free Software Download: Index, Search Analyze Logs and other IT data in Real-Time with Splunk. Collect, index and harness all the fast moving IT data generated by your applications, servers and devices whether physical, virtual or in the cloud. Deliver compliance at lower cost and gain new business insights. http://p.sf.net/sfu/splunk-dev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] METAR wrong, at least on one airport
On Nov 15, Guy Brand wrote: So I ran the metar command from the CLI to see what it told. That gives the same result for this particular airport. I was using git revision 0917a5e0. Upgrading to the current git revision 5bb247d4 also shows the same result. I haven't found another airport for which the METAR information is wrong/outdated (LFPO, KSFO, KJFK, EHAM showed correct METAR and date). Sorry, maybe I wasn't clear enough. FlightGear displays outdated METAR for LFST, ok (this can happend, and I understand the reason why a METAR data could be obsolete). FlightGear comes with a line command client called metar which also retrieves the obsolete METAR data for LFST. If I check the METAR data for LFST using another program (AeroWeather on the iPhone for example or the metar utility for debian from the http://packages.debian.org/unstable/utils/metar package), I receive correct METAR data for LFST. So METAR fetching in FlightGear is wrong. -- bug -- Beautiful is writing same markup. Internet Explorer 9 supports standards for HTML5, CSS3, SVG 1.1, ECMAScript5, and DOM L2 L3. Spend less time writing and rewriting code and more time creating great experiences on the web. Be a part of the beta today http://p.sf.net/sfu/msIE9-sfdev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] METAR wrong, at least on one airport
But would it be possible to accept old data, just not time going backwards. I feel any METAR data is better than none, so perhaps; 1. accept any any valid METAR data, log warning message if it is old, 2. don't update METAR data if the date is older than current METAR date, log severe message. you can set the maximum allowed age of METAR reports by setting /environment/params/metar-max-age-min to you prefered maximum age in minutes. -- Beautiful is writing same markup. Internet Explorer 9 supports standards for HTML5, CSS3, SVG 1.1, ECMAScript5, and DOM L2 L3. Spend less time writing and rewriting code and more time creating great experiences on the web. Be a part of the beta today http://p.sf.net/sfu/msIE9-sfdev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] METAR wrong, at least on one airport
If I check the METAR data for LFST using another program (AeroWeather on the iPhone for example or the metar utility for debian from the http://packages.debian.org/unstable/utils/metar package), I receive correct METAR data for LFST. So METAR fetching in FlightGear is wrong. FlightGear uses NOAA as a data source for METAR. The url to fetch the data is http://weather.noaa.gov/pub/data/observations/metar/stations/.txt where xxx is the ICAO 4-Letter code of the airport in uppercase. We simply rely on the NOAA data - if the return outdated METAR to our request, we are lost. Currently I receive up-to-date METAR for LFST, so I assume a hickup on the noaa server. Torsten -- Beautiful is writing same markup. Internet Explorer 9 supports standards for HTML5, CSS3, SVG 1.1, ECMAScript5, and DOM L2 L3. Spend less time writing and rewriting code and more time creating great experiences on the web. Be a part of the beta today http://p.sf.net/sfu/msIE9-sfdev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] METAR wrong, at least on one airport
On Nov 16, Torsten Dreyer wrote: FlightGear uses NOAA as a data source for METAR. The url to fetch the data is http://weather.noaa.gov/pub/data/observations/metar/stations/.txt where xxx is the ICAO 4-Letter code of the airport in uppercase. We simply rely on the NOAA data - if the return outdated METAR to our request, we are lost. Currently I receive up-to-date METAR for LFST, so I assume a hickup on the noaa server. Thank you for your answer. -- bug -- Beautiful is writing same markup. Internet Explorer 9 supports standards for HTML5, CSS3, SVG 1.1, ECMAScript5, and DOM L2 L3. Spend less time writing and rewriting code and more time creating great experiences on the web. Be a part of the beta today http://p.sf.net/sfu/msIE9-sfdev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] METAR wrong, at least on one airport
On Tue, 2010-11-16 at 17:52 +0100, Torsten Dreyer wrote: If I check the METAR data for LFST using another program (AeroWeather on the iPhone for example or the metar utility for debian from the http://packages.debian.org/unstable/utils/metar package), I receive correct METAR data for LFST. So METAR fetching in FlightGear is wrong. FlightGear uses NOAA as a data source for METAR. The url to fetch the data is http://weather.noaa.gov/pub/data/observations/metar/stations/.txt where xxx is the ICAO 4-Letter code of the airport in uppercase. We simply rely on the NOAA data - if the return outdated METAR to our request, we are lost. Currently I receive up-to-date METAR for LFST, so I assume a hickup on the noaa server. Torsten I have also seen this twice (a week apart) for YSSY and just put it down to NOAA hiccup for a while (it lasted for more than 24 hours this hiccup..) But would it be possible to accept old data, just not time going backwards. I feel any METAR data is better than none, so perhaps; 1. accept any any valid METAR data, log warning message if it is old, 2. don't update METAR data if the date is older than current METAR date, log severe message. S. -- Beautiful is writing same markup. Internet Explorer 9 supports standards for HTML5, CSS3, SVG 1.1, ECMAScript5, and DOM L2 L3. Spend less time writing and rewriting code and more time creating great experiences on the web. Be a part of the beta today http://p.sf.net/sfu/msIE9-sfdev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] METAR wrong, at least on one airport
Hello Today I noticed this on the terminal: NoaaMetarRealWxController::fetchMetar(): dropping outdated METAR 2010/11/12 16:00 LFST 121600Z 19009KT 170V230 BKN030 13/09 Q1004 NOSIG NoaaMetarRealWxController::fetchMetar(): dropping outdated METAR 2010/11/12 16:00 LFST 121600Z 19009KT 170V230 BKN030 13/09 Q1004 NOSIG NoaaMetarRealWxController::fetchMetar(): dropping outdated METAR 2010/11/12 16:00 LFST 121600Z 19009KT 170V230 BKN030 13/09 Q1004 NOSIG NoaaMetarRealWxController::fetchMetar(): dropping outdated METAR 2010/11/12 16:00 LFST 121600Z 19009KT 170V230 BKN030 13/09 Q1004 NOSIG NoaaMetarRealWxController::fetchMetar(): dropping outdated METAR 2010/11/12 16:00 LFST 121600Z 19009KT 170V230 BKN030 13/09 Q1004 NOSIG So I ran the metar command from the CLI to see what it told. That gives the same result for this particular airport. I was using git revision 0917a5e0. Upgrading to the current git revision 5bb247d4 also shows the same result. I haven't found another airport for which the METAR information is wrong/outdated (LFPO, KSFO, KJFK, EHAM showed correct METAR and date). If there is anything more I can do to investigate the issue, let me know. -- bug -- Centralized Desktop Delivery: Dell and VMware Reference Architecture Simplifying enterprise desktop deployment and management using Dell EqualLogic storage and VMware View: A highly scalable, end-to-end client virtualization framework. Read more! http://p.sf.net/sfu/dell-eql-dev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] METAR wrong, at least on one airport
Guy Brand wrote: Today I noticed this on the terminal: NoaaMetarRealWxController::fetchMetar(): dropping outdated METAR 2010/11/12 16:00 LFST 121600Z [...] These are three days old. Current (almost) METAR looks like this: jive: 21:25:32 ~ metar LFST LFST 152000Z AUTO 34003KT 320V020 NDV -RA FEW013 SCT026 BKN034 07/06 Q1016 Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- -- Centralized Desktop Delivery: Dell and VMware Reference Architecture Simplifying enterprise desktop deployment and management using Dell EqualLogic storage and VMware View: A highly scalable, end-to-end client virtualization framework. Read more! http://p.sf.net/sfu/dell-eql-dev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] METAR wrong, at least on one airport
2010/11/12 16:00 LFST 121600Z 19009KT 170V230 BKN030 13/09 Q1004 NOSIG So I ran the metar command from the CLI to see what it told. That gives the same result for this particular airport. I was using git revision 0917a5e0. Upgrading to the current git revision 5bb247d4 also shows the same result. I haven't found another airport for which the METAR information is wrong/outdated (LFPO, KSFO, KJFK, EHAM showed correct METAR and date). This METAR is to old to be used as a weather source. Some airfield don't update their METAR regularly and some abandoned airfields don't update their METAR at all any more, but the last issued report persists in NOAA's database. To avoid rapid weather changes when hitting these airports enroute, theses reports are discarded. So, this is a feature - not a bug. Torsten BTW: you can set the maximum allowed age of METAR reports by setting /environment/params/metar-max-age-min to you prefered maximum age in minutes. -- Centralized Desktop Delivery: Dell and VMware Reference Architecture Simplifying enterprise desktop deployment and management using Dell EqualLogic storage and VMware View: A highly scalable, end-to-end client virtualization framework. Read more! http://p.sf.net/sfu/dell-eql-dev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] METAR stopped working
Unfortunately this means METAR is broken (probably permanently) for all previous FG versions now... As a follow-up to the METAR issue: there actually is a workaround for FG 1.9.x and 2.0 - by using a proxy server. The requests sent by FG to a configured proxy server are fine. And the actual HTTP request for the weather server is then generated by the proxy - which, of course, also works. So this revives METAR for older FG versions. Only takes a valid proxy server given to the fgfs command-line. More details in the forum: http://www.flightgear.org/forums/viewtopic.php?t=10002 cheers, Thorsten -- Centralized Desktop Delivery: Dell and VMware Reference Architecture Simplifying enterprise desktop deployment and management using Dell EqualLogic storage and VMware View: A highly scalable, end-to-end client virtualization framework. Read more! http://p.sf.net/sfu/dell-eql-dev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] METAR stopped working
On 05 Nov 2010, at 20:37, ThorstenB wrote: Anyway, what are the plans for the next FG release? Hi Thorsten, I have a gut feeling we might just have chatted about this; but anyways, after December 15 (approximately), My immediate workload is settling down a bit, and hoping that we may pull a build off of the hudson machine, it should be too hard to build a release sometime during the late part of December. Cheers, Durk-- The Next 800 Companies to Lead America's Growth: New Video Whitepaper David G. Thomson, author of the best-selling book Blueprint to a Billion shares his insights and actions to help propel your business during the next growth cycle. Listen Now! http://p.sf.net/sfu/SAP-dev2dev___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] METAR stopped working
On 7 Nov 2010, at 18:58, Durk Talsma wrote: I have a gut feeling we might just have chatted about this; but anyways, after December 15 (approximately), My immediate workload is settling down a bit, and hoping that we may pull a build off of the hudson machine, it should be too hard to build a release sometime during the late part of December. Right, I'm going to work with Gene (and anyone else!) to add automated steps to Hudson, such that there is zero work in cutting a release (or pre-release, or bug-fix release) beyond pressing one button on Hudson - tagging, make dist, uploading to flightgear.org and the mirrors, building of Mac + Windows installers should all be automated. Releasing software is no fun - let's make the computers do it :) James -- The Next 800 Companies to Lead America's Growth: New Video Whitepaper David G. Thomson, author of the best-selling book Blueprint to a Billion shares his insights and actions to help propel your business during the next growth cycle. Listen Now! http://p.sf.net/sfu/SAP-dev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] METAR stopped working
On Sun, 7 Nov 2010, James Turner wrote: On 7 Nov 2010, at 18:58, Durk Talsma wrote: I have a gut feeling we might just have chatted about this; but anyways, after December 15 (approximately), My immediate workload is settling down a bit, and hoping that we may pull a build off of the hudson machine, it should be too hard to build a release sometime during the late part of December. Right, I'm going to work with Gene (and anyone else!) to add automated steps to Hudson, such that there is zero work in cutting a release (or pre-release, or bug-fix release) beyond pressing one button on Hudson - tagging, make dist, uploading to flightgear.org and the mirrors, building of Mac + Windows installers should all be automated. We got quite a bit done today too. The backup is even automated. :D Fred, is there any advantage to using VS2010 to build the Windows binaries with over the VS2008 compiler? I don't follow the C++ side of the house so I don't know of any compiler improvements that FG would benefit from. g. -- Proud owner of F-15C 80-0007 http://www.f15sim.com - The only one of its kind. http://www.simpits.org/geneb - The Me-109F/X Project ScarletDME - The red hot Data Management Environment A Multi-Value database for the masses, not the classes. http://www.scarletdme.org - Get it _today_! Political correctness is a doctrine, fostered by a delusional, illogical minority, and rabidly promoted by an unscrupulous mainstream media, which holds forth the proposition that it is entirely possible to pick up a turd by the clean end. -- The Next 800 Companies to Lead America's Growth: New Video Whitepaper David G. Thomson, author of the best-selling book Blueprint to a Billion shares his insights and actions to help propel your business during the next growth cycle. Listen Now! http://p.sf.net/sfu/SAP-dev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] METAR stopped working
- Gene Buckle a écrit : Fred, is there any advantage to using VS2010 to build the Windows binaries with over the VS2008 compiler? I don't follow the C++ side of the house so I don't know of any compiler improvements that FG would benefit from. I'd stick to VS2008 until the next fg release. -Fred -- Frédéric Bouvier http://my.fotolia.com/frfoto/ Photo gallery - album photo http://www.youtube.com/user/fgfred64 Videos -- The Next 800 Companies to Lead America's Growth: New Video Whitepaper David G. Thomson, author of the best-selling book Blueprint to a Billion shares his insights and actions to help propel your business during the next growth cycle. Listen Now! http://p.sf.net/sfu/SAP-dev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] METAR stopped working
Thanks. I think it is pretty inconsiderate of the NOAA to change this two days before our largest flightsim event worldwide :-D But as you pointed out, METAR will have stopped working for older releases too. Which is even worse. m Op 05-11-10 20:37, ThorstenB schreef: That was a problem with the simgear METAR loader. Obviously NOAA is using a shared server for their websites now (one IP for several sites). The new webserver couldn't tell for which website we were asking for. HTTP requires a GET and a Host line - we were missing the latter. A fix is in GIT now. Unfortunately this means METAR is broken (probably permanently) for all previous FG versions now... Anyway, what are the plans for the next FG release? -- The Next 800 Companies to Lead America's Growth: New Video Whitepaper David G. Thomson, author of the best-selling book Blueprint to a Billion shares his insights and actions to help propel your business during the next growth cycle. Listen Now! http://p.sf.net/sfu/SAP-dev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] METAR stopped working
Hello, to avoid this happen again in the future: Is it possible to add a metar-server functionality to the mpservers? If the NOAA protocol / access changes we only have to modify the mpservers, not the clients? Maik m schrieb am 06.11.2010 09:30: Thanks. I think it is pretty inconsiderate of the NOAA to change this two days before our largest flightsim event worldwide :-D But as you pointed out, METAR will have stopped working for older releases too. Which is even worse. m Op 05-11-10 20:37, ThorstenB schreef: That was a problem with the simgear METAR loader. Obviously NOAA is using a shared server for their websites now (one IP for several sites). The new webserver couldn't tell for which website we were asking for. HTTP requires a GET and a Host line - we were missing the latter. A fix is in GIT now. Unfortunately this means METAR is broken (probably permanently) for all previous FG versions now... Anyway, what are the plans for the next FG release? -- The Next 800 Companies to Lead America's Growth: New Video Whitepaper David G. Thomson, author of the best-selling book Blueprint to a Billion shares his insights and actions to help propel your business during the next growth cycle. Listen Now! http://p.sf.net/sfu/SAP-dev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel -- The Next 800 Companies to Lead America's Growth: New Video Whitepaper David G. Thomson, author of the best-selling book Blueprint to a Billion shares his insights and actions to help propel your business during the next growth cycle. Listen Now! http://p.sf.net/sfu/SAP-dev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] METAR stopped working
On 6 Nov 2010, at 08:46, Maik Justus wrote: to avoid this happen again in the future: Is it possible to add a metar-server functionality to the mpservers? If the NOAA protocol / access changes we only have to modify the mpservers, not the clients? Just to be clear, NOAA aren't being 'inconsiderate' - the FG code has been broken, and non-compliant, all along - it just happened to be a non-compliance the old servers tolerated. We weren't, prior to Thorsten's fix, sending a valid request - any cache, proxy or server would have been entirely permitted to ignore it. There's no need to postulate complex additions to our side - we should just check our HTTP compliance better! James -- The Next 800 Companies to Lead America's Growth: New Video Whitepaper David G. Thomson, author of the best-selling book Blueprint to a Billion shares his insights and actions to help propel your business during the next growth cycle. Listen Now! http://p.sf.net/sfu/SAP-dev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] METAR stopped working
Hmmm Something is not quite right yet. I have recompiled simgear and fgfs. I had METAR info this morning, but now after a restart, it says NIL again. Intermittend... Is METAR info read on more than one place? m -- The Next 800 Companies to Lead America's Growth: New Video Whitepaper David G. Thomson, author of the best-selling book Blueprint to a Billion shares his insights and actions to help propel your business during the next growth cycle. Listen Now! http://p.sf.net/sfu/SAP-dev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] METAR stopped working
Funny, I disabled METAR for global weather in the GUI and later set it to Live Data again, and now it is collecting METAR info again... without restarting. m Op 06-11-10 12:09, fiers...@zonnet.nl schreef: Hmmm Something is not quite right yet. I have recompiled simgear and fgfs. I had METAR info this morning, but now after a restart, it says NIL again. Intermittend... Is METAR info read on more than one place? -- The Next 800 Companies to Lead America's Growth: New Video Whitepaper David G. Thomson, author of the best-selling book Blueprint to a Billion shares his insights and actions to help propel your business during the next growth cycle. Listen Now! http://p.sf.net/sfu/SAP-dev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] METAR stopped working
On Saturday 06 November 2010 03:51:28 James Turner wrote: On 6 Nov 2010, at 08:46, Maik Justus wrote: to avoid this happen again in the future: Is it possible to add a metar-server functionality to the mpservers? If the NOAA protocol / access changes we only have to modify the mpservers, not the clients? Just to be clear, NOAA aren't being 'inconsiderate' - the FG code has been broken, and non-compliant, all along - it just happened to be a non-compliance the old servers tolerated. We weren't, prior to Thorsten's fix, sending a valid request - any cache, proxy or server would have been entirely permitted to ignore it. There's no need to postulate complex additions to our side - we should just check our HTTP compliance better! James I looked at the NOAA site last night. http://weather.noaa.gov/pub/data/observations/metar/stations/ There are some seriously old metar files mixed in there! http://weather.noaa.gov/pub/data/observations/metar/stations/ENLU.TXT for example, is from 02 JUN 2007! It would be nice if someone could figure out a way to guard against that! Thanks, Ron -- The Next 800 Companies to Lead America's Growth: New Video Whitepaper David G. Thomson, author of the best-selling book Blueprint to a Billion shares his insights and actions to help propel your business during the next growth cycle. Listen Now! http://p.sf.net/sfu/SAP-dev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] METAR stopped working
On Sat, 6 Nov 2010 12:23:33 -0600, Ron wrote in message 201011061223.33277.w...@jentronics.com: I looked at the NOAA site last night. http://weather.noaa.gov/pub/data/observations/metar/stations/ There are some seriously old metar files mixed in there! http://weather.noaa.gov/pub/data/observations/metar/stations/ENLU.TXT for example, is from 02 JUN 2007! It would be nice if someone could figure out a way to guard against that! ..easy now; how do we do historical weather? Or rather, how _should_ we do historical weather? E.g. of interest to air crash investigations? Custom event mp-servers? I understand you guys has set up a few air show mp servers here. -- ..med vennlig hilsen = with Kind Regards from Arnt... ;o) ...with a number of polar bear hunters in his ancestry... Scenarios always come in sets of three: best case, worst case, and just in case. -- The Next 800 Companies to Lead America's Growth: New Video Whitepaper David G. Thomson, author of the best-selling book Blueprint to a Billion shares his insights and actions to help propel your business during the next growth cycle. Listen Now! http://p.sf.net/sfu/SAP-dev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] METAR stopped working
Recompiled all very early this morning. I have just noticed that in global weather, there is no METAR data. METAR source is set to live data. In the METAR data box I read 'NIL'. Something broke the METAR updates? m -- The Next 800 Companies to Lead America's Growth: New Video Whitepaper David G. Thomson, author of the best-selling book Blueprint to a Billion shares his insights and actions to help propel your business during the next growth cycle. Listen Now! http://p.sf.net/sfu/SAP-dev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] METAR stopped working
On 5 Nov 2010, at 08:16, fiers...@zonnet.nl wrote: Recompiled all very early this morning. I have just noticed that in global weather, there is no METAR data. METAR source is set to live data. In the METAR data box I read 'NIL'. Something broke the METAR updates? Torsten has been making changes near this (though not in the last couple of days - when was your previous, working, build from?), and I've been making core changes to fix other bugs (David Megginson's startup state issues), so this has probably got knocked around. I'll poke around when I have a spare moment. James -- The Next 800 Companies to Lead America's Growth: New Video Whitepaper David G. Thomson, author of the best-selling book Blueprint to a Billion shares his insights and actions to help propel your business during the next growth cycle. Listen Now! http://p.sf.net/sfu/SAP-dev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] METAR stopped working
On Fri, 2010-11-05 at 09:54 +, James Turner wrote: On 5 Nov 2010, at 08:16, fiers...@zonnet.nl wrote: Recompiled all very early this morning. I have just noticed that in global weather, there is no METAR data. METAR source is set to live data. In the METAR data box I read 'NIL'. Something broke the METAR updates? Torsten has been making changes near this (though not in the last couple of days - when was your previous, working, build from?), and I've been making core changes to fix other bugs (David Megginson's startup state issues), so this has probably got knocked around. I'll poke around when I have a spare moment. Another option would be that the metar server is unavailable .. checking, jup: metar EHAM ERROR: no metar data available from at http://weather.noaa.gov/pub/data/observations/metar/stations/EHAM.TXT -- The Next 800 Companies to Lead America's Growth: New Video Whitepaper David G. Thomson, author of the best-selling book Blueprint to a Billion shares his insights and actions to help propel your business during the next growth cycle. Listen Now! http://p.sf.net/sfu/SAP-dev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] METAR stopped working
Another option would be that the metar server is unavailable .. checking, jup: metar EHAM ERROR: no metar data available from at http://weather.noaa.gov/pub/data/observations/metar/stations/EHAM.TXT I guess the same, I run a older GIT from early Octobre, and METAR worked two days ago. Now I get NIL at every airport. -- The Next 800 Companies to Lead America's Growth: New Video Whitepaper David G. Thomson, author of the best-selling book Blueprint to a Billion shares his insights and actions to help propel your business during the next growth cycle. Listen Now! http://p.sf.net/sfu/SAP-dev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] METAR stopped working
On Friday 05 November 2010 10:21, Heiko Schulz wrote: Another option would be that the metar server is unavailable .. checking, jup: metar EHAM ERROR: no metar data available from at http://weather.noaa.gov/pub/data/observations/metar/stations/EHAM.TXT I guess the same, I run a older GIT from early Octobre, and METAR worked two days ago. Now I get NIL at every airport. I see it with GIT and version 1.0.0. The files are present on the NOAA server but no version of metar that I have will pull them. Martin. -- The Next 800 Companies to Lead America's Growth: New Video Whitepaper David G. Thomson, author of the best-selling book Blueprint to a Billion shares his insights and actions to help propel your business during the next growth cycle. Listen Now! http://p.sf.net/sfu/SAP-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
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
Re: [Flightgear-devel] --metar
John Denker wrote: I have some basic questions about the --metar command-line option. AFAICT the getstart.pdf manual doesn't mention this option. That's correct - we've still to complete the updates to the manual for the upcoming release. However, it's on my TODO list. If you want to submit a LateX patch, or just some text, you are more than welcome. The --verbose --help message mentions the option, and implies that it takes an argument ... but doesn't say anything about the syntax or semantics of the argument. I was hoping that something like --metar= 012345Z 0KT 10SM CLR 59/M01 A2992 would work, but it doesn't. Can somebody please explain what the --metar option is supposed to do, and/or how to specify static weather via the command line? A I recall, Torsten implemented that feature. There was a description of it on the -dev list a couple of months back, but I've been unable to locate it myself in the archive. -Stuart -- Return on Information: Google Enterprise Search pays you back Get the facts. http://p.sf.net/sfu/google-dev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] --metar
On Sun, Dec 13, 2009 at 10:16 AM, Stuart Buchanan stuart_d_bucha...@yahoo.co.uk wrote: A I recall, Torsten implemented that feature. There was a description of it on the -dev list a couple of months back, but I've been unable to locate it myself in the archive. Here you go: http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg22309.html -- Csaba/Jester -- Return on Information: Google Enterprise Search pays you back Get the facts. http://p.sf.net/sfu/google-dev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] --metar
I have some basic questions about the --metar command-line option. AFAICT the getstart.pdf manual doesn't mention this option. The --verbose --help message mentions the option, and implies that it takes an argument ... but doesn't say anything about the syntax or semantics of the argument. I was hoping that something like --metar= 012345Z 0KT 10SM CLR 59/M01 A2992 would work, but it doesn't. Can somebody please explain what the --metar option is supposed to do, and/or how to specify static weather via the command line? -- Return on Information: Google Enterprise Search pays you back Get the facts. http://p.sf.net/sfu/google-dev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] METAR++ or: live wind aloft data for FlightGear
2009/2/19 Torsten Dreyer tors...@t3r.de: Comments welcome. All works fine, thank you very much for this feature. From now long-range flights got new level of realism. -- --- WBR, Vadym. -- Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA -OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise -Strategies to boost innovation and cut costs with open source participation -Receive a $600 discount off the registration fee with the source code: SFAD http://p.sf.net/sfu/XcvMzF8H ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] METAR++ or: live wind aloft data for FlightGear
Hi, as a proof of concept, I have a little hack that provides live wind aloft data for FlightGear. A draft can be found here: http://wiki.flightgear.org/index.php/Howto:_Fetch_live_aloft_data Comments welcome. Torsten -- Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA -OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise -Strategies to boost innovation and cut costs with open source participation -Receive a $600 discount off the registration fee with the source code: SFAD http://p.sf.net/sfu/XcvMzF8H ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] METAR interpolation?
I wrote : Csaba wrote: On Fri, Dec 19, 2008 at 11:38 PM, Stuart Buchanan wrote: The patch below backs out that change. Unfortunately this means the change to the cloud coverage due to changing METAR will not be reflected in the 3D clouds (2D clouds are unaffected). Unfortunately I don't think it will be possible to fix this before the release. I personally consider that a show-stopper (unless we disable 3d clouds in the release). Just to be clear: a) The patch I provided fixes METAR interpolation. b) However, it means that 3D clouds are not completely interpolated. A change in cloudbase will be interpolated (quite nicely). However, a change in cloud coverage (including the removing or adding of layers) will _not_ have any effect. I agree that its bad. Unfortunately I don't have time to fix it this weekend before the release. I've managed to fix this by differentiating rebuilding the 3D layers (e.g. due to METAR updates) from rebuilding the entire environment (due to a change in scenario). Could someone apply the attached patch please? Thanks -Stuart clouds.tar.gz Description: GNU Zip compressed data -- ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] METAR interpolation?
You're right. That's why I have implemented quickly a smooth changement precipitations. I think that the changement should be refactoring. Mostly for wind... Regards, Le vendredi 19 décembre 2008 à 14:35 -0600, Curtis Olson a écrit : I just did a cross country flight with the latest CVS cloud/weather/metar changes and I noticed that the weather interpolation that smoothed out abrubt changes to wind and clouds when a new METAR report comes in seems to have now been lost. We are back to abrubt wind and cloud changes. I haven't had a chance to dig in myself, but thought I'd mention this to the folks that currently have their heads immersed in that section of the code. Regards, Curt. -- Curtis Olson: http://baron.flightgear.org/~curt/ -- ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel -- Nicolas VIVIEN -- ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] METAR interpolation?
I just did a cross country flight with the latest CVS cloud/weather/metar changes and I noticed that the weather interpolation that smoothed out abrubt changes to wind and clouds when a new METAR report comes in seems to have now been lost. We are back to abrubt wind and cloud changes. I haven't had a chance to dig in myself, but thought I'd mention this to the folks that currently have their heads immersed in that section of the code. Regards, Curt. -- Curtis Olson: http://baron.flightgear.org/~curt/ -- ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] METAR interpolation?
Curt wrote:
I just did a cross country flight with the latest CVS cloud/weather/metar
changes and I noticed that the weather interpolation that smoothed out
abrubt changes to wind and clouds when a new METAR report comes
in seems to have now been lost. We are back to abrubt wind and cloud
changes. I haven't had a chance to dig in myself, but thought I'd mention
this to the folks that currently have their heads immersed in that section of
the code.
Thanks for the bug report.
The culprit as you guessed is some of the 3D cloud changes. The attached patch
reverts one of my changes which ensured that the 3D clouds were updated with
METAR. Unfortunately this had the side-effect of over-writing the environment
properties, and therefore nuking the interpolation work.
The patch below backs out that change. Unfortunately this means the change
to the cloud coverage due to changing METAR will not be reflected in the 3D
clouds
(2D clouds are unaffected). Unfortunately I don't think it will be possible to
fix
this before the release.
Could someone please commit this? Thanks.
-Stuart
Index: environment_ctrl.cxx
===
RCS file: /var/cvs/FlightGear-0.9/source/src/Environment/environment_ctrl.cxx,v
retrieving revision 1.58
diff -u -p -r1.58 environment_ctrl.cxx
--- environment_ctrl.cxx19 Dec 2008 07:42:13 -1.58
+++ environment_ctrl.cxx19 Dec 2008 22:36:48 -
@@ -502,7 +502,6 @@ FGMetarEnvironmentCtrl::update_env_confi
double aircraft_alt = fgGetDouble(/position/altitude-ft);
char s[128];
int i;
-bool rebuild_clouds = false;
for (i = 0, layer = layers.begin(); layer != layers_end; ++layer, i++)
{
double currentval;
@@ -520,7 +519,6 @@ FGMetarEnvironmentCtrl::update_env_confi
const char* coverage = (*layer)-getStringValue(coverage,
clear);
if (strncmp(fgGetString(s), coverage, 128) != 0) {
fgSetString(s, coverage);
-rebuild_clouds = true;
}
snprintf(s, 128, cl, i);
@@ -570,10 +568,6 @@ FGMetarEnvironmentCtrl::update_env_confi
}
}
-if (rebuild_clouds) {
-// Force an update of the 3D clouds
-fgSetDouble(/environment/rebuild-layers, 1.0);
-}
} else {
// We haven't already loaded a METAR, so apply it immediately.
dir_from = fgGetDouble(/environment/metar/base-wind-range-from);
--
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] METAR interpolation?
On Fri, Dec 19, 2008 at 11:38 PM, Stuart Buchanan stuart_d_bucha...@yahoo.co.uk wrote: The patch below backs out that change. Unfortunately this means the change to the cloud coverage due to changing METAR will not be reflected in the 3D clouds (2D clouds are unaffected). Unfortunately I don't think it will be possible to fix this before the release. I personally consider that a show-stopper (unless we disable 3d clouds in the release). -- Csaba/Jester -- ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] METAR interpolation?
Csaba wrote: On Fri, Dec 19, 2008 at 11:38 PM, Stuart Buchanan wrote: The patch below backs out that change. Unfortunately this means the change to the cloud coverage due to changing METAR will not be reflected in the 3D clouds (2D clouds are unaffected). Unfortunately I don't think it will be possible to fix this before the release. I personally consider that a show-stopper (unless we disable 3d clouds in the release). Just to be clear: a) The patch I provided fixes METAR interpolation. b) However, it means that 3D clouds are not completely interpolated. A change in cloudbase will be interpolated (quite nicely). However, a change in cloud coverage (including the removing or adding of layers) will _not_ have any effect. I agree that its bad. Unfortunately I don't have time to fix it this weekend before the release. If someone else wants to look, the place to start is the fgclouds.cxx code, in particular update_metar_properties() and update_env_config(). There is currently a split between fgclouds and the environment manager setting up these properties. -Stuart -- ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] METAR interpolation?
On Fri, 2008-12-19 at 23:30 +, Stuart Buchanan wrote: Csaba wrote: On Fri, Dec 19, 2008 at 11:38 PM, Stuart Buchanan wrote: The patch below backs out that change. Unfortunately this means the change to the cloud coverage due to changing METAR will not be reflected in the 3D clouds (2D clouds are unaffected). Unfortunately I don't think it will be possible to fix this before the release. I personally consider that a show-stopper (unless we disable 3d clouds in the release). Just to be clear: a) The patch I provided fixes METAR interpolation. b) However, it means that 3D clouds are not completely interpolated. A change in cloudbase will be interpolated (quite nicely). However, a change in cloud coverage (including the removing or adding of layers) will _not_ have any effect. I agree that its bad. Unfortunately I don't have time to fix it this weekend before the release. If someone else wants to look, the place to start is the fgclouds.cxx code, in particular update_metar_properties() and update_env_config(). There is currently a split between fgclouds and the environment manager setting up these properties. -Stuart I agree with Jester, I'd rather have fully functional 3D clouds in the release and fix the METAR Interpolation later. Ron -- ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] METAR Patch (was : no subject)
I wrote: Subject: Hi All, Attached is a very small patch that fixes the issue reported by Martin where --prop:/environment/weather-scenario=METAR had no effect. I think this is a pretty safe patch that should be included in the release. -Stuart Sorry for the lack of subject. -Stuart -- SF.Net email is Sponsored by MIX09, March 18-20, 2009 in Las Vegas, Nevada. The future of the web can't happen without you. Join us at MIX09 to help pave the way to the Next Web now. Learn more and register at http://ad.doubleclick.net/clk;208669438;13503038;i?http://2009.visitmix.com/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] METAR update failuere on Windows / Linux with local time BIOS configuration
Hi,
I've been discussing with Japanese FlightGear users about METAR update failure
on 1.0.0.
It seems that METAR update fails when BIOS time is set to local time (JST, GMT+
9) on Windows (and probably on Linux).
According to windows users, launching fgfs with --log-level=warn outputs
METAR data too old (xxx min)
xxx depends on a station but it's likely more than 540, (+9 hours), so I wonder
if GMT calculation depends on
BIOS time configuration (local time or GMT). I know some stations update METER
less frequently,
but it also happens on RJTT which updates every 30 min.
With my rough guess, replacing time(0) with sgTimeGetGMT( gmtime(cur_time) )
in Environment/fgmetar.cxx
can fix this problem, but not sure since this problem doesn't happen on Macs.
here's the code related to METAR age calcuation in Environment/fgmetar.cxx
long FGMetar::getAge_min() const
{
time_t now = _x_proxy ? _rq_time : time(0);
return (now - _time) / 60;
}
Best,
Tat
-
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel
