Using OSM Vector Data in FlightGear

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

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)

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.