Sign in to follow this  
Guest DSandberg

InfoMETAR proposed feature question/poll

Recommended Posts

I can't promise if or when I might do a new update of InfoMETAR, but if I get around to it at some point, I'd like to add to my planned features list the addition of another option to the METAR download dialog which would force InfoMETAR to get a specific METAR cycle file, rather than always getting the current one(s).I'd appreciate it if people who are interested in such a feature would chime in to tell me which implementation of this feature they would likely find most useful, selecting from the following:1) selecting a single cycle file absolutely by filename only (UTC hour)2) selecting a single cycle file absolutely by local time (translated to UTC by the program)3) selecting a single cycle file as a relative offset in hours, counted backwards from the current local time (from 1 to 23 hours)I'd personally be inclined to go with implementation #3, or possibly #2. But both of those would still require the host computer to have its clock set correctly (not offset), whereas #1 would be completely independent of the computer's clock but would require the user to know how to figure out which UTC cycle they want. The only problem I see with #2 is that some users might be confused by the fact that cycle files switch over at the :45 minute mark, whereas the offset method (#3) would handle this automatically.Again, I'm not promising anything right now, but please do let me know which of these approaches (if any) appeals most to you!- David Sandberg[br][br]infomsig.jpg

Share this post


Link to post
Share on other sites
Help AVSIM continue to serve you!
Please donate today!

David,#3 sounds good to me.Can you not query the time and timezone and then apply a correction to get UTC for the user's computer, or are you talking about summer time offsets?If that's the case, then it should be easy enough for the user to do.Colin

Share this post


Link to post
Share on other sites

My question isn't a matter of making the programming part easier. InfoMETAR already uses the time and timezone information on the user's computer to correct local time to UTC in several places. This method also handles daylight savings time where applicable. So the additional coding to do such translations would be rather trivial.My question is more along the lines of the following: if a user is looking for weather from a specific time other than the current, from what starting point are they usually going to be working:1) they want weather from a certain UTC hour (e.g., "2200 Zulu" ... I think this to be unlikely except in the case of serious pilots)2) they want weather from a certain local hour (e.g., "3 p.m. this afternoon")3) they want weather from a certain number of hours ago (e.g., "three hours ago there was heavy fog here, I'd like to try flying in that")I'd prefer to just go with a single one of these methods, to avoid making the dialog too confusing. So whichever one is the closest to the point most users will be starting from is the one I'd choose to implement, just to make it as natural a process as possible for the user.- David Sandberginfomsig.jpg

Share this post


Link to post
Share on other sites

David#3 sounds good to me. Great program btw. I use it all the time.Andrew Luck18 miles SW EGSH

Share this post


Link to post
Share on other sites

Hi David,I like #2 best - more selective control. Still one of the best programs around for the Fly! series!Many Cheers,Ken WoodCNN International Weather :-sun1

Share this post


Link to post
Share on other sites

The more I think about it, the more I'm starting to lean this way myself. I was slightly concerned about how to present the UI for this particular case, but I think I know how I'd choose to approach it now.Still waiting for additional feedback before I decide (since it's a dead heat between #2 and #3 right now).- David Sandberg[br][br]infomsig.jpg

Share this post


Link to post
Share on other sites

Hi DavidI would prefer #3, then #2.Thanks for this great programRegardsJean

Share this post


Link to post
Share on other sites

My preference would be for number two, but either would be a big enhancement. BTW, I do have a problem with the handling of certain reports. For example, when the summer monsoon is running in the southwestern U.S. and thundersyorms are in the air, the WX at KLAS will read, "Few 65 TRW" or some such; I download the metar file and either Infometar or Fly!'s weather engine gives a couple micro-clouds at several miles apart. In the real world, there are one or two bases observed of 40,000 ft. high cumulonimbus. Can this be fixed?Still, it's a great program, and I use it all the time when Fly!ing.- Dave Reed

Share this post


Link to post
Share on other sites

Just thought I would try to provide a little additional information and be a little less enigmatic ...Last winter I did begin work on a very ambitious expansion for InfoMETAR. However it was a little too ambitious, and after a while it became clear that I'd have to make it a fulltime job if I were to have any chance to complete it. Then, earlier this summer, I began working with Richard Harvey on weather issues in the Fly II beta patch process. Unfortunately, that work is unlikely to make it into a released patch at this point, for reasons that should now be readily understandable.What I have in mind right now for InfoMETAR is a two fold approach. First off, I'm intending to back burner my ambitious InfoMETAR changes from earlier this year, roll the source back to the 1.01 version that's currently available and then do a more limited feature update that I can hopefully complete relatively quickly (including elements like what the rest this thread has been about). I'm hoping this could be ready for public consumption by around the February timeframe. I can't guarantee this of course (one never knows what can happen in the intervening months), but I do think it is fairly likely.After that, I do also have some longer term ideas for taking a different tack on improving the overall weather performance within Fly II, in a way that will not require anything to be addressed in an actual patch to the EXE (such as the one Rich and I were working on this summer). Among other things, this will have to wait until I get a different computer, as the one I currently have isn't capable of running Fly II very well.The main points I'm trying to make are these:1) InfoMETAR hasn't really been hung out to dry for the last year, even though it might have appeared that way, and ...2) Even for those things that will not be able to be addressed with a Fly II patch, such as weather, there remains lots of hope for improvement in the future.- David Sandberginfomsig.jpg

Share this post


Link to post
Share on other sites

David,I lean toward number 2. That is the thought process I use when I'm picking a metar cycle manually, which is the way I use Infometar.

Share this post


Link to post
Share on other sites

David,I'll be the odd man out and choose Number 1. :-)Actually, if the coding is not going to be a hassle, 2 would be a great addition to your program.

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
Sign in to follow this