|
From: James T. <ja...@fl...> - 2024-01-09 10:32:56
|
> On 8 Jan 2024, at 16:56, Stuart Buchanan <stu...@gm...> wrote: > > On Mon, Jan 8, 2024 at 4:04 PM James Turner wrote: >> >> >>> On 8 Jan 2024, at 15:17, merspieler <mer...@al... <mailto:mer...@al...>> wrote: >>> >>> Also (iirc James mentioned that this might be possible) what >>> about loading the tgx/tgz files directly instead of unpacking >>> them onto disk? >>> Would save me from doubling the data, cause I then don't have >>> to have it once packed for the mirror and once unpacked for use. >>> Instead I could, just like with ws2.0 terrasync use the same >>> thing for both. >> >> It’s possible with some dev effort : easier than the fully general case (Aircraft / FGData from compressed sources) but not trivial unfortunately either. We need to use the OSG Archive stuff to tell osgDB about our compressed files, when someone looks for a path which might be inside one. > > This (compression) might be easier than it looks if we use the osg archive format directly rather than .tgz files. > I would absolutely avoid this like the plague, because then we are tied to .osga going forward, which I think will cause us other problems. And in general when working with any compressed archive format, being able to inspect / create / extract it using standard command line tools on any machine is a tremendous benefit. We already have good archive support working for TerraSYnc, and the osgDB::Archive API will let us support .zip or .txz or whatever we need, so if we use do that we are data-compatible forwards and backwards, only a client-side change. Kind regards, James |