InfoMetar ICAO Updates

[Kennair 4]

Can anyone tell me if it is possible to edit/update the airport database in Infometar 1.01? I am based in Western Australia and find that generating metar for any flight in this region using FSBuild and InfoMetar results in unkown or errant airport codes. This program is very useful but there has been no update since version 1.01 as far as I can find.Can someone suggest a fix?Ken:-roll

[Guest DSandberg]

To be honest, I don't recall if there is anything in the InfoMETAR code itself that is hardcoded with regards to the ICAO database ... I don't think so. So in theory it might be possible to alter that file without updating the program. However, it is stored in a compressed binary format, so editing it would not be simple for anyone besides myself. (I don't have any fancy GUI tools for doing so, only a kludgey converter routine that was compiled into the debug version of InfoMETAR just to get the job done.)The ICAO database distributed with InfoMETAR is in sync with Fly! and Fly2K, and I think Fly II as well (my memory suggests that TRI didn't change or update the ICAO database used by the weather engine in the latter version, even if they added additional airports). Since Fly! is the program for which InfoMETAR was designed, my initial inclination is not to change the database to include extra airports which would then be thrown out when Fly! loads the files, because it would be likely to result in significant weather problems in Fly!.However I'm open to hear any proposed solutions, especially ones that don't require time-consuming modifications of InfoMETAR.By the way, there haven't been any more versions since 1.01 because it seems to be largely bug-free in its current form. I'd wanted to create a new version with some additional features at some point, but with the other things going on in my life I don't know if or when that could happen.[table cellspacing=0 cellpadding=0][tr][td width=320]http://www.usinternet.com/users/mystic/infomsig.gif[/td][/tr][/table]

[Kennair 4]

David,Thanks for your prompt reply and may I say thanks for a terrific program to add to an already terrific simulator, however this problem leaves me a little confused. Your Help file also indicated that the InfoMetar's database uses FlyII's default database (I think Airport.pod), however while Fly shows up my airports, InfoMetar doesn't. For example Jandakot airport "YPJT" (the airport I fly out of in real life) is not recognised by InfoMetar yet FlyII does. Also the town of Albany in the Southwest of the state has it's airport code in InfoMetar as "YPAL", when it is actually "YABA" (also recognised correctly by Fly). All this makes me wonder where InfoMetar is getting its information from. Not being able to recognise airports makes it a little difficult to gather weather for a planned flight in this region.In all other respects your application works great and I can see why there has been no need to update, I would just like to find a solution to this anomoly.Many thanks,Ken:-violin

[Guest HeliFLYer]

Hi David,I just want to use the opportunity to thank you very much for the InfoMETAR utility which I use regularly.RegardsGeorg (EDDW)

[Guest DSandberg]

(Argh! I'd just finished typing a long, more detailed response when my browser ate it.)Here's the short answer: Fly!'s database of ICAO codes used by the weather engine isn't the same database as its list of airports that appear in the sim. If you try feeding in a METAR directly (without using InfoMETAR) for one of those airports that appears in the sim but that InfoMETAR doesn't show as available, you'll find that Fly II won't load that METAR information.[table cellspacing=0 cellpadding=0][tr][td width=320]http://www.usinternet.com/users/mystic/infomsig.gif[/td][/tr][/table]

[Guest DSandberg]

You're most welcome! :D[table cellspacing=0 cellpadding=0][tr][td width=320]http://www.usinternet.com/users/mystic/infomsig.gif[/td][/tr][/table]

[Kennair 4]

Hmmmm! That's a bummer. It kind of makes it difficult to use such a good program.Thanks for investigating this for me anyway. I'm still confused but then that's not too hard these days.Ken.:-beerchug

[KenWood 5]

Hi David, Understanding the limitations of both Sims' abilities, would it still be possible to attempt to make a newer database for Fly! II users to download? But if I underestand correctly, maybe Fly! II cannot for as you say, TRI may not have updated the weather file for parsing the metars as it were (the infamous - the Publisher's "lets get it out the door fast, TRI" (as in NOT TRI's fault). I know this isn't the way the program is meant to be used, but could the user license then be modified to allow for two instances of InfoMetar to be loaded, so users like me who use both sims have a second version loaded to do the metars from? That might make it possible for users like Ken in Australia (and the NZ users if they have similar problems) to be able to use their metars. The database is a separate file InfoMetar looks for, yes? Or do you feel that would just create more confusion? :-eekCheers!Ken Wood :-sun1http://www.avsim.com/hangar/fly/dfdg/bannernewkw.jpgGateway 700X; Intel P4 2.4GHz; 512MB RAM; NVIDIA Ti4200 4X AGP 128MB; SB Audigy; Thrustmaster TopGun Fox 2 Pro Shock

[Guest DSandberg]

Ken,Hmm. Let's think some more about this. (Brace yourself for a long read - this is going to cover much of the same ground that my longer, lost message from yesterday was intended to cover.)As I am perceiving things, this isn't really a case where the Fly II database hasn't been updated due to a "rush to production", nor is it a case where Fly II has different requirements from Fly2K. For one thing, we need to keep in mind that the airport ICAO database and the METAR station ICAO database simply cannot and should not be the same database. Not all airports report METARs, and some stations that report METARs are not airports. But I'm sure you already know that far better than I, given your profession. :)I've not used FSBuild, but I'm presuming that it is making the mistaken assumption that any airport ICAO code it has as part of a flight is a valid place to request InfoMETAR for METARs from, and that when it provides those ICAO codes to InfoMETAR via a command line, InfoMETAR doesn't recognize them as valid places to get METAR data from, and generates an error message about that fact. This also suggests to me that using FSBuild and InfoMETAR to generate flights for Fly 1.0 or Fly2K would have exactly the same occasional problems.If I'm understanding this correctly, then there would be two ways to possibly resolve this:1) If FSBuild was altered to only request METAR data for valid METAR reporting stations (actually to be a complete fix this would have to be not just valid stations, but stations that are valid to the sim in question, which could be a problem given that I believe FSBuild supports more than just Fly!)or:2) If InfoMETAR were enhanced to add FSBuild's ICAO database, but only those entries that are not in Fly!'s list of METAR reporting stations. Then each of those extra database entries would have to be tagged as "location data only", so that InfoMETAR knows to only use them to set the bounds of the flight route and doesn't attempt to get and use METAR data for those stations. (I.e., this would not be a small editing job, although it would only require the ICAO code, the full name and the lat/lon coordinates, and not all of the extra data fields that are required for METAR station entries.) There would also be some additional complexities here in that InfoMETAR's logic for forcing METAR data for flight route endpoints or waypoints would have to become conditional upon whether the defined points were valid METAR reporting stations or not. And the extra entries would probably have to be shown on the screen in some fashion, or else such flight routes will look like they are headed to/from empty places on the map. Maybe a different color for the ICAO codes could be used to distinguish them from METAR reporting stations ... that would also require some additional logic, another toolbar button, etc. Funny how the job keeps growing, eh? :) This would also require that the raw FSBuild ICAO database be available to us (do they publish it in a readable format?).Approach #2 isn't out of the question, but I doubt I'd have the time to do all of the by-hand editing of the raw database that might be required. I might be able to make the changes to InfoMETAR to handle such an extended database, though, if someone else was inclined to do the editing grunt work (not a job I would wish on anyone). A substantial part of the database editing process (selecting unique ICAO codes) could be automated, but there would be a need to go through the altered database by hand afterwards to do "clean up". In particular, some decisions would have to be made about how to handle those cases where the ICAO code used by Fly for certain METAR stations doesn't match the one in FSBuild ... either both would need to be present, or the Fly! code would have to be deleted and METARs from that ICAO code (if it exists) simply not used.What do you guys think, particularly those who have used this combination of programs? Am I at least more or less on-base about what FSBuild is doing and where the aforementioned errors occur?[table cellspacing=0 cellpadding=0][tr][td width=320]http://www.usinternet.com/users/mystic/infomsig.gif[/td][/tr][/table]

[KenWood 5]

Hi David, Well, that certainly puts things into proper perspective! :-) I would have to get some input from Ernie about how FSBuild calls infoMetar for the reports to verify. Either way, hand-editing the DB would tend to be rather involved... ;-) Ken - which version of FSBuild are you using? I'm using the last FREE version (1.42, I believe). I've not had the opportunity to purchase the 2.0 version, so know nothing on it or how it makes the calls. In the 1.xx versions, FSBuild used a separate file that was pulled from the airports podfile for Fly! and Fly! II, and used as a separate/ replacement text file from the original for MSFS within FSBuild.Now, I will make the assumption that it is from that file FSBuild sends the queries for weather to infoMetar. So if the airports pod for Fly! or Fly! II was edited, the list FSBuild uses is no longer up to date. One needs to re-extract the Airports POD file into text format and overwrite the file FSBuild uses. Then it would be a matter of ensuring that the FSbuild file matches what we have for weather METAR AIRPORT reporting stations that Fly! or Fly! II uses.Since I really don't do any programming, I have no decompiler for the binary .bin format TRI uses or David uses. Hence my dilemma... I would be happy to investigate further - but could someone let me know which (if any) program would allow me to see / decompile the .bin files? Preferrably one that doesn't require a lot of reading up on. Would something like HexEdit work (old DOS program I have somewhere)? David - thanks for the thorough explanation. Yes - to do one small change ends up adding to the pot! Many may not understand how one fix can suddenly cause more problems down the road. This is a nice way to indicate how such a thing can increase the problem exponetionally (sp?)of fixing when making only a couple small changes to a complex program.Many cheers!Ken Wood :-sun1(former US Navy Weather Guesser and forecaster for CNN International) for those wondering http://www.avsim.com/hangar/fly/dfdg/bannernewkw.jpgGateway 700X; Intel P4 2.4GHz; 512MB RAM; NVIDIA Ti4200 4X AGP 128MB; SB Audigy; Thrustmaster TopGun Fox 2 Pro Shock

[ErnieAlston 33]

Fsbuild does indeed submit the departure and destination airport ICAO airport.The mistaken assumption was that InfoMetar was selecting the closest valid weather station to the airport rathr than accepting the ICAO code as only a weather station code. If true as David suggeststhen yes there would be a problem retrieving Metars for airports that do not have a weather reporting station.Fsbuild will only export plans for FLy!/Fly!II where it finds that airport actually exists in the airports database file extracted from the .pod file.There is a utility used to do this, of which the name escapes me now, but that would be a way to update the airports list that Fsbuild is using t export flight plans to FLY!As far as exporting Flight Plans to Fly!, and using InfoMetar Fsbuild version 1, and Fsbuild version 2 work pretty much the same way.If there was some sort of weather station lookup table in InfoMetar with its lat/lon position, it might be possible for Fsbuild to select the closest weather station to the dep/dest and submit that code rather than submitting the actual dep/dest ICAO code to InFoMetar.Regards.Ernie.

[Guest DSandberg]

Thank you for the information, Ernie. Nice to see that the various add-on developers are alive and well here on the Fly! forum. :)I'm thinking that, whatever you might decide to do with FSBuild, there will still be a need to enhance InfoMETAR to handle flight plans that are not weather stations in some manner. I have to thank Kennair for pointing this problem out, as I hadn't heard about it before now.One solution would be via what I have described above (extending InfoMETAR's database with secondary entries for airports that are not METAR stations). I think this option is a daunting one, for all of the reasons I've listed previously.Another would be something like what you have suggested ... a callback facility that allows InfoMETAR to accept lat/lon coordinates and then give back the ICAO code of the nearest valid METAR reporting station. I could add that pretty easily. However, the problem I see with this approach is that, when the "nearest code" is then used to generate weather in InfoMETAR, the flight route shown in InfoMETAR will not exactly reflect the actual planned flight. Sounds pretty ugly to me.But another approach which has occurred to me today is to add a new command line argument to InfoMETAR, wherein another program like FSBuild can pass in the filename of a temporary file that contains a list of lat/lon coordinates (either floating point or deg/mn/sec) along with (optionally) the ICAO code and descriptive text (name) for each such coordinate. This would have the positive effect of not requiring the InfoMETAR database to be updated, and furthermore would mean that InfoMETAR could remain compatible with any program such as FSBuild in the future, regardless of changes in the airport databases for those other programs. InfoMETAR could then use the information in this temporary file to decide if it has to create "placeholder ICAO dots" on the map for any of the provided waypoints. Both the displayed flight route and the selected weather area would be exactly correct, and the ICAO text (if provided) would allow InfoMETAR to identify those points to the user on the map. This would even allow flight plan waypoints that have been located at navigational reporting points (i.e., ARCEY) to be used when defining a flight route for InfoMETAR, if the calling program happens to support the use of such points in flight planning (which is something that InfoMETAR most certainly cannot handle right now).I personally prefer the last idea, because I like the idea of future compatibility, and because I fear a massive database edit in the marrow of my bones. :) The bad things are that it would also require FSBuild to explicitly add code to create and then later delete this temporary file (though I'd expect the file format would be one that's pretty straightforward to implement), and also that this wouldn't help people using older versions of FSBuild. Probably the only way to address the problem for older FSBuild versions would be the extension of InfoMETAR's database which was described earlier.[table cellspacing=0 cellpadding=0][tr][td width=320]http://www.usinternet.com/users/mystic/infomsig.gif[/td][/tr][/table]

[Guest DSandberg]

Ken,Regarding the decompilation of .BIN files, I can't speak to any podded files in Fly!. InfoMETAR's station database is in the file "vmdata.bin" in the InfoMETAR application folder, and was compiled using its own binary format. The source data for that file can be found in the "METARnsd_cccc.doc" file distributed with Fly! (I don't recall if Fly II also included it or not.) Also, some of the entries in that source file were fixed up by hand by myself before the conversion, as there were literally dozens of typographical errors in the original document.I don't have a decompiler for my .bin files, sorry! However, IF we were to get to the point of someone being willing to hand-edit the database, I could easily enough provide them with the original source text file (including my earlier edits) to get them started. However, I'm now leaning strongly toward the solution proposed in my response to Ernie, which would not require the editing of any databases (a BIG plus).[table cellspacing=0 cellpadding=0][tr][td width=320]http://www.usinternet.com/users/mystic/infomsig.gif[/td][/tr][/table]

[Kennair 4]

David & Ken (Wood),Whew! Looks like I've opened a can of worms. Serves me right for living in the most isolated capital city in the world.To answer your question Ken, I'm using FSBuild version 1.3.8. This builds my flight plans quite satisfactorily, I was just perturbed by the errors generated by InfoMetar and thought there may be a simple way to solve it. Obviously not so. David, don't go spending endless nights updating your program on my account, it works fine for most situations and I can live with it. Remember, you don't get paid for this. But if future-proofing is what you're after, then I'm all for it. Not being a programmer I understood about 10% of what you said, but it sounded convincing anyway.Thanks for all your help and input and I'll watch this forum with interest,Ken.;)

[KenWood 5]

Hi Ken, Well, I do not think you've actually "opened a can of worms" - just pointed out a small - albiet not an easy fix - problem infoMetar is encountering when used in conjunction with FSBuild. David is always entertaining ideas on ways to enhance the program for compatibility, it is just real-world obligations hinder one's ability to do much at this time. Something we all can relate to! As a weather forecaster/ observer, I can attest to the multitude of problems with stations that do not report, do not report regularly, not located at airports, etc. in what Ernie and David contend with when writing their programs. Even our weather Super Computers have problems due to these types of situations. ;-) Now, I wouldn't say Western Australia is really all that isolated! :-) I "Fly!" there regularly - just I usually choose those stations for VFR flying. Just wish we could get good, "free" data to build TerraScene scenery for each region. With the Shuttle missions of mapping, this may soon become a reality, though! I just don't recall if it were a global project or not. Oops - off topic! Anywho - David - should you require any assistance on database stuff, just let me know and I will be more than happy to help where I can. I am no programmer, but I can usually figure things out enough to do something useful. And you are correct - infoMetar is one of the most bug-free programs to come out! Most problems encountered are more NWS server problems - not infoMetar problems. I still seem to encounter one issue - that of the ticked boxes for changing elevations / ignoring RMKS data... I do not know for sure, but I still seem to have a problem on occasion with it. Is the program supposed to actually delete the remarks part, i.e. the hourly high/low and max/min temps from the ob when it copies the obs out when thinning? I usually have to edit those out of the thinned .txt file to ensure I am getting the correct Barometer readings. Just wondering... ;-) And thanks for considering methods to enhance infoMetar.Cheers to all! Ken Wood :-sun1http://www.avsim.com/hangar/fly/dfdg/bannernewkw.jpgGateway 700X; Intel P4 2.4GHz; 512MB RAM; NVIDIA Ti4200 4X AGP 128MB; SB Audigy; Thrustmaster TopGun Fox 2 Pro Shock