Using OSM Vector Data in FlightGear: Difference between revisions

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 [http://forum.flightgear.org/viewtopic.php?f=5&t=16083&p=192393&hilit=osm2city#p192393], 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) [http://forum.flightgear.org/viewtopic.php?f=5&t=19625] [http://forum.flightgear.org/viewtopic.php?f=5&t=16083&p=192393&hilit=osm2city#p192393], roads, rivers - even railways (vivian) and procedural bridge generation (radi) [http://forum.flightgear.org/viewtopic.php?f=5&t=21061&hilit=bridges], but also procedural power lines (vanosten) [http://forum.flightgear.org/viewtopic.php?f=5&t=20665&hilit=osm2city]. 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.

[[Category:Developer Plans]]