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 12:21, 13 January 2015
, 13 January 2015→Status (11/2014)
| Line 39: | Line 39: | ||
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 [http://forum.flightgear.org/viewtopic.php?f=5&t=17598#p166794] or interface OSM with osgEarth. | 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 [http://forum.flightgear.org/viewtopic.php?f=5&t=17598#p166794] or interface OSM with osgEarth. | ||
== Status ( | == Status (01/2015) == | ||
{{FGCquote | |||
| I've been working on a tool that combines all the static models within a .stg file into a single .osgb file using quadtrees, texture atlases etc. to make it as efficient as possible. | |||
|{{cite web |url=http://forum.flightgear.org/viewtopic.php?p=229623#p229623 | |||
|title=<nowiki>stgmerge</nowiki> | |||
|author=<nowiki>stuart</nowiki> | |||
|date=<nowiki>Tue Jan 13</nowiki> | |||
}} | |||
}} | |||
{{FGCquote | |||
|The main benefit of this is that it would allow the output of osm2city to be uploaded into the scenery object database and distributed via Terrasync. At the moment this isn't possible because the database requires models to be uploaded individually, and the large number of individual models produced by osm2city (unless various combine options are enabled) has too much performance impact.<br/> | |||
<br/> | |||
This would also allow random buildings to be generated offline and stored in the scenery object database as well, which was the original trigger for writing the tool.<br/> | |||
|{{cite web |url=http://forum.flightgear.org/viewtopic.php?p=229623#p229623 | |||
|title=<nowiki>stgmerge</nowiki> | |||
|author=<nowiki>stuart</nowiki> | |||
|date=<nowiki>Tue Jan 13</nowiki> | |||
}} | |||
}} | |||
{{FGCquote | |||
|The idea is that this tool would be run on the scenery server itself so the data downloaded via terrasync would already be merged. <br/> | |||
<br/> | |||
It would probably be fast enough to run at runtime, but doing so is complicated by the deferred loading we have in place within FlightGear which means that not all models are loaded at once.<br/> | |||
<br/> | |||
Doing it on the scenery server also saves some CPU time on the user's computer.<br/> | |||
<br/> | |||
osm2city would then revert to creating individual models, and get them added to the scenery DB. I think we'd want to tag them so they can be easily replaced by subsequent runs of osm2city. | |||
|{{cite web |url=http://forum.flightgear.org/viewtopic.php?p=229644#p229644 | |||
|title=<nowiki>Re: stgmerge</nowiki> | |||
|author=<nowiki>stuart</nowiki> | |||
|date=<nowiki>Tue Jan 13</nowiki> | |||
}} | |||
}} | |||
{{FGCquote | |||
|There's still a place for random buildings, but I think they would be generated offline and similarly placed in the scenery DB. PostGIS has the function available that would allow us to easily generate building locations based on the OSM street data. We'd probably move away from the shader-based instantiated buildings and instead just have big meshes. This has the advantage of allowing collision detection, helicopter landing etc. but obviously uses more memory. | |||
|{{cite web |url=http://forum.flightgear.org/viewtopic.php?p=229644#p229644 | |||
|title=<nowiki>Re: stgmerge</nowiki> | |||
|author=<nowiki>stuart</nowiki> | |||
|date=<nowiki>Tue Jan 13</nowiki> | |||
}} | |||
}} | |||
{{FGCquote | {{FGCquote | ||