Re: [Flightgear-devel] Helipad thresholds

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

Hi David,

I'll tell what I believe based on a quick look at the code, but beware
that I'm not familiar at all with the startup position and
{threshold,ils,...}.xml loading code. I had to use gdb to “quickly” find
which-place-I-know calls FGAirport::loadSceneryDefinitions(). Here it
is, but there may well be other cases:

#0  FGAirport::loadSceneryDefinitions() const (this=0x555559908ea0)
    at .../flightgear/src/flightgear/src/Airports/airport.cxx:606
#1  0x0000555555829394 in FGAirport::loadRunways() const (this=0x555559908ea0)
    at .../flightgear/src/flightgear/src/Airports/airport.cxx:535
#2  0x000055555582809e in FGAirport::findBestRunwayForHeading(double, FGAirport::FindBestRunwayForHeadingParams*) const
    (this=0x555559908ea0, aHeading=270, parms=0x0)
    at .../flightgear/src/flightgear/src/Airports/airport.cxx:205
#3  0x00005555561115c9 in flightgear::setPosFromAirportIDandHdg(std::string const&, double) (id="LFNA", tgt_hdg=270)
    at .../flightgear/src/flightgear/src/Main/positioninit.cxx:173
#4  0x00005555561155d4 in flightgear::initPosition() ()
    at .../flightgear/src/flightgear/src/Main/positioninit.cxx:663
#5  0x00005555560f341c in fgIdleFunction() ()

David Megginson <dav...@gm...> wrote:

> 1. A threshold file will always override apt.dat for starting position on a
> runway.

This seems to be the case.

> 2. If the Terrasync scenery has a threshold file, and my custom scenery has
> only apt.dat, the Terrasync threshold file will determine the aircraft
> starting position.

Ditto.

> Does that sound correct? It matches my observations, at least.

*.threshold.xml files and similar seem to be located using
XMLLoader::findAirportData() — see for instance
flightgear/src/Airports/airport.cxx:613 in next.
XMLLoader::findAirportData() is easy to understand: it goes through each
non-empty element of globals->get_fg_scenery() in sequence and returns
the first existing path that follows the naming pattern
Airports/I/C/A/ICAO.⟨stem⟩.xml using the specified ICAO and ⟨stem⟩ (such
as “threshold”).

Maybe we could:

1) Extend APTLoader::readAptDatFile() to store in a global map M — or
   some better place, I don't know — made of (ICAO, p) pairs. Each pair
   would correspond to an airport for which the actually-used apt.dat
   data comes from p/NavData/apt/whatever.dat[.gz].

2) Based on this map, XMLLoader::findAirportData() could be modified to
   only consider XML files under scenery path M[ICAO] when the ICAO is
   in map M.

The effect would be that if an airport has its data defined by an
apt.dat snippet from custom scenery, only “corrective XML files”
(threshold, ils, procedures, etc.) from the same scenery path would be
used for it. Airports for which the data comes from
$FG_ROOT/Airports/apt.dat.gz would still benefit from “corrective XML
files” located in any scenery path because there is no “NavData”
component in $FG_ROOT/Airports/.

This is maybe a bit complicated but that's the simplest idea that comes
to mind in order to achieve what I perceive as the desired goal...

Regards

-- 
Florent