Re: [Flightgear-devel] Helipad thresholds

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

Hi James,

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

> Yes I’m pretty sure procedures needs to be special cased because we have
> ‘procedures only’ scenery dirs. Sorry.

Riiight.

> Another option could be to process the ‘extension’ XML files (runway_rename,
> ils, threshold, twr) when building the NavCache, when the apt.dat path is
> known? But this would make the NavCache build much much slower.

Except for the cache rebuild speed issue, this would make sense, however
too many places reading these XML files are involved; this way looks
much more complicated that what I can do now. If someone else wants, no
problem, though.

> The ground-net and procedures files are different because they add in new
> data, rather than overriding apt.dat data

That's right for the apt.dat we handle (I haven't looked at the apt.dat
format in years, so can't say if this would still hold with newer
versions).

Regarding the “global map” I mentioned earlier (reworded here to be
clearer):

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

after thinking more about it, I believe it would be good to store this
in the 'airport' table of the SQLite database, which currently is only:

  "CREATE TABLE airport (has_metar BOOL);"

So, we'd add one field, say:

  custom_scenery_path VARCHAR

FGAirport would make this path publically accessible (or the empty
string if only the default apt.dat.gz is used for the airport in
question), say via FGAirport::customSceneryPath() which would return a
null SGPath for the default apt.dat.gz (I'll modify the type of
NavDataCache::DatFilesGroupInfo::paths in NavDataCache.hxx so that
NavDataCache::updateListsOfDatFiles() can mark the “default dat file” in
a special way [for the apt, fix and nav types — the other types aren't
searched in scenery dirs]). And finally, XMLLoader::findAirportData()
could query FGAirport::customSceneryPath() in order to know if the
airport has apt.dat data from a custom scenery dir and, in such a case,
which dir it is (namely, the path I noted as 'p' above).

(There will be a few little changes to APTLoader and NavDataCache, but
in parts I know well.)

Does that sound good?

Regards

-- 
Florent