Sorry, I only just noticed that you replied ...
As you can see, we have had a fair share of discussions related to this. Stuart's work has certainly paved the way for even more improvements.
Like I mentioned, I would be interested in exposing the creation of procedural scenery to scripting space (or even just the property tree) so that customizing this aspect of FG is no longer possible purely from C++ space.
With your background in Java and Python, understanding the C++ and Nasal side of things should definitely be pretty easy - even though Nasal is in fact closer to Java/JavaScript syntax-wise ... but many Nasal concepts will seem familiar to you due to Python.
Stuart is the developer of the random buildings code (and the random trees), so he's got plenty of experience with procedural creation of scenery elements.
To understand the C++ side of things, you'll definitely also need to be familiar with OpenGL and preferably OSG, i.e. 3D graphics and 3D maths.
But even if that's not your thing, reusing Stuart's code to the largest possible degree would definitely be a good idea, because he's already tackled many of the difficult issues - and creating an interface (scripting or property tree) is definitely simpler than writing such a system from scratch.
Once you do take a look, you'll also find a number of threads related to the open source PixelCity project, which uses a fixed rendering pipeline (i.e. no shaders) - but which is nonetheless extremely impressive. Like Torsten mentioned a while ago, this would need to be ported to OSG (and shaders) to be usable in FG, but this could probably be done by merging it with Stuart's code, because that's a very good (and
working!) example of how the FlightGear/SimGear side of things works.
If you are interested in pre-processing and enriching vector data, you'll probably want to get in touch with some of the other folks who have done similar things, such as the osm2xp project.
Also, if that's definitely your main interest, you may also want to look at TerraGear, which is the "FG scenery compiler suite" to build scenery.
That said, a "pre-processor" could also be implemented as a native FG component, i.e. within the main fgfs executable - quite probably even as a fully threaded component, so that pre-processing could take place in a simple worker thread using exclusive read/write access.
I'm just saying this because "compiling" scenery from scratch is generally understood not to be a simple task for most people here. In other words, even if you should come up with such an OSM-pre-processor to enrich FG scenery, the resulting data may not be usable by most people - not without an official scenery rebuild at least.
Thus, having a component that would be running inside (or next to) FG would be easier from a deployment point of view.
FG already has fairly extensive networking support, and it would be comparatively simple to define an I/O interface to enrich scenery with metadata for scenery vector information, whereas said metadata could be created by a separate process, running in parallel with FG - that would mean that it would be up to us to provide such an interface, and that it would be up to you to provide an application that talks to FG in order to provide a "metadata feed".
The corresponding data would not necessarily need to be propagated via sockets, it could just well use pipes on most OS.
So there are really various options here and it really only depends on your background and your main area of interest.
Obviously, being able to build FG from source would still be useful regardless, because most approaches would inevitably require modifications to the C++ side of things - even though you may not necessarily need to implement them yourself.
Well, give me some time to read all articles, try to understand it and write a proof-of-concept in Java or Python.
Before you spend any serious amount of time coding, I'd suggest to report back here and let us know about your ideas and approach - it's pretty likely that some of us can provide further pointers that could turn out to be real time savers when getting started hacking FG.