153
edits
Osm2city.py: Difference between revisions
Jump to navigation
Jump to search
extended workflow docs
m (→Related: http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg40092.html) |
(extended workflow docs) |
||
| Line 8: | Line 8: | ||
It's at a rather early stage of development, and currently not very user-friendly. You probably should know some python if you want to use it yourself. But it produces realistic city layouts (after all, it uses realistic data). The whole process -- from scratch to flying in FG -- for a city the size of LOWI takes perhaps one hour, including maybe a total of 15 mins manual work. | It's at a rather early stage of development, and currently not very user-friendly. You probably should know some python if you want to use it yourself. But it produces realistic city layouts (after all, it uses realistic data). The whole process -- from scratch to flying in FG -- for a city the size of LOWI takes perhaps one hour, including maybe a total of 15 mins manual work. | ||
It has been tested with Dresden, Germany (EDDC) and Innsbruck, Austria (LOWI). Both areas are now populated with about 50,000 buildings. Rendering this in FG is quite demanding. The FG process eats ~2.8GB RAM when flying in those areas, the download is ~50 MB each. | It has been tested with Dresden, Germany (EDDC) and Innsbruck, Austria (LOWI). Both areas are now populated with about 50,000 buildings. Rendering this in FG is quite demanding. The FG process eats ~2.8GB RAM when flying in those areas, the download is ~50 MB each. | ||
== Status 05/2013 == | == Status 05/2013 == | ||
Please see the development repository at: https://gitorious.org/fg-radi/osm2city | Please see the development repository at: https://gitorious.org/fg-radi/osm2city | ||
Currently data is processed offline | Currently data is processed offline beforehand. Basically, it parses the OSM | ||
xml, generates a list of building outlines, discards some based on their area, | xml, generates a list of building outlines, discards some based on their area, | ||
simplifies the outlines, clusters them into ~500x500m blocks and different LODs, | simplifies the outlines, clusters them into ~500x500m blocks and different LODs, | ||
then writes .ac, .xml, and .stgs. OSM parsing is by far the most expensive, | then writes .ac, .xml, and .stgs. OSM parsing is by far the most expensive, | ||
easily taking 10 minutes for 50k buildings. Once that's done, the remaining | easily taking 10 minutes for 50k buildings. Once that's done, the remaining | ||
parts take maybe 1 minute in total | parts take maybe 1 minute in total. | ||
At the moment, the code knows only the floor plans. No streets, no runways, no | At the moment, the code knows only the floor plans. No streets, no runways, no | ||
land-use. But it'll certainly process such data in the future, and then could | land-use. But it'll certainly process such data in the future, and then could | ||
use some heuristics (some OSM buildings are labeled "Terminal 1" or so) to apply | use some heuristics (some OSM buildings are labeled "Terminal 1" or so) to apply | ||
terminal/hangar textures to buildings at airports. | terminal/hangar textures to buildings at airports. This way we could rather easily populate some airports with | ||
'semi-generic' terminal/hangar buildings. | 'semi-generic' terminal/hangar buildings. | ||
| Line 43: | Line 38: | ||
:* find matching roof texture for given facade texture | :* find matching roof texture for given facade texture | ||
* basic lightmap support | * basic lightmap support | ||
* position lights on tall buildings | |||
* shows statistics on processed buildings | * shows statistics on processed buildings | ||
* writes .ac, .xml, .stg | * writes .ac, .xml, .stg | ||
| Line 68: | Line 64: | ||
* bump map/reflection effects? | * bump map/reflection effects? | ||
* a mode that generally uses shared models? If we find a shared models of matching floorplan, use this instead of creating a new, individual building? Will break clusters. | * a mode that generally uses shared models? If we find a shared models of matching floorplan, use this instead of creating a new, individual building? Will break clusters. | ||
* a terrasync-like thing? Users get OSM buildings | |||
(where available) on-the-fly? Might be quite costly in terms of runtime performance and bandwidth. The OSM download (buildings only!) is | |||
~40MB for the 25x25km LOWI area. | |||
== Install == | |||
* copy elev.nas to $FGDATA/Nasal/ | |||
== Workflow == | == Workflow == | ||
* get | |||
* decide on a region you want to populate. Get its lon/lat coordinates. | |||
* create project directory, say LOWI/ | |||
* get corresponding OSM data in OSM's native .xml format. | |||
There are several options to get OSM data. From command line: | |||
wget www.overpass-api.de/api/xapi?*[building=*][bbox=11.16898,47.20837,11.79108,47.38161] | |||
Put this data into LOWI/ | |||
* probe elevation for this area: | * probe elevation for this area: | ||
:* | :* enter lon/lat for your area in the call to raster_glob() near tools.py:241 | ||
:* run FG | :* run tools.py, this will create a file elev.in. Copy elev.in to $FGDATA/Nasal/ | ||
:* hide scenery/Objects/e.... folder, to prevent probing elevation on top of existing objects | |||
:* run FG, open nasal console, enter: elev.get(), press execute. Might take a long time, depending on the area scanned. This will write elevation data to /tmp/elev.xml (which is actually just plain 5 column data: lon,lat,x,y,elevation). Put elev.xml into LOWI/ | |||
* set up osm2city.py (near top of file) | |||
:* set prefix to LOWI/ | |||
:* set infile to your OSM .xml data. You can give a maximum number of objects to be parsed via total_objects = .. | |||
:* enter list of .stg paths which should be checked for existing objects in your area. Near osm2city.py:493 | |||
static_objects = stg_io.Stg(["e011n47/3138129.stg", "e011n47/3138128.stg"]) | |||
(FIXME: we could easily compute this on the fly) | |||
* run osm2city.py | * run osm2city.py | ||
:* the first run parses OSM data. This again takes quite | :* the first run parses OSM data. This again takes quite looong (10 minutes or more for 50k buildings), but the result is written to file data.pkl. Next startup is much faster. | ||
* run install.sh | :* move buildings.pkl to LOWI/buildings.pkl | ||
:* if all goes well, you should now have lots of files like LOWIcity0101.ac and their corresponding .xml files, along with .stg files | |||
* adjust and run install.sh, this will install .ac, .xml, .stg files | |||
== Improve fps == | == Improve fps == | ||