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 11:25, 19 November 2014
, 19 November 2014→Status: update (devel list pointers)
m (http://sourceforge.net/p/flightgear/mailman/flightgear-devel/thread/E495A106FF5F31448739E79D34138C193C8DBAE1%40mbs2.ad.jyu.fi/#msg32325675) |
m (→Status: update (devel list pointers)) |
||
| 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 (11/2014) == | ||
{{FGCquote | |||
|I'd like to try to initiate a strategy discussion about how we should handle cities in the future. Right now, there's tools like osm2city.py, there's the urban shader, there are random buildings, there are static buildings (Paris...), there's streets painted on the texture, streets as part of the vector mesh and (experimental) streets draped onto the terrain.... | |||
Which is fine as long as these approaches aren't mutually exclusive, but unfortunately we left that state, so I think we should eventually have a strategy how to proceed. | |||
|{{cite web |url=http://sourceforge.net/p/flightgear/mailman/message/33054935/ | |||
|title=<nowiki>[Flightgear-devel] Future city terrain strategy (see full posting)</nowiki> | |||
|author=<nowiki>Renk Thorsten</nowiki> | |||
|date=<nowiki>2014-11-19</nowiki> | |||
}} | |||
}} | |||
{{FGCquote | |||
|Moving to ‘real’ OSM data for this seems the best plan - for all the reasons you list. It also have a very nice ‘user upgrade path’ - not enough buildings in your area? Submit them to OSM!<br/> | |||
<br/> | |||
I would prefer to avoid hardcoding a distinction at scenery creation time - actually I’d be looking to go the other way, and have road data and building data be fetched at runtime + cached directly. So if you disable buildings, they aren’t fetched. This would bring the tile complexity (vertex count) right down, since we also have to do flattening of the terrain for buildings / roads at runtime. (We could still include the road/building data in the scenery dirs, but separate from the BTG). | |||
|{{cite web |url=http://sourceforge.net/p/flightgear/mailman/message/33055284/ | |||
|title=<nowiki>Re: [Flightgear-devel] Future city terrain strategy (see full posting)</nowiki> | |||
|author=<nowiki>James Turner</nowiki> | |||
|date=<nowiki>2014-11-19</nowiki> | |||
}} | |||
}} | |||
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. | 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. | 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. | ||