20,741
edits
Using OSM Vector Data in FlightGear: Difference between revisions
Jump to navigation
Jump to search
m
Using OSM Vector Data in FlightGear (view source)
Revision as of 20:21, 30 January 2014
, 30 January 2014→Status: http://forum.flightgear.org/viewtopic.php?f=5&t=17598&p=166686#p166861
m (→PixelCity (Hooray, TorstenD): http://forum.flightgear.org/viewtopic.php?f=5&t=17598&p=166686#p166861) |
m (→Status: http://forum.flightgear.org/viewtopic.php?f=5&t=17598&p=166686#p166861) |
||
| Line 22: | Line 22: | ||
== Status == | == Status == | ||
If you are interested in pre-processing and enriching vector data, you'll probably want to get in touch with some of the other folks who have done similar things, such as the osm2xp project. | |||
Also, if that's definitely your main interest, you may also want to look at TerraGear, which is the "FG scenery compiler suite" to build scenery. | |||
That said, a "pre-processor" could also be implemented as a native FG component, i.e. within the main fgfs executable - quite probably even as a fully threaded component, so that pre-processing could take place in a simple worker thread using exclusive read/write access. | |||
I'm just saying this because "compiling" scenery from scratch is generally understood not to be a simple task for most people here. In other words, even if you should come up with such an OSM-pre-processor to enrich FG scenery, the resulting data may not be usable by most people - not without an official scenery rebuild at least. | |||
Thus, having a component that would be running inside (or next to) FG would be easier from a deployment point of view. | |||
== Efforts == | == Efforts == | ||