Re: [Flightgear-devel] Localiser radial definition in nav.datignored

[Florent R. <f.r...@fr...>]

Hi Alan,

"Alan Teeder" <ajt...@v-...> wrote:

> Also no luck with patching the code to set the default values to "true" and 
> "0.5" respectively.
> The LOC beam is obstinately stuck parallel to the runway.

You are right to be confused!

1) The code in flightgear/src/Navaids/navdb.cxx does what it is supposed
   to do when building the navcache. If you use:

     --prop:bool:/sim/navdb/localizers/auto-align=true
     --prop:double:/sim/navdb/localizers/auto-align-threshold-deg=0.5
     --log-class=navaid # groundnets, generation of the NavData cache, etc.
     --log-level=debug

   with for instance 267.000 for ident IPKT with row code 4 in
   nav.dat.gz:

     4  08.11359200  098.30684700     19 10990  18     267.000 IPKT VTSP 27  ILS-cat-I

   then you'll see:

     localizer:IPKT, aligning with runway 27 exceeded heading threshold

   in the FG output (on stdout or stderr, *not* in the log file which is
   stuck at log level 'info'). This shows that:

void alignLocaliserWithRunway(FGRunway* rwy, const string& ident, SGGeod& pos, double& heading)
{

  [...]

  if ( fabs(hdg_diff) <= autoAlignThreshold ) {
    pos = SGGeod::fromGeodFt(newPos, pos.getElevationFt());
    heading = rwy->headingDeg();
  } else {
    SG_LOG(SG_NAVAID, SG_DEBUG, "localizer:" << ident << ", aligning with runway "
            << rwy->ident() << " exceeded heading threshold");
  }
}

   from flightgear/src/Navaids/navdb.cxx took the right code path. And I
   think the SQLite DB *has* the value you put in nav.dat.gz.

2) So why don't you see any change in the built-in map? This is because
   the data from nav.dat.gz is shadowed by
   $scenery_path/Airports/V/T/S/VTSP.ils.xml (which is shipped as part
   of TerraScenery). In this file, you'll see:

     <runway>
       <ils>
         <lon>98.306847</lon>
         <lat>8.113592</lat>
         <rwy>27</rwy>
         <hdg-deg>263.45</hdg-deg>
         <elev-m>5.79</elev-m>
         <nav-id>IPKT</nav-id>
       </ils>
     </runway>

   If you replace the 263.45 with 163.45 for intance, you should see
   this:

     http://imgur.com/a/tEQA4

   which quite clearly shows how the arrows are drawn with respect to
   localizer position and runway threshold. cf. this comment in
   flightgear/src/GUI/MapWidget.cxx:

     void MapWidget::drawILS(bool tuned, FGRunway* rwy)
     {
     	// arrow, tip centered on the landing threshold
       // using LOC transmitter position would be more accurate, but
       // is visually cluttered

   When is the data overlaid? When it is retrieved from the NavCache:
   NavDataCache::loadById() does:

     FGAirport* apt = FGPositioned::loadById<FGAirport>(aptId);
     apt->validateILSData();

   which indirectly does:

     FGNavRecordRef nav(FGPositioned::loadById<FGNavRecord>(ils));
     assert(nav.valid());
     nav->updateFromXML(SGGeod::fromDegM(lon, lat, elevM), hdgDeg);

So, all in all, it is just Airports/V/T/S/VTSP.ils.xml in TerraScenery
that is overriding the data from nav.dat.gz...

Regards

-- 
Florent