Given all the progress here, I would suggest to really consider looking at the C++ side of things. Pulling most of this off in C++ space should be fairly straightforward, much of the infrastructure is already in place in FG or SG, and can be easily exposed to Nasal space thanks to
cppbind. I can help with some of the details or open questions here.
We already have Stuart's "random buildings" system, so this could be generalized, made more configurable and exposed to scripting space, so that we could use OSM data as input for placement heuristics. This should be in line with Stuart's own comments:
Subject: OSM buidings EHLEstuart wrote:zakalawe wrote in Wed Oct 23, 2013 2:09 pm:A thought occurs - this is much more blue-sky, could we run a C++ version of the script in real-time? As an alternative / replacement for random-buildings. This relies on two assumptions: that the input data per tile is sensible sized (tens of kbytes, or worst case a hundred for centre of really built up city), and that the script could run in 'almost real time' on the OSG Pager thread.
Probably the best way to do this would be to separate the "random" from the "buildings" in the curent random buildings, and use the OSM data as an alternative data source for the latter.
-Stuart
Currently, the random building code is only configurable to some degree via XML tags - those are used to populate OSG data structures, but these could also be populated from scripting space. Thanks to cppbind, there's really very little needed in terms of C++ code to expose OSG data structures to Nasal and vice versa. Basically, city/building outlines could be pre-defined and randomized from Nasal, turned into OSG data structures and used by the SG code to build cities procedurally.
Also see:
http://wiki.flightgear.org/Using_OSM_Ve ... FlightGear