Re: [Flightgear-devel] Helipad thresholds

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

Hi,

[ Stuart's input needed below, please! ;-) ]

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

> Yes, absolutely fine with me, and a good solution.

I have something that compiles and implements about 75% of the changes,
namely everything up to and including storing the scenery path in the
SQLite DB.

I have a question for Stuart because I believe he wrote
APTLoader::loadAirportFromFile() in
flightgear/src/Airports/apt_loader.cxx, and this relies on
APTLoader::readAptDatFile() whose first arg type is now a little struct:

class NavDataCache
{
public:

...

    struct DatFile {            // better name allowed...
        SGPath datPath;
        SGPath sceneryPath;     // scenery realpath() the dat file belongs to
    };

...
};

(bummer that nested classes can't be forward-declared in C++!)

This argument type change is needed because APTLoader::readAptDatFile()
will now store, in the 'airport' table of the SQLite database, the
scenery path(*) where each airport got its apt.dat data from — this, in
order to implement the requested feature.

I see that APTLoader::loadAirportFromFile() is called from
AirportBuilder::readNode() but didn't find where that one is used. If
you (Stuart) want APTLoader::loadAirportFromFile() to load the airport
in the same way as “as requested in this thread”, i.e.:

  - further airport-related funcs from the sim may use XML extension
    files (threshold, ils, groundnet...) for this airport *only* if they
    belong to the scenery path the apt.dat snippet for the airport comes
    from...

  - ... except for XML procedure files pertaining to the airport, which
    could still be found in other scenery paths (this is a special case;
    see the previous messages for its rationale).

then AirportBuilder::readNode() would need to know the scenery path the
relevant apt.dat file comes from, in order to initialize the second
member of the little DatFile struct shown above.

Otherwise, if this handling is not necessary (as in, you might want to
ignore XML extension files for airports loaded by
AirportBuilder::readNode()?), then we could pass a null SGPath as the
second member of the DatFile struct, and handle this as desired (e.g,
skip) in pending changes to XMLLoader::findAirportData(). This is what
the attached patch does (see the line containing “XXXFlo” in a comment),
except it doesn't modify XMLLoader::findAirportData() yet (I implemented
everything “up to and including storing the scenery path in the SQLite
db”; the changes to XMLLoader::findAirportData() belong to the part I
left out for now, that will use the new path stored in the SQLite db for
each airport).

Regards

(*) Well, there are still a few open options:

    (a) A null path may be stored and treated specially (most notably by
        XMLLoader::findAirportData()).

    (b) In the attached patch, when an airport is loaded from
        $FG_ROOT/Airports/apt.dat.gz, the associated scenery_path field
        (stored in corresponding record of the airport table of the
        SQLite db) contains the realpath() of $FG_ROOT (this is
        implemented at the end of
        NavDataCache::NavDataCachePrivate::findDatFiles()).

        This allows such airports to be treated by the same code as
        those for which the apt.dat file is in a custom scenery path
        (under the NavData subdirectory), and would thus allow XML
        extension files to be found under $FG_ROOT/Airports/…/…/…/. This
        is quite cheap to implement (no special case) but I'm not sure
        it would be really useful, as said findDatFiles() member
        function adds $FG_ROOT/Scenery to the list of scenery paths if
        it isn't there yet, so such XML files could as well be stored
        under $FG_ROOT/Scenery.

    (c) Rather than (except for procedures) “only load XML extension
        files from the scenery path p the apt.dat snippet comes from”, I
        could implement: “load XML extension files from the first
        scenery path that contains the requested file and is no later
        than p in $FG_SCENERY”. No complication and would allow one to
        have, say, temporary overlays (or rather, *overrides*) via XML
        extension files in early scenery paths — in case you need to
        override one of these XML files but don't want to modify the
        custom scenery dir itself (external repository...).

        Overlaying rather than overriding is not possible without
        breaking the API of XMLLoader::findAirportData(), so all in all,
        I'm a bit skeptical regarding the desirability of this option —
        just mentioning it “in case”.

-- 
Florent