Using OSM Vector Data in FlightGear

Background

This is referring to procedural/autogen scenery generation/enrichment (buildings, cities, roads, bridges and power lines) via OSM data.

We've seen quite a few people working on this independently in 2013 and making very promising progress in different fields. Many of them being contributors able to build from source, and able to write C++ code. TorstenD mentioned a while ago, that he was also considering porting PixelCity to use Stuart's random buildings system (and thus, OSG) for these purposes. Now, we also have osgEarth as a secondary scenery engine, so it makes sense to coordinate things accordingly.

Please see thee ongoing discussion at: http://wiki.flightgear.org/User_talk:F-JJTH#Implement_an_OSM_client_in_FG

The main point being that we should work out a way to expose the underlying APIs to FG, so that these can be used as the common back-end for OSM vector data access (probably via Tom's cppbind) - so that related efforts can benefit without having to duplicate work, and without having to use approaches that are not native to FG (such as python code).

As could be seen in 2013, we have an unprecedented number of people interested in this currently, who are able to contribute to the code - so if we could coordinate this a little, this could work out as well as the NavDisplay effort, which had a similar amount of people interested in related things.

We now have so many people doing work related to this, that the wiki is the only sane place to coordinate things - because some use the devel list, others only the forum - and others only IRC ... so better use the wiki for now.

Also, the wiki is the only future-safe method to organize things, in case we need to drop the effort for a "while" (weeks, months or years).

Objective

Any OSM-processing should ideally be exposed via FG APIs, so that OSM data can be processed by other subsystems (either via fgcommands, extension function or cppbind), to ensure that we cannot just visualize OSM data using the Canvas, but also use it affect the placement heuristics in Random Buildings according to Stuart's plans [1] or interface OSM with osgEarth.

Efforts

Random Buildings (Stuart)

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.

Random Buildings Scripting Interface (Hooray, Thorsten)

Hooray: 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.

PixelCity (Hooray, TorstenD)

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.

It really looks cool from the distance and close up. Implementing it into FlightGear requires porting the OpenGL calls to be OpenSceneGraph compatible, probably by implementing osgDrawable. The current implementation only shows night-time views, so this has to be tweaked, too. Another issue to take care of is interaction with existing scenery models, so the generated buildings do not interfere with our scenery models. The same is true for our landcover, roads and elevation data. Definitely worth some thinking. Probably as a google summer of code

Also see AutoGen Scenery for FlightGear.

OSM & Canvas (TheTom)

TheTom is also working on something to show tilemaps inside a canvas. I've now pushed a function to fgdata (https://gitorious.org/fg/fgdata/commit/41b6c9c688ce78d8c907a07c42b9ea4d8290da0c) which allows building templates for the tile urls.

Also see Canvas & Tiled Maps Note that osgEarth will probably soon be linked into FG by default according to [2], which means that GDAL/OGR can be relied upon, i.e. supporting GeoTIFF processing would be another useful option for any mapping/charting needs implemented via Tom's Canvas system.

Procedural Buildings & Cities (radi & vanosten)

Also see Osm2city.py

Radi has focused on OSM buildings/bridges in the past, but is now interested in procedural city generation in general. OSM xml data for LOWI region alone is 50 MB. Might be a bit heavy a download for some users. Radi discussed this with James at FSweekend last year: we could pre-process OSM data, extract what's useful for us, and ship the outcome with our scenery. OSM buildings for LOWI would then add perhaps 1MB or so. OTOH, if this is generated at run-time (and then cached), users could decide themselves if/what OSM features they wish/can afford.

vanosten: I understand there are advantages to do stuff on the fly - it might be even faster to do calculations than reading detailed info like ac-files from the file system. However I wonder whether it really is the same thing that people try to accomplish. Together with Radi I want with osm2city make a plausible world, which satisfies also someone on sightseeing with a helicopter, who knows the area. The other is generating a plausible world. The first one needs a lot of parametrization and logic on a per object level. If the first one can be satisfied with on-the-fly processing, then I would look into porting code to C++ and learning C++. If not, then potentially we should leave the initiatives apart?

Populate FG world with OSM data (F-JJTH)

F-JJTH's idea here is to populate FG world with OSM data. OSM provides some API for HTTP request ( [3] ) Once data are downloaded we could be able to draw them on-the-fly in FG. In other words: it's similar to the osm2fg but in-live.

BTW, this feature is not at the top of my priority and I would wait the osgEarth integration before all.

Using the HTTP APIs is a bit overlapping with the recent work on HTTP bindings for Nasal via cppbind, but also with poweroftwo's osgEarth integration, which uses curl to provide fully threaded access to this kind of data. Also, Stuart repeatedly mentioned on the forums that he would be supportive of exposing the placement heuristics for his random buildings code-seconded by Zakalawe [4], so that these can be affected via corresponding APIs - we've had quite a bit of progress regarding procedural scenery generation in 2013, including buildings & cities (radi, Soitanen/osm2fg) [5] [6], roads, rivers - even railways (vivian) and procedural bridge generation (radi) [7], but also procedural power lines (vanosten) [8]. In other words, there's some serious -and unprecented manpower- to be leveraged and coordinated here, including quite a few folks who are able to build from source and able to write C++ code. So this deserves being coordinated among all interested parties. And it would clearly make sense not to just expose things to the Canvas system, but to expose the corresponding APIs so that other subsystems and users can access these and use these for the purposes outlined above.