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 06:15, 1 February 2014
, 1 February 2014→Powerlines (owenpsmith): http://forum.flightgear.org/viewtopic.php?f=5&t=20665&hilit=power+lines
(Soitanen: added description of my converter) |
m (→Powerlines (owenpsmith): http://forum.flightgear.org/viewtopic.php?f=5&t=20665&hilit=power+lines) |
||
| Line 251: | Line 251: | ||
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) === | ||
'''vanosten:'''It is meant to be to support pylons from the shared objects library be placed based on OSM data in Python (extending osm2city). | |||
'''f-ojac:'''Have a look at https://gitorious.org/fgscenery/tools too to avoid duplicate work. Power lines are showing in OSM, for instance http://osm.org/go/WJHUyw34- | |||
For mapserver, yes we'll have to wait a little as there are some prioritary works on. Automated power line object generation from OSM data has already been tested a few years ago. Right now we're trying to make this process rework, with other objects (windturbines, watertowers...) before going into more complicated stuff. Aligning the pylons is also doable, Jon wrote a script on that a few years ago. Now the webforms are done and terrain generation is quite finished, we'll focus on some other nice features. | |||
'''Soitanen:'''data can be taken from OSM - if two power pylons are connected with line tagged power=line, that means there are wires in the air. I think wires can be modeled with one 3D model. It must be some kind of parabolic function, when viewing on it from side. But, if power line is turning, length of wires on one and other side will not be the same. So, script, that will place pylons, must compute attaching point for wires and place 3D model in needed place with needed scale. | |||
'''Hooray:'''You can do that procedurally even without touching TerraGear or 3D modeling - e.g. by using a Nasal script that uses the OSM data to add those lines to the scenery - you would look up height/elevation, distance and connection points - and then use a technique like the one demonstrated in the glideslope tunnel script to add lines | |||
'''owenpsmith:'''When flying VFR in the heavily forested areas of western Canada, it is never the power lines you look for, it is the clearing through the trees made for the power lines. They stick out like a sore thumb. Terrain and auto-generated trees are not my domain by any means, but I would think that it would be easier to make a script to omit trees under the lines that it would be to generate the lines themselves. If you could say draw a line between any two models in a set of models (various transmission tower models) that are closer than a certain distance apart, then omit the trees within a given distance of that line? Just my 2 bits. If we can clear the trees, this might come along as a bonus with winter ground textures | |||
'''Johan G:'''Goes for Sweden as well. In the about 60% of Sweden's area covered by forest no other line features, except for rivers and highways, sticks out like a 25-50 m (80-160 ft) wide clear cut that stretches for mile after mile. It just struck me that the power line clearings is not really a problem related to the random tree placement algorithms, but rather a land classing problem. The area in the clearings are in essence a different land class than the surroundings. | |||
'''Hooray:'''You would need to get in touch with Thorsten and/or Stuart to see if omitting trees based on heuristics is currently possible or not, I have no idea - otherwise I agree, that it would seem like a straightforward improvement. | |||
'''owenpsmith:'''Setting the elevation offsets is a bit tricky and is done in several steps. First I add the towers on either side of the span if they do not already exist. Once they are uploaded and their terrain elevations have been set, I plug the lat/long/terrain elevation/tower height into a spreadsheet. Each spreadsheet is tweaked based on the number and layout of markers. The spreadsheet is set up to calculate the lat/long of each marker, and the absolute elevation based on a catenary curve. The coefficient of the curve is set for each span based on the length and adjusted until it "looks right". I then create all the objects locally and fire up the sim. I find the terrain elevation below each marker and subtract this from the absolute elevation to get the elevation offset. Once uploaded, I reload scenery in the sim and do a flypast to double check. This work is on hold right now because the mapserver site is acting up, and I can't access the object properties from the map. This is preventing me from getting the information for the towers on each end of the span. In the meantime I'm adding more towers so hopefully I can do a marker blitz once the mapserver is working properly again. On the subject of implementing the clearing through the trees, I've been thinking about this a bit. It occurred to me that the roads in FG use OSM line data and in the simulator, we get a grey line on the terrain, on which the trees have been omitted. So if we could implement a line type for power lines for which the trees will be omitted, but not draw the grey line, then we'd have the clearing we want. The line data could be derived from existing power pylon object positions. The line type may already be defined, we just need to set positions and process it appropriately in FG. Will dig into OSM when I get a chance. It would be nice to get automated power line object generation complete with tree clearing. Object heading might be a bit tricky. Adding power pylons is not that exciting but it is pretty quick work. I'd settle for OSM based tree clearing provided it aligns accurately with existing FG power pylons. It would seem that the power line data in OSM is just line data, similar to the roads for which we already clear the trees in FG. So if we can add the pylon objects based on this line data, can't we clear the trees the same way we currently do for roads? How is the line data (roads, power lines) defined? Are they not just a series of "waypoints" defined by lat/lon? If they are then couldn't the line data in the btg files, and the pylon positions in the stg files be based on the same set of lat/lon points? Then they would align in the rendered scenery? My development experience is in the C family (C, C++, C#), Perl, SQL databases, mostly "backend" development, very little GUI work. About 15 years ago I did some work on ATC systems, and ISS robotics using Ada :-/ Most of my career has been spent in aerospace/defence which grew out of my first career choice which was to be a commercial pilot. I got my commercial licence and my parents and a few other relatives have had various Cessna's over the years. So I pretty much grew up at small airports along the west coast of Canada. My favorite times in the cockpit have been on Cessna 180/185 floatplanes. So with this backwoods VFR experience, power lines have always been far more available than navaids for navigation. So is this how the roads are generated then? The road line data gets "baked" into the terrain files by giving these areas their own land class? So FG knows nothing about line data when it renders scenery at runtime? So if we have some power line line data, it would be similarly "baked" into the terrain using a land class which would ideally have the same terrain texture as the surrounding land classes with the exception that no trees would be generated. I see how it could get more complicated if you consider the impact on all terrain types, and the type of random objects on each (trees, buildings etc). Obviously for certain types of landclass the effects could be ignored, ie water, grassland, tundra, dessert etc. Others would require trees to be cleared. The urban effects are still a mystery to me but everything is slowly becoming less mysterious! I guess each landclass would have to be analyzed and grouped into categories based on impact of power lines. Then sibling/child land classes introduced based on that analysis, to be substituted for the base landclass. | |||
'''psadro_gm:'''ow that World Scenery 2.0 is rolling out, we're looking for new ideas to sketch out a roadmap for scenery features that require changes to the terragear tools and the .btg file format. I think one of the largest requests is from shader developers to get more into the .btg file. I'm currently looking at adding vertex attributes, and alternate texture coordinates. The biggest concern is backwards compatibility. Any new additions to the .btg should (hopefully) be ignored by older simgear versions. This will be an exciting time for experimentation to see what sticks.. I am unsure what we could do to 'clear out' tree generation on existing landclasses, as I am unfamiliar with how the trees are positioned. If there's anything that could be done with added info for the shader, let me know. | |||
'''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. | |||
[[Category:Developer Plans]] | [[Category:Developer Plans]] | ||