153
edits
Osm2city.py: Difference between revisions
Jump to navigation
Jump to search
features and status update, more details on install (Thanks, Rick)
m (added roof LOD cmd line, fixed OSM download URL example) |
(features and status update, more details on install (Thanks, Rick)) |
||
| Line 4: | Line 4: | ||
Development [https://gitorious.org/fg-radi/osm2city repository] on gitorous. | Development [https://gitorious.org/fg-radi/osm2city repository] on gitorous. | ||
Written in python 2.7, developed on Linux | Written in python 2.7, developed on Linux. It should also run on Mac OSX. Windows users, see [[Osm2city.py#Install_on_Windows below.]] | ||
It's at a rather early stage of development. There's no GUI, everything is controlled by an input file. | It's at a rather early stage of development. There's no GUI, everything is controlled by an input file. 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 | == Status 10/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 | ||
| Line 16: | Line 16: | ||
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. <del>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. | </del> (Some optimization gave a huge speedup). | ||
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 | ||
| Line 32: | Line 32: | ||
* LOD animation based on building height and area (see below) | * LOD animation based on building height and area (see below) | ||
* cluster a number of buildings into a single .ac files. Clusters overlap to alleviate sharp LOD borders | * cluster a number of buildings into a single .ac files. Clusters overlap to alleviate sharp LOD borders | ||
* | * complex sloped roof generation (using Olivier Teboul's implementation of the straight skeleton algorithm) | ||
* texture manager: DB of facade/roof textures | * texture manager: DB of facade/roof textures | ||
:* ~10 different, hi-res facade textures, some roof textures | :* ~10 different, hi-res facade textures, some roof textures | ||
| Line 43: | Line 43: | ||
== LOD Scheme == | == LOD Scheme == | ||
FlightGear knows three standard LOD: bare, rough and detail. 'Bare' sets the drawing distance of the terrain, which may easily be 50 km or more. Drawing buildings 50 km out makes little sense (unless they are ''really'' tall), so we shouldn't use this level here. Of the remaining two standard levels, 'rough' is used for large and/or tall buildings, and 'detail' for smaller ones. | FlightGear knows three standard LOD: bare, rough and detail. 'Bare' sets the drawing distance of the terrain, which may easily be 50 km or more. Drawing buildings 50 km out makes little sense (unless they are ''really'' tall), so we shouldn't use this level here. Of the remaining two standard levels, 'rough' is used for large and/or tall buildings, and 'detail' for smaller ones. | ||
In the near future, osm2city will generate more complex roof shapes. This will increase the poly count further, and I believe it's a good idea to use another LOD 'roof' for complex roofs. Fortunately, we can change every aspect of FlightGear, and adding another LOD is easy. Use the FG command line | In the near future, osm2city will generate more complex roof shapes. This will increase the poly count further, and I believe it's a good idea to use another LOD 'roof' for complex roofs. Fortunately, we can change every aspect of FlightGear, and adding another LOD is easy. Use the FG command line | ||
| Line 52: | Line 52: | ||
* make command line interface. Currently, everything is hard-coded. | * make command line interface. Currently, everything is hard-coded. | ||
:* 2013/08: now uses parameters file, thanks to forum user vanosten | :* 2013/08: now uses parameters file, thanks to forum user vanosten | ||
* also parse OSM 'relation' tag and create 'buildings with holes' | * <del>also parse OSM 'relation' tag and create 'buildings with holes'</del> (done) | ||
* more complex roof shapes, put these into separate LOD | * <del> more complex roof shapes, put these into separate LOD</del> (done) | ||
* 2013/10 started: simplify/automate elevation probing by using fgelev | |||
* more complex facade generation. Currently, all sides get same texture | * more complex facade generation. Currently, all sides get same texture | ||
* Rembrandt lighting | * Rembrandt lighting | ||
* put shared models if/where OSM indicates so: gas stations... | * put shared models if/where OSM indicates so: gas stations... | ||
* use residential/industrial/commercial tags/areas. ATM, all is residential. | * use residential/industrial/commercial tags/areas. ATM, all is residential. | ||
* geometry cleanup, simplify too complex buildings (what is "too complex"?) | * <del>geometry cleanup, simplify too complex buildings (what is "too complex"?)</del> (done) | ||
* use more LOD levels, write them to different .ac so users can easily reduce building density, therefore improve performance | * use more LOD levels, write them to different .ac so users can easily reduce building density, therefore improve performance | ||
:* 2013/05: started: now roofs go into separate LOD | :* 2013/05: started: now roofs go into separate LOD | ||
| Line 77: | Line 76: | ||
== Install == | == Install == | ||
* dependencies: Install the following packages (names from Debian packages): | |||
python-imposm python-imposm-parser python-numpy python-shapely python-matplotlib python-scipy | |||
* get [https://gitorious.org/fg-radi/osm2city osm2city] from gitorious | |||
* add the directory with osm2city modules to your [http://docs.python.org/2/using/cmdline.html#envvar-PYTHONPATH PYTHONPATH] (unless your PYTHONPATH already contains .) | |||
* copy elev.nas to $FGDATA/Nasal/ | * copy elev.nas to $FGDATA/Nasal/ | ||
* Change the first two lines of elev.nas to match specific directories | |||
with write access (e.g. $FG_HOME/Export). See [[IORules]] and [[$FG_HOME]] | |||
== Install on Windows == | |||
osm2city is pure python, but it depends on imposm.parser for OSM parsing. Some users report problems with imposm.parser on Windows -- YMMV. In the future, we might replace imposm.parser with a standard XML parser. | |||
== Workflow == | == Workflow == | ||