153
edits
Osm2city.py: Difference between revisions
Jump to navigation
Jump to search
Major status update
Portreekid (talk | contribs) |
(Major status update) |
||
| Line 5: | Line 5: | ||
Development [https://gitorious.org/fg-radi/osm2city repository] on gitorous. | Development [https://gitorious.org/fg-radi/osm2city repository] on gitorous. | ||
Forum thread [http://forum.flightgear.org/viewtopic.php?f=5&t=22809 osm2city.py development] | |||
Written in python 2.7, developed on Linux. It should also run on Mac OSX. Windows users, see [[Osm2city.py#Install_on_Windows|below.]] | 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. 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 | 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 30 min, including maybe a total of 15 min 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 06/2014 == | |||
I'm currently adding textured roads, railroads, intersections and bridges. | |||
== Status 04/2014 == | == Status 04/2014 == | ||
[[File:LOWI with OSM buildings from FL300.jpg|thumb|Aerial view of LOWI, with 60k OSM buildings]] | [[File:LOWI with OSM buildings from FL300.jpg|thumb|Aerial view of LOWI, with 60k OSM buildings]] | ||
Following Mathias' suggestion at FS Weekend 2013, I've now changed the code such that it merges all buildings per (osm2city) tile into one object, reducing the number of drawables from O(10k) to O(10). That indeed gives a nice speed-up. In fact, I'm overwhelmed by what's possible now -- here's a scene looking down at LOWI from FL300 showing 60k buildings | Following Mathias' suggestion at FS Weekend 2013, I've now changed the code such that it merges all buildings per (osm2city) tile into one object, reducing the number of drawables from O(10k) to O(10). That indeed gives a nice speed-up. In fact, I'm overwhelmed by what's possible now -- here's a scene looking down at LOWI from FL300 showing 60k buildings. Plain Scenery 2.0 gives 19 fps on i7 Intel HD 5000 2560x1440. With buildings framerate goes down to 14. | ||
[[File:LOWI with OSM buidings one object per tile.jpg|thumb|Approaching LOWI, with 60k OSM buildings]] | [[File:LOWI with OSM buidings one object per tile.jpg|thumb|Approaching LOWI, with 60k OSM buildings]] | ||
| Line 20: | Line 23: | ||
== Status 10/2013 == | == Status 10/2013 == | ||
Currently data is processed offline beforehand. Basically, it parses the OSM | 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, | ||
| Line 29: | Line 30: | ||
</del> (Some optimization gave a huge speedup). | </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. <del>No streets</del>, 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 | ||
| Line 36: | Line 37: | ||
== Features == | == Features == | ||
* reads buildings from OSM. Honors height and level tags | * reads buildings from OSM. Honors height and level tags, reads relations ('buildings with holes') | ||
* reads existing .stg, won't place OSM building if there's a static model nearby | * reads existing .stg, won't place OSM building if there's a static model nearby | ||
* reads pre-calculated terrain elevation: places buildings at correct elevation | * reads pre-calculated terrain elevation: places buildings at correct elevation | ||
* simplify/automate elevation probing by using fgelev | |||
* 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 | ||
| Line 46: | Line 48: | ||
:* find matching texture for given building (number of levels, modern/old building, etc) | :* find matching texture for given building (number of levels, modern/old building, etc) | ||
:* find matching roof texture for given facade texture | :* find matching roof texture for given facade texture | ||
* basic lightmap support | * basic lightmap support (currently broken) | ||
* obstruction lights on tall buildings | * obstruction lights on tall buildings | ||
* command line interface and parameters file (thanks to forum user vanosten) | |||
* shows statistics on processed buildings | * shows statistics on processed buildings | ||
* writes .ac, .xml, .stg | * writes .ac, .xml, .stg | ||
== Planned Features == | |||
(in random order) | |||
* more complex facade generation. Currently, all sides get same texture {{not done}} | |||
* Rembrandt lighting {{not done}} | |||
* put a piece of matching ground texture around buildings ('garden') {{progressbar|10}} | |||
* put shared models if/where OSM indicates so: gas stations... {{not done}} | |||
* geometry cleanup, simplify too complex buildings {{done}} | |||
* use residential/industrial/commercial tags/areas. ATM, all is residential. {{not done}} | |||
* geometry cleanup, simplify too complex buildings {{done}} | |||
* Batch processing of greater areas including downloads (PortreeKid) | |||
* use more LOD levels, write them to different .ac so users can easily reduce building density, therefore improve performance {{progressbar|50}} | |||
:* put large buildings into one ac, sort/rate buildings by stand-out-ness {{done}} | |||
:* then ship light/med/full .stg {{not done}} | |||
* mid-term: develop this into a city-engine that procedurally generates a city based on OSM roads. {{not done}} | |||
:* read, drape, texture roads and railways {{progressbar|70}} | |||
:* texture road intersections {{not done}} | |||
:* illuminate roads {{not done}} | |||
:* procedural bridges {{progressbar|30}} | |||
:* place shared models along roads if no OSM data available {{not done}} | |||
* long-term: integrate into FG to do all this on the fly. {{not done}} | |||
== 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. | ||
Osm2city can generate complex roof shapes. This increases 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 | |||
--prop:double:/sim/rendering/static-lod/roof=2000 | --prop:double:/sim/rendering/static-lod/roof=2000 | ||
to set the distance for 'roof' to 2 km. If you want to adjust it via FG's GUI, copy static-lod.xml (from osm2city's git repo) to $FGDATA/gui/dialogs. | to set the distance for 'roof' to 2 km. If you want to adjust it via FG's GUI, copy static-lod.xml (from osm2city's git repo) to $FGDATA/gui/dialogs. | ||
== Ideas == | == Ideas == | ||
| Line 87: | Line 92: | ||
== Install == | == Install == | ||
* dependencies: Install the following packages (names from Debian packages): | * dependencies: Install the following packages (names from Debian packages): | ||
python-numpy python-shapely python-matplotlib python-scipy python-pil | |||
* get [https://gitorious.org/fg-radi/osm2city osm2city] from gitorious | * 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 .) | * add the directory with osm2city modules to your [http://docs.python.org/2/using/cmdline.html#envvar-PYTHONPATH PYTHONPATH] (unless your PYTHONPATH already contains . (the dot)) | ||
* copy elev.nas to $FGDATA/Nasal/ | * copy elev.nas to $FGDATA/Nasal/ | ||
| Line 98: | Line 102: | ||
== Install on Windows == | == Install on Windows == | ||
osm2city is pure python | osm2city is pure python. Install the following packages. | ||
Install the following packages. | |||
http://www.lfd.uci.edu/~gohlke/pythonlibs/#numpy | http://www.lfd.uci.edu/~gohlke/pythonlibs/#numpy | ||
| Line 107: | Line 109: | ||
http://www.lfd.uci.edu/~gohlke/pythonlibs/#scipy-stack | http://www.lfd.uci.edu/~gohlke/pythonlibs/#scipy-stack | ||
TODO: PIL or pillow | |||
== Workflow == | == Workflow == | ||