Using OSM Vector Data in FlightGear

From FlightGear wiki
Revision as of 20:08, 30 January 2014 by Hooray (talk | contribs) (→‎Objective)
Jump to navigation Jump to search

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.[/quote]

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.

Status

Efforts

Random Buildings (Stuart)

osgEarth (poweroftwo)

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.

OSM2FG (Saitonen)

Powerlines (owenpsmith)