Are you good with BGLs - can you help with magnetic var

[Guest]

I've been interested in developing a navigation log to append to the flight releases our VA pilots get; a key component of this is the heading which pilots fly between waypoints. I've got the latest NIMA nav data, complete with magnetic variations, but as you probably know they don't match AT ALL with the default mag vars found in FS. These are stored in a .bgl file (magdec.bgl); I'd love to see an updated BGL file produced and released. I'm not sure if the table has values based on waypoint or by coordinate, but if giving you the mag var value at every waypoint in the database helps, I'll give it to you in whatever format you need. I think this is generally an important endeavour (if for nothing else than to keep FS in line with real world charts), so I welcome any discussion or suggestions on the topic. Thanks!-Darren

[wsieffert 0]

I tried disassembling/decompiling the magvar.bgl without success. I would assume Microsoft is using an earlier version of the magvar data. The problem with just updating this magvar.bgl may be that there are other areas in the simulation that use the present magvar.bgl which would cause other anomalies in the simulation without those files being updated.This very problem is experienced in high end simulators also. It is an ever ending maintenance task to keep up with MagVar changes as the different NAVAIDS are inspected and calibrated and their information is sent for publication to aviators.

[Guest rafaelds]

I have produced a new magvar.bgl with data for 2002However, now all VORs are misaligned. One would have to create a program that would scan all VORs in the BGL's, fetch their coordinates, read magvar from the new data and update the BGL's.That's the reason I never released it. I wouldn't be able to cope with the avalanche of emails complaining about the problem, how to fix it, how to restore the default file (after they had overwrittn it...).But IMHO it is still worth using. The only side effect is that when you track a radial it's like if there was some crosswind.Rafa

[Guest]

This is great - thanks for the info, guys! So Rafa, if there was a way to correct the VOR data, do you think it'd be worth it? I'm pretty sure that I've seen somewhere that someone has tackled large-scale VOR editing (at the very least, Nav 3.0 and the like read the BGLs to gather the data). I'll admit that I don't appreciate the size of a project like that, so maybe its not feasible. But again, the NIMA data includes current magnetic variations at all VORs, airports, etc, so maybe it wouldn't be so bad (and again I'd be happy to provide the data in a useful format). I'd love to see this happen, especially since there's already an updated magdec.bgl file. Anyone have further thoughts?-Darren

[wsieffert 0]

Rafa and Darren,Just the kind of thing I was talking about. Change one thing and everything gets hosed.BTW Darren, what did you use to decompile the magvar.bgl? I tried BGLAnalyzer and ScDis without success.

[Guest]

I actually didn't decompile it, although my guess is Rafa may have. A collaborator of mine came up with some little Visual Basic ditty that could read a value from the file if you provided it with coordinates (which was my understanding). I provided him with the coordinates of the VOR's in the US and he hands me back a text file with what FS thinks are the mag var values; I've used this to produce a database table which contains "FS MagDecs", which I could substitue for the real ones if I REALLY need to. If you were interested in this program, my guess is I could get it - I think it took him like an hour to write.But I still have faith - I think it can be done!! But hey, I'm an optimist at heart!-Darren

[Guest rafaelds]

The format is quite simple.I forgot completely the details (I have done this over 6 months ago), but the BGL starts with a standard header with the appropriate pointer to magvar data. Then there are lots of 16 bit values. The first two are the number of rows and columns (may be inverted) and the rest are all magvars in 16 bit pseudodegrees. There are 360 lines, one for each longitude, and 181 entries for every line (one for every lat, from -90 to +90). It's just a band-sequential bit map like DEMs, landclasses etc. Starts with longitude 0 and goes all the way to 359 (it wraps around the globe). I think but Im not sure that there is a footer in the file as well, but I guess it is ignored.What I did was:-with a hex editor, cut the header and footer off the default file and save them;-generate a list of lat/lon for processing later, i did this in a small qbasic program. Just two for/next loops, one for lon from 0 to 359 and one for lat from -90 to +90. This program generated a text file.-use a program that I found on the web that generates magvar from lat/lon/alt using several magnetic models. With some DOS tricks from the old good days I was able to make a batch file that processed all the 360*181 entries and appended the result to a text file.-using a word processor with search/replace, clean up the resulting file letting only the real data in it.-another small qbasic program that read the data from the text file and output the results to a proper binary file.-with the hex editor, patch the file parts up together again.There. It's a lot of hand job.Using the magvar generating program I found that the data in FS was generated using the WMM85 magnetic model with date set to july 1st 1987. It's very likely that it's the same file from the first version of FS which simulated magvar...About the VOR lining-up program... It would be easy (but not for me). Herve Sors' EasyNav for example, reads VOR data and reads magvar from the FS file flawlessly. It's just a matter of setting up a routine to make the task automatically.As for the magvar data from NIMA, it's not needed. We need to assure it's correct with the FS data, even if it differs a couple of tenths of degrees from the real data. Neverteless, it's very easy and quick to read the magvar from the BGL. The formula for the offset in the file where the data should be read is well known since FS5 and is:posi = ((Lat + 90) + 181 * ((Lon + 360) MOD 360)) * 2 + 137where 'posi' is the offset in the file. One may need to subtract or add 1, it depends if the language considers the start position as 1 or 0.If any of you guys really want the magvar file I can send it to you.But I'd really appreciate if someone made a program to adjust the magvars or at least talked to one of the programmers of things like NAV, EasyNav etc. which could probably make this.Apologies for the confusion in the text. English is not my native language and I am a bit drunk (after all, it's saturday!).rafa

[wsieffert 0]

Thanks for the input. No, I don't want the data! I use the flightsim in the manner it was built with the 1987 magvar data. I feel changing the data would seriously affect addon scenery that has been aligned with the present table. It may also affect the default scenery. Its one thing to have the instruments in the aircraft point to a different heading and another to have the scenery point the correct direction. The pilot flying the VOR heading doesn't necessarily see the VOR station but when he comes in for a landing and the visual runway is off now by some degrees, it makes a difference. This is the problem I mentioned in my earlier post.I suspect MS used the 1987 data so they wouldn't have to convert a lot of items they reused from earlier sims.

[Guest rafaelds]

Actually no, the problem is really only with VORs. And it affects default and add-on sceneries the same way.All visual scenery, including runways, are referenced to true heading. Including ILS's. If the sceneries were made with good maps, charts or plans of the airfield, the runways are correctly aligned with true north and the new magvar should only make their mag heading more correct. Default airfields are also not much of a problem - their true heading seems to have been calculated by subtracting or adding the current magvar from navigational data from the approximate runway heading (ie 60. deg for rwy 06/24). Thay may explain why some are a couple of degrees off.Also, the new magvar will correct the runway headings in airports done with the help of charts (the ones with taxiways, aprons...). For example, take a look at 'SBPA' in the default scenery. The runway 11/29 has a mag heading of 104 deg, and so is the ILS as well. That does not make sense, for a rwy to have an ID number of 11 it must have a heading between 105 and 114 deg. Putting the new magvar on will bring the heading to 106 deg, which matches reality. The heading displayed in the AFD window is also updated automatically.Rafa