To help newly registered users get more familiar with the wiki (and maybe older users too) there is now a {{Welcome to the wiki}} template. Have a look at it and feel free to add it to new users discussion pages (and perhaps your own).

Contents

Objective

people definitely need to understand what they are doing, I would not suggest to actually try this unless people really understand how to patch/build different versions of SG/FG - people blindly following instructions by copying & pasting shell commands into a terminal window is begging for trouble - as matter of fact, that is why I always encourage folks to set up dedicated "fgfs" accounts to be on the safe side.

Someone able to build from source should still be able to get osgEarth working without too much effort - on Windows there should even be some kind of "overlay" (set of patch files) - I am not sure if those have recently been updated for 3.2 though.

you do need osgEarth support for that, which is not included in any of the standard releases so far - which is why you need to follow the instructions from the osgEarth thread - however, osgEarth in 3.2 is a completely different matter, because this may very well involve building FlightGear from source - all of this is fairly well documented via a number of different wiki articles. However, it is a fairly technical and tedious process, certainly for people new to compiling software. In other words, osgEarth support in FlightGear in its current form hasn't yet been included in any official release, which means that it must be considered an experimental feature, which is primarily supported by the community, through a number of wiki articles, forum threads/postings and instructions on getting it to work.

I believe that the OsgEarthNext branch can be built in Linux but seems to require some gyrations to accomplish the setup. see above conversations.

The fgmindata is simply a minimal set of fgdata necessary to run Flightgear, particularly with the osgEarth build without having to download all of the fgdata repository. It contains only a handful of aircraft.
I would not recommend dumping the contents on top of an existing fgdata data set unless you are careful about the merging. There are probably only about a dozen or so files that need to be added/merged to the existing fgdata set.
If you have the fgdata git repository cloned already, you might consider adding a remote pointing to the fgdata-osgearth repository. That would allow you to cleanly manage as a separate branch.

Background

However, most SG/FG related changes that would conflict with a merge are relatively trivial, i.e. could be resolved by manual edits pretty easily - I don't think that there's lots of scenery related code that got updated recently, i.e. anything affecting the osgEarth patch - simply because FG/osgEarth overrides much of the standard scenery engine anyway.
I *assume* that merge conflicts should be relatively straightforward to fix up - but it would make sense to look at the latest release branch in that case.

Status

It is what it is, and being what it is (a set of external patches), it has a certain barrier to entry, and learning curve, associated with it.

Basically, people wanting to use this, will need to know how to build FlightGear from source, how to use git and how to apply patches.

People with a working build environment should have no problems getting this to work - the main caveat being currently that some recent sg/fg developments would not be integrated yet.

But otherwise, all the documentation that you can find on the wiki about building FlightGear from source, using git, will be applicable - the main difference is that once you have everything set up and working to build stock fgfs, you would add poweroftwo's gitlab branches as git remotes, and then build an older version of SimGear/FlightGear which contains the corresponding patches.