Using OSM Vector Data in FlightGear: Difference between revisions

Jump to navigation Jump to search
(Switch to {{simgear source}} and {{gitorious source}} to update the out of date and broken Gitorious links.)
 
Line 367: Line 367:
http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg38134.html
http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg38134.html


=== Power Lines (vanosten, owenpsmith, Soitanen) ===
=== Power Lines (vanosten, owenpsmith, Soitanen, David.megginson) ===


'''vanosten:'''It is meant to be to support pylons from the shared objects library be placed based on OSM data in Python (extending osm2city).
'''vanosten:'''It is meant to be to support pylons from the shared objects library be placed based on OSM data in Python (extending osm2city).
Line 389: Line 389:


'''Hooray:'''Having runtime access to certain vector data would be useful for a number of other subsystems in FlightGear. Time has shown, that the more data is available, the more people are going to use it come up with novel features. And then, being able to dynamically place/replace scenery textures easily has been requested several times (see the runway skid marks discussions for example). Also, it would be awesome if TG development could be closely coordinated with the ongoing random buildings/OSM efforts (by radi et al). These are two areas that are clearly overlapping in various ways - despite the fact, that FlightGear's random buildings are less static than TG scenery compilation historically is. But you guys once mentioned that you were looking into creating more and more stuff procedurally at runtime anways - so given that both efforts seem to be alive and kicking currently, it would be great to see some form of JV for the greater good (i.e. final outcome)regarding random trees/buildings, Stuart is the right person to talk to - he should be able to explain how everything works currently. But if I remember correctly, he announced a while that he was reworking the whole subsystem, and considering to decouple the "randomness" aspect a little more, so that other placement heuristics could be used, too.
'''Hooray:'''Having runtime access to certain vector data would be useful for a number of other subsystems in FlightGear. Time has shown, that the more data is available, the more people are going to use it come up with novel features. And then, being able to dynamically place/replace scenery textures easily has been requested several times (see the runway skid marks discussions for example). Also, it would be awesome if TG development could be closely coordinated with the ongoing random buildings/OSM efforts (by radi et al). These are two areas that are clearly overlapping in various ways - despite the fact, that FlightGear's random buildings are less static than TG scenery compilation historically is. But you guys once mentioned that you were looking into creating more and more stuff procedurally at runtime anways - so given that both efforts seem to be alive and kicking currently, it would be great to see some form of JV for the greater good (i.e. final outcome)regarding random trees/buildings, Stuart is the right person to talk to - he should be able to explain how everything works currently. But if I remember correctly, he announced a while that he was reworking the whole subsystem, and considering to decouple the "randomness" aspect a little more, so that other placement heuristics could be used, too.
'''david.megginson:'''As an Eastern Canadian pilot, I agree with @owenpsmith — unless you're flying very low level (e.g. landing, taking off, pipeline inspection, etc) it's mainly the clearing that you see, not the pylons and wires themselves.  I'd suggest that we need a material for "DefaultClearing" that can vary by region: for example, it would be grass in wet, temperate parts of North America, but we wouldn't want a strip of lush grass running through the desert under a power line.


== Related ==
== Related ==

Navigation menu