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:05, 30 January 2014
, 30 January 2014→Procedural Buildings & Cities (radi)
| Line 12: | Line 12: | ||
Also see [https://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg38354.html Canvas & Tiled Maps ] Note that osgEarth will probably soon be linked into FG by default according to [http://sourceforge.net/p/flightgear/mailman/flightgear-devel/thread/CAP3ntysiT0x-Fd_xN%2BS4qqSV%2BDwh7FNk%2BMj7BeHhmz-FB%2B5y9w%40mail.gmail.com/#msg31901878], which means that GDAL/OGR can be relied upon, i.e. supporting GeoTIFF processing would be another useful option for any mapping/charting needs implemented via Tom's Canvas system. | Also see [https://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg38354.html Canvas & Tiled Maps ] Note that osgEarth will probably soon be linked into FG by default according to [http://sourceforge.net/p/flightgear/mailman/flightgear-devel/thread/CAP3ntysiT0x-Fd_xN%2BS4qqSV%2BDwh7FNk%2BMj7BeHhmz-FB%2B5y9w%40mail.gmail.com/#msg31901878], which means that GDAL/OGR can be relied upon, i.e. supporting GeoTIFF processing would be another useful option for any mapping/charting needs implemented via Tom's Canvas system. | ||
=== Procedural Buildings & Cities (radi) === | === Procedural Buildings & Cities (radi & vanosten) === | ||
Radi has focused on OSM buildings/bridges in the past, but is now interested in procedural city generation in general. OSM xml data for LOWI region alone is 50 MB. Might be a bit heavy a download for some users. Radi discussed this with James at FSweekend last year: we could pre-process OSM data, extract what's useful for us, and ship the outcome with our scenery. OSM buildings for LOWI would then add perhaps 1MB or so. OTOH, if this is generated at run-time (and then cached), users could decide themselves if/what OSM features they wish/can afford. | Radi has focused on OSM buildings/bridges in the past, but is now interested in procedural city generation in general. OSM xml data for LOWI region alone is 50 MB. Might be a bit heavy a download for some users. Radi discussed this with James at FSweekend last year: we could pre-process OSM data, extract what's useful for us, and ship the outcome with our scenery. OSM buildings for LOWI would then add perhaps 1MB or so. OTOH, if this is generated at run-time (and then cached), users could decide themselves if/what OSM features they wish/can afford. | ||
'''vanosten:''' I understand there are advantages to do stuff on the fly - it might be even faster to do calculations than reading detailed info like ac-files from the file system. However I wonder whether it really is the same thing that people try to accomplish. Together with Radi I want with osm2city make a plausible world, which satisfies also someone on sightseeing with a helicopter, who knows the area. The other is generating a plausible world. The first one needs a lot of parametrization and logic on a per object level. If the first one can be satisfied with on-the-fly processing, then I would look into porting code to C++ and learning C++. If not, then potentially we should leave the initiatives apart? | |||
===Populate FG world with OSM data (F-JJTH) === | ===Populate FG world with OSM data (F-JJTH) === | ||