20,741
edits
Osm2city.py: Difference between revisions
Jump to navigation
Jump to search
→Status 05/2013: http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg40100.html
(status updates. More inviting 'contributing' section.) |
(→Status 05/2013: http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg40100.html) |
||
| Line 12: | Line 12: | ||
== 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 before hand. Basically, it parses the OSM | |||
xml, generates a list of building outlines, discards some based on their area, | |||
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, | |||
easily taking 10 minutes for 50k buildings. Once that's done, the remaining | |||
parts take maybe 1 minute in total. In C++, this would be faster, of course. Are | |||
you thinking of a terrasync-like thing here, where users get OSM buildings | |||
(where available) on-the-fly? In addition to what Stuart said, this might be | |||
quite expensive in terms of bandwidth. The OSM download (buildings only!) was | |||
~40MB for the 25x25km LOWI area. | |||
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 | |||
use some heuristics (some OSM buildings are labeled "Terminal 1" or so) to apply | |||
terminal/hangar textures to buildings at airports. Hadn't thought of this | |||
before, but yes, this way we could rather easily populate some airports with | |||
'semi-generic' terminal/hangar buildings. | |||
== Features == | == Features == | ||
* reads buildings from OSM. Honors height and level tags. | * reads buildings from OSM. Honors height and level tags. | ||