Re: [Flightgear-devel] Helipad thresholds

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

Hi,

James Turner <ja...@fl...> wrote:

> (I’ve forgotten exactly where we do and don’t support single-ended runways in
> the code, it looks like it should mostly work, but I don’t know if we have any
> in the data…. probably some unit tests need to be added for these cases)

In the code I' ve looked at recently, there is only
FGAirport::readThresholdData() at
flightgear/src/Airports/airport.cxx:636:

  for (; (runway = aRoot->getChild("runway", runwayIndex)) != NULL; ++runwayIndex) {
    SGPropertyNode* t0 = runway->getChild("threshold", 0),
      *t1 = runway->getChild("threshold", 1);
    if (!t0 || !t1) {
      throw sg_io_exception("Mis-configured runway threshold data: exactly two thresholds must be defined",
                            sg_location{runway}, "FGAirport::readThresholdData", false);
    }

This one seems easy to fix; I don't know if there are places elsewhere
in the NavData code which assume that “a runway always has a
reciprocal”.

> The major problem David had, and which Florent has fixed, is us picking a
> threshold.xml in say E/G/P/EGPH.threshold.xml which corresponds to
> FGData/Airports/apt.dat, but because a custom scenery overrides the
> definitions for EGPH, the threshold data is wrong. With the recent change, we
> only use the XML data if its path is ‘ahead’ of the apt.dat in the scenery
> search paths, not ‘behind it’, so the scenery search path order works out as
> users would expect.

Yes, the only exception being *.procedures.xml files because we want to
allow big datasets of such files (like those from Navigraph) to be
usable when their base path in scenery search path order is *after*
custom sceneries. This way, custom sceneries may ship *.procedures.xml
files that take precedence over the big datasets.

Regards

-- 
Florent