Magvar and MakeRwys

[Claude Troncy]

Bonjour Pete and John,

May be you can help !
I have just installed fsaerodata and it confuse FSIPanel, which use MakeRwys to build it's own database.

Investigating the problem, I compared the runway.xml, and I found a difference in the magvar data. For LFPO it is -2.00 without fsaerodata and 0.780 with it.
Nevertheless if I compare the two runway.txt (with and without fsaerodata), i do not see any difference both are at -2.00.

 

**** Runway.txt  --- with fsaerodata ****
Airport LFPO :N48:43:23.9967  E002:22:45.9997  291ft
          Country Name="France"
          State Name=""
          City Name="Paris"
          Airport Name="Orly"
          in file: Scenery\0601\scenery\APX48140.bgl

          Runway 6 /24  centre: N48:43:39.9347  E002:20:20.1818  291ft
              Start 6 : N48:43:12.9826  E002:19:03.9770  291ft Hdg: 61.8T, Length 11961ft 
              Computed start 6 : Lat 48.720020 Long 2.317014
              Offset Threshold primary: 984 feet
              Start 24 : N48:44:06.8868  E002:21:36.3851  291ft Hdg: 241.8T, Length 11961ft 
              Computed start 24 : Lat 48.735500 Long 2.360865
              Hdg: 61.840 true (MagVar -2.000), Concrete, 11961 x 148 ft

**** Runway.xml  --- with fsaerodata ****
<ICAO id="LFPO">
<ICAOName>Orly</ICAOName>
<Country>France</Country>
<City>Paris</City>
<File>C:\Users\Troncy\Documents\fsAerodata Files\Navigation Data\Comms\scenery\FSAD_comms.BGL</File>
<SceneryName>FSAD_Comms</SceneryName>
<Longitude>2.379441</Longitude>
<Latitude>48.723324</Latitude>
<Altitude>291</Altitude>
<MagVar>0.780</MagVar>
  
***  In R4.csv ---  with fsaerodata  ****  The magvar is the same than the one in runway.txt but different thank the one in runway.xml
  LFPO,0020,48.717541,2.376687,291,20.340,7866,110.30,197,-2.000,48.727779,2.381833,0

I do not know if it is the source of the problem for FSIPanel, but is there something which could explain the difference between the xml and the txt file for the magvar data.

Thanks for youy help

Cheers
Claude

[Pete Dowson]

21 hours ago, Claude Troncy said:

I do not know if it is the source of the problem for FSIPanel, but is there something which could explain the difference between the xml and the txt file for the magvar data.

MakeRunways merely reads the data in the BGLs.  FSAerodata modifies those.  Whilst processing the BGLs the program builds tables containing all the data needed for the various files it produces. It only makes the files at the end, when it has finished the complete scan.

The MagVar put into both R4.csv and Runways.xml are both from the same value, the same entry in the table.. The two code lines doing this for those two files are close to each oher and there's no way the value can be changed in between.

So, the only explanation for your findings is that the R4.csv is not being written. Something is stopping this -- maybe it is open somewhere, or protected from writing. Try deleting it first.

Pete

 

[Claude Troncy]

Hi Pete,

So I deleted three files . r4.csv, Runways.xml and Runways.txt.

I then run MakeRwys and for LFPO
- In r4.csv the MagVar is -2.00
- In Runways.txt MagVar is -2.00
- In Runways.xml MagVar is 0.780

The three files have the same "Date modified" value.

Without fsaerodata all the MagVar values are equal to -2.00

Cheers

Claude

[Pete Dowson]

12 minutes ago, Claude Troncy said:

So I deleted three files . r4.csv, Runways.xml and Runways.txt.

I then run MakeRwys and for LFPO
- In r4.csv the MagVar is -2.00
- In Runways.txt MagVar is -2.00
- In Runways.xml MagVar is 0.780

The three files have the same "Date modified" value.

Well, that is really inexplicable.  Maybe, if you supply the BGL concerned which has been modified by fsaerodata, I could track it down. But I don't think i'll be able to do that soon. I'm really tied up for the next few days.

the BGL is

Scenery\0601\scenery\APX48140.bgl

Pete

 

[Claude Troncy]

What is strange is that the bgl file detected in the runway. txt and in the runway.xml is not the same.

See my first post

Claude

[Claude Troncy]

Continuing the investigation I found that fsaerodata adds 4 sceneries at the top

Extract of MakeRwys_Scenery.cfg

Quote

[Area.175]
Title=FSAD_Navaids
Local=C:\Users\Troncy\Documents\fsAerodata Files\Navigation Data\Navaids
Layer=175
Active=TRUE
Required=FALSE

[Area.176]
Title=FSAD_Approaches
Local=C:\Users\Troncy\Documents\fsAerodata Files\Navigation Data\P3D\PROC
Layer=176
Active=FALSE
Required=FALSE

[Area.177]
Title=FSAD_Approaches1
Local=C:\Users\Troncy\Documents\fsAerodata Files\Navigation Data\P3D\PROC_SIDs
Layer=177
Active=FALSE
Required=FALSE

[Area.178]
Title=FSAD_Comms
Local=C:\Users\Troncy\Documents\fsAerodata Files\Navigation Data\Comms
Layer=178
Active=FALSE
Required=FALSE

If one of FSAD_Approaches,  FSAD_Approaches1 or FSAD_Comms is active then Runways.xml (LFPO data) is construct with the first one which is active.

Quote

<File>C:\Users\Troncy\Documents\fsAerodata Files\Navigation Data\Comms\scenery\FSAD_comms.BGL</File>
<SceneryName>FSAD_Comms</SceneryName>

<File>C:\Users\Troncy\Documents\fsAerodata Files\Navigation Data\P3D\PROC_SIDs\scenery\LFPO_SIDS.BGL</File>
<SceneryName>FSAD_Approaches1</SceneryName>

<File>C:\Users\Troncy\Documents\fsAerodata Files\Navigation Data\P3D\PROC\scenery\LFPO.BGL</File>
<SceneryName>FSAD_Approaches</SceneryName>

If none is active the data from the standard BGL file  "Scenery\0601\scenery\APX48140.bgl" is used.

In all case Runways.txt and I suppose r4.csv are built using the standard BGL file  "Scenery\0601\scenery\APX48140.bgl"

Cheers

Claude

[Pete Dowson]

4 hours ago, Claude Troncy said:

What is strange is that the bgl file detected in the runway. txt and in the runway.xml is not the same.

Presumably that's the file fsaerodata amends, and not the default. However, my first reply still stands -- the exact same table entry is used for both files and at the same time.

50 minutes ago, Claude Troncy said:

Continuing the investigation I found that fsaerodata adds 4 sceneries at the top

Yes, but for some reason 3 of those aren't enabled ("Active=FALSE"). Ah, i see you experimented with activating those after.

52 minutes ago, Claude Troncy said:

If none is active the data from the standard BGL file  "Scenery\0601\scenery\APX48140.bgl" is used.

In all case Runways.txt and I suppose r4.csv are built using the standard BGL file  "Scenery\0601\scenery\APX48140.bgl"

But all that cannot make any difference when the same value is used at the same time for all.

Maybe I just need whatever FSAD BGL is it which was logged for your XML file. There's no way of solving it by discussion.

Pete

 

[Claude Troncy]

27 minutes ago, Pete Dowson said:

But all that cannot make any difference when the same value is used at the same time for all.

I agree with you. That is incomprehensible.

29 minutes ago, Pete Dowson said:

Maybe I just need whatever FSAD BGL is it which was logged for your XML file

OK I attach them.

Thanks

Claude

FSAD_comms.BGL

LFPO.BGL

LFPO_SIDS.BGL

[Pete Dowson]

16 hours ago, Claude Troncy said:

I attach them.

Thanks. I'll take a look within the next few days, max a week.

Pete

 

[Pete Dowson]

Actually, it was quicker to debug this using the files you supplied.

The thing is, the Magvar entry in the XML file is from the AIRPORT data, whilst the ones associated with runways in the individual runway entries is in the specific runway sections of the BGLs. Both of these are in the same place in the same tables I create the files from, but there are separate sections for AIRPORT, RUNWAYS, GATES and TAXIWAYS. Oh, also COMMS.

It looks like your fsaerodata updater only updates one of these -- the airport headers, not the magvar associated with each runway. I think perhaps this could be a problem with ILS orientations. 

I did once subscribe ot faaerodata, but these days, when I think of updating these things, I use Herve Sors freeway updates. Might be worth you trying those instead?
http://www.aero.sors.fr/navaids3.html
Let me know.

Of course, mostly I only fly to/from addon airports which tend to have updated data in any case.

Pete

 

 

[Claude Troncy]

45 minutes ago, Pete Dowson said:

It looks like your fsaerodata updater only updates one of these -- the airport headers, not the magvar associated with each runway. I think perhaps this could be a problem with ILS orientations. 

I know that with aero.sors the problem is identical.  https://www.fsipanel.com/forum/viewtopic.php?f=6&amp;t=233

That means the problem is not in the data provided by aero.sor and fsaerodata.

As the problem doesn't seem to be with MakeRwys, I am going to check again with FSIPanel. 

Nevertheless I'll try the aero.sors data and let you know.

Merci

Claude

[Pete Dowson]

3 hours ago, Claude Troncy said:

As the problem doesn't seem to be with MakeRwys, I am going to check again with FSIPanel. 

How is fsipanel going wrong? Are you expecting it to show 0.78 or -2.00 and it isn't, or what. You need to know what it is reading and why.

I tried to analyse LFPO_SIDS.BGL with ADE (airport design editor), but is contains nothing to analyse. Having only that providing the modification of the variation from fsaerodata or Herve Sors updates seems odd. The important values are surely those connected to the runways as they will affect the magnetic headings of the runways (the true headings don't change of course).

I don't really see what I should do any differently in MakeRunways. Having different variations for the same airport just seems wrong.

Pete

 

 

[Claude Troncy]

1 minute ago, Pete Dowson said:

I don't really see what I should do any differently in MakeRunways. Having different variations for the same airport just seems wrong.

I perfectly understand.

5 minutes ago, Pete Dowson said:

Are you expecting it to show 0.78 or -2.00

 -2.00 is expected.

2 minutes ago, Pete Dowson said:

I tried to analyse LFPO_SIDS.BGL with ADE

I tried too and the file looks strange, but I think it is in this file (or the other two) that MakeRwys find the wrong value 0.78 associated with the airport. But is it really an airport ? 

When the  3 sceneries are not active then MakeRwys find the correct value in  Scenery\0601\scenery\APX48140.bgl. This file is also provided by fsaerodata and overwrite de initial one.

Claude

[Pete Dowson]

5 hours ago, Claude Troncy said:

 -2.00 is expected.

So fsaerodata makes the airport value wrong, but leaves it okay for the runways?

Why use it if it makes things wrong? What do the suppliers say?

5 hours ago, Claude Troncy said:

I tried too and the file looks strange, but I think it is in this file (or the other two) that MakeRwys find the wrong value 0.78 associated with the airport. But is it really an airport ? 

Well:

1. It is evidently created or amended by fsaerodata, so they are best placed to answer properly, but
2. It definitely contains an airport definition, which is why MakeRunways picks it up. And
3. Because it is apparently at the top of the priority list it takes precedence over any other such records. That's the whole point of the ordering of priorities.

None of the BGLs you supplied appear to  contain any sort of record which MakeRunways recognises as relating to an airport other than the header type data with name, coordinates, altitude and magvar. Those are in both LFPO.BGL and LFPO_SIDS. BGL.

Take a look in your Runways.txt file. That's a log of the rersults for every file containing airport related data of any sort which is of interest. Search for each entre starting "Airport LFPO" and you'll be able to identify each relevant BGL file for that airport. Each later one will have details replacing or adding to the ones before. There can also be "Delete" entries which delete specific stuff from lower airports. They tend to be used when replacing navaids, runways, gates taxiways, etc when the IDs are different -- otherwise they'd be accumulative, so getting runway 24 as well as 23, for example, where the mag var has changed sufficiently to warrant a new designation.

I wonder if it would be worth trying to get LFPO.BGL processed AFTER LFPO_SIDS.BGL, which would make the former higher in priority. I think you might achieve that by simply renaming it, say LFPO_XYZ.BGL.

Pete

 

 

[Claude Troncy]

Bonjour Pete,

10 hours ago, Pete Dowson said:

Take a look in your Runways.txt file

So the infos are for LFPO

Quote

Airport LFPO :N48:43:23.9967  E002:22:45.9997  291ft
          Country Name="France"
          State Name=""
          City Name="Paris"
          Airport Name="Orly"
          in file: Scenery\0601\scenery\APX48140.bgl

          Runway 6 /24  centre: N48:43:39.9347  E002:20:20.1818  291ft
              Start 6 : N48:43:12.9826  E002:19:03.9770  291ft Hdg: 61.8T, Length 11961ft 
              Computed start 6 : Lat 48.720020 Long 2.317014
              Offset Threshold primary: 984 feet
              Start 24 : N48:44:06.8868  E002:21:36.3851  291ft Hdg: 241.8T, Length 11961ft 
              Computed start 24 : Lat 48.735500 Long 2.360865
              Hdg: 61.840 true (MagVar -2.000), Concrete, 11961 x 148 ft
              Primary ILS ID = ORE 
........ etc

**********************************************************************************************************************************

Airport LFPO :N48:43:23.9967  E002:22:45.8403  291ft
          Country Name="France"
          State Name=""
          City Name="Paris"
          Airport Name="Orly"
          in file: C:\Users\Troncy\Documents\fsAerodata Files\Navigation Data\P3D\PROC\scenery\LFPO.BGL

          FSM A/P LFPO, lat=48.723331, long=2.379400, alt=291

**********************************************************************************************************************************

Airport LFPO :N48:43:23.9967  E002:22:45.8403  291ft
          Country Name="France"
          State Name=""
          City Name="Paris"
          Airport Name="Orly"
          in file: C:\Users\Troncy\Documents\fsAerodata Files\Navigation Data\P3D\PROC_SIDs\scenery\LFPO_SIDS.BGL

          FSM A/P LFPO, lat=48.723331, long=2.379400, alt=291

***********************************************************************************************************************************

Airport LFPO :N48:43:23.9319  E002:22:45.9885  291ft
          Country Name="France"
          State Name=""
          City Name="Paris"
          Airport Name="Orly"
          in file: C:\Users\Troncy\Documents\fsAerodata Files\Navigation Data\Comms\scenery\FSAD_comms.BGL

          COM: Type=8 (APPROACH), Freq=123.87, Name="ORLY"
          COM: Type=8 (APPROACH), Freq=124.45, Name="ORLY"
          COM: Type=8 (APPROACH), Freq=118.85, Name="ORLY"
          COM: Type=8 (APPROACH), Freq=120.85, Name="ORLY"
          COM: Type=8 (APPROACH), Freq=126.57, Name="DE GAULLE"
          COM: Type=1 (ATIS), Freq=126.50, Name="LFPO"
          COM: Type=1 (ATIS), Freq=131.35, Name="LFPO"
          COM: Type=7 (CLEARANCE), Freq=121.55, Name="ORLY"
          COM: Type=7 (CLEARANCE), Freq=120.50, Name="ORLY"
          COM: Type=9 (DEPARTURE), Freq=124.35, Name="DE GAULLE"
          COM: Type=9 (DEPARTURE), Freq=127.75, Name="ORLY"
          COM: Type=9 (DEPARTURE), Freq=133.37, Name="DE GAULLE"
          COM: Type=9 (DEPARTURE), Freq=128.37, Name="ORLY"
          COM: Type=5 (GROUND), Freq=121.70, Name="ORLY"
          COM: Type=5 (GROUND), Freq=121.82, Name="ORLY"
          COM: Type=6 (TOWER), Freq=118.70, Name="ORLY"
          COM: Type=6 (TOWER), Freq=120.50, Name="ORLY"
          FSM A/P LFPO, lat=48.723324, long=2.379441, alt=291

 

MakeRnwys detects LFPO airport in 4 files, the last three, which are at the top of the sceneries doesn't have any MagVar at all.

Cheers

Claude

[Pete Dowson]

4 hours ago, Claude Troncy said:

MakeRnwys detects LFPO airport in 4 files, the last three, which are at the top of the sceneries doesn't have any MagVar at all.

The only point in looking at the Runways.txt log was to see the priority oder. The airport Magvar isn't logged there. But as you saw in your Runways.xml file, it is certainly the LFPO_SIDS.BGL from which that MagVar is obtained.

So my previous message applies. The main question must be to the fsaerodata folks as to why they are changing the Airport Magvar to a wrong value (you said it should be -2.00), ad they are not doing this with the runways.

How is your program adversely affected? What is it using airport magvar for in any case? Surely only the runways orientations magnetically are important.

Pete

 

 

[Claude Troncy]

Hi Pete,

I made a mistake! 
In fact with fsaerodata, the MagVar should be 0.780

I investigate with an hexa editor in the different files.
- In the  files situated in the 3 sceneries at the top, the MagVar is coded as 0.780
- But in the file APX48140.bgl (provided by fsaerodata) they did not change the initial P3D MagVar, and is -2.00

That explain the difference in the files generated by MakeRwys. 

Now if I modify the fsaerodata APX48140.bgl with the correct MagVar 0.780 instead of -2.00 then all the date made by MakeRwys are coherent and FSIPanel is happy.

When FSIPanel is not happy the A/C is positionned far to the left or the right of the runway axe and after the A/P doesn't capture the ILS (PMDG 737 NGX)

I am going to send an email to fsaerodata asking them why there is an inconsistency, between the MagVar values in their files.

I hope they will not say that the MagVar in the top sceneries must overide the one in the APX48140.bgl.

Again thank you for helping me to understand where  the problem was.

Cheers

Claude

[Pete Dowson]

17 minutes ago, Claude Troncy said:

I investigate with an hexa editor in the different files.
- In the  files situated in the 3 sceneries at the top, the MagVar is coded as 0.780
- But in the file APX48140.bgl (provided by fsaerodata) they did not change the initial P3D MagVar, and is -2.00

That explain the difference in the files generated by MakeRwys. 

Now if I modify the fsaerodata APX48140.bgl with the correct MagVar 0.780 instead of -2.00 then all the date made by MakeRwys are coherent and FSIPanel is happy.

When FSIPanel is not happy the A/C is positionned far to the left or the right of the runway axe and after the A/P doesn't capture the ILS (PMDG 737 NGX)

I am going to send an email to fsaerodata asking them why there is an inconsistency, between the MagVar values in their files.

I hope they will not say that the MagVar in the top sceneries must overide the one in the APX48140.bgl.

So FSIpanel is using the runway data and it's orientation, which has to be corrected for MagVar.  That's more like what i would have thought.

I'm amazed the FSAerodata does not amend the runway entries. Those are far more important than the airport MagVar which is really not used for navigation at all. Maybe it has only omitted doing so for this one airport. Did you check, for instance, Paris de Gaulle (LFPG) or other likely affected airports?

Note that it can amend the runway entries without actually changing that APX BGL. It shouldn't really change existing files. All it should do is include the runway entries in its BGLs, so that they override the lower priority entries. If the magvar changes enough to force a change in runway designation they's surely have to do this --  and with approriate "delete" entries to stop two runways being derived with different designations.

Pete

 

[Claude Troncy]

42 minutes ago, Pete Dowson said:

Did you check, for instance, Paris de Gaulle (LFPG)

Yes all airports  have this problem.

42 minutes ago, Pete Dowson said:

I'm amazed the FSAerodata does not amend the runway entries.

I only change the MagVar in the global airport section and  it was reflected by MakeRwys for all the runways. In fact I do not find any MagVar data in the runway subrecord. Where is this data ?

Claude

 

[Pete Dowson]

59 minutes ago, Claude Troncy said:

I only change the MagVar in the global airport section and  it was reflected by MakeRwys for all the runways. In fact I do not find any MagVar data in the runway subrecord. Where is this data ?

Ah. Maybe you are correct and the airport one should reflect on all the runways. Sorry, I probably was making what seemed to be logical assumptions.

MakeRunways dates back many years -- to FS98. I have since then modified it to fetch additional BGL data, stuff that didn't occur in the files back then, and one major revision for the change in formats for FS2004 (I think).  And some additional file formats made on requests.  But I've not got a good memory for all the details.:-(

So, the problem is presumably that fsaerodata does what is thought to be enough, but it doesn't suit the way MakeRunways is designed. MakeRunways produces the data for the runways when that runway data is presented. From what you say, it must include then the MagVar for the airport do that it will be used for each runway.

I suspect that if I'd have known about this potential problem at the time all that was programmed I'd have designed the end data differently so that this happened automatically.... But I didn't.

It may or may not be easy for me to correct for this. I can certainly look at doing this, but it won't be for at least 4 weeks. My days are booked up solid for 2 weeks then I'm on holiday for nearly another 2. 

Apologies for my earlier incorrect assumptions.

Pete

 

[Claude Troncy]

Thank you Pete.

You don't have to apologyze. You make  such a great job for the world of FSX... P3D.
Take your time to fix the problem.  I wish you nice holidays.

Cheers

Claude

 

[herve_sors]

As Pete explained airport magvar (as coded at 0x24 of airport record) is not used by the sim. So there's really no need correcting it. Some designers provide a correct valuet. Other don't. So, I don't think it is a good idea for any addon to use it. Now, there is no way to obtain from BGL scenery files alone magnetic orientation of runways since the only coded value is the runway TRUE heading and airport magvar is not reliable.
In the simulator  runway magnetic heading is calculated from true heading and current magnetic variation at runway position from the MAGDEC.BGL file. So it is impossible to obtain it from the scenery BGL alone if you wish to obtain a trustable value.

Hervé

 

[Pete Dowson]

On 2/17/2019 at 3:25 PM, Claude Troncy said:

Take your time to fix the problem.  I wish you nice holidays.

I'm back and it is fixed -- MakeRunways version 4.87, available in the subforums and the usual links.

Pete

 

 

[Claude Troncy]

Hi Pete,

Thank you very much, the airport magvar are now well reflected for each runway, but in the runways.xml, it seems that the <Hdg> and <ILSHdg> tags don't reflect the correct magnetic heading, and whatever the magvar is, these value don't change.

Cheers

Claude

 

[Pete Dowson]

12 minutes ago, Claude Troncy said:

Thank you very much, the airport magvar are now well reflected for each runway, but in the runways.xml, it seems that the <Hdg> and <ILSHdg> tags don't reflect the correct magnetic heading, and whatever the magvar is, these value don't change.

Ah, are those in Magnetic? They are in True in the sources of course. I'll check ...

Does that affect all files, do you know?

Pete