FlightGear wiki - User contributions [en]

Wingflexer

2023-01-31T10:34:51Z

Radi: make wingflexer run as <autopilot> instead of <property-rule>, and remove comment about instability (which suggests just that).

[[File:787 wing flex hard landing.gif|thumb|Wingflex after a touchdown at 9 ft/s on a 787-8.]]

The '''Wingflexer''' module aims at animating the 3-D model of a wing in a somewhat realistic fashion. Wings of large aspect ratio tend to behave similar to a spring. They bend under load and oscillate for a while when the load changes, for example when entering a turn, during turbulence, or on touchdown. The method used is a significant improvement over what has been described [[Howto:Implement_wing_flex|here]]. However, the actual model animation part is identical and will not be covered.

Including this in your aircraft is fairly straightforward, but obtaining plausible parameters can require some research and trial-and-error. We will give an example (for the 787) below.

Introduced in FG 3.5, there are two implementations available. The first, which this article is focused on, uses autopilot/property rules. It is therefore very optimized and should be your first choice. The second implementation uses Nasal. It is a bit more flexible in the sense that it could also be applied to AI aircraft.

== Physical model ==
This section describes the physical model. You don't need to fully understand the math here to be able to use Wingflexer, but you should understand the parameters involved -- you will need to adapt them to your aircraft.

We use a simple spring-mass-damper system sketched below to model a flexible wing:
--> |<---- z --->|
g
+-----+ +-----+
<--- | m_w |---/\/\/\---| |
+-----+ +-----+
Lift wing spring fuselage
force mass

Lift is trying to pull the wing upwards (to the left in the sketch), which is countered by gravity acting on the wing mass. The wing's inertia, in combination with its stiffness and damping characteristics, will create damped oscillations after an initial deflection.

Mathematically speaking, the wing's motion, measured by the deflection z(t), is governed by the following parameters:

k wing stiffness
d damping
m_w = m_dw + fuel_frac * m_fuel
Total wing mass = dry wing mass + fuel mass. Because the fuel is distributed over the wing, we use
a fraction of the fuel mass in the calculation.
0.5*F_L lift force/2 (we look at one wing only)
..
z_f acceleration of the frame of reference (fuselage)

We integrate the equation of motion
.. k d . 0.5*F_L ..
0 = -z + --- z + ---- z - ------- - g - z_f
m_w m_w m_w
and write the deflection (z + z_ofs) in meters to /sim/systems/wingflexer/z-m.
The offset z_ofs is calculated automatically and ensures that the dry wing
(which still has a non-zero mass) creates a neutral deflection.

Discretisation by first order finite differences leads to
z_0 - 2 z_1 + z_2 k d (z_0 - z_1) 1/2 F_L ..
----------------- + --- z_1 + --- ----------- - ------- - g - z_f = 0
dt^2 m_w m_w dt m_w
It is convenient to divide k and d by a (constant) reference mass:
K = k / m_dw
D = d / m_dw

== Obtaining plausible parameters ==
To make our model produce a convincing dynamic behaviour, you will need to obtain estimates and fine-tune the parameters.

These include the wing mass m_w, the wing stiffness K, the damping D, and a scaling factor z_fac.
There's a python script wingflexer.py which assists you in fine-tuning. It will quickly simulate the dynamics of the model with your parameters.
So how to estimate the parameters?

1. Assume a dry wing mass m_dw. Research the wing fuel mass m_fuel.

2. Obtain estimates of
* the deflection z_flight in level flight, e.g by comparing photos of the real aircraft on ground and in air,
* the wing's natural frequency, perhaps from videos of the wing's oscillation in turbulence,
* the deflection with full and empty tanks while sitting on the ground.

3. Compute K to match in-flight deflection with full tanks:
K = g * (m_ac / 2 - (fuel_frac * m_fuel)) / (z_in_flight / z_fac) / m_dw
where
m_ac aircraft mass
g 9.81 m/s^2
z_fac scaling factor for the deflection, start with 1

4. Compute the natural frequency of this system for full and empty wing tanks:
f_full = sqrt(K * m_dw / (m_dw + fuel_frac * m_fuel)) / (2 pi)
f_empty = sqrt(K) / (2 pi)

Ideally we want our model to match the wing's natural frequency, the wing's deflection
while sitting on the ground with full or empty tanks, and the deflection (bounce)
during a hard landing. Getting real-world data for the latter is difficult.

Here are some relations:
* A lower wing mass increases the natural frequency, and weakens the touchdown bounce
* A higher stiffness K reduces the deflection and increases the natural frequency

== Enable developer options ==
By default, Wingflexer and the user-tunable parameters live in
/sim/systems/wingflexer/
/sim/systems/wingflexer/params/

There are two properties disabled by default which are only useful when you're tuning the parameters. To enable them, uncomment the developer section in Aircraft/Generic/wingflexer.xml.
This will activate
/sim/systems/wingflexer/params/z-fac
/sim/systems/wingflexer/sink-rate-fps
Z-fac simply scales the output. Once you're happy with the results, include this factor in the animation.
Sink-rate-fps allows you to simulate a touchdown at given vertical speed.

It will become clear in the next section why these two settings are useful.

== An example: the 787 ==
The 787 is known for its very flexible wings; the deflection in
unaccelerated flight is quoted as z = 3 m. One wing tank of FG's 787-8 holds
23,000 kg of fuel. Because the fuel is distributed over the wing, we use a
fraction of the fuel mass in the calculation: fuel_frac = 0.75. For the same reason
we don't use the true wing mass, but rather something that makes our model look
plausible.

So assuming a wing mass of 12000 kg, we get K=25.9 and f_empty = 0.5 Hz.
That frequency might be a bit low, videos of a 777 wing in turbulence show about
2-3 Hz. (I didn't research 787 videos).

To increase it, we could either reduce m_dw or increase K. A lower m_dw results
in a rather weak bounce on touchdown which might look odd. A higher K reduces
the deflection z_flight, but we can simply scale the animation to account for
that. We'll multiply the deflection z by a factor z_fac to get an angle for the
<rotate> animation later on anyway. So repeat 3. and 4. using e.g. z_fac = 10.
Now K = 259 and f_empty=2.6 Hz. While our model spring now only deflects
to 0.3 m instead of 3 m, the animation scale factor will make sure the wing
bends to 3 m. This way, we can match both natural frequency and observed deflection,
and still get a realistic bounce on touch down. Finally, adjust D such that an
impulse is damped out after about one or two oscillations; D = 12 seems to work
OK in our example.

It's difficult to get real-world data on the deflection during touchdown.
Touchdown at more than 10 ft/s is considered a hard landing and could result in some significant wing bending.
There's a video of a hard landing of an A346 (http://avherald.com/h?article=471e70e9), showing the
wings bend perhaps 1 m.

To assist you in tuning parameters for the touchdown bounce you can initialize your
wing mass with a (touchdown) vertical speed via /sim/systems/wingflexer/sink-rate-fps, and then observe the deflection and oscillation. This avoids you having to fly too many touch-and-go's while developing ;)

Finally, our model outputs the deflection in meters, but the <rotate> animation expects an
angle. It is up to you convert appropriately, depending on your wing
span and number of segments in the animation. Also don't forget to include z_fac.

== How to add to your aircraft ==
Create a file <tt>''[[$FG_ROOT]]/Aircraft/<your aircraft>/Systems/wingflexer-params.xml''</tt> which contains the parameters adjusted to your aircraft:
<syntaxhighlight lang="xml">
<?xml version="1.0" encoding="UTF-8"?>

<PropertyList>

<params>
<m-wing-dry-kg type="double">12000</m-wing-dry-kg>
<K type="double">259</K>
<D type="double">12</D>
<fuel-frac type="double">0.375</fuel-frac>
<lift-node-lbs alias="/fdm/jsbsim/forces/fbz-aero-lbs"/>
<fuel-node-1-kg alias="/consumables/fuel/tank/level-kg"/>
<fuel-node-2-kg alias="/consumables/fuel/tank[1]/level-kg"/>
<fuel-node-3-kg type="double">0</fuel-node-3-kg>
<fuel-node-4-kg type="double">0</fuel-node-4-kg>
</params>

</PropertyList>
</syntaxhighlight>

Also adjust the property node aliases for the wing fuel tanks. Wingflexer supports up to four tanks in total. Since we're currently only solving one equation and hence get only one deflection which is used for both wings, we have to average the wing mass. Internally, m_fuel is simply the sum of all given fuel nodes,
m_fuel = fuel-node-1-kg + fuel-node-2-kg + fuel-node-3-kg + fuel-node-4-kg
so you must include the weighting factor in fuel-frac (e.g. 1/2 if you provide 2 fuel nodes). If you have more than 4 wing tanks in total, use another property rule to compute the average.

In your aircraft's [[Aircraft-set.xml|*-set.xml file]], in <code><nowiki><systems></nowiki></code> section, load the parameters and the wingflexer module:
<syntaxhighlight lang="xml">
<systems>
<wingflexer include="Systems/wingflexer-params.xml"/>
<autopilot>
<name>wing flexer property rule</name>
<path>Aircraft/Generic/wingflexer.xml</path>
</autopilot>
</systems>
</syntaxhighlight>

The wingflexer writes the deflection to <code>/sim/systems/wingflexer/z-m</code>.
Finally, your model rotate animation has to pick it up and multiply it by z_fac:
<syntaxhighlight lang="xml">
<animation>
<type>rotate</type>
<property>sim/systems/wingflexer/z-m</property>
<factor>10</factor>

</animation>
</syntaxhighlight>

If your aircraft uses JSBSim, you're done now. YASim requires an extra step, described next.

== Yasim ==
Older Yasim does not write the lift to the property tree. But you can create a helper
function which computes the lift as
lift_force_lbs = aircraft_weight_lbs * load_factor - total_weight_on_wheels_lbs
and point the <lift-node-lbs> alias in wingflexer-params.xml to it.

More recent Yasim does write the force, but it needs its sign inverted as wingflexer expects z is positive downwards, and converted to LBF.

In Nasal that would be something like:

<syntaxhighlight lang="nasal">
setprop("fdm/yasim/forces/f-z-lift-lbf", getprop("fdm/yasim/forces/f-z-lift")*-0.224809);
</syntaxhighlight>

As an expression:

<syntaxhighlight lang="xml">
<expression>
<product>
<property>fdm/yasim/forces/f-z-lift</property>
<value>-0.224809</value>
</product>
</expression>
</syntaxhighlight>

== Implementation details ==
The autopilot/Property rules implementation lives in Aircraft/Generic/wingflexer.xml

The ODE x" + ax' + bx + c = 0 is integrated by DampedOsciFilterImplementation in FG/src/autopilot/digitalfilter.cxx.

== TODO ==
* write Yasim helper
* input for fuselage acceleration should rather be acceleration at CG instead of the pilot's location -- is there a property?
* add wingflexer.py (to where?)

== Related content ==
=== Wiki articles ===
* [[Howto:Implement wing flex]] – An older way to add wing flex, though the wingflexer need to be animated in a similar way, but based on /sim/model/wing-flex/z-m.
* [[Wingflex Shader]] - A shader that can animate the wingflex.

=== Forum topics ===
* [http://forum.flightgear.org/viewtopic.php?f=30&t=24699 Wing flex -- spring/damper Nasal module] – Development topic

=== Source code ===
* {{fgdata file|Aircraft/Generic/wingflexer.xml}} – [[Autopilot configuration reference|Autopilot/property rule]] part of the implementation
* {{fgdata file|Aircraft/Generic/wingflexer.nas}} – Nasal part of the implementation

[[Category:FlightGear feature]]

Wingflexer

2017-03-09T23:26:30Z

Radi: /* Physical model */ explain basic oscillation

[[File:787 wing flex hard landing.gif|thumb|Wingflex after a touchdown at 9 ft/s on a 787-8.]]

The '''Wingflexer''' module aims at animating the 3-D model of a wing in a somewhat realistic fashion. Wings of large aspect ratio tend to behave similar to a spring. They bend under load and oscillate for a while when the load changes, for example when entering a turn, during turbulence, or on touchdown. The method used is a significant improvement over what has been described [[Howto:Implement_wing_flex|here]]. However, the actual model animation part is identical and will not be covered.

Including this in your aircraft is fairly straightforward, but obtaining plausible parameters can require some research and trial-and-error. We will give an example (for the 787) below.

Introduced in FG 3.5, there are two implementations available. The first, which this article is focused on, uses autopilot/property rules. It is therefore very optimized and should be your first choice. The second implementation uses Nasal. It is a bit more flexible in the sense that it could also be applied to AI aircraft.

== Physical model ==
This section describes the physical model. You don't need to fully understand the math here to be able to use Wingflexer, but you should understand the parameters involved -- you will need to adapt them to your aircraft.

We use a simple spring-mass-damper system sketched below to model a flexible wing:
--> |<---- z --->|
g
+-----+ +-----+
<--- | m_w |---/\/\/\---| |
+-----+ +-----+
Lift wing spring fuselage
force mass

Lift is trying to pull the wing upwards (to the left in the sketch), which is countered by gravity acting on the wing mass. The wing's inertia, in combination with its stiffness and damping characteristics, will create damped oscillations after an initial deflection.

Mathematically speaking, the wing's motion, measured by the deflection z(t), is governed by the following parameters:

k wing stiffness
d damping
m_w = m_dw + fuel_frac * m_fuel
Total wing mass = dry wing mass + fuel mass. Because the fuel is distributed over the wing, we use
a fraction of the fuel mass in the calculation.
0.5*F_L lift force/2 (we look at one wing only)
..
z_f acceleration of the frame of reference (fuselage)

We integrate the equation of motion
.. k d . 0.5*F_L ..
0 = -z + --- z + ---- z - ------- - g - z_f
m_w m_w m_w
and write the deflection (z + z_ofs) in meters to /sim/systems/wingflexer/z-m.
The offset z_ofs is calculated automatically and ensures that the dry wing
(which still has a non-zero mass) creates a neutral deflection.

Discretisation by first order finite differences leads to
z_0 - 2 z_1 + z_2 k d (z_0 - z_1) 1/2 F_L ..
----------------- + --- z_1 + --- ----------- - ------- - g - z_f = 0
dt^2 m_w m_w dt m_w
It is convenient to divide k and d by a (constant) reference mass:
K = k / m_dw
D = d / m_dw

== Obtaining plausible parameters ==
To make our model produce a convincing dynamic behaviour, you will need to obtain estimates and fine-tune the parameters.

These include the wing mass m_w, the wing stiffness K, the damping D, and a scaling factor z_fac.
There's a python script wingflexer.py which assists you in fine-tuning. It will quickly simulate the dynamics of the model with your parameters.
So how to estimate the parameters?

1. Assume a dry wing mass m_dw. Research the wing fuel mass m_fuel.

2. Obtain estimates of
* the deflection z_flight in level flight, e.g by comparing photos of the real aircraft on ground and in air,
* the wing's natural frequency, perhaps from videos of the wing's oscillation in turbulence,
* the deflection with full and empty tanks while sitting on the ground.

3. Compute K to match in-flight deflection with full tanks:
K = g * (m_ac / 2 - (fuel_frac * m_fuel)) / (z_in_flight / z_fac) / m_dw
where
m_ac aircraft mass
g 9.81 m/s^2
z_fac scaling factor for the deflection, start with 1

4. Compute the natural frequency of this system for full and empty wing tanks:
f_full = sqrt(K * m_dw / (m_dw + fuel_frac * m_fuel)) / (2 pi)
f_empty = sqrt(K) / (2 pi)

Ideally we want our model to match the wing's natural frequency, the wing's deflection
while sitting on the ground with full or empty tanks, and the deflection (bounce)
during a hard landing. Getting real-world data for the latter is difficult.

Here are some relations:
* A lower wing mass increases the natural frequency, and weakens the touchdown bounce
* A higher stiffness K reduces the deflection and increases the natural frequency

== Enable developer options ==
By default, Wingflexer and the user-tunable parameters live in
/sim/systems/wingflexer/
/sim/systems/wingflexer/params/

There are two properties disabled by default which are only useful when you're tuning the parameters. To enable them, uncomment the developer section in Aircraft/Generic/wingflexer.xml.
This will activate
/sim/systems/wingflexer/params/z-fac
/sim/systems/wingflexer/sink-rate-fps
Z-fac simply scales the output. Once you're happy with the results, include this factor in the animation.
Sink-rate-fps allows you to simulate a touchdown at given vertical speed.

It will become clear in the next section why these two settings are useful.

== An example: the 787 ==
The 787 is known for its very flexible wings; the deflection in
unaccelerated flight is quoted as z = 3 m. One wing tank of FG's 787-8 holds
23,000 kg of fuel. Because the fuel is distributed over the wing, we use a
fraction of the fuel mass in the calculation: fuel_frac = 0.75. For the same reason
we don't use the true wing mass, but rather something that makes our model look
plausible.

So assuming a wing mass of 12000 kg, we get K=25.9 and f_empty = 0.5 Hz.
That frequency might be a bit low, videos of a 777 wing in turbulence show about
2-3 Hz. (I didn't research 787 videos).

To increase it, we could either reduce m_dw or increase K. A lower m_dw results
in a rather weak bounce on touchdown which might look odd. A higher K reduces
the deflection z_flight, but we can simply scale the animation to account for
that. We'll multiply the deflection z by a factor z_fac to get an angle for the
<rotate> animation later on anyway. So repeat 3. and 4. using e.g. z_fac = 10.
Now K = 259 and f_empty=2.6 Hz. While our model spring now only deflects
to 0.3 m instead of 3 m, the animation scale factor will make sure the wing
bends to 3 m. This way, we can match both natural frequency and observed deflection,
and still get a realistic bounce on touch down. Finally, adjust D such that an
impulse is damped out after about one or two oscillations; D = 12 seems to work
OK in our example.

It's difficult to get real-world data on the deflection during touchdown.
Touchdown at more than 10 ft/s is considered a hard landing and could result in some significant wing bending.
There's a video of a hard landing of an A346 (http://avherald.com/h?article=471e70e9), showing the
wings bend perhaps 1 m.

To assist you in tuning parameters for the touchdown bounce you can initialize your
wing mass with a (touchdown) vertical speed via /sim/systems/wingflexer/sink-rate-fps, and then observe the deflection and oscillation. This avoids you having to fly too many touch-and-go's while developing ;)

Finally, our model outputs the deflection in meters, but the <rotate> animation expects an
angle. It is up to you convert appropriately, depending on your wing
span and number of segments in the animation. Also don't forget to include z_fac.

== How to add to your aircraft ==
Create a file <tt>''[[$FG_ROOT]]/Aircraft/<your aircraft>/Systems/wingflexer-params.xml''</tt> which contains the parameters adjusted to your aircraft:
<syntaxhighlight lang="xml">
<?xml version="1.0" encoding="UTF-8"?>

<PropertyList>

<params>
<m-wing-dry-kg type="double">12000</m-wing-dry-kg>
<K type="double">259</K>
<D type="double">12</D>
<fuel-frac type="double">0.375</fuel-frac>
<lift-node-lbs alias="/fdm/jsbsim/forces/fbz-aero-lbs"/>
<fuel-node-1-kg alias="/consumables/fuel/tank/level-kg"/>
<fuel-node-2-kg alias="/consumables/fuel/tank[1]/level-kg"/>
<fuel-node-3-kg type="double">0</fuel-node-3-kg>
<fuel-node-4-kg type="double">0</fuel-node-4-kg>
</params>

</PropertyList>
</syntaxhighlight>

Also adjust the property node aliases for the wing fuel tanks. Wingflexer supports up to four tanks in total. Since we're currently only solving one equation and hence get only one deflection which is used for both wings, we have to average the wing mass. Internally, m_fuel is simply the sum of all given fuel nodes,
m_fuel = fuel-node-1-kg + fuel-node-2-kg + fuel-node-3-kg + fuel-node-4-kg
so you must include the weighting factor in fuel-frac (e.g. 1/2 if you provide 2 fuel nodes). If you have more than 4 wing tanks in total, use another property rule to compute the average.

In your aircraft's [[Aircraft-set.xml|*-set.xml file]], in <code><nowiki><systems></nowiki></code> section, load the parameters and the wingflexer module:
<syntaxhighlight lang="xml">
<systems>
<wingflexer include="Systems/wingflexer-params.xml"/>
<property-rule n="100">
<name>wing flexer property rule</name>
<path>Aircraft/Generic/wingflexer.xml</path>
</property-rule>
</systems>
</syntaxhighlight>

The wingflexer writes the deflection to <code>/sim/systems/wingflexer/z-m</code>.
Finally, your model rotate animation has to pick it up and multiply it by z_fac:
<syntaxhighlight lang="xml">
<animation>
<type>rotate</type>
<property>sim/systems/wingflexer/z-m</property>
<factor>10</factor>

</animation>
</syntaxhighlight>

If your aircraft uses JSBSim, you're done now. YASim requires an extra step, described next.

== Yasim ==
Yasim does not write the lift to the property tree. But you can create a helper
function which computes the lift as
lift_force_lbs = aircraft_weight_lbs * load_factor - total_weight_on_wheels_lbs
and point the <lift-node-lbs> alias in wingflexer-params.xml to it.

== Implementation details ==
The autopilot/Property rules implementation lives in Aircraft/Generic/wingflexer.xml

The ODE x" + ax' + bx + c = 0 is integrated by DampedOsciFilterImplementation in FG/src/autopilot/digitalfilter.cxx.

== TODO ==
* write Yasim helper
* input for fuselage acceleration should rather be acceleration at CG instead of the pilot's location -- is there a property?
* add wingflexer.py (to where?)

== Related content ==
=== Wiki articles ===
* [[Howto:Implement wing flex]] – An older way to add wing flex, though the wingflexer need to be animated in a similar way, but based on /sim/model/wing-flex/z-m.

=== Forum topics ===
* [http://forum.flightgear.org/viewtopic.php?f=30&t=24699 Wing flex -- spring/damper Nasal module] – Development topic

=== Source code ===
* {{fgdata file|Aircraft/Generic/wingflexer.xml}} – [[Autopilot configuration reference|Autopilot/property rule]] part of the implementation
* {{fgdata file|Aircraft/Generic/wingflexer.nas}} – Nasal part of the implementation

[[Category:FlightGear feature]]

Changelog 3.6

2015-09-17T21:59:13Z

Radi: /* Major enhancements in this release */ wingflexer: wording, add link to wiki page

{{draft|changelog|This changelog is currently being written for the FlightGear v3.6 release. Feel free to help! If you are aware of any FlightGear related changes, please add them to the changelog.}}

{{FGCquote|1= As many people have noticed, the v3.6 release has been slightly delayed. The main reason is that too many key developers have been out of town for work or holiday this month. We are currently hoping for a mid-September release. We will post further updates once our release manager returns and we can regroup from all the end of the summer (northern hemisphere) :-) activities. Thank you, Curt.|2= {{cite web | url = http://sourceforge.net/p/flightgear/mailman/message/34407279/ | title = <nowiki>[Flightgear-devel] Release v3.6 update</nowiki> | author = <nowiki>Curtis Olson</nowiki> | date = Aug 26th, 2015 }}}}

The FlightGear development team is delighted to announce the v3.6 release of FlightGear, the free, open-source flight simulator. This new version contains many exciting new features, enhancements and bugfixes. Highlights in this release include a reduced base installation size, improvements to the built-in Web UI, cockpit shadows without Rembrandt, and a massively improved default aircraft - the Cessna 172P.

Founded in 1997, FlightGear is developed by a worldwide group of volunteers, brought together by a shared ambition to create
the most realistic flight simulator possible that is free to use, modify and distribute. FlightGear is used all over the world
by desktop flight simulator enthusiasts, for research in universities and for interactive exhibits in museums.

FlightGear features more than 400 aircraft, a worldwide scenery database, a multiplayer environment, detailed sky modelling, a flexible and open aircraft modelling system, varied networking options, multiple display support, a powerful scripting language and an open architecture. Best of all, being open-source, the simulator is owned by the community and everyone is encouraged to contribute.

Download FlightGear v3.6 for free from [http://www.flightgear.org/ FlightGear.org]

FlightGear - Fly Free!

=== Major enhancements in this release ===
'''Project Organization'''
* The base package has been reduced in size to 1.3GB and moved to http://sourceforge.net/p/flightgear/fgdata/. All aircraft except the c172p and ufo have been removed.
* All core repositories have been moved to sourceforge. They can be found at https://sourceforge.net/projects/flightgear/

'''Core'''
* Numerous improvements to Phi, the built in web interface.
* Interactive traffic system re-enabled, having been disabled by mistake some releases previously.
* Various security improvements, including the disabling of system.fgfsrc,

'''Launcher'''
[[File:Qt launcher for FlightGear 3.5 on Windows 7.jpg|thumb|The aircraft page of the Qt launcher for FlightGear 3.5 as rendered on Windows 7.]]

The [[Integrated Qt5 Launcher|built-in Qt launcher]], developed by James Turner shipped by default with the Mac version of FlightGear 3.4, will be used for other OSes<ref>{{cite web
|url = http://sourceforge.net/p/flightgear/codetickets/1591/#4cb7
|title = Issue #1591
|author = Gijs
|authorlink-wiki = User:Gijs
|date = April 8th, 2015
}}</ref>. In addition, [[FGRun]] will be dropped in favor of this.

{{inote|In future FlightGear releases, there will be an additional HTML5-based version ([[Phi]], developed by Torsten D), and the Qt launcher, based on well-supported libraries, will be used as the main launcher (replacing [[FGRun]]). This parallel development is intentional<ref>http://forum.flightgear.org/viewtopic.php?p=229445#p229445</ref>, and it is likely that both will use a common service layer to provide the necessary data<ref>http://forum.flightgear.org/viewtopic.php?p=229303#p229303</ref>.}}

To learn more, see [[Integrated Qt5 Launcher]]

'''Aircraft Modeling'''
* [[Tooltips]] can now be positioned at a specific place on-screen.
* [[Wingflexer|wing flex]] module added, controlled via Nasal or Property Rules.
* Bug-fixes and improvements to the [[Failure Manager]].
* <code><nowiki><variant-of></nowiki></code> tag in the [[Aircraft-set.xml|*-set.xml]] file has been added. See [[FlightGear Newsletter March 2015]].
* Automatic checklist execution, e.g. for autostart
* 8.33 kHz spacing is now supported on comms radios.

'''JSBSim'''
* Sync with latest version of JSBSim
* The Pitot angle can now be tweaked with the <code><nowiki><pitot_angle></nowiki></code> tag in the <code><nowiki><metrics></nowiki></code> block.
* The refuel rate is now configurable with the <code><nowiki><refuel-rate></nowiki></code> tag in the <code><nowiki><propulsion></nowiki></code> block.

'''Atmospheric Light Scattering'''
* The addition of volumetric grass to the random vegetation system.
* Interior cockpit shadows.
* Interior glass reflections, frosting and fogging.
* Interior panel backlighting.
* New thruster effect (Afterburners, Rockets, etc).

'''Environment Rendering'''
* Improved rendering of the sun, particularly in space.

'''Usability'''
* Many improvements to Phi - the built-in web interface
* GUI cleanup to improve support for multiple GUI styles

'''Scenery'''
* Regional texture definitions for Florida, Brazil, Latin America, Africa, Middle East and Southeastern Asia.
* stgmerge tool added to merge objects in a scenery tile into a small number of meshes

'''Canvas System'''
* Improvements to Canvas/MapStructure and NavDisplay
* Canvas failure manager GUI dialog

'''Highlighted new and improved aircraft'''
* Complete refresh of the default c172p, including engine options, various tire sizes and floats.
* Major enhancements to the Shuttle. Shuttle can be flown as per the Crew Operations manual from launch to touchdown.
* The following aircraft have received significant updates: 787-8, F-15, B-1B, JA37, Citation II, Lockheed1049h, 737-300, Mirage 2000-5

'''Misc/Uncategorized'''
* Improved support for KDI572-574 DME equipment
* Update the World Magnetic Model to 2015.0

'''Bug fixes'''
* See [http://sourceforge.net/p/flightgear/codetickets/search/?q=status%3AFixed+AND+_milestone%3A3.6 our bugtracker] for an extensive, yet incomplete, list of the bugs fixed in this release.

{{Appendix}}

[[Category:FlightGear changelogs]]

Howto:Implement wing flex

2015-09-03T21:32:22Z

Radi: link the wingflexer article

[[File:747-400_wing_flex.jpg|thumb|270px|Wing flex as seen on the [[Boeing 747-400]].]]

'''Wing flex''' is the flexing of wings on [[aircraft]], due to lift and fuselage load. [[FlightGear]] is able to show realistic wing flex. Currently the [[Boeing 787]], [[Airbus A330-200|A330-200]], [[Boeing 747-400|747-400]], and [[Bombardier CRJ-900|CRJ-900]] are equipped with flexing wings.

This article describes a simple approach to model static wing flex. Using this approach, the wing will bend realistically under load, but it will not oscillate after load changes, e.g., on hard touchdown. For a more sophisticated model for dynamic wing flex, please see the [[Wingflexer|Wingflexer article]].

== Model ==
A few edits have to be made to the aircraft model. Each wing has to be cut into multiple sections. The more sections, the smoother the wing flex. Be carefull that you do not cut through flaps or engines. Naming our wing sections, from fuselage to wing tip: wing.1, wing.2 and wing.3.

Measure the coordinates of the start of each new wing section, you will need them to animate the wings.

== Animation ==
The following lines have to be added to the aircraft model .xml file. These lines are used with three wing sections, and a [[JSBSim]] [[FDM]].

<source>
<animation>
<type>rotate</type>
<object-name>LeftWing.1</object-name>
<object-name>LeftWing.2</object-name>
<object-name>LeftWing.3</object-name>
<property>fdm/jsbsim/aero/coefficient/CLalpha</property>
<factor>-0.0000045</factor>
<offset-deg>0</offset-deg>
<center>
<x-m> 0.00</x-m>
<y-m>-4.00</y-m>
<z-m>-1.70</z-m>
</center>
<axis>
<x>1.0</x>
<y>0.0</y>
<z>0.0</z>
</axis>
</animation>

<animation>
<type>rotate</type>
<object-name>LeftWing.2</object-name>
<object-name>LeftWing.3</object-name>
<property>fdm/jsbsim/aero/coefficient/CLalpha</property>
<factor>-0.0000045</factor>
<offset-deg>0</offset-deg>
<center>
<x-m> 0.00</x-m>
<y-m>-8.00</y-m>
<z-m>-1.50</z-m>
</center>
<axis>
<x>1.0</x>
<y>0.0</y>
<z>0.0</z>
</axis>
</animation>

<animation>
<type>rotate</type>
<object-name>LeftWing.3</object-name>
<property>fdm/jsbsim/aero/coefficient/CLalpha</property>
<factor>-0.0000045</factor>
<offset-deg>0</offset-deg>
<center>
<x-m> 0.00</x-m>
<y-m>-12.25</y-m>
<z-m> -1.25</z-m>
</center>
<axis>
<x>1.0</x>
<y>0.0</y>
<z>0.0</z>
</axis>
</animation>
</source>

You probably need to add a lot more objects to each section (like engines, flaps, ailerons etc.) and also change the ''center'' coordinates according to your aircraft. For the right wing, just change the sign of the center <y-m> coordinate and the factor value.

=== JSBSim ===
[[JSBSim]] calculates the lift force of the aircraft. The lift reacts on the G-forces, the velocity and turbulences. The respective property is: <tt>fdm/jsbsim/aero/coefficient/CLalpha</tt>

=== YASim ===
[[YASim]] does not calculate wingflex as nice as JSBSim, but a pretty realistic effect can be reached by using the <tt>accelerations/pilot-g[0]</tt> property instead.

[[es:Howto: Implement wing flex]]
[[Category:Aircraft enhancement|Implement wing flex]]
[[Category:Howto|Implement wing flex]]

Wingflexer

2015-09-03T21:06:17Z

Radi: wording

[[File:787 wing flex hard landing.gif|thumb|Wingflex after a touchdown at 9 ft/s on a 787-8.]]

The '''Wingflexer''' module aims at animating the 3-D model of a wing in a somewhat realistic fashion. Wings of large aspect ratio tend to behave similar to a spring. They bend under load and oscillate for a while when the load changes, for example when entering a turn, during turbulence, or on touchdown. The method used is a significant improvement over what has been described [[Howto:Implement_wing_flex|here]]. However, the actual model animation part is identical and will not be covered.

Including this in your aircraft is fairly straightforward, but obtaining plausible parameters can require some research and trial-and-error. We will give an example (for the 787) below.

Introduced in FG 3.5, there are two implementations available. The first, which this article is focused on, uses autopilot/property rules. It is therefore very optimized and should be your first choice. The second implementation uses Nasal. It is a bit more flexible in the sense that it could also be applied to AI aircraft.

== Physical model ==
This section describes the physical model. You don't need to fully understand the math here to be able to use Wingflexer, but you should understand the parameters involved -- you will need to adapt them to your aircraft.

We use a simple spring-mass-damper system sketched below to model a flexible wing:
--> |<---- z --->|
g
+-----+ +-----+
<--- | m_w |---/\/\/\---| |
+-----+ +-----+
Lift wing spring fuselage
force mass

The wing's motion, measured by the deflection z(t), is governed by the following parameters:

k wing stiffness
d damping
m_w = m_dw + fuel_frac * m_fuel
Total wing mass. Because the fuel is distributed over the wing, we use
a fraction of the fuel mass in the calculation.
0.5*F_L lift force/2 (we look at one wing only)
..
z_f acceleration of the frame of reference (fuselage)

We integrate the equation of motion
.. k d . 0.5*F_L ..
0 = -z + --- z + ---- z - ------- - g - z_f
m_w m_w m_w
and write the deflection (z + z_ofs) in meters to /sim/systems/wingflexer/z-m.
The offset z_ofs is calculated automatically and ensures that the dry wing
(which still has a non-zero mass) creates a neutral deflection.

Discretisation by first order finite differences leads to
z_0 - 2 z_1 + z_2 k d (z_0 - z_1) 1/2 F_L ..
----------------- + --- z_1 + --- ----------- - ------- - g - z_f = 0
dt^2 m_w m_w dt m_w
It is convenient to divide k and d by a (constant) reference mass:
K = k / m_dw
D = d / m_dw

== Obtaining plausible parameters ==
To make our model produce a convinving dynamic behaviour, you will need to obtain estimates and fine-tune the parameters.

These include the wing mass m_w, the wing stiffness K, the damping D, and a scaling factor z_fac.
There's a python script wingflexer.py which assists you in fine-tuning. It will quickly simulate the dynamics of the model with your parameters.
So how to estimate the parameters?

1. Assume a dry wing mass m_dw. Research the wing fuel mass m_fuel.

2. Obtain estimates of
* the deflection z_flight in level flight, e.g by comparing photos of the real aircraft on ground and in air,
* the wing's natural frequency, perhaps from videos of the wing's oscillation in turbulence,
* the deflection with full and empty tanks while sitting on the ground.

3. Compute K to match in-flight deflection with full tanks:
K = g * (m_ac / 2 - (fuel_frac * m_fuel)) / (z_in_flight / z_fac) / m_dw
where
m_ac aircraft mass
g 9.81 m/s^2
z_fac scaling factor for the deflection, start with 1

4. Compute the natural frequency of this system for full and empty wing tanks:
f_full = sqrt(K * m_dw / (m_dw + fuel_frac * m_fuel)) / (2 pi)
f_empty = sqrt(K) / (2 pi)

Ideally we want our model to match the wing's natural frequency, the wing's deflection
while sitting on the ground with full or empty tanks, and the deflection (bounce)
during a hard landing. Getting real-world data for the latter is difficult.

Here are some relations:
* a lower wing mass increases the natural frequency, and weakens the touchdown bounce
* a higher stiffness K reduces the deflection and increases the natural frequency

== Enable developer options ==
By default, Wingflexer and the user-tunable parameters live in
/sim/systems/wingflexer/
/sim/systems/wingflexer/params/

There are two properties disabled by default which are only useful when you're tuning the parameters. To enable them, uncomment the developer section in Aircraft/Generic/wingflexer.xml.
This will activate
/sim/systems/wingflexer/params/z-fac
/sim/systems/wingflexer/sink-rate-fps
Z-fac simply scales the output. Once you're happy with the results, include this factor in the animation.
Sink-rate-fps allows you to simulate a touchdown at given vertical speed.

It will become clear in the next section why these two settings are useful.

== An example: the 787 ==
The 787 is known for its very flexible wings; the deflection in
unaccelerated flight is quoted as z = 3 m. One wing tank of FG's 787-8 holds
23,000 kg of fuel. Because the fuel is distributed over the wing, we use a
fraction of the fuel mass in the calculation: fuel_frac = 0.75. For the same reason
we don't use the true wing mass, but rather something that makes our model look
plausible.

So assuming a wing mass of 12000 kg, we get K=25.9 and f_empty = 0.5 Hz.
That frequency might be a bit low, videos of a 777 wing in turbulence show about
2-3 Hz. (I didn't research 787 videos).

To increase it, we could either reduce m_dw or increase K. A lower m_dw results
in a rather weak bounce on touchdown which might look odd. A higher K reduces
the deflection z_flight, but we can simply scale the animation to account for
that. We'll multiply the deflection z by a factor z_fac to get an angle for the
<rotate> animation later on anyway. So repeat 3. and 4. using e.g. z_fac = 10.
Now K = 259 and f_empty=2.6 Hz. While our model spring now only deflects
to 0.3 m instead of 3 m, the animation scale factor will make sure the wing
bends to 3 m. This way, we can match both natural frequency and observed deflection,
and still get a realistic bounce on touch down. Finally, adjust D such that an
impulse is damped out after about one or two oscillations; D = 12 seems to work
OK in our example.

It's difficult to get real-world data on the deflection during touchdown.
Touchdown at more than 10 ft/s is considered a hard landing and could result in some significant wing bending.
There's a video of a hard landing of an A346 (http://avherald.com/h?article=471e70e9), showing the
wings bend perhaps 1 m.

To assist you in tuning parameters for the touchdown bounce you can initialize your
wing mass with a (touchdown) vertical speed via /sim/systems/wingflexer/sink-rate-fps, and then observe the deflection and oscillation. This avoids you having to fly too many touch-and-go's while developing ;)

Finally, our model outputs the deflection in meters, but the <rotate> animation expects an
angle. It is up to you convert appropriately, depending on your wing
span and number of segments in the animation. Also don't forget to include z_fac.

== How to add to your aircraft ==
Create a file $YourAircraft/Systems/wingflexer-params.xml which contains the parameters adjusted to your aircraft
<?xml version="1.0" encoding="UTF-8"?>
<PropertyList>
<params>
<m-wing-dry-kg type="double">12000.</m-wing-dry-kg>
<K type="double">259.</K>
<D type="double">12.</D>
<fuel-frac type="double">0.375</fuel-frac>
<lift-node-lbs alias="/fdm/jsbsim/forces/fbz-aero-lbs"/>
<fuel-node-1-kg alias="/consumables/fuel/tank/level-kg"/>
<fuel-node-2-kg alias="/consumables/fuel/tank[1]/level-kg"/>
<fuel-node-3-kg type="double">0.</fuel-node-3-kg>
<fuel-node-4-kg type="double">0.</fuel-node-4-kg>
</params>
</PropertyList>
Also adjust the property node aliases for the wing fuel tanks. Wingflexer supports up to four tanks in total. Since we're currently only solving one equation and hence get only one deflection which is used for both wings, we have to average the wing mass. Internally, m_fuel is simply the sum of all given fuel nodes,
m_fuel = fuel-node-1-kg + fuel-node-2-kg + fuel-node-3-kg + fuel-node-4-kg
so you must include the weighting factor in fuel-frac (e.g. 1/2 if you provide 2 fuel nodes). If you have more than 4 wing tanks in total, use another property rule to compute the average.

In $yourAircraft-set.xml, in <systems> section, load the parameters and the wingflexer module:
<systems>
<wingflexer include="Systems/wingflexer-params.xml"/>
<property-rule n="100">
<name>wing flexer property rule</name>
<path>Aircraft/Generic/wingflexer.xml</path>
</property-rule>
</systems>

The wingflexer writes the deflection to /sim/systems/wingflexer/z-m.
Finally, your model rotate animation has to pick it up and multiply it by z_fac
<animation>
<type>rotate</type>
<property>sim/systems/wingflexer/z-m</property>
<factor>10.</factor>
...
</animation>

If your aircraft uses JSBSim, you're done now. Yasim requires an extra step, described next.

== Yasim ==
Yasim does not write the lift to the property tree. But you can create a helper
function which computes the lift as
lift_force_lbs = aircraft_weight_lbs * load_factor - total_weight_on_wheels_lbs
and point the <lift-node-lbs> alias in wingflexer-params.xml to it.

== Implementation details ==
=== Autopilot/Property rules implementation ===
Code lives in Aircraft/Generic/wingflexer.xml

The ODE x" + ax' + bx + c = 0 is integrated by DampedOsciFilterImplementation in FG/src/autopilot/digitalfilter.cxx.

=== Nasal implementation ===
Code lives in Aircraft/Generic/wingflexer.nas, see comment therein.

== TODO ==
* write Yasim helper
* input for fuselage acceleration should rather be acceleration at CG instead of the pilot's location -- is there a property?
* add wingflexer.py (to where?)

[[Category:FlightGear feature]]

Osm2city.py

2015-07-31T01:07:22Z

Radi: /* get OSM data */ formatting

{{OSM Navigation}}
[[File:LOWI with OSM buildings.jpg|thumb|LOWI with OSM buildings]]

This Python script takes OpenStreetMap floorplans and creates 3d buildings ready for use in FlightGear.

The development [https://gitlab.com/fg-radi/osm2city repository] is hosted on <del>gitorious</del> gitlab.
Forum thread [http://forum.flightgear.org/viewtopic.php?f=5&t=22809 osm2city.py development]
Written in Python 2.7, developed on GNU/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 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.

== News ==
=== Status 10/2014 ===
New features:
* textures reside in a separate [https://gitlab.com/fg-radi/osm2city-data]
* the recommended elevation probing method is ELEV_MODE=FgelevCaching
* roads.py is now quite usable
* SKIP_LIST can contain OSM_IDs

=== Status 06/2014 ===
I'm currently adding textured roads, railroads, intersections and bridges.

{{FGCquote
| the shader is now on osm2city's git (in fgdata/). Again -- all credit goes to Emilian. He is improving the shader side, I will continue on the model side. So this is very much work in progress. The shader requires the default renderer. No ALS/Rembrandt yet. Get the LOWI roads pack (including the shader) here: [https://dl.dropboxusercontent.com/u/24846517/fg/osm2city/LOWI_roads.tar.gz https://dl.dropboxusercontent.com/u/24846517/fg/osm2city/LOWI_roads.tar.gz] The fgdata/ folder goes to your $FGDATA. In roads.xml enable either the lightmap or the traffic shader.
|{{cite web |url=http://forum.flightgear.org/viewtopic.php?p=212460#p212460
|title=<nowiki>Re: osm2city.py development</nowiki>
|author=<nowiki>radi</nowiki>
|date=<nowiki>Fri Jun 13</nowiki>
}}
}}

{{FGCquote
|Creating your own road network is a bit cumbersome ATM, I'll try to make it more general in the next few days. But if you're really, really keen on it: <ul><li> get latest osm2city git</li><li> run roads.py -f your-parameters-file.</li><li> if you also create buildings, make sure to use the same BOUNDARY_* parameters for both osm2city.py and roads.py. Otherwise, buildings and roads might be misaligned. Basically, if your OSM file contains both roads and buildings, you can just use one parameters file.</li><li> roads.py will print an OBJECT_STATIC line, add this to your .stg (appears to add itself)</li><li> copy roads.ac to your scenery</li><li> copy roads.xml and tex/ from the LOWI roads pack to your scenery (roads.ac and .xml copy themselves)</li></ul>
|{{cite web |url=http://forum.flightgear.org/viewtopic.php?p=212460#p212460
|title=<nowiki>Re: osm2city.py development</nowiki>
|author=<nowiki>radi</nowiki>
|date=<nowiki>Fri Jun 13</nowiki>
}}
}}

=== Status 04/2014 ===
[[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. 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]]
The second scene, approaching LOWI from the east, went from 30 fps without buildings down to 20 fps.

=== Status 10/2013 ===
Currently data is processed offline beforehand. 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. <del>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.
</del> (Some optimization gave a huge speedup).

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
use some heuristics (some OSM buildings are labeled "Terminal 1" or so) to apply
terminal/hangar textures to buildings at airports. This way we could rather easily populate some airports with
'semi-generic' terminal/hangar buildings.

== Features ==
* 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 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)
* 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
:* ~10 different, hi-res facade textures, some roof textures
:* find matching texture for given building (number of levels, modern/old building, etc)
:* find matching roof texture for given facade texture
* basic lightmap support
* obstruction lights on tall buildings
* command line interface and parameters file (thanks to forum user vanosten)
* shows statistics on processed buildings
* 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 {{done}}
* 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|50}}
:* 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 ==
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
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 ==
* nearby hi-rise objects of similar shape get same texture? Probably too special a feature.
* 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 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 ==
1. dependencies: Install the following packages (names from Debian packages):
python-numpy python-shapely python-matplotlib python-scipy python-pil python-networkx curl
2. get [https://gitlab.com/fg-radi/osm2city osm2city] and [https://gitlab.com/fg-radi/osm2city-data osm2city-data] from gitlab.

3. 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))
You can add
<syntaxhighlight lang="bash">
PYTHONPATH=$PYTHONPATH:/path/of/osm2city
</syntaxhighlight>
or
<syntaxhighlight lang="bash">
PYTHONPATH=$PYTHONPATH:.
</syntaxhighlight>
into your hidden configuration file .bashrc located in your home directory.

4. soft link osm2city-data/tex and osm2city-data/tex.src into osm2city/. Typically you will have to "adapt" and execute these commands.
<syntaxhighlight lang="bash">
cd osm2city
ln -sf ../osm2city-data/tex.src
ln -sf ../osm2city-data/tex
</syntaxhighlight>
Then the sub-directory of osm2city will appears like that
<syntaxhighlight lang="bash">
osm2city/
tex.src/
tex/
osm2city.py
textures.py
...
</syntaxhighlight>

If you're running FG >= 3.3, or git newer than 10 Oct 2014, and have more than 4 GB RAM, you're done installing now. Otherwise, you will most likely need to set-up and use the old-fashioned way of elevation probing, which requires you to

5. copy elev.nas to $FGDATA/Nasal/

6. Open elev.nas in a text editor. Change the out variable to a directory with write access (e.g. $FG_HOME/Export). See [[IORules]] and [[$FG_HOME]]

== Install on Windows ==
In general, you'll want to follow the above install section. This section lists some additional Windows particularities.

Osm2city is pure python.

https://www.python.org/downloads/release/python-278/

{{caution|Python 2.7 is recommended unless you're an experienced Python developer willing to update the Python scripts to support Python 3. Also pay attention to versions and cpu builds of the below helper files. Make sure they match your OS build and Python version.}}

Install the following packages, then proceed with [[Osm2city.py#Install|step 2. above]].

http://www.lfd.uci.edu/~gohlke/pythonlibs/#numpy

http://www.lfd.uci.edu/~gohlke/pythonlibs/#shapely

http://www.lfd.uci.edu/~gohlke/pythonlibs/#scipy-stack

https://pypi.python.org/pypi/Pillow/2.5.0#downloads

== Workflow ==
There are five main steps:
* get OSM data
* adjust input file
* if neccessary, create elevation grid and run FG to probe elevation data.
* run osm2city
* <del>install the generated scenery</del>installs itself

We'll now walk through these steps in detail:
=== get OSM data ===
* decide on a region you want to populate. Get its lon/lat coordinates.
* create a project directory. We will use LOWI/ in this example.
* get corresponding OSM data in its native .xml format.
There are several options to get OSM data. You may find the [http://harrywood.co.uk/maps/uixapi/xapi.html XAPI Query Builder] helpful, it will generate a template download URL that you can fetch with wget:

wget -O buildings.osm http://www.overpass-api.de/api/xapi?*[key=value][bbox=11.16898,47.20837,11.79108,47.38161]

Note that you either need to give a valid ''key=value'' pair, or remove ''[key=value]'' altogether. The alternative

wget -O buildings.osm http://www.overpass-api.de/api/xapi?map?bbox=11.16898,47.20837,11.79108,47.38161

will result in a file compatible with JOSM, at the cost of a larger download. If unsure, use the first option.

If you use [http://wiki.openstreetmap.org/wiki/Osmosis Osmosis] and cut the area with ''--bounding-box'' then you need to use ''completeWays=yes''.

Put this data into LOWI/buildings.osm

=== Adjust input file ===
* Now adjust the input file. You can generate a commented default parameters file by
<syntaxhighlight lang="bash">
parameters.py -d > LOWI/params.ini
</syntaxhighlight>

Edit this file, adjusting (at least) the following:
:* PREFIX = "LOWI" (the project directory)
:* BOUNDARY_EAST, BOUNDARY_NORTH, BOUNDARY_SOUTH, BOUNDARY_WEST
:* OSM_FILE = "buildings.osm"
:* set PATH_TO_SCENERY to a standard [[$FG_SCENERY]] path. This is the path where we'll get the elevation from. Most likely you'll want to use your TerraSync path here. Suppose the area you want to populate is /home/user/fgfs/scenery/TerraSync/Objects/e010n40/e011n47/, PATH_TO_SCENERY would then be "/home/user/fgfs/scenery/TerraSync" .
:* set PATH_TO_OUTPUT to a ''different'' scenery path, e.g. "/home/user/fgfs/scenery/osm2city" . Osm2city will generate its objects there. First, this avoids TerraSync overwriting the generated scenery. Second, you can easily remove that folder in case you're not happy with the result. Make sure to include that path in your [[$FG_SCENERY]].
:* you might want to set MAX_OBJECTS to a small number (say, 100) for your first try. This will limit the number of buildings parsed, and speed up the whole process.
:* you also need to set up elevation probing in the parameters file, described in the next section.

{{note|Python does not recognize environment variables, please use full paths in the parameters file (no $HOME etc).}}

=== Probe elevation ===
Probe elevation for your region. Pick one of the three available modes for ELEV_MODE in params.ini. If you have enough memory (4GB should be fine, but YMMV) and run FG git later than 10 Oct 2014, try FgelevCaching. Failing that, try Manual. (portreekid, what's the 3rd mode good for?)

{{caution|1=There are a lot of problems reported currently with fgelev. I can't really test for the next month or so. See troubleshooting or use ELEV_MODE = "Manual".}}

* ELEV_MODE = "FgelevCaching"
:* Set FG_ELEV to your fgelev executable. For example: FG_ELEV = "/usr/local/fg/bin/fgelev" or just FG_ELEV = "fgelev" if fgelev is already in your OS's path.
:* Set PATH_TO_SCENERY (Missing terrain will result in error message)
:* make sure the environment variable [[$FG ROOT]] points to your FG base path, (e.g. export FG_ROOT=/usr/share/games/flightgear/ on Linux)

* ELEV_MODE = "Manual"
:* run tools.py (tools.py -f LOWI/params.ini), this will create a file elev.in. Copy elev.in to $FG_ROOT/Nasal/
:* Open $FG_ROOT/Nasal/elev.nas in a text editor. Point the in variable to your elev.in file e.g. var in = "/path/to/$FG_ROOT/Nasal/elev.in".
:* tools.py will tell you to hide a certain scenery/Objects/... folder, to prevent probing elevation on top of existing objects. Simply rename the folder
:* run FG, open debug->nasal console, enter: elev.get_elevation(), press execute. Might take a long time, depending on the area scanned. This will write elevation data to /tmp/elev.out (which is actually just plain 5 column data: lon,lat,x,y,elevation). Put elev.out into LOWI/
:* unhide, rename the objects folder

* ELEV_MODE = "Telnet"
:* Run setup.py
:* Start FG with the properties service on Port 5501
:* Run tools.py, this will create a elev.in, start the nasal script and copy the elev.out back to your project directory

=== Run osm2city ===
* Make sure you're in osm2city's directory and run

python osm2city.py -f LOWI/params.ini.

The parsed OSM data is cached to file LOWI/buildings.osm.pkl which is used on next startup if you set USE_PKL = 1.
If all goes well, files like LOWIcity0101.ac and their corresponding .xml, along with .stg files, were created and moved to the correct location in $FG_SCENERY
* copy or link the tex/ folder into the objects folder where these files were created

=== Roads ===
* run roads.py in the same fashion for roads
* <del>copy roads.eff to the same Objects\e0XXnXX\e0XXnXX\ directory</del> roads.eff is copied automatically
* Band-aid fix for the roads is to adjust their height in roads.py change AGL_ofs to a higher number e.g. 0.5
* the moving cars (TRAFFIC_SHADER_ENABLE = True) are only visible when you disable Atmospheric light scattering (ALS)

== Support and troubleshooting ==
Time permitting, we can provide limited support on the [http://forum.flightgear.org/viewtopic.php?f=5&t=22809 Forums]. Please don't use PM for support questions.

Before you ask a question, make sure you read this wiki page. If your question is not covered here, tell us as much as possible about the problem you're facing. Which steps have you taken to solve it? What is the exact error message? What operating system? Screenshots?

We will not cover general questions like "I don't know how to install XY" -- search the Internet.

=== FGElev crashes ===

<syntaxhighlight lang="bash">
CRITICAL:root:1173 -95.5767 37.0965
CRITICAL:root:fgelev returned <>, resulting in list index out of range. Did fgelev start OK (Record : 1173)?
</syntaxhighlight>
The first line is the last input to fgelev.
Try running fgelev directly:
<syntaxhighlight lang="bash">
/path/to/fgelev --expire 1000 --fg-root $FG_ROOT --fg-scenery $FG_SCENERY
</syntaxhighlight>
then enter the line last sent to fgelev.
<syntaxhighlight lang="bash">
1173 -95.5767 37.0965
</syntaxhighlight>
The response should look like
<syntaxhighlight lang="bash">
1173: 226.793
</syntaxhighlight>

=== Buildings are generated, but they sit below the ground. I'm using ELEV_MODE = FgelevCaching. ===

Try running fgelev directly:
<syntaxhighlight lang="bash">
/path/to/fgelev --expire 1000 --fg-root $FG_ROOT --fg-scenery $FG_SCENERY
</syntaxhighlight>
then enter
<syntaxhighlight lang="bash">
0 $lon $lat
</syntaxhighlight>
where $lon and $lat are coordinates in the area you want to generate. See if it returns a sane value. If it does, double-check PATH_TO_SCENERY and $FG_ROOT.

=== Buildings/roads have no texture. I get errors "osgDB ac3d reader: could not find texture "tex/atlas_facades.png". ===

Copy or link the tex/ folder into the objects folder where the .stg files were created, such that you have $FG_SCENERY/Objects/eXXXnXX/eXXXnXX/tex/. Note that buildings might have been created in more than one folder, e.g. in e011n47 and e011n48. You must have a tex/ folder in each of them. On Windows it is sufficient to have one copy in $FG_ROOT.

=== ImportError: No module named calc_tile ===

Copy calc_tile.py into batch_processing folder

== Improve frame rate ==
* adjust LOD ranges in FG
* decrease MAX_OBJECTS, increase LOD_*
(- use larger/smaller tiles? Tradeoff between distance calculations/xml parsing and GPU)

== Contributing ==
You know some python? Or you're keen on writing docs? Contact radi on the FG forum.
None of the above? Take [[Howto:Create_textures_from_photos|pictures]] of buildings where you live and [[Osm2city.py Textures|create textures]]! I'm especially interested in south-east asian style architecture, as I'm planning to populate Hong Kong Kai Tak (VHXX) in the future.

== Related content ==
=== Wiki articles ===
* [[Areas populated with osm2city scenery]]
* [[AutoGen Scenery for FlightGear]]
* [[OpenStreetMap buildings]]
* [[Random Buildings]]
* [[Using OSM Vector Data in FlightGear]]

=== Forum topics ===
* [http://forum.flightgear.org/viewtopic.php?f=5&t=21131 OSM buidings EHLE]
* [http://forum.flightgear.org/viewtopic.php?f=5&t=22809 osm2city.py development]
* [http://forum.flightgear.org/viewtopic.php?f=5&t=19625 LOWI city buildings]
* [http://forum.flightgear.org/viewtopic.php?f=38&t=8837 <nowiki>[</nowiki>Proposal<nowiki>]</nowiki> Autogen Cities using PixelCity]
* [http://forum.flightgear.org/viewtopic.php?f=5&t=17598 Procedural buildings in OSM before part of Scenery]

=== Mailing list threads ===
* [http://sourceforge.net/p/flightgear/mailman/message/30825768/ <nowiki>[</nowiki>Flightgear-devel<nowiki>]</nowiki> osm2city.py]

[[Category:Scenery software]]

Osm2city.py

2015-07-31T01:06:30Z

Radi: /* get OSM data */ fix download URL

{{OSM Navigation}}
[[File:LOWI with OSM buildings.jpg|thumb|LOWI with OSM buildings]]

This Python script takes OpenStreetMap floorplans and creates 3d buildings ready for use in FlightGear.

The development [https://gitlab.com/fg-radi/osm2city repository] is hosted on <del>gitorious</del> gitlab.
Forum thread [http://forum.flightgear.org/viewtopic.php?f=5&t=22809 osm2city.py development]
Written in Python 2.7, developed on GNU/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 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.

== News ==
=== Status 10/2014 ===
New features:
* textures reside in a separate [https://gitlab.com/fg-radi/osm2city-data]
* the recommended elevation probing method is ELEV_MODE=FgelevCaching
* roads.py is now quite usable
* SKIP_LIST can contain OSM_IDs

=== Status 06/2014 ===
I'm currently adding textured roads, railroads, intersections and bridges.

{{FGCquote
| the shader is now on osm2city's git (in fgdata/). Again -- all credit goes to Emilian. He is improving the shader side, I will continue on the model side. So this is very much work in progress. The shader requires the default renderer. No ALS/Rembrandt yet. Get the LOWI roads pack (including the shader) here: [https://dl.dropboxusercontent.com/u/24846517/fg/osm2city/LOWI_roads.tar.gz https://dl.dropboxusercontent.com/u/24846517/fg/osm2city/LOWI_roads.tar.gz] The fgdata/ folder goes to your $FGDATA. In roads.xml enable either the lightmap or the traffic shader.
|{{cite web |url=http://forum.flightgear.org/viewtopic.php?p=212460#p212460
|title=<nowiki>Re: osm2city.py development</nowiki>
|author=<nowiki>radi</nowiki>
|date=<nowiki>Fri Jun 13</nowiki>
}}
}}

{{FGCquote
|Creating your own road network is a bit cumbersome ATM, I'll try to make it more general in the next few days. But if you're really, really keen on it: <ul><li> get latest osm2city git</li><li> run roads.py -f your-parameters-file.</li><li> if you also create buildings, make sure to use the same BOUNDARY_* parameters for both osm2city.py and roads.py. Otherwise, buildings and roads might be misaligned. Basically, if your OSM file contains both roads and buildings, you can just use one parameters file.</li><li> roads.py will print an OBJECT_STATIC line, add this to your .stg (appears to add itself)</li><li> copy roads.ac to your scenery</li><li> copy roads.xml and tex/ from the LOWI roads pack to your scenery (roads.ac and .xml copy themselves)</li></ul>
|{{cite web |url=http://forum.flightgear.org/viewtopic.php?p=212460#p212460
|title=<nowiki>Re: osm2city.py development</nowiki>
|author=<nowiki>radi</nowiki>
|date=<nowiki>Fri Jun 13</nowiki>
}}
}}

=== Status 04/2014 ===
[[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. 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]]
The second scene, approaching LOWI from the east, went from 30 fps without buildings down to 20 fps.

=== Status 10/2013 ===
Currently data is processed offline beforehand. 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. <del>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.
</del> (Some optimization gave a huge speedup).

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
use some heuristics (some OSM buildings are labeled "Terminal 1" or so) to apply
terminal/hangar textures to buildings at airports. This way we could rather easily populate some airports with
'semi-generic' terminal/hangar buildings.

== Features ==
* 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 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)
* 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
:* ~10 different, hi-res facade textures, some roof textures
:* find matching texture for given building (number of levels, modern/old building, etc)
:* find matching roof texture for given facade texture
* basic lightmap support
* obstruction lights on tall buildings
* command line interface and parameters file (thanks to forum user vanosten)
* shows statistics on processed buildings
* 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 {{done}}
* 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|50}}
:* 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 ==
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
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 ==
* nearby hi-rise objects of similar shape get same texture? Probably too special a feature.
* 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 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 ==
1. dependencies: Install the following packages (names from Debian packages):
python-numpy python-shapely python-matplotlib python-scipy python-pil python-networkx curl
2. get [https://gitlab.com/fg-radi/osm2city osm2city] and [https://gitlab.com/fg-radi/osm2city-data osm2city-data] from gitlab.

3. 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))
You can add
<syntaxhighlight lang="bash">
PYTHONPATH=$PYTHONPATH:/path/of/osm2city
</syntaxhighlight>
or
<syntaxhighlight lang="bash">
PYTHONPATH=$PYTHONPATH:.
</syntaxhighlight>
into your hidden configuration file .bashrc located in your home directory.

4. soft link osm2city-data/tex and osm2city-data/tex.src into osm2city/. Typically you will have to "adapt" and execute these commands.
<syntaxhighlight lang="bash">
cd osm2city
ln -sf ../osm2city-data/tex.src
ln -sf ../osm2city-data/tex
</syntaxhighlight>
Then the sub-directory of osm2city will appears like that
<syntaxhighlight lang="bash">
osm2city/
tex.src/
tex/
osm2city.py
textures.py
...
</syntaxhighlight>

If you're running FG >= 3.3, or git newer than 10 Oct 2014, and have more than 4 GB RAM, you're done installing now. Otherwise, you will most likely need to set-up and use the old-fashioned way of elevation probing, which requires you to

5. copy elev.nas to $FGDATA/Nasal/

6. Open elev.nas in a text editor. Change the out variable to a directory with write access (e.g. $FG_HOME/Export). See [[IORules]] and [[$FG_HOME]]

== Install on Windows ==
In general, you'll want to follow the above install section. This section lists some additional Windows particularities.

Osm2city is pure python.

https://www.python.org/downloads/release/python-278/

{{caution|Python 2.7 is recommended unless you're an experienced Python developer willing to update the Python scripts to support Python 3. Also pay attention to versions and cpu builds of the below helper files. Make sure they match your OS build and Python version.}}

Install the following packages, then proceed with [[Osm2city.py#Install|step 2. above]].

http://www.lfd.uci.edu/~gohlke/pythonlibs/#numpy

http://www.lfd.uci.edu/~gohlke/pythonlibs/#shapely

http://www.lfd.uci.edu/~gohlke/pythonlibs/#scipy-stack

https://pypi.python.org/pypi/Pillow/2.5.0#downloads

== Workflow ==
There are five main steps:
* get OSM data
* adjust input file
* if neccessary, create elevation grid and run FG to probe elevation data.
* run osm2city
* <del>install the generated scenery</del>installs itself

We'll now walk through these steps in detail:
=== get OSM data ===
* decide on a region you want to populate. Get its lon/lat coordinates.
* create a project directory. We will use LOWI/ in this example.
* get corresponding OSM data in its native .xml format.
There are several options to get OSM data. You may find the [http://harrywood.co.uk/maps/uixapi/xapi.html XAPI Query Builder] helpful, it will generate a template download URL that you can fetch with wget:

wget -O buildings.osm http://www.overpass-api.de/api/xapi?*[key=value][bbox=11.16898,47.20837,11.79108,47.38161]

Note that you either need to give a valid ''key=value pair'', or remove ''[key=value]'' altogether. The alternative

wget -O buildings.osm http://www.overpass-api.de/api/xapi?map?bbox=11.16898,47.20837,11.79108,47.38161

will result in a file compatible with JOSM, at the cost of a larger download. If unsure, use the first option.

If you use [http://wiki.openstreetmap.org/wiki/Osmosis Osmosis] and cut the area with ''--bounding-box'' then you need to use ''completeWays=yes''.

Put this data into LOWI/buildings.osm

=== Adjust input file ===
* Now adjust the input file. You can generate a commented default parameters file by
<syntaxhighlight lang="bash">
parameters.py -d > LOWI/params.ini
</syntaxhighlight>

Edit this file, adjusting (at least) the following:
:* PREFIX = "LOWI" (the project directory)
:* BOUNDARY_EAST, BOUNDARY_NORTH, BOUNDARY_SOUTH, BOUNDARY_WEST
:* OSM_FILE = "buildings.osm"
:* set PATH_TO_SCENERY to a standard [[$FG_SCENERY]] path. This is the path where we'll get the elevation from. Most likely you'll want to use your TerraSync path here. Suppose the area you want to populate is /home/user/fgfs/scenery/TerraSync/Objects/e010n40/e011n47/, PATH_TO_SCENERY would then be "/home/user/fgfs/scenery/TerraSync" .
:* set PATH_TO_OUTPUT to a ''different'' scenery path, e.g. "/home/user/fgfs/scenery/osm2city" . Osm2city will generate its objects there. First, this avoids TerraSync overwriting the generated scenery. Second, you can easily remove that folder in case you're not happy with the result. Make sure to include that path in your [[$FG_SCENERY]].
:* you might want to set MAX_OBJECTS to a small number (say, 100) for your first try. This will limit the number of buildings parsed, and speed up the whole process.
:* you also need to set up elevation probing in the parameters file, described in the next section.

{{note|Python does not recognize environment variables, please use full paths in the parameters file (no $HOME etc).}}

=== Probe elevation ===
Probe elevation for your region. Pick one of the three available modes for ELEV_MODE in params.ini. If you have enough memory (4GB should be fine, but YMMV) and run FG git later than 10 Oct 2014, try FgelevCaching. Failing that, try Manual. (portreekid, what's the 3rd mode good for?)

{{caution|1=There are a lot of problems reported currently with fgelev. I can't really test for the next month or so. See troubleshooting or use ELEV_MODE = "Manual".}}

* ELEV_MODE = "FgelevCaching"
:* Set FG_ELEV to your fgelev executable. For example: FG_ELEV = "/usr/local/fg/bin/fgelev" or just FG_ELEV = "fgelev" if fgelev is already in your OS's path.
:* Set PATH_TO_SCENERY (Missing terrain will result in error message)
:* make sure the environment variable [[$FG ROOT]] points to your FG base path, (e.g. export FG_ROOT=/usr/share/games/flightgear/ on Linux)

* ELEV_MODE = "Manual"
:* run tools.py (tools.py -f LOWI/params.ini), this will create a file elev.in. Copy elev.in to $FG_ROOT/Nasal/
:* Open $FG_ROOT/Nasal/elev.nas in a text editor. Point the in variable to your elev.in file e.g. var in = "/path/to/$FG_ROOT/Nasal/elev.in".
:* tools.py will tell you to hide a certain scenery/Objects/... folder, to prevent probing elevation on top of existing objects. Simply rename the folder
:* run FG, open debug->nasal console, enter: elev.get_elevation(), press execute. Might take a long time, depending on the area scanned. This will write elevation data to /tmp/elev.out (which is actually just plain 5 column data: lon,lat,x,y,elevation). Put elev.out into LOWI/
:* unhide, rename the objects folder

* ELEV_MODE = "Telnet"
:* Run setup.py
:* Start FG with the properties service on Port 5501
:* Run tools.py, this will create a elev.in, start the nasal script and copy the elev.out back to your project directory

=== Run osm2city ===
* Make sure you're in osm2city's directory and run

python osm2city.py -f LOWI/params.ini.

The parsed OSM data is cached to file LOWI/buildings.osm.pkl which is used on next startup if you set USE_PKL = 1.
If all goes well, files like LOWIcity0101.ac and their corresponding .xml, along with .stg files, were created and moved to the correct location in $FG_SCENERY
* copy or link the tex/ folder into the objects folder where these files were created

=== Roads ===
* run roads.py in the same fashion for roads
* <del>copy roads.eff to the same Objects\e0XXnXX\e0XXnXX\ directory</del> roads.eff is copied automatically
* Band-aid fix for the roads is to adjust their height in roads.py change AGL_ofs to a higher number e.g. 0.5
* the moving cars (TRAFFIC_SHADER_ENABLE = True) are only visible when you disable Atmospheric light scattering (ALS)

== Support and troubleshooting ==
Time permitting, we can provide limited support on the [http://forum.flightgear.org/viewtopic.php?f=5&t=22809 Forums]. Please don't use PM for support questions.

Before you ask a question, make sure you read this wiki page. If your question is not covered here, tell us as much as possible about the problem you're facing. Which steps have you taken to solve it? What is the exact error message? What operating system? Screenshots?

We will not cover general questions like "I don't know how to install XY" -- search the Internet.

=== FGElev crashes ===

<syntaxhighlight lang="bash">
CRITICAL:root:1173 -95.5767 37.0965
CRITICAL:root:fgelev returned <>, resulting in list index out of range. Did fgelev start OK (Record : 1173)?
</syntaxhighlight>
The first line is the last input to fgelev.
Try running fgelev directly:
<syntaxhighlight lang="bash">
/path/to/fgelev --expire 1000 --fg-root $FG_ROOT --fg-scenery $FG_SCENERY
</syntaxhighlight>
then enter the line last sent to fgelev.
<syntaxhighlight lang="bash">
1173 -95.5767 37.0965
</syntaxhighlight>
The response should look like
<syntaxhighlight lang="bash">
1173: 226.793
</syntaxhighlight>

=== Buildings are generated, but they sit below the ground. I'm using ELEV_MODE = FgelevCaching. ===

Try running fgelev directly:
<syntaxhighlight lang="bash">
/path/to/fgelev --expire 1000 --fg-root $FG_ROOT --fg-scenery $FG_SCENERY
</syntaxhighlight>
then enter
<syntaxhighlight lang="bash">
0 $lon $lat
</syntaxhighlight>
where $lon and $lat are coordinates in the area you want to generate. See if it returns a sane value. If it does, double-check PATH_TO_SCENERY and $FG_ROOT.

=== Buildings/roads have no texture. I get errors "osgDB ac3d reader: could not find texture "tex/atlas_facades.png". ===

Copy or link the tex/ folder into the objects folder where the .stg files were created, such that you have $FG_SCENERY/Objects/eXXXnXX/eXXXnXX/tex/. Note that buildings might have been created in more than one folder, e.g. in e011n47 and e011n48. You must have a tex/ folder in each of them. On Windows it is sufficient to have one copy in $FG_ROOT.

=== ImportError: No module named calc_tile ===

Copy calc_tile.py into batch_processing folder

== Improve frame rate ==
* adjust LOD ranges in FG
* decrease MAX_OBJECTS, increase LOD_*
(- use larger/smaller tiles? Tradeoff between distance calculations/xml parsing and GPU)

== Contributing ==
You know some python? Or you're keen on writing docs? Contact radi on the FG forum.
None of the above? Take [[Howto:Create_textures_from_photos|pictures]] of buildings where you live and [[Osm2city.py Textures|create textures]]! I'm especially interested in south-east asian style architecture, as I'm planning to populate Hong Kong Kai Tak (VHXX) in the future.

== Related content ==
=== Wiki articles ===
* [[Areas populated with osm2city scenery]]
* [[AutoGen Scenery for FlightGear]]
* [[OpenStreetMap buildings]]
* [[Random Buildings]]
* [[Using OSM Vector Data in FlightGear]]

=== Forum topics ===
* [http://forum.flightgear.org/viewtopic.php?f=5&t=21131 OSM buidings EHLE]
* [http://forum.flightgear.org/viewtopic.php?f=5&t=22809 osm2city.py development]
* [http://forum.flightgear.org/viewtopic.php?f=5&t=19625 LOWI city buildings]
* [http://forum.flightgear.org/viewtopic.php?f=38&t=8837 <nowiki>[</nowiki>Proposal<nowiki>]</nowiki> Autogen Cities using PixelCity]
* [http://forum.flightgear.org/viewtopic.php?f=5&t=17598 Procedural buildings in OSM before part of Scenery]

=== Mailing list threads ===
* [http://sourceforge.net/p/flightgear/mailman/message/30825768/ <nowiki>[</nowiki>Flightgear-devel<nowiki>]</nowiki> osm2city.py]

[[Category:Scenery software]]

Project Hong Kong

2015-05-02T05:46:16Z

Radi: current status 05/2015

Project Hong Kong is aimed to improve the Hong Kong scenery in FlightGear.

Forum development thread: http://forum.flightgear.org/viewtopic.php?f=5&t=24508&start=45#p238855

== Current status (May 2015) ==
* built custom scenery, using landcover provided by statto and Martin
* "fixed" airport layout -- had to remove a taxiway because I couldn't create an airport with holes in it.
* add OSM forest/parks (some prominent ones are still missing)
* add osm2city buildings and roads
* add curved approach lights, based on OT-666's LOWI approach lights

== Airports we are planning to work on ==
* VHHH
* VHXX
* VHSK

== Hong Kong terrain improvements ==
We also will fix the FG terrain in Hong Kong to be close as possible to Real Hong Kong

=== To Do List ===
* New Models for all airports and sounding areas
* Adding Detailed markings on runways and taxiways
* Moving existing models to their correct possessions
* Replacing inaccurate models
* Building the Victoria Harbor skyline
* Building Kowloon City
* Urbanizing the City
* Regenerating the Hong Kong terrain using TerraGear
* Building realistic roads with moving traffic
* Building realistic tracks with moving trains

== Volunteers are welcomed ==
If you wish to help in this project, please contact Pakistan-1 or Radi on the FlightGear Forum.

[[Category:Community|Hong Kong]]
[[Category:Development projects|Hong Kong]]

Using TerraGear

2015-04-11T13:07:16Z

Radi: /* Troubleshooting */ apt.dat.gt must be unzipped!

{{Out of date}}

[[File:Terragearprocesschart.png|thumb|TerraGear Process Flow Chart]]
The [[TerraGear]] software project supports [[FlightGear]] by creating the files used by FlightGear to represent the elevation and texture of the earth, including airports, cities, fields, forests, rivers, roads and so on. The TerraGear software reads data files containing ground elevation, airport locations and layouts, geographical land-cover data, and more, and produces the scenery files used by FlightGear to represent the terrain of the world.

For simplicity and convenience, most FlightGear users simply download the plug-and-play scenery files from the FlightGear scenery server, or use [[TerraSync]] to automatically download scenery as needed. But there is a variety of reasons you might want to use TerraGear to produce your own terrain files, rather than downloading the standard FlightGear scenery.

For instance, if you use [[WorldEditor]] to modify/improve information about an [[:Category:Airports|airport]]'s taxiway/apron layout, you might wish to see how that modified airport would look in the scenery before deciding you're happy with the results. Maybe the official scenery is too detailed for your slow machine, and you'd like to build terrain using a digital elevation model (DEM) with poorer resolution, to decrease the number of polygons and thus improve your framerates. Or maybe you've got a fantastically fast machine, and you want to build your own terrain using higher-resolution vector data (vmap1, Tiger, osm) to get better roads/streams. For all these reasons, learning how to use TerraGear is a good idea.

== Obtaining TerraGear ==
You can either build TerraGear yourself, or download a pre-compiled binary. The later is the easiest and advised for starters.

* '''Option 1 - Download TerraGear pre-compiled (recommended for beginners) on Windows'''
*# Download the latest TerraGear build from [http://flightgear.simpits.org:8080/job/TerraGear-Win-Cmake/lastSuccessfulBuild/artifact/*zip*/archive.zip the FlightGear Build Server].
*# Create or choose a directory to hold the TerraGear tools.
*# Unzip the package and move the files from <tt>archive/install/msvc100/TerraGear/bin</tt> into a sub-directory named <tt>Terragear/</tt> in the base directory.
* '''Option 2 - Compile TerraGear from source code''' as explained in [[Building TerraGear|this article]].

''Note:'' You might need default_priorities.txt from the [https://gitorious.org/fg/terragear/blobs/raw/master/src/BuildTiles/Clipper/default_priorities.txt Git repository] or from the archive downloaded from the build server (in the <tt>archive/install/msvc100/TerraGear/share</tt> subdirectory). See [http://forum.flightgear.org/viewtopic.php?f=5&p=77950 this forum thread] for details,

=== GUI tool ===
A [[TerraGear GUI]] is available for those that would like to use TerraGear without knowing/using the command line options.

== Using TerraGear ==
First, choose the boundaries for the area of scenery you want to build, in terms of latitude and longitude. The smaller the area of scenery you generate, the smaller the amount of data you will need, and the less CPU time it will take. For example, if you are just interested in generating a new airport layout at 12.3W 34.4N, then simply generating the scenery between 12W 34N and 13W 35N would be sufficient.

Write down the bounding box (minimum and maximum longitude and latitude) for the scenery you want to generate. Remember that West and South are negative - i.e. 4W 10S would be -4, -10. Try not to get mixed up, otherwise you'll end up generating scenery or airports on the other side of the planet!

You'll be dealing with multiple different types of data in various formats. Create a new directory for your scenery work. Within that directory, create the following sub-directories:

* '''data/''' - for raw and pre-processed data (eg elevation files)
* '''output/''' - for the scenery files you will create
* '''work/''' - for data that has been processed (eg by shape-decode) and is ready to be munged into scenery

=== Obtaining and processing data ===
Terragear uses three different kinds of information to generate scenery:

# The elevation of the land (provided by SRTM)
# The location and layout of airports (provided by apt.dat or a custom .dat)
# Whether a given lat/lon is sea, land, city, forest, town, road, railway (provided by VMAP0, [[CORINE]] etc. or custom shapefiles)

This article describes how obtain and process each of these types of data in order, and bring it together for use by FlightGear. The order of these steps is important. For example, the airport data step needs the elevation data to determine the elevation of the airports and thus you should start with preparing elevation data.

'''Please note: for inclusion in the official FlightGear scenery, all data must come from [[GNU GPL]] compatible sources!'''

==== Elevation data ====
The best worldwide elevation data currently available is from the Shuttle Radar Topography Mission (SRTM). There are two types of SRTM data:
* Highly accurate 1-arcsecond resolution data, known as SRTM-1, for the USA
* Less accurate 3-arcsecond data, known as SRTM-3, for the rest of the world.
From now on, we'll assume you are using SRTM-3 data. Unless otherwise noted, the process for SRTM-1 is identical.

You can download the appropriate data from http://dds.cr.usgs.gov/srtm/version2_1/. You want all .hgt.zip files covering your region of interest. Depending on the size of your scenery, there may be quite a few. Download them to <tt>data/SRTM-1/</tt>(or SRTM-3/SRTM-30 depending on the type you downloaded) in your base directory. (Genapts looks for a few known, hardcoded elevation data directories in its working directory. SRTM-30 is one of them and this is the least confusing in that list. Note: W.E.F. 31st July 2010, the genapts tool now also looks for SRTM-1/SRTM-3 directories. If you are using an older version, please supply the directories using --dem-path).

Now we've got the data, we need to convert it into something of use to TerraGear. First, you need to unzip each of the .hgt files. After that, open the commandline (Windows: <tt>Start > Run > cmd.exe</tt>) and change into the base directory (<tt>cd .../.../TerraGear</tt>).
* '''NOTE:''' If you want to create a batch-file, replace <tt>%f</tt> with <tt>%%f</tt>, see [http://technet.microsoft.com/en-us/library/bb490909.aspx]
* '''NOTE:''' For SRTM-1 data, replace the <tt>3</tt> by a <tt>1</tt> in the first argument to hgtchop

'''Note: According to [[TerraGear_Documentation]], hgtchop is superseded by gdalchop.'''

For Windows:
for %f in (.\data\SRTM-3\*.hgt) do .\Terragear\hgtchop.exe 3 %f .\work\SRTM-3
or
for %f in (.\data\SRTM-3\*.hgt) do .\Terragear\hgtchop.exe 3 .\data\SRTM-3\%f .\work\SRTM-3

For Linux:
for i in $PWD/data/SRTM-3/*.hgt; do ./Terragear/hgtchop 3 $i $PWD/work/SRTM-3; done

Now you will get a lot of .arr.gz files in your work/SRTM-3/ directory. We need to convert these to the .fit.gz format. Run the commandline again with
* '''NOTE:''' the space and dot at the and are important!

For Windows:
.\Terragear\terrafit.exe work\SRTM-3

For Linux:
./Terragear/terrafit work/SRTM-3

==== Airport data ====
Now we've got elevation data, we can generate our airports. First, create a <tt>data/airports/</tt> directory and copy in your apt.dat file. This may be direct from your FlightGear data package (though you'll need to unzip it), or it may be one that you've modified with [[WorldEditor]].

The command to create airports is "genapts850". Run it without any arguments to see the various command-line options.

If it is simply run with a specified apt.dat and work directory, it will generate airport layouts for every airport in the file, which can take a long time.

If you are just creating a single airport and you know the ICAO ID (e.g. [[KSFO]], EGPH, EG32), use is as follows from your root scenery directory (i.e. the directory above your data, work and output directories). If you use an apt.dat file with one single airport in it you should omit the "--airport" parameter.

genapts850 --input=data/airports/apt.dat --work=./work --airport=<AIRPORT_ID>

If you are generating a larger set of scenery, then you can specify the minimum and maximum longitude and latitude.

Genapts will create two sub-directories in your work directory:
* <tt>AirportArea/</tt>
* <tt>AirportObj/</tt>
These contain the definitions of the airport layout and any objects present (e.g. windsocks and beacons).

==== Landuse data ====
The final piece of data we need to generate is the landuse data. In general, this is taken from the VMAP0 dataset as shapefiles from the scenery database mapserver, but other sources can also be used.

The landuse data can be split into a number of different types:
* '''Landmass''' separates the land from the sea. It can be used as a mask for all other data. The most commonly used is the VMAP0 Landmass, but GSHHS can also be used. When running tg-construct with <code>--ignore-landmass</code>, all input shapefiles will be taken into consideration, so no landmass mask is required then.
* '''Land use data:''' defines whether a piece of land is forest, urban, sand, lava, glacier etc. These are usually VMAP0 data, defined as polygons.
* '''Line data:''' includes railroads, streams, roads. Typically VMAP0, but also Open Street Map for roads.
* '''Point data:''' is currently only used for defining towns.

By far the easiest way to get this data is to download shapefiles from the wonderful [http://mapserver.flightgear.org MapServer]. The MapServer lets you download the shapefiles for any selected scenery area. Click on the "Download Shapefiles" link (or go direct: http://mapserver.flightgear.org/download.psp). Enter in the bounding box of the scenery you want to generate, select the type of shapefile data you want, and click download.

'''Layer differences'''

* '''v0''': global coverage, low detail. This is "the last resort", but unfortunately it is the only layer that covers the entire world.
* '''cs''': it is v0 with some contributions someone did in the past. Get this instead of v0.
* '''v1''': only parts of some countries available, higher detail than v0.
* '''clc06''': European '''only'''. Very high detail, this is the preferred choice for an European country.
* '''osm''': global coverage, high resolution but very low detail. This means: if you are interested in an area out of Europe and forests are defined in OpenStreetMaps for your area, this is going to be the best data source. If forests are not defined, you will get a dull, neverending DEFAULT landclass. OSM provides the best coastline and I encourage you to use this coastline even in Europe. [http://forum.flightgear.org/viewtopic.php?f=5&t=25549&sid=d501cb651ef9e34ca9dc8fae429d51ab&p=234002#p234002]

{{caution|Make sure each shape file is in its own directory whether you download shape files or create your own otherwise the ogrDecode step will fail.}}
Download each shapefile into a seperate (!) <tt>data/shapefiles/...</tt> directory. So, for v0_landmass, you would end up with <tt>data/shapefiles/v0_landmass/v0_landmass.shp</tt> etc.

You can load these shapefiles into a GIS editor such as [[QGIS]] or GRASS to view and edit. This is a good idea to verify you have the correct files! Later on, you can experiment with replacing various shapefiles with other versions (GSHHS for coastline, OSM for roads etc.).

The next step is to decode the shape-files into TerraGear format using the '''ogr-decode''' command.

There are three important command-line arguments for ogr-decode:
* the destination directory for the decoded data
* the location of the shapefile's directory
* the material type

Each shape-file corresponds with one of the material types defined in the materials.xml files. The mapping is pretty obvious. For example, v0_mixedcroppasturecover maps to MixedCropPastureCover. Note that the material types are case-sensitive, so it is a good idea to refer to the <tt>[[$FG_ROOT]]/Materials/default/materials.xml</tt> file (<tt>[[$FG ROOT]]/materials.xml</tt> in FlightGear 2.6.0 and older) to hand so you can check. The exception is landmass, which - when used - MUST be mapped onto the type Default.

Additionally, there are a number of optional arguments, to indicate the width of line data (for roads, streams, railways), how large to make point data (for towns) and how long the longest straight line is allowed to be.

For example, to decode the v0_landmass shapefile, you use the following command:

ogr-decode --max-segment 500 --area-type Default work/Default data/shapefiles/v0_landmass

To create streams of width 10 metres

ogr-decode --max-segment 500 --line-width 10 --area-type Stream work/Stream data/shapefiles/v0_stream

To generate some towns about 1km across

ogr-decode --point-width 500 --area-type Town work/Town data/shapefiles/v0_town

Run this command for each shapefile in the set.

== Generating scenery ==
You will now have a work directory, with subdirectories like:
{|
|
: AirportArea
: AirportObj
: Bog
: Default
: DryCropPastureCover
: EvergreenBroadCover
: GrassCover
: IrrCropPastureCover
: Lake
: Marsh
: MixedCropPastureCover
| valign="top" |
: MixedForestCover
: Railroad
: Road
: Sand
: ScrubCover
: Shared
: SRTM-3
: Stream
: Town
: Urban
|}

Now we can actually generate the scenery. This is done by the tg-construct command. Run the command with <code>--help</code> to get usage information.

We need to define:
* The work (--work-dir) and output (--output-dir) directories.
** '''Note''' about the output directory: this must point to a <tt>Terrain/</tt> directory, else recent FlightGear versions will be unable to load the terrain.
* The center of the scenery we want to generate (--lat, --lon).
* The radius (--xdist, --ydist) from which to generate.
* All the work directories to include in the scenery.

For example:
{{Pre2|<nowiki>tg-construct --work-dir=./work --output-dir=./output/Terrain --min-lon=55 --max-lon=57 --min-lat=60 --max-lat=62 AirportArea SRTM-3 AirportObj Default Stream Bog IrrCropPastureCover Town Lake Urban Railroad DryCropPastureCover Road EvergreenBroadCover Marsh Sand MixedCropPastureCover ScrubCover GrassCover MixedForestCover</nowiki> }}

When this finishes, the output directory will contain a scenery sub-tree. Point to it by setting either [[$FG_SCENERY]] or by using the --fg-scenery command-line option to fgfs, and give your new scenery a try!

== Troubleshooting ==
Below is a list of common problems and solutions. If in doubt - Google it. Many problems (particularly when compiling TerraGear) have been hit before:

* Crashes in genapts. Sometimes genapts will crash when dealing with a particular airport. In that case, try running it again with the --start-id argument to start at the airport it failed on, and the --nudge argument which tries to nudge the calculations in the right direction.
* tg-construct Killed. The tg-construct process may kill itself if it is using too many system resources. Increasing the values for setrlimit in src/BuildTiles/Main/main.cxx is the best solution.
* tg-construct silently stops immediately without an error and nothing goes to the "output" directory: make sure that lon/lat values correspond to tiles boundaries. See [[Tile_Index_Scheme]]
* Airports appear in the bottom of holes, or there are spaces between the airports and the scenery. This typically happens when genapts is unable to find the correct elevation data, or the elevation data changed between running genapts and shape-decode. Try generating a single airport in your scenery area using genapts, and look at the output. In particular, make sure there is a work/SRTM-3 directory.
* Only the airports appear in the scenery. There are three typical causes for this:
** You didn't download the correct shapefiles for the area.
** You haven't run shape-decode on the v0_landmass shapefile as Default
** You didn't include the correct directories in tg-construct.
* Generate scenery includes data removed from the shapefiles. If you are editing shapefiles, you need to delete the appropriate work subdirectory before running shape-decode. Otherwise your changes will be in addition to those already present.
* All the scenery is flat and at sea-level. Typically this is because you didn't include any elevation data in your tg-construct command. Make sure there's a STRM-3 directory included in the command-line.
* All terrain copies the material of a certain shapefile. You have probably forgotten to put each of the downloaded shapefiles in a seperate directory inside the Data/shapefiles directory.
* genapts850 never passes the stage "Adding airport <ICAO> to parse list": did you unzip apt.dat.gz?

== General comments from forum discussion ==
{{cquote|f-ojac, you are right, the parameters used in scenery 2.0 were "-e 5 -x 20000" according to the wiki. I don't know why I had the impression these parameters were not public. In any case, it does not matter because using the same parameters will create closer results, but they are not guaranteed to be the same.

The parameters used to create scenery 2,0 seem to be:

-m ??: the minimum number of vertices in a tile. In FG, any number bellow 100 (and probably, any number below 1000) will do. I don't think there is any surface on the world perfectly flat for several kilometers. The default value is 50 and I'm sure is ok for any normal use.
-e 5: the max allowed error for elevation, in meters. That is: if terrafit calculates a simplification of the terrain where all points are at most this distance from the real elevation, no more vertices are created. The default value is 40 meters: a point may have an elevation error up to 40m (~100ft) High values for this parameter create less detailed mountains and smaller (in disk size) and more efficient (in FPS) terrain.
-x 20000: the max number of vertices in a tile. If this number of vertices is reached, terrafit stop regardless the max error of the vertices. The default value is 1000

Keep in mind you can set values that do not make sense:

* "-e 1 -x 100" does not make sense because it is going to be impossible to calculate errors less than 1 meters using only 100 vertices. The max number of vertices will be reached always and the max error will be probably ignored.
* "-e 300 -x 20000" does not make sense, tiles are going to use for sure much less vertices than 20,000 because you are allowing huge elevation errors.

If you want an efficient scenery (less vertices), use the default values "-e 40 -x 1000". If you want more accurate elevation at the cost of disk space and FPS, use values similar to scenery 2.0 ("-e 5 -x 20000") Anything in the middle will produce performance and disk use in the middle.<ref>{{cite web |url=http://forum.flightgear.org/viewtopic.php?f=5&t=24681#p225363
|title=Re: Terrasync Help (surprinsingly!) :)
|author=ludomotico |date= Mon Nov 24, 2014 4:28 am}}</ref>|ludomotico}}

<references/>

== Related content ==
* [[Howto:Create custom terrain]], editing/making terrain data.
* [[TerraGear CORINE]], building terrain from CORINE data.
* [[TerraGear Documentation]], using TerraGear details.

{{Terra}}

[[Category:Scenery enhancement|TerraGear, Using]]

[[fr:Utiliser TerraGear]]

Using TerraGear

2015-04-11T13:04:26Z

Radi: /* Elevation data */ hgtchop is deprecated?

{{Out of date}}

[[File:Terragearprocesschart.png|thumb|TerraGear Process Flow Chart]]
The [[TerraGear]] software project supports [[FlightGear]] by creating the files used by FlightGear to represent the elevation and texture of the earth, including airports, cities, fields, forests, rivers, roads and so on. The TerraGear software reads data files containing ground elevation, airport locations and layouts, geographical land-cover data, and more, and produces the scenery files used by FlightGear to represent the terrain of the world.

For simplicity and convenience, most FlightGear users simply download the plug-and-play scenery files from the FlightGear scenery server, or use [[TerraSync]] to automatically download scenery as needed. But there is a variety of reasons you might want to use TerraGear to produce your own terrain files, rather than downloading the standard FlightGear scenery.

For instance, if you use [[WorldEditor]] to modify/improve information about an [[:Category:Airports|airport]]'s taxiway/apron layout, you might wish to see how that modified airport would look in the scenery before deciding you're happy with the results. Maybe the official scenery is too detailed for your slow machine, and you'd like to build terrain using a digital elevation model (DEM) with poorer resolution, to decrease the number of polygons and thus improve your framerates. Or maybe you've got a fantastically fast machine, and you want to build your own terrain using higher-resolution vector data (vmap1, Tiger, osm) to get better roads/streams. For all these reasons, learning how to use TerraGear is a good idea.

== Obtaining TerraGear ==
You can either build TerraGear yourself, or download a pre-compiled binary. The later is the easiest and advised for starters.

* '''Option 1 - Download TerraGear pre-compiled (recommended for beginners) on Windows'''
*# Download the latest TerraGear build from [http://flightgear.simpits.org:8080/job/TerraGear-Win-Cmake/lastSuccessfulBuild/artifact/*zip*/archive.zip the FlightGear Build Server].
*# Create or choose a directory to hold the TerraGear tools.
*# Unzip the package and move the files from <tt>archive/install/msvc100/TerraGear/bin</tt> into a sub-directory named <tt>Terragear/</tt> in the base directory.
* '''Option 2 - Compile TerraGear from source code''' as explained in [[Building TerraGear|this article]].

''Note:'' You might need default_priorities.txt from the [https://gitorious.org/fg/terragear/blobs/raw/master/src/BuildTiles/Clipper/default_priorities.txt Git repository] or from the archive downloaded from the build server (in the <tt>archive/install/msvc100/TerraGear/share</tt> subdirectory). See [http://forum.flightgear.org/viewtopic.php?f=5&p=77950 this forum thread] for details,

=== GUI tool ===
A [[TerraGear GUI]] is available for those that would like to use TerraGear without knowing/using the command line options.

== Using TerraGear ==
First, choose the boundaries for the area of scenery you want to build, in terms of latitude and longitude. The smaller the area of scenery you generate, the smaller the amount of data you will need, and the less CPU time it will take. For example, if you are just interested in generating a new airport layout at 12.3W 34.4N, then simply generating the scenery between 12W 34N and 13W 35N would be sufficient.

Write down the bounding box (minimum and maximum longitude and latitude) for the scenery you want to generate. Remember that West and South are negative - i.e. 4W 10S would be -4, -10. Try not to get mixed up, otherwise you'll end up generating scenery or airports on the other side of the planet!

You'll be dealing with multiple different types of data in various formats. Create a new directory for your scenery work. Within that directory, create the following sub-directories:

* '''data/''' - for raw and pre-processed data (eg elevation files)
* '''output/''' - for the scenery files you will create
* '''work/''' - for data that has been processed (eg by shape-decode) and is ready to be munged into scenery

=== Obtaining and processing data ===
Terragear uses three different kinds of information to generate scenery:

# The elevation of the land (provided by SRTM)
# The location and layout of airports (provided by apt.dat or a custom .dat)
# Whether a given lat/lon is sea, land, city, forest, town, road, railway (provided by VMAP0, [[CORINE]] etc. or custom shapefiles)

This article describes how obtain and process each of these types of data in order, and bring it together for use by FlightGear. The order of these steps is important. For example, the airport data step needs the elevation data to determine the elevation of the airports and thus you should start with preparing elevation data.

'''Please note: for inclusion in the official FlightGear scenery, all data must come from [[GNU GPL]] compatible sources!'''

==== Elevation data ====
The best worldwide elevation data currently available is from the Shuttle Radar Topography Mission (SRTM). There are two types of SRTM data:
* Highly accurate 1-arcsecond resolution data, known as SRTM-1, for the USA
* Less accurate 3-arcsecond data, known as SRTM-3, for the rest of the world.
From now on, we'll assume you are using SRTM-3 data. Unless otherwise noted, the process for SRTM-1 is identical.

You can download the appropriate data from http://dds.cr.usgs.gov/srtm/version2_1/. You want all .hgt.zip files covering your region of interest. Depending on the size of your scenery, there may be quite a few. Download them to <tt>data/SRTM-1/</tt>(or SRTM-3/SRTM-30 depending on the type you downloaded) in your base directory. (Genapts looks for a few known, hardcoded elevation data directories in its working directory. SRTM-30 is one of them and this is the least confusing in that list. Note: W.E.F. 31st July 2010, the genapts tool now also looks for SRTM-1/SRTM-3 directories. If you are using an older version, please supply the directories using --dem-path).

Now we've got the data, we need to convert it into something of use to TerraGear. First, you need to unzip each of the .hgt files. After that, open the commandline (Windows: <tt>Start > Run > cmd.exe</tt>) and change into the base directory (<tt>cd .../.../TerraGear</tt>).
* '''NOTE:''' If you want to create a batch-file, replace <tt>%f</tt> with <tt>%%f</tt>, see [http://technet.microsoft.com/en-us/library/bb490909.aspx]
* '''NOTE:''' For SRTM-1 data, replace the <tt>3</tt> by a <tt>1</tt> in the first argument to hgtchop

'''Note: According to [[TerraGear_Documentation]], hgtchop is superseded by gdalchop.'''

For Windows:
for %f in (.\data\SRTM-3\*.hgt) do .\Terragear\hgtchop.exe 3 %f .\work\SRTM-3
or
for %f in (.\data\SRTM-3\*.hgt) do .\Terragear\hgtchop.exe 3 .\data\SRTM-3\%f .\work\SRTM-3

For Linux:
for i in $PWD/data/SRTM-3/*.hgt; do ./Terragear/hgtchop 3 $i $PWD/work/SRTM-3; done

Now you will get a lot of .arr.gz files in your work/SRTM-3/ directory. We need to convert these to the .fit.gz format. Run the commandline again with
* '''NOTE:''' the space and dot at the and are important!

For Windows:
.\Terragear\terrafit.exe work\SRTM-3

For Linux:
./Terragear/terrafit work/SRTM-3

==== Airport data ====
Now we've got elevation data, we can generate our airports. First, create a <tt>data/airports/</tt> directory and copy in your apt.dat file. This may be direct from your FlightGear data package (though you'll need to unzip it), or it may be one that you've modified with [[WorldEditor]].

The command to create airports is "genapts850". Run it without any arguments to see the various command-line options.

If it is simply run with a specified apt.dat and work directory, it will generate airport layouts for every airport in the file, which can take a long time.

If you are just creating a single airport and you know the ICAO ID (e.g. [[KSFO]], EGPH, EG32), use is as follows from your root scenery directory (i.e. the directory above your data, work and output directories). If you use an apt.dat file with one single airport in it you should omit the "--airport" parameter.

genapts850 --input=data/airports/apt.dat --work=./work --airport=<AIRPORT_ID>

If you are generating a larger set of scenery, then you can specify the minimum and maximum longitude and latitude.

Genapts will create two sub-directories in your work directory:
* <tt>AirportArea/</tt>
* <tt>AirportObj/</tt>
These contain the definitions of the airport layout and any objects present (e.g. windsocks and beacons).

==== Landuse data ====
The final piece of data we need to generate is the landuse data. In general, this is taken from the VMAP0 dataset as shapefiles from the scenery database mapserver, but other sources can also be used.

The landuse data can be split into a number of different types:
* '''Landmass''' separates the land from the sea. It can be used as a mask for all other data. The most commonly used is the VMAP0 Landmass, but GSHHS can also be used. When running tg-construct with <code>--ignore-landmass</code>, all input shapefiles will be taken into consideration, so no landmass mask is required then.
* '''Land use data:''' defines whether a piece of land is forest, urban, sand, lava, glacier etc. These are usually VMAP0 data, defined as polygons.
* '''Line data:''' includes railroads, streams, roads. Typically VMAP0, but also Open Street Map for roads.
* '''Point data:''' is currently only used for defining towns.

By far the easiest way to get this data is to download shapefiles from the wonderful [http://mapserver.flightgear.org MapServer]. The MapServer lets you download the shapefiles for any selected scenery area. Click on the "Download Shapefiles" link (or go direct: http://mapserver.flightgear.org/download.psp). Enter in the bounding box of the scenery you want to generate, select the type of shapefile data you want, and click download.

'''Layer differences'''

* '''v0''': global coverage, low detail. This is "the last resort", but unfortunately it is the only layer that covers the entire world.
* '''cs''': it is v0 with some contributions someone did in the past. Get this instead of v0.
* '''v1''': only parts of some countries available, higher detail than v0.
* '''clc06''': European '''only'''. Very high detail, this is the preferred choice for an European country.
* '''osm''': global coverage, high resolution but very low detail. This means: if you are interested in an area out of Europe and forests are defined in OpenStreetMaps for your area, this is going to be the best data source. If forests are not defined, you will get a dull, neverending DEFAULT landclass. OSM provides the best coastline and I encourage you to use this coastline even in Europe. [http://forum.flightgear.org/viewtopic.php?f=5&t=25549&sid=d501cb651ef9e34ca9dc8fae429d51ab&p=234002#p234002]

{{caution|Make sure each shape file is in its own directory whether you download shape files or create your own otherwise the ogrDecode step will fail.}}
Download each shapefile into a seperate (!) <tt>data/shapefiles/...</tt> directory. So, for v0_landmass, you would end up with <tt>data/shapefiles/v0_landmass/v0_landmass.shp</tt> etc.

You can load these shapefiles into a GIS editor such as [[QGIS]] or GRASS to view and edit. This is a good idea to verify you have the correct files! Later on, you can experiment with replacing various shapefiles with other versions (GSHHS for coastline, OSM for roads etc.).

The next step is to decode the shape-files into TerraGear format using the '''ogr-decode''' command.

There are three important command-line arguments for ogr-decode:
* the destination directory for the decoded data
* the location of the shapefile's directory
* the material type

Each shape-file corresponds with one of the material types defined in the materials.xml files. The mapping is pretty obvious. For example, v0_mixedcroppasturecover maps to MixedCropPastureCover. Note that the material types are case-sensitive, so it is a good idea to refer to the <tt>[[$FG_ROOT]]/Materials/default/materials.xml</tt> file (<tt>[[$FG ROOT]]/materials.xml</tt> in FlightGear 2.6.0 and older) to hand so you can check. The exception is landmass, which - when used - MUST be mapped onto the type Default.

Additionally, there are a number of optional arguments, to indicate the width of line data (for roads, streams, railways), how large to make point data (for towns) and how long the longest straight line is allowed to be.

For example, to decode the v0_landmass shapefile, you use the following command:

ogr-decode --max-segment 500 --area-type Default work/Default data/shapefiles/v0_landmass

To create streams of width 10 metres

ogr-decode --max-segment 500 --line-width 10 --area-type Stream work/Stream data/shapefiles/v0_stream

To generate some towns about 1km across

ogr-decode --point-width 500 --area-type Town work/Town data/shapefiles/v0_town

Run this command for each shapefile in the set.

== Generating scenery ==
You will now have a work directory, with subdirectories like:
{|
|
: AirportArea
: AirportObj
: Bog
: Default
: DryCropPastureCover
: EvergreenBroadCover
: GrassCover
: IrrCropPastureCover
: Lake
: Marsh
: MixedCropPastureCover
| valign="top" |
: MixedForestCover
: Railroad
: Road
: Sand
: ScrubCover
: Shared
: SRTM-3
: Stream
: Town
: Urban
|}

Now we can actually generate the scenery. This is done by the tg-construct command. Run the command with <code>--help</code> to get usage information.

We need to define:
* The work (--work-dir) and output (--output-dir) directories.
** '''Note''' about the output directory: this must point to a <tt>Terrain/</tt> directory, else recent FlightGear versions will be unable to load the terrain.
* The center of the scenery we want to generate (--lat, --lon).
* The radius (--xdist, --ydist) from which to generate.
* All the work directories to include in the scenery.

For example:
{{Pre2|<nowiki>tg-construct --work-dir=./work --output-dir=./output/Terrain --min-lon=55 --max-lon=57 --min-lat=60 --max-lat=62 AirportArea SRTM-3 AirportObj Default Stream Bog IrrCropPastureCover Town Lake Urban Railroad DryCropPastureCover Road EvergreenBroadCover Marsh Sand MixedCropPastureCover ScrubCover GrassCover MixedForestCover</nowiki> }}

When this finishes, the output directory will contain a scenery sub-tree. Point to it by setting either [[$FG_SCENERY]] or by using the --fg-scenery command-line option to fgfs, and give your new scenery a try!

== Troubleshooting ==
Below is a list of common problems and solutions. If in doubt - Google it. Many problems (particularly when compiling TerraGear) have been hit before:

* Crashes in genapts. Sometimes genapts will crash when dealing with a particular airport. In that case, try running it again with the --start-id argument to start at the airport it failed on, and the --nudge argument which tries to nudge the calculations in the right direction.
* tg-construct Killed. The tg-construct process may kill itself if it is using too many system resources. Increasing the values for setrlimit in src/BuildTiles/Main/main.cxx is the best solution.
* tg-construct silently stops immediately without an error and nothing goes to the "output" directory: make sure that lon/lat values correspond to tiles boundaries. See [[Tile_Index_Scheme]]
* Airports appear in the bottom of holes, or there are spaces between the airports and the scenery. This typically happens when genapts is unable to find the correct elevation data, or the elevation data changed between running genapts and shape-decode. Try generating a single airport in your scenery area using genapts, and look at the output. In particular, make sure there is a work/SRTM-3 directory.
* Only the airports appear in the scenery. There are three typical causes for this:
** You didn't download the correct shapefiles for the area.
** You haven't run shape-decode on the v0_landmass shapefile as Default
** You didn't include the correct directories in tg-construct.
* Generate scenery includes data removed from the shapefiles. If you are editing shapefiles, you need to delete the appropriate work subdirectory before running shape-decode. Otherwise your changes will be in addition to those already present.
* All the scenery is flat and at sea-level. Typically this is because you didn't include any elevation data in your tg-construct command. Make sure there's a STRM-3 directory included in the command-line.
* All terrain copies the material of a certain shapefile. You have probably forgotten to put each of the downloaded shapefiles in a seperate directory inside the Data/shapefiles directory.

== General comments from forum discussion ==
{{cquote|f-ojac, you are right, the parameters used in scenery 2.0 were "-e 5 -x 20000" according to the wiki. I don't know why I had the impression these parameters were not public. In any case, it does not matter because using the same parameters will create closer results, but they are not guaranteed to be the same.

The parameters used to create scenery 2,0 seem to be:

-m ??: the minimum number of vertices in a tile. In FG, any number bellow 100 (and probably, any number below 1000) will do. I don't think there is any surface on the world perfectly flat for several kilometers. The default value is 50 and I'm sure is ok for any normal use.
-e 5: the max allowed error for elevation, in meters. That is: if terrafit calculates a simplification of the terrain where all points are at most this distance from the real elevation, no more vertices are created. The default value is 40 meters: a point may have an elevation error up to 40m (~100ft) High values for this parameter create less detailed mountains and smaller (in disk size) and more efficient (in FPS) terrain.
-x 20000: the max number of vertices in a tile. If this number of vertices is reached, terrafit stop regardless the max error of the vertices. The default value is 1000

Keep in mind you can set values that do not make sense:

* "-e 1 -x 100" does not make sense because it is going to be impossible to calculate errors less than 1 meters using only 100 vertices. The max number of vertices will be reached always and the max error will be probably ignored.
* "-e 300 -x 20000" does not make sense, tiles are going to use for sure much less vertices than 20,000 because you are allowing huge elevation errors.

If you want an efficient scenery (less vertices), use the default values "-e 40 -x 1000". If you want more accurate elevation at the cost of disk space and FPS, use values similar to scenery 2.0 ("-e 5 -x 20000") Anything in the middle will produce performance and disk use in the middle.<ref>{{cite web |url=http://forum.flightgear.org/viewtopic.php?f=5&t=24681#p225363
|title=Re: Terrasync Help (surprinsingly!) :)
|author=ludomotico |date= Mon Nov 24, 2014 4:28 am}}</ref>|ludomotico}}

<references/>

== Related content ==
* [[Howto:Create custom terrain]], editing/making terrain data.
* [[TerraGear CORINE]], building terrain from CORINE data.
* [[TerraGear Documentation]], using TerraGear details.

{{Terra}}

[[Category:Scenery enhancement|TerraGear, Using]]

[[fr:Utiliser TerraGear]]

Template:OSM Navigation

2015-03-20T08:14:17Z

Radi: add link to osm2roads

{{infobox subsystem

|name =Autogen Scenery
|started= 11/2013
|description = Improved autogen support for FlightGear using OSM data
|status = [https://gitorious.org/+flightgear-autogen-team Under active development as of 05/2014]
|developers = radi, vanosten, Soitanen, portreekid
|topic-sg = https://gitorious.org/fg/fg-autogen-simgear
|topic-fg = https://gitorious.org/fg/fg-autogen-flightgear
|topic-fgdata = https://gitorious.org/fg/fg-autogen-fgdata
}}

{{sidebar
| name = OSM Navigation
| title = OpenStreetMap use in FlightGear
| contentstyle= text-align: left;

| content1 =
* [[OpenStreetMap]]
* [[Using OSM Vector Data in FlightGear]]
* [[AutoGen Scenery for FlightGear]]
* [[OpenStreetMap buildings]]
* [[Osm2city.py]]
** [[Osm2city.py Development]]
** [[Osm2city.py Batch]]
** [[Osm2city.py Textures]]
** [[Osm2pylons.py]]
** [[OsmPiers.py]]
** [[OsmPlatforms.py]]
** [[Osm2city_landuse.py]]
** [[Osm2roads.py]]
* [[Random Buildings]]
* [[OpenStreetMap import]]


}}{{main other|

[[Category:OpenStreetMap]]
[[Category:Core development projects]]}}
<noinclude>{{Informative template|1=
== Goal ==
This template can be used at the top of articles related to using OpenStreetMap with FlightGear or the scenery tools.

== Usage ==
Put this at the top of the article:
<nowiki>{{OSM Navigation}}</nowiki>

}}

[[Category:Navigation templates]]
[[Category:OpenStreetMap|OSM Navigation]]
</noinclude>

Osm2city.py textures

2015-03-18T07:39:25Z

Radi: updated texture atlas restrictions

This article describes how you can prepare and register your own textures for use with osm2city.py.
It assumes you already have a texture image file. If not, see [[Howto:Create_textures_from_photos]].

== Introduction ==
To texture a facade or a roof, you need
* two image files: the texture itself and a lightmap
* the texture's dimensions in meters
* locations in pixels at which osm2city.py may cut the texture to fit it to a given facade geometry, e.g. to apply a photo of a 15-storey building to a 12 storey model without shrinking it.
* 'provides' and 'requires' tags, e.g., a texture could require a black roof, while providing a commercial facade.

Osm2city uses a texture atlas to improve performance. But that places some restrictions:
# textures can only wrap around in zero or one direction.
# textures that don't wrap around must come in 2^n sizes (32, 64, 128px ...)
# textures that wrap around in one direction will be resized to (currently hardcoded) 256 px in that direction

== texGUI.py ==
The script texGUI.py eases calibration and finding the cut locations. Run the GUI and supply your texture file:
<syntaxhighlight lang="bash">
texGUI.py facade.png
</syntaxhighlight>

[[File:TexGUI calibrating width.jpg|thumb|texGUI: Calibrating a texture's width using an aircon as a reference object. Note the red line.]]
[[File:TexGUI added cut locations.jpg|thumb|texGUI: Added horizontal and vertical cut locations.]]

It is generally a good idea to use descriptive names, such as "facade_industrial_old_white.png", but for this example we simply use "facade.png".

# Calibrate the image width/height. Find a feature in the image whose dimensions you know or can estimate. For example, simple windows are typically about 0.8 m wide. Here, we're using the aircon's width, estimated 0.82 m. Left drag to select that horizontal feature, then enter its length. Right drag for a vertical feature. You need only one of them. If both are given, both are used (e.g. if your image is stretched in one direction).
# Mark locations at which osm2city.py may cut the texture. Use left and right mouse buttons. Shift+click removes the last marker.
# Once you're satisfied, click "dump and quit". This writes calibration/cut data to a file "facade_24x19m.py". Note that texGUI added "_24x19m" to the texture file name (the original file is still in place), since you're likely to have more than one texture for an industrial facade.

== Texture metadata ==

Now edit facade_24x19m.py:

<syntaxhighlight lang="python">
facades.append(Texture('tex.src/facade_24x19m.png',
23.8, [364, 742, 1086], h_can_repeat=True,
18.5, [295, 565, 842], v_can_repeat=False,
v_align_bottom = True,
requires=[],
provides=[]))
</syntaxhighlight>

Usually you need to change very little here.
* You can set the texture to wrap around in at most one direction using ''h_can_repeat'' or ''v_can_repeat''
* If ''v_align_bottom'' is True, osm2city.py will align the bottom part of the texture with the ground and cut away the top part if neccessary. Otherwise, it will align the top part with the roof and cut away the bottom.

For reference, we now descibe the format in a bit more detail. You might want to skip to the [[Osm2city.py_Textures#Texture_compatibility|next section]].

First line is the path to our texture.
Second line says the texture
* is 23.8m wide
* can be cut at u = 364, 742, and 1068 px, where u is the horizontal coordinate. The last value 1086 also gives the width in px. Note that the .ac file uses normalized coordinates (0 ... 1). Internally, osm2city.py divides all coordinates by the last value. Therefore, when preparing the textures, you can work with the highest resolution possible and register those numbers, then just downscale the texture for actual flightgear use. Once the next generation of graphics cards arrives you just replace the textures with higher resolution ones without touching the cut locations.
* the texture can repeat in horizontal direction.

The third line gives the same information for the vertical direction:
* 18.5m height
* can cut at 295, 565, 842 px,
* the texture cannot repeat in vertical direction

== Texture compatibility ==

The fourth and fifth line state compatibility with other textures. TexGUI.py just creates an empty template here. A useful example could look like this:

<syntaxhighlight lang="python">
requires=['roof:color:black'],
provides=['shape:industrial','age:old','compat:roof-flat','compat:roof-gable']))
</syntaxhighlight>

This facade texture requires a black roof. It provides an old-aged, industrial facade, and is compatible with both flat and gable roofs. TODO: describe details on our requires/provides mechanism.

== Lightmap ==

A lightmap <del>is required for every texture, having</del>has the same file name with a postfix "_LM". So for our example this would be
"facade_24x19m_LM.png"

Osm2city uses
* red channel for window lights
* green channel for ambient street lights shining onto facade
* blue and alpha unused

TODO describe add_streetlight.py

== Install texture and lightmap ==
* copy texture and lightmap to tex.src/
* add the snippet from "facade_24x19m.py" to textures/catalog.py

If you're adding a roof, name your texture "roof_something.png" and append it to the list of ''roofs'' (instead of ''facades'')
<syntaxhighlight lang="python">
roofs.append(Texture('tex.src/roof_something.png',
</syntaxhighlight>

See roof examples starting around line 400.<del>Note that also roofs need a lightmap.</del> They no longer need a LM.

Finally, run
<syntaxhighlight lang="bash">
osm2city.py -A
</syntaxhighlight>

to re-create the texture atlas. If there are no errors, your texture is registered and will be used next time you run osm2city.py. If your texture is GPL compatible, please consider
sending it (along with the meta data) to one of the osm2city.py devs to have it included in the official distribution.

[[Category:Modeling]]
[[Category:OpenStreetMap]]

Osm2city.py

2015-03-16T10:51:24Z

Radi: /* Install */ gitlab links

{{OSM Navigation}}
[[File:LOWI with OSM buildings.jpg|thumb|LOWI with OSM buildings]]

This Python script takes OpenStreetMap floorplans and creates 3d buildings ready for use in FlightGear.

The development [https://gitlab.com/fg-radi/osm2city repository] is hosted on <del>gitorious</del> gitlab.
Forum thread [http://forum.flightgear.org/viewtopic.php?f=5&t=22809 osm2city.py development]
Written in Python 2.7, developed on GNU/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 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.

== News ==
=== Status 10/2014 ===
New features:
* textures reside in a separate [https://gitorious.org/fg-radi/osm2city-data repository]
* the recommended elevation probing method is ELEV_MODE=FgelevCaching
* roads.py is now quite usable
* SKIP_LIST can contain OSM_IDs

=== Status 06/2014 ===
I'm currently adding textured roads, railroads, intersections and bridges.

{{FGCquote
| the shader is now on osm2city's git (in fgdata/). Again -- all credit goes to Emilian. He is improving the shader side, I will continue on the model side. So this is very much work in progress. The shader requires the default renderer. No ALS/Rembrandt yet. Get the LOWI roads pack (including the shader) here: [https://dl.dropboxusercontent.com/u/24846517/fg/osm2city/LOWI_roads.tar.gz https://dl.dropboxusercontent.com/u/24846517/fg/osm2city/LOWI_roads.tar.gz] The fgdata/ folder goes to your $FGDATA. In roads.xml enable either the lightmap or the traffic shader.
|{{cite web |url=http://forum.flightgear.org/viewtopic.php?p=212460#p212460
|title=<nowiki>Re: osm2city.py development</nowiki>
|author=<nowiki>radi</nowiki>
|date=<nowiki>Fri Jun 13</nowiki>
}}
}}

{{FGCquote
|Creating your own road network is a bit cumbersome ATM, I'll try to make it more general in the next few days. But if you're really, really keen on it: <ul><li> get latest osm2city git</li><li> run roads.py -f your-parameters-file.</li><li> if you also create buildings, make sure to use the same BOUNDARY_* parameters for both osm2city.py and roads.py. Otherwise, buildings and roads might be misaligned. Basically, if your OSM file contains both roads and buildings, you can just use one parameters file.</li><li> roads.py will print an OBJECT_STATIC line, add this to your .stg (appears to add itself)</li><li> copy roads.ac to your scenery</li><li> copy roads.xml and tex/ from the LOWI roads pack to your scenery (roads.ac and .xml copy themselves)</li></ul>
|{{cite web |url=http://forum.flightgear.org/viewtopic.php?p=212460#p212460
|title=<nowiki>Re: osm2city.py development</nowiki>
|author=<nowiki>radi</nowiki>
|date=<nowiki>Fri Jun 13</nowiki>
}}
}}

=== Status 04/2014 ===
[[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. 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]]
The second scene, approaching LOWI from the east, went from 30 fps without buildings down to 20 fps.

=== Status 10/2013 ===
Currently data is processed offline beforehand. 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. <del>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.
</del> (Some optimization gave a huge speedup).

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
use some heuristics (some OSM buildings are labeled "Terminal 1" or so) to apply
terminal/hangar textures to buildings at airports. This way we could rather easily populate some airports with
'semi-generic' terminal/hangar buildings.

== Features ==
* 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 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)
* 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
:* ~10 different, hi-res facade textures, some roof textures
:* find matching texture for given building (number of levels, modern/old building, etc)
:* find matching roof texture for given facade texture
* basic lightmap support
* obstruction lights on tall buildings
* command line interface and parameters file (thanks to forum user vanosten)
* shows statistics on processed buildings
* 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 {{done}}
* 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|50}}
:* 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 ==
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
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 ==
* nearby hi-rise objects of similar shape get same texture? Probably too special a feature.
* 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 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 ==
1. dependencies: Install the following packages (names from Debian packages):
python-numpy python-shapely python-matplotlib python-scipy python-pil python-networkx
2. get [https://gitlab.com/fg-radi/osm2city osm2city] and [https://gitlab.com/fg-radi/osm2city-data osm2city-data] from gitlab.

3. 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))

4. soft link osm2city-data/tex and osm2city-data/tex.src into osm2city/ such that it appears as a sub-directory of osm2city
<syntaxhighlight lang="bash">
osm2city/
tex.src/
tex/
osm2city.py
textures.py
...
</syntaxhighlight>

If you're running FG >= 3.3, or git newer than 10 Oct 2014, and have more than 4 GB RAM, you're done installing now. Otherwise, you will most likely need to set-up and use the old-fashioned way of elevation probing, which requires you to

5. copy elev.nas to $FGDATA/Nasal/

6. Open elev.nas in a text editor. Change the out variable to a directory with write access (e.g. $FG_HOME/Export). See [[IORules]] and [[$FG_HOME]]

== Install on Windows ==
In general, you'll want to follow the above install section. This section lists some additional Windows particularities.

Osm2city is pure python.

https://www.python.org/downloads/release/python-278/

{{caution|Python 2.7 is recommended unless you're an experienced Python developer willing to update the Python scripts to support Python 3. Also pay attention to versions and cpu builds of the below helper files. Make sure they match your OS build and Python version.}}

Install the following packages, then proceed with [[Osm2city.py#Install|step 2. above]].

http://www.lfd.uci.edu/~gohlke/pythonlibs/#numpy

http://www.lfd.uci.edu/~gohlke/pythonlibs/#shapely

http://www.lfd.uci.edu/~gohlke/pythonlibs/#scipy-stack

https://pypi.python.org/pypi/Pillow/2.5.0#downloads

== Workflow ==
There are five main steps:
* get OSM data
* adjust input file
* if neccessary, create elevation grid and run FG to probe elevation data.
* run osm2city
* <del>install the generated scenery</del>installs itself

We'll now walk through these steps in detail:
=== get OSM data ===
* decide on a region you want to populate. Get its lon/lat coordinates.
* create a project directory. We will use LOWI/ in this example.
* get corresponding OSM data in its native .xml format.
There are several options to get OSM data. You may find the [http://harrywood.co.uk/maps/uixapi/xapi.html XAPI Query Builder] helpful, it will generate a download URL that you can fetch with wget:
wget -O buildings.osm http://www.overpass-api.de/api/xapi?map?bbox=11.16898,47.20837,11.79108,47.38161

If you use [http://wiki.openstreetmap.org/wiki/Osmosis Osmosis] and cut the area with ''--bounding-box'' then you need to use ''completeWays=yes''.

Put this data into LOWI/buildings.osm

=== Adjust input file ===
* Now adjust the input file. You can generate a commented default parameters file by
<syntaxhighlight lang="bash">
parameters.py -d > LOWI/params.ini
</syntaxhighlight>

Edit this file, adjusting (at least) the following:
:* PREFIX = "LOWI" (the project directory)
:* BOUNDARY_EAST, BOUNDARY_NORTH, BOUNDARY_SOUTH, BOUNDARY_WEST
:* OSM_FILE = "buildings.osm"
:* set PATH_TO_SCENERY to a standard [[$FG_SCENERY]] path. This is the path where we'll get the elevation from. Most likely you'll want to use your TerraSync path here. Suppose the area you want to populate is /home/user/fgfs/scenery/TerraSync/Objects/e010n40/e011n47/, PATH_TO_SCENERY would then be "/home/user/fgfs/scenery/TerraSync" .
:* set PATH_TO_OUTPUT to a ''different'' scenery path, e.g. "/home/user/fgfs/scenery/osm2city" . Osm2city will generate its objects there. First, this avoids TerraSync overwriting the generated scenery. Second, you can easily remove that folder in case you're not happy with the result. Make sure to include that path in your [[$FG_SCENERY]].
:* you might want to set MAX_OBJECTS to a small number (say, 100) for your first try. This will limit the number of buildings parsed, and speed up the whole process.
:* you also need to set up elevation probing in the parameters file, described in the next section.

{{note|Python does not recognize environment variables, please use full paths in the parameters file (no $HOME etc).}}

=== Probe elevation ===
Probe elevation for your region. Pick one of the three available modes for ELEV_MODE in params.ini. If you have enough memory (4GB should be fine, but YMMV) and run FG git later than 10 Oct 2014, try FgelevCaching. Failing that, try Manual. (portreekid, what's the 3rd mode good for?)

{{caution|1=There are a lot of problems reported currently with fgelev. I can't really test for the next month or so. See troubleshooting or use ELEV_MODE = "Manual".}}

* ELEV_MODE = "FgelevCaching"
:* Set FG_ELEV to your fgelev executable. For example: FG_ELEV = "/usr/local/fg/bin/fgelev" or just FG_ELEV = "fgelev" if fgelev is already in your OS's path.
:* Set PATH_TO_SCENERY (Missing terrain will result in error message)
:* make sure the environment variable [[$FG ROOT]] points to your FG base path, (e.g. export FG_ROOT=/usr/share/games/flightgear/ on Linux)

* ELEV_MODE = "Manual"
:* run tools.py (tools.py -f LOWI/params.ini), this will create a file elev.in. Copy elev.in to $FG_ROOT/Nasal/
:* Open $FG_ROOT/Nasal/elev.nas in a text editor. Point the in variable to your elev.in file e.g. var in = "/path/to/$FG_ROOT/Nasal/elev.in".
:* tools.py will tell you to hide a certain scenery/Objects/... folder, to prevent probing elevation on top of existing objects. Simply rename the folder
:* run FG, open debug->nasal console, enter: elev.get_elevation(), press execute. Might take a long time, depending on the area scanned. This will write elevation data to /tmp/elev.out (which is actually just plain 5 column data: lon,lat,x,y,elevation). Put elev.out into LOWI/
:* unhide, rename the objects folder

* ELEV_MODE = "Telnet"
:* Run setup.py
:* Start FG with the properties service on Port 5501
:* Run tools.py, this will create a elev.in, start the nasal script and copy the elev.out back to your project directory

=== Run osm2city ===
* Make sure you're in osm2city's directory and run

python osm2city.py -f LOWI/params.ini.

The parsed OSM data is cached to file LOWI/buildings.osm.pkl which is used on next startup if you set USE_PKL = 1.
If all goes well, files like LOWIcity0101.ac and their corresponding .xml, along with .stg files, were created and moved to the correct location in $FG_SCENERY
* copy or link the tex/ folder into the objects folder where these files were created

=== Roads ===
* run roads.py in the same fashion for roads
* <del>copy roads.eff to the same Objects\e0XXnXX\e0XXnXX\ directory</del> roads.eff is copied automatically
* Band-aid fix for the roads is to adjust their height in roads.py change AGL_ofs to a higher number e.g. 0.5
* the moving cars (TRAFFIC_SHADER_ENABLE = True) are only visible when you disable Atmospheric light scattering (ALS)

== Support and troubleshooting ==
Time permitting, we can provide limited support on the [http://forum.flightgear.org/viewtopic.php?f=5&t=22809 Forums]. Please don't use PM for support questions.

Before you ask a question, make sure you read this wiki page. If your question is not covered here, tell us as much as possible about the problem you're facing. Which steps have you taken to solve it? What is the exact error message? What operating system? Screenshots?

We will not cover general questions like "I don't know how to install XY" -- search the Internet.

=== FGElev crashes ===

<syntaxhighlight lang="bash">
CRITICAL:root:1173 -95.5767 37.0965
CRITICAL:root:fgelev returned <>, resulting in list index out of range. Did fgelev start OK (Record : 1173)?
</syntaxhighlight>
The first line is the last input to fgelev.
Try running fgelev directly:
<syntaxhighlight lang="bash">
/path/to/fgelev --expire 1000 --fg-root $FG_ROOT --fg-scenery $FG_SCENERY
</syntaxhighlight>
then enter the line last sent to fgelev.
<syntaxhighlight lang="bash">
1173 -95.5767 37.0965
</syntaxhighlight>
The response should look like
<syntaxhighlight lang="bash">
1173: 226.793
</syntaxhighlight>

=== Buildings are generated, but they sit below the ground. I'm using ELEV_MODE = FgelevCaching. ===

Try running fgelev directly:
<syntaxhighlight lang="bash">
/path/to/fgelev --expire 1000 --fg-root $FG_ROOT --fg-scenery $FG_SCENERY
</syntaxhighlight>
then enter
<syntaxhighlight lang="bash">
0 $lon $lat
</syntaxhighlight>
where $lon and $lat are coordinates in the area you want to generate. See if it returns a sane value. If it does, double-check PATH_TO_SCENERY and $FG_ROOT.

=== Buildings/roads have no texture. I get errors "osgDB ac3d reader: could not find texture "tex/atlas_facades.png". ===

Copy or link the tex/ folder into the objects folder where the .stg files were created, such that you have $FG_SCENERY/Objects/eXXXnXX/eXXXnXX/tex/. Note that buildings might have been created in more than one folder, e.g. in e011n47 and e011n48. You must have a tex/ folder in each of them. On Windows it is sufficient to have one copy in $FG_ROOT.

== Improve frame rate ==
* adjust LOD ranges in FG
* decrease MAX_OBJECTS, increase LOD_*
(- use larger/smaller tiles? Tradeoff between distance calculations/xml parsing and GPU)

== Contributing ==
You know some python? Or you're keen on writing docs? Contact radi on the FG forum.
None of the above? Take [[Howto:Create_textures_from_photos|pictures]] of buildings where you live and [[Osm2city.py Textures|create textures]]! I'm especially interested in south-east asian style architecture, as I'm planning to populate Hong Kong Kai Tak (VHXX) in the future.

== Related ==
* [[Using OSM Vector Data in FlightGear]]
* [[OpenStreetMap buildings]]
* [[AutoGen Scenery for FlightGear]]
* [[Random Buildings]]
* [http://forum.flightgear.org/viewtopic.php?f=5&t=21131#p192198 OSM buidings EHLE]
* [http://forum.flightgear.org/viewtopic.php?f=5&t=22809 osm2city.py development]
* [http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg40092.html Osm2city.py]
* http://forum.flightgear.org/viewtopic.php?f=5&t=19625
* [http://forum.flightgear.org/viewtopic.php?f=38&t=8837 PixelCity]
* [http://forum.flightgear.org/viewtopic.php?p=166794#p166681 Procedural OSM buildings]

[[Category:Scenery software]]

Osm2city.py

2015-03-16T10:46:11Z

Radi: we moved to gitlab

{{OSM Navigation}}
[[File:LOWI with OSM buildings.jpg|thumb|LOWI with OSM buildings]]

This Python script takes OpenStreetMap floorplans and creates 3d buildings ready for use in FlightGear.

The development [https://gitlab.com/fg-radi/osm2city repository] is hosted on <del>gitorious</del> gitlab.
Forum thread [http://forum.flightgear.org/viewtopic.php?f=5&t=22809 osm2city.py development]
Written in Python 2.7, developed on GNU/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 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.

== News ==
=== Status 10/2014 ===
New features:
* textures reside in a separate [https://gitorious.org/fg-radi/osm2city-data repository]
* the recommended elevation probing method is ELEV_MODE=FgelevCaching
* roads.py is now quite usable
* SKIP_LIST can contain OSM_IDs

=== Status 06/2014 ===
I'm currently adding textured roads, railroads, intersections and bridges.

{{FGCquote
| the shader is now on osm2city's git (in fgdata/). Again -- all credit goes to Emilian. He is improving the shader side, I will continue on the model side. So this is very much work in progress. The shader requires the default renderer. No ALS/Rembrandt yet. Get the LOWI roads pack (including the shader) here: [https://dl.dropboxusercontent.com/u/24846517/fg/osm2city/LOWI_roads.tar.gz https://dl.dropboxusercontent.com/u/24846517/fg/osm2city/LOWI_roads.tar.gz] The fgdata/ folder goes to your $FGDATA. In roads.xml enable either the lightmap or the traffic shader.
|{{cite web |url=http://forum.flightgear.org/viewtopic.php?p=212460#p212460
|title=<nowiki>Re: osm2city.py development</nowiki>
|author=<nowiki>radi</nowiki>
|date=<nowiki>Fri Jun 13</nowiki>
}}
}}

{{FGCquote
|Creating your own road network is a bit cumbersome ATM, I'll try to make it more general in the next few days. But if you're really, really keen on it: <ul><li> get latest osm2city git</li><li> run roads.py -f your-parameters-file.</li><li> if you also create buildings, make sure to use the same BOUNDARY_* parameters for both osm2city.py and roads.py. Otherwise, buildings and roads might be misaligned. Basically, if your OSM file contains both roads and buildings, you can just use one parameters file.</li><li> roads.py will print an OBJECT_STATIC line, add this to your .stg (appears to add itself)</li><li> copy roads.ac to your scenery</li><li> copy roads.xml and tex/ from the LOWI roads pack to your scenery (roads.ac and .xml copy themselves)</li></ul>
|{{cite web |url=http://forum.flightgear.org/viewtopic.php?p=212460#p212460
|title=<nowiki>Re: osm2city.py development</nowiki>
|author=<nowiki>radi</nowiki>
|date=<nowiki>Fri Jun 13</nowiki>
}}
}}

=== Status 04/2014 ===
[[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. 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]]
The second scene, approaching LOWI from the east, went from 30 fps without buildings down to 20 fps.

=== Status 10/2013 ===
Currently data is processed offline beforehand. 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. <del>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.
</del> (Some optimization gave a huge speedup).

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
use some heuristics (some OSM buildings are labeled "Terminal 1" or so) to apply
terminal/hangar textures to buildings at airports. This way we could rather easily populate some airports with
'semi-generic' terminal/hangar buildings.

== Features ==
* 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 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)
* 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
:* ~10 different, hi-res facade textures, some roof textures
:* find matching texture for given building (number of levels, modern/old building, etc)
:* find matching roof texture for given facade texture
* basic lightmap support
* obstruction lights on tall buildings
* command line interface and parameters file (thanks to forum user vanosten)
* shows statistics on processed buildings
* 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 {{done}}
* 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|50}}
:* 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 ==
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
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 ==
* nearby hi-rise objects of similar shape get same texture? Probably too special a feature.
* 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 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 ==
1. dependencies: Install the following packages (names from Debian packages):
python-numpy python-shapely python-matplotlib python-scipy python-pil python-networkx
2. get [https://gitorious.org/fg-radi/osm2city osm2city] and [https://gitorious.org/fg-radi/osm2city-data osm2city-data] from gitorious

3. 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))

4. soft link osm2city-data/tex and osm2city-data/tex.src into osm2city/ such that it appears as a sub-directory of osm2city
<syntaxhighlight lang="bash">
osm2city/
tex.src/
tex/
osm2city.py
textures.py
...
</syntaxhighlight>

If you're running FG >= 3.3, or git newer than 10 Oct 2014, and have more than 4 GB RAM, you're done installing now. Otherwise, you will most likely need to set-up and use the old-fashioned way of elevation probing, which requires you to

5. copy elev.nas to $FGDATA/Nasal/

6. Open elev.nas in a text editor. Change the out variable to a directory with write access (e.g. $FG_HOME/Export). See [[IORules]] and [[$FG_HOME]]

== Install on Windows ==
In general, you'll want to follow the above install section. This section lists some additional Windows particularities.

Osm2city is pure python.

https://www.python.org/downloads/release/python-278/

{{caution|Python 2.7 is recommended unless you're an experienced Python developer willing to update the Python scripts to support Python 3. Also pay attention to versions and cpu builds of the below helper files. Make sure they match your OS build and Python version.}}

Install the following packages, then proceed with [[Osm2city.py#Install|step 2. above]].

http://www.lfd.uci.edu/~gohlke/pythonlibs/#numpy

http://www.lfd.uci.edu/~gohlke/pythonlibs/#shapely

http://www.lfd.uci.edu/~gohlke/pythonlibs/#scipy-stack

https://pypi.python.org/pypi/Pillow/2.5.0#downloads

== Workflow ==
There are five main steps:
* get OSM data
* adjust input file
* if neccessary, create elevation grid and run FG to probe elevation data.
* run osm2city
* <del>install the generated scenery</del>installs itself

We'll now walk through these steps in detail:
=== get OSM data ===
* decide on a region you want to populate. Get its lon/lat coordinates.
* create a project directory. We will use LOWI/ in this example.
* get corresponding OSM data in its native .xml format.
There are several options to get OSM data. You may find the [http://harrywood.co.uk/maps/uixapi/xapi.html XAPI Query Builder] helpful, it will generate a download URL that you can fetch with wget:
wget -O buildings.osm http://www.overpass-api.de/api/xapi?map?bbox=11.16898,47.20837,11.79108,47.38161

If you use [http://wiki.openstreetmap.org/wiki/Osmosis Osmosis] and cut the area with ''--bounding-box'' then you need to use ''completeWays=yes''.

Put this data into LOWI/buildings.osm

=== Adjust input file ===
* Now adjust the input file. You can generate a commented default parameters file by
<syntaxhighlight lang="bash">
parameters.py -d > LOWI/params.ini
</syntaxhighlight>

Edit this file, adjusting (at least) the following:
:* PREFIX = "LOWI" (the project directory)
:* BOUNDARY_EAST, BOUNDARY_NORTH, BOUNDARY_SOUTH, BOUNDARY_WEST
:* OSM_FILE = "buildings.osm"
:* set PATH_TO_SCENERY to a standard [[$FG_SCENERY]] path. This is the path where we'll get the elevation from. Most likely you'll want to use your TerraSync path here. Suppose the area you want to populate is /home/user/fgfs/scenery/TerraSync/Objects/e010n40/e011n47/, PATH_TO_SCENERY would then be "/home/user/fgfs/scenery/TerraSync" .
:* set PATH_TO_OUTPUT to a ''different'' scenery path, e.g. "/home/user/fgfs/scenery/osm2city" . Osm2city will generate its objects there. First, this avoids TerraSync overwriting the generated scenery. Second, you can easily remove that folder in case you're not happy with the result. Make sure to include that path in your [[$FG_SCENERY]].
:* you might want to set MAX_OBJECTS to a small number (say, 100) for your first try. This will limit the number of buildings parsed, and speed up the whole process.
:* you also need to set up elevation probing in the parameters file, described in the next section.

{{note|Python does not recognize environment variables, please use full paths in the parameters file (no $HOME etc).}}

=== Probe elevation ===
Probe elevation for your region. Pick one of the three available modes for ELEV_MODE in params.ini. If you have enough memory (4GB should be fine, but YMMV) and run FG git later than 10 Oct 2014, try FgelevCaching. Failing that, try Manual. (portreekid, what's the 3rd mode good for?)

{{caution|1=There are a lot of problems reported currently with fgelev. I can't really test for the next month or so. See troubleshooting or use ELEV_MODE = "Manual".}}

* ELEV_MODE = "FgelevCaching"
:* Set FG_ELEV to your fgelev executable. For example: FG_ELEV = "/usr/local/fg/bin/fgelev" or just FG_ELEV = "fgelev" if fgelev is already in your OS's path.
:* Set PATH_TO_SCENERY (Missing terrain will result in error message)
:* make sure the environment variable [[$FG ROOT]] points to your FG base path, (e.g. export FG_ROOT=/usr/share/games/flightgear/ on Linux)

* ELEV_MODE = "Manual"
:* run tools.py (tools.py -f LOWI/params.ini), this will create a file elev.in. Copy elev.in to $FG_ROOT/Nasal/
:* Open $FG_ROOT/Nasal/elev.nas in a text editor. Point the in variable to your elev.in file e.g. var in = "/path/to/$FG_ROOT/Nasal/elev.in".
:* tools.py will tell you to hide a certain scenery/Objects/... folder, to prevent probing elevation on top of existing objects. Simply rename the folder
:* run FG, open debug->nasal console, enter: elev.get_elevation(), press execute. Might take a long time, depending on the area scanned. This will write elevation data to /tmp/elev.out (which is actually just plain 5 column data: lon,lat,x,y,elevation). Put elev.out into LOWI/
:* unhide, rename the objects folder

* ELEV_MODE = "Telnet"
:* Run setup.py
:* Start FG with the properties service on Port 5501
:* Run tools.py, this will create a elev.in, start the nasal script and copy the elev.out back to your project directory

=== Run osm2city ===
* Make sure you're in osm2city's directory and run

python osm2city.py -f LOWI/params.ini.

The parsed OSM data is cached to file LOWI/buildings.osm.pkl which is used on next startup if you set USE_PKL = 1.
If all goes well, files like LOWIcity0101.ac and their corresponding .xml, along with .stg files, were created and moved to the correct location in $FG_SCENERY
* copy or link the tex/ folder into the objects folder where these files were created

=== Roads ===
* run roads.py in the same fashion for roads
* <del>copy roads.eff to the same Objects\e0XXnXX\e0XXnXX\ directory</del> roads.eff is copied automatically
* Band-aid fix for the roads is to adjust their height in roads.py change AGL_ofs to a higher number e.g. 0.5
* the moving cars (TRAFFIC_SHADER_ENABLE = True) are only visible when you disable Atmospheric light scattering (ALS)

== Support and troubleshooting ==
Time permitting, we can provide limited support on the [http://forum.flightgear.org/viewtopic.php?f=5&t=22809 Forums]. Please don't use PM for support questions.

Before you ask a question, make sure you read this wiki page. If your question is not covered here, tell us as much as possible about the problem you're facing. Which steps have you taken to solve it? What is the exact error message? What operating system? Screenshots?

We will not cover general questions like "I don't know how to install XY" -- search the Internet.

=== FGElev crashes ===

<syntaxhighlight lang="bash">
CRITICAL:root:1173 -95.5767 37.0965
CRITICAL:root:fgelev returned <>, resulting in list index out of range. Did fgelev start OK (Record : 1173)?
</syntaxhighlight>
The first line is the last input to fgelev.
Try running fgelev directly:
<syntaxhighlight lang="bash">
/path/to/fgelev --expire 1000 --fg-root $FG_ROOT --fg-scenery $FG_SCENERY
</syntaxhighlight>
then enter the line last sent to fgelev.
<syntaxhighlight lang="bash">
1173 -95.5767 37.0965
</syntaxhighlight>
The response should look like
<syntaxhighlight lang="bash">
1173: 226.793
</syntaxhighlight>

=== Buildings are generated, but they sit below the ground. I'm using ELEV_MODE = FgelevCaching. ===

Try running fgelev directly:
<syntaxhighlight lang="bash">
/path/to/fgelev --expire 1000 --fg-root $FG_ROOT --fg-scenery $FG_SCENERY
</syntaxhighlight>
then enter
<syntaxhighlight lang="bash">
0 $lon $lat
</syntaxhighlight>
where $lon and $lat are coordinates in the area you want to generate. See if it returns a sane value. If it does, double-check PATH_TO_SCENERY and $FG_ROOT.

=== Buildings/roads have no texture. I get errors "osgDB ac3d reader: could not find texture "tex/atlas_facades.png". ===

Copy or link the tex/ folder into the objects folder where the .stg files were created, such that you have $FG_SCENERY/Objects/eXXXnXX/eXXXnXX/tex/. Note that buildings might have been created in more than one folder, e.g. in e011n47 and e011n48. You must have a tex/ folder in each of them. On Windows it is sufficient to have one copy in $FG_ROOT.

== Improve frame rate ==
* adjust LOD ranges in FG
* decrease MAX_OBJECTS, increase LOD_*
(- use larger/smaller tiles? Tradeoff between distance calculations/xml parsing and GPU)

== Contributing ==
You know some python? Or you're keen on writing docs? Contact radi on the FG forum.
None of the above? Take [[Howto:Create_textures_from_photos|pictures]] of buildings where you live and [[Osm2city.py Textures|create textures]]! I'm especially interested in south-east asian style architecture, as I'm planning to populate Hong Kong Kai Tak (VHXX) in the future.

== Related ==
* [[Using OSM Vector Data in FlightGear]]
* [[OpenStreetMap buildings]]
* [[AutoGen Scenery for FlightGear]]
* [[Random Buildings]]
* [http://forum.flightgear.org/viewtopic.php?f=5&t=21131#p192198 OSM buidings EHLE]
* [http://forum.flightgear.org/viewtopic.php?f=5&t=22809 osm2city.py development]
* [http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg40092.html Osm2city.py]
* http://forum.flightgear.org/viewtopic.php?f=5&t=19625
* [http://forum.flightgear.org/viewtopic.php?f=38&t=8837 PixelCity]
* [http://forum.flightgear.org/viewtopic.php?p=166794#p166681 Procedural OSM buildings]

[[Category:Scenery software]]

Wingflexer

2015-03-12T13:44:23Z

Radi: add animated gif

[[File:787 wing flex hard landing.gif|thumb|Wingflex after a touchdown at 9 ft/s on a 787-8.]]

Wings of large aspect ratio tend to behave similar to a spring. They bend under load and oscillate for a while when the load changes, for example in a turn, during turbulence, or on touchdown. This article describes the Wingflexer module, which aims at animating the 3-D model of a wing in a somewhat realistic fashion. The method used is a significant improvement over what has been described [[Howto:Implement_wing_flex|here]]. However, the actual model animation part is identical and will not be covered.

Including this in your aircraft is fairly straightforward, but obtaining plausible parameters can require some research and trial-and-error. We will give an example (the 787) below.

Introduced in FG 3.5, there are two implementations available. The first, which this article is focused on, uses autopilot/property rules. It is therefore very optimized and should be your first choice. The second implementation uses Nasal. It is a bit more flexible in the sense that it could also be applied to AI aircraft.

== Physical model ==
This section describes the physical model. You don't need to fully understand the maths here to be able to use Wingflexer, but you should understand the parameters involved -- you will need to adapt them to your aircraft.

We use a simple spring-mass-damper system sketched below to model a flexible wing:
--> |<---- z --->|
g
+-----+ +-----+
<--- | m_w |---/\/\/\---| |
+-----+ +-----+
Lift wing spring fuselage
force mass

The wing's motion, measured by the deflection z(t), is governed by the following parameters:

k wing stiffness
d damping
m_w = m_dw + fuel_frac * m_fuel
Total wing mass. Because the fuel is distributed over the wing, we use
a fraction of the fuel mass in the calculation.
0.5*F_L lift force/2 (we look at one wing only)
..
z_f acceleration of the frame of reference (fuselage)

We integrate the equation of motion
.. k d . 0.5*F_L ..
0 = -z + --- z + ---- z - ------- - g - z_f
m_w m_w m_w
and write the deflection (z + z_ofs) in meters to /sim/systems/wingflexer/z-m.
The offset z_ofs is calculated automatically and ensures that the dry wing
(which still has a non-zero mass) creates a neutral deflection.

Discretisation by first order finite differences leads to
z_0 - 2 z_1 + z_2 k d (z_0 - z_1) 1/2 F_L ..
----------------- + --- z_1 + --- ----------- - ------- - g - z_f = 0
dt^2 m_w m_w dt m_w
It is convenient to divide k and d by a (constant) reference mass:
K = k / m_dw
D = d / m_dw

== Obtaining plausible parameters ==
To make our model produce a convinving dynamic behaviour, you will need to obtain estimates and fine-tune the parameters.

These include the wing mass m_w, the wing stiffness K, the damping D, and a scaling factor z_fac.
There's a python script wingflexer.py which assists you in fine-tuning. It will quickly simulate the dynamics of the model with your parameters.
So how to estimate the parameters?

1. Assume a dry wing mass m_dw. Research the wing fuel mass m_fuel.

2. Obtain estimates of
* the deflection z_flight in level flight, e.g by comparing photos of the real aircraft on ground and in air,
* the wing's natural frequency, perhaps from videos of the wing's oscillation in turbulence,
* the deflection with full and empty tanks while sitting on the ground.

3. Compute K to match in-flight deflection with full tanks:
K = g * (m_ac / 2 - (fuel_frac * m_fuel)) / (z_in_flight / z_fac) / m_dw
where
m_ac aircraft mass
g 9.81 m/s^2
z_fac scaling factor for the deflection, start with 1

4. Compute the natural frequency of this system for full and empty wing tanks:
f_full = sqrt(K * m_dw / (m_dw + fuel_frac * m_fuel)) / (2 pi)
f_empty = sqrt(K) / (2 pi)

Ideally we want our model to match the wing's natural frequency, the wing's deflection
while sitting on the ground with full or empty tanks, and the deflection (bounce)
during a hard landing. Getting real-world data for the latter is difficult.

Here are some relations:
* a lower wing mass increases the natural frequency, and weakens the touchdown bounce
* a higher stiffness K reduces the deflection and increases the natural frequency

== Enable developer options ==
By default, Wingflexer and the user-tunable parameters live in
/sim/systems/wingflexer/
/sim/systems/wingflexer/params/

There are two properties disabled by default which are only useful when you're tuning the parameters. To enable them, uncomment the developer section in Aircraft/Generic/wingflexer.xml.
This will activate
/sim/systems/wingflexer/params/z-fac
/sim/systems/wingflexer/sink-rate-fps
Z-fac simply scales the output. Once you're happy with the results, include this factor in the animation.
Sink-rate-fps allows you to simulate a touchdown at given vertical speed.

It will become clear in the next section why these two settings are useful.

== An example: the 787 ==
The 787 is known for its very flexible wings; the deflection in
unaccelerated flight is quoted as z = 3 m. One wing tank of FG's 787-8 holds
23,000 kg of fuel. Because the fuel is distributed over the wing, we use a
fraction of the fuel mass in the calculation: fuel_frac = 0.75. For the same reason
we don't use the true wing mass, but rather something that makes our model look
plausible.

So assuming a wing mass of 12000 kg, we get K=25.9 and f_empty = 0.5 Hz.
That frequency might be a bit low, videos of a 777 wing in turbulence show about
2-3 Hz. (I didn't research 787 videos).

To increase it, we could either reduce m_dw or increase K. A lower m_dw results
in a rather weak bounce on touchdown which might look odd. A higher K reduces
the deflection z_flight, but we can simply scale the animation to account for
that. We'll multiply the deflection z by a factor z_fac to get an angle for the
<rotate> animation later on anyway. So repeat 3. and 4. using e.g. z_fac = 10.
Now K = 259 and f_empty=2.6 Hz. While our model spring now only deflects
to 0.3 m instead of 3 m, the animation scale factor will make sure the wing
bends to 3 m. This way, we can match both natural frequency and observed deflection,
and still get a realistic bounce on touch down. Finally, adjust D such that an
impulse is damped out after about one or two oscillations; D = 12 seems to work
OK in our example.

It's difficult to get real-world data on the deflection during touchdown.
Touchdown at more than 10 ft/s is considered a hard landing and could result in some significant wing bending.
There's a video of a hard landing of an A346 (http://avherald.com/h?article=471e70e9), showing the
wings bend perhaps 1 m.

To assist you in tuning parameters for the touchdown bounce you can initialize your
wing mass with a (touchdown) vertical speed via /sim/systems/wingflexer/sink-rate-fps, and then observe the deflection and oscillation. This avoids you having to fly too many touch-and-go's while developing ;)

Finally, our model outputs the deflection in meters, but the <rotate> animation expects an
angle. It is up to you convert appropriately, depending on your wing
span and number of segments in the animation. Also don't forget to include z_fac.

== How to add to your aircraft ==
Create a file $YourAircraft/Systems/wingflexer-params.xml which contains the parameters adjusted to your aircraft
<?xml version="1.0" encoding="UTF-8"?>
<PropertyList>
<params>
<m-wing-dry-kg type="double">12000.</m-wing-dry-kg>
<K type="double">259.</K>
<D type="double">12.</D>
<fuel-frac type="double">0.375</fuel-frac>
<lift-node-lbs alias="/fdm/jsbsim/forces/fbz-aero-lbs"/>
<fuel-node-1-kg alias="/consumables/fuel/tank/level-kg"/>
<fuel-node-2-kg alias="/consumables/fuel/tank[1]/level-kg"/>
<fuel-node-3-kg type="double">0.</fuel-node-3-kg>
<fuel-node-4-kg type="double">0.</fuel-node-4-kg>
</params>
</PropertyList>
Also adjust the property node aliases for the wing fuel tanks. Wingflexer supports up to four tanks in total. Since we're currently only solving one equation and hence get only one deflection which is used for both wings, we have to average the wing mass. Internally, m_fuel is simply the sum of all given fuel nodes,
m_fuel = fuel-node-1-kg + fuel-node-2-kg + fuel-node-3-kg + fuel-node-4-kg
so you must include the weighting factor in fuel-frac (e.g. 1/2 if you provide 2 fuel nodes). If you have more than 4 wing tanks in total, use another property rule to compute the average.

In $yourAircraft-set.xml, in <systems> section, load the parameters and the wingflexer module:
<systems>
<wingflexer include="Systems/wingflexer-params.xml"/>
<property-rule n="100">
<name>wing flexer property rule</name>
<path>Aircraft/Generic/wingflexer.xml</path>
</property-rule>
</systems>

The wingflexer writes the deflection to /sim/systems/wingflexer/z-m.
Finally, your model rotate animation has to pick it up and multiply it by z_fac
<animation>
<type>rotate</type>
<property>sim/systems/wingflexer/z-m</property>
<factor>10.</factor>
...
</animation>

If your aircraft uses JSBSim, you're done now. Yasim requires an extra step, described next.

== Yasim ==
Yasim does not write the lift to the property tree. But you can create a helper
function which computes the lift as
lift_force_lbs = aircraft_weight_lbs * load_factor - total_weight_on_wheels_lbs
and point the <lift-node-lbs> alias in wingflexer-params.xml to it.

== Implementation details ==
=== Autopilot/Property rules implementation ===
Code lives in Aircraft/Generic/wingflexer.xml

The ODE x" + ax' + bx + c = 0 is integrated by DampedOsciFilterImplementation in FG/src/autopilot/digitalfilter.cxx.

=== Nasal implementation ===
Code lives in Aircraft/Generic/wingflexer.nas, see comment therein.

== TODO ==
* write Yasim helper
* input for fuselage acceleration should rather be acceleration at CG instead of the pilot's location -- is there a property?
* add wingflexer.py (to where?)

[[Category:FlightGear feature]]

File:787 wing flex hard landing.gif

2015-03-12T13:39:55Z

Radi: User created page with UploadWizard

=={{int:filedesc}}==
{{Information
|description={{en|1=Wingflex after a rather hard touchdown (9 ft/s) on a 787-8.}}
|date=2015-03-13 00:35:34
|source={{own}}
|author=[[User:Radi|Radi]]
|permission=
|other versions=
}}

=={{int:license-header}}==
{{self|cc-by-sa-4.0}}

Wingflexer

2015-03-11T10:26:08Z

Radi: /* Enable developer options */ fix sink-rate-fps path

Wings of large aspect ratio tend to behave similar to a spring. They bend under load and oscillate for a while when the load changes, for example in a turn, during turbulence, or on touchdown. This article describes the Wingflexer module, which aims at animating the 3-D model of a wing in a somewhat realistic fashion. The method used is a significant improvement over what has been described [[Howto:Implement_wing_flex|here]]. However, the actual model animation part is identical and will not be covered.

Including this in your aircraft is fairly straightforward, but obtaining plausible parameters can require some research and trial-and-error. We will give an example (the 787) below.

Introduced in FG 3.5, there are two implementations available. The first, which this article is focused on, uses autopilot/property rules. It is therefore very optimized and should be your first choice. The second implementation uses Nasal. It is a bit more flexible in the sense that it could also be applied to AI aircraft.

== Physical model ==
This section describes the physical model. You don't need to fully understand the maths here to be able to use Wingflexer, but you should understand the parameters involved -- you will need to adapt them to your aircraft.

We use a simple spring-mass-damper system sketched below to model a flexible wing:
--> |<---- z --->|
g
+-----+ +-----+
<--- | m_w |---/\/\/\---| |
+-----+ +-----+
Lift wing spring fuselage
force mass

The wing's motion, measured by the deflection z(t), is governed by the following parameters:

k wing stiffness
d damping
m_w = m_dw + fuel_frac * m_fuel
Total wing mass. Because the fuel is distributed over the wing, we use
a fraction of the fuel mass in the calculation.
0.5*F_L lift force/2 (we look at one wing only)
..
z_f acceleration of the frame of reference (fuselage)

We integrate the equation of motion
.. k d . 0.5*F_L ..
0 = -z + --- z + ---- z - ------- - g - z_f
m_w m_w m_w
and write the deflection (z + z_ofs) in meters to /sim/systems/wingflexer/z-m.
The offset z_ofs is calculated automatically and ensures that the dry wing
(which still has a non-zero mass) creates a neutral deflection.

Discretisation by first order finite differences leads to
z_0 - 2 z_1 + z_2 k d (z_0 - z_1) 1/2 F_L ..
----------------- + --- z_1 + --- ----------- - ------- - g - z_f = 0
dt^2 m_w m_w dt m_w
It is convenient to divide k and d by a (constant) reference mass:
K = k / m_dw
D = d / m_dw

== Obtaining plausible parameters ==
To make our model produce a convinving dynamic behaviour, you will need to obtain estimates and fine-tune the parameters.

These include the wing mass m_w, the wing stiffness K, the damping D, and a scaling factor z_fac.
There's a python script wingflexer.py which assists you in fine-tuning. It will quickly simulate the dynamics of the model with your parameters.
So how to estimate the parameters?

1. Assume a dry wing mass m_dw. Research the wing fuel mass m_fuel.

2. Obtain estimates of
* the deflection z_flight in level flight, e.g by comparing photos of the real aircraft on ground and in air,
* the wing's natural frequency, perhaps from videos of the wing's oscillation in turbulence,
* the deflection with full and empty tanks while sitting on the ground.

3. Compute K to match in-flight deflection with full tanks:
K = g * (m_ac / 2 - (fuel_frac * m_fuel)) / (z_in_flight / z_fac) / m_dw
where
m_ac aircraft mass
g 9.81 m/s^2
z_fac scaling factor for the deflection, start with 1

4. Compute the natural frequency of this system for full and empty wing tanks:
f_full = sqrt(K * m_dw / (m_dw + fuel_frac * m_fuel)) / (2 pi)
f_empty = sqrt(K) / (2 pi)

Ideally we want our model to match the wing's natural frequency, the wing's deflection
while sitting on the ground with full or empty tanks, and the deflection (bounce)
during a hard landing. Getting real-world data for the latter is difficult.

Here are some relations:
* a lower wing mass increases the natural frequency, and weakens the touchdown bounce
* a higher stiffness K reduces the deflection and increases the natural frequency

== Enable developer options ==
By default, Wingflexer and the user-tunable parameters live in
/sim/systems/wingflexer/
/sim/systems/wingflexer/params/

There are two properties disabled by default which are only useful when you're tuning the parameters. To enable them, uncomment the developer section in Aircraft/Generic/wingflexer.xml.
This will activate
/sim/systems/wingflexer/params/z-fac
/sim/systems/wingflexer/sink-rate-fps
Z-fac simply scales the output. Once you're happy with the results, include this factor in the animation.
Sink-rate-fps allows you to simulate a touchdown at given vertical speed.

It will become clear in the next section why these two settings are useful.

== An example: the 787 ==
The 787 is known for its very flexible wings; the deflection in
unaccelerated flight is quoted as z = 3 m. One wing tank of FG's 787-8 holds
23,000 kg of fuel. Because the fuel is distributed over the wing, we use a
fraction of the fuel mass in the calculation: fuel_frac = 0.75. For the same reason
we don't use the true wing mass, but rather something that makes our model look
plausible.

So assuming a wing mass of 12000 kg, we get K=25.9 and f_empty = 0.5 Hz.
That frequency might be a bit low, videos of a 777 wing in turbulence show about
2-3 Hz. (I didn't research 787 videos).

To increase it, we could either reduce m_dw or increase K. A lower m_dw results
in a rather weak bounce on touchdown which might look odd. A higher K reduces
the deflection z_flight, but we can simply scale the animation to account for
that. We'll multiply the deflection z by a factor z_fac to get an angle for the
<rotate> animation later on anyway. So repeat 3. and 4. using e.g. z_fac = 10.
Now K = 259 and f_empty=2.6 Hz. While our model spring now only deflects
to 0.3 m instead of 3 m, the animation scale factor will make sure the wing
bends to 3 m. This way, we can match both natural frequency and observed deflection,
and still get a realistic bounce on touch down. Finally, adjust D such that an
impulse is damped out after about one or two oscillations; D = 12 seems to work
OK in our example.

It's difficult to get real-world data on the deflection during touchdown.
Touchdown at more than 10 ft/s is considered a hard landing and could result in some significant wing bending.
There's a video of a hard landing of an A346 (http://avherald.com/h?article=471e70e9), showing the
wings bend perhaps 1 m.

To assist you in tuning parameters for the touchdown bounce you can initialize your
wing mass with a (touchdown) vertical speed via /sim/systems/wingflexer/sink-rate-fps, and then observe the deflection and oscillation. This avoids you having to fly too many touch-and-go's while developing ;)

Finally, our model outputs the deflection in meters, but the <rotate> animation expects an
angle. It is up to you convert appropriately, depending on your wing
span and number of segments in the animation. Also don't forget to include z_fac.

== How to add to your aircraft ==
Create a file $YourAircraft/Systems/wingflexer-params.xml which contains the parameters adjusted to your aircraft
<?xml version="1.0" encoding="UTF-8"?>
<PropertyList>
<params>
<m-wing-dry-kg type="double">12000.</m-wing-dry-kg>
<K type="double">259.</K>
<D type="double">12.</D>
<fuel-frac type="double">0.375</fuel-frac>
<lift-node-lbs alias="/fdm/jsbsim/forces/fbz-aero-lbs"/>
<fuel-node-1-kg alias="/consumables/fuel/tank/level-kg"/>
<fuel-node-2-kg alias="/consumables/fuel/tank[1]/level-kg"/>
<fuel-node-3-kg type="double">0.</fuel-node-3-kg>
<fuel-node-4-kg type="double">0.</fuel-node-4-kg>
</params>
</PropertyList>
Also adjust the property node aliases for the wing fuel tanks. Wingflexer supports up to four tanks in total. Since we're currently only solving one equation and hence get only one deflection which is used for both wings, we have to average the wing mass. Internally, m_fuel is simply the sum of all given fuel nodes,
m_fuel = fuel-node-1-kg + fuel-node-2-kg + fuel-node-3-kg + fuel-node-4-kg
so you must include the weighting factor in fuel-frac (e.g. 1/2 if you provide 2 fuel nodes). If you have more than 4 wing tanks in total, use another property rule to compute the average.

In $yourAircraft-set.xml, in <systems> section, load the parameters and the wingflexer module:
<systems>
<wingflexer include="Systems/wingflexer-params.xml"/>
<property-rule n="100">
<name>wing flexer property rule</name>
<path>Aircraft/Generic/wingflexer.xml</path>
</property-rule>
</systems>

The wingflexer writes the deflection to /sim/systems/wingflexer/z-m.
Finally, your model rotate animation has to pick it up and multiply it by z_fac
<animation>
<type>rotate</type>
<property>sim/systems/wingflexer/z-m</property>
<factor>10.</factor>
...
</animation>

If your aircraft uses JSBSim, you're done now. Yasim requires an extra step, described next.

== Yasim ==
Yasim does not write the lift to the property tree. But you can create a helper
function which computes the lift as
lift_force_lbs = aircraft_weight_lbs * load_factor - total_weight_on_wheels_lbs
and point the <lift-node-lbs> alias in wingflexer-params.xml to it.

== Implementation details ==
=== Autopilot/Property rules implementation ===
Code lives in Aircraft/Generic/wingflexer.xml

The ODE x" + ax' + bx + c = 0 is integrated by DampedOsciFilterImplementation in FG/src/autopilot/digitalfilter.cxx.

=== Nasal implementation ===
Code lives in Aircraft/Generic/wingflexer.nas, see comment therein.

== TODO ==
* write Yasim helper
* input for fuselage acceleration should rather be acceleration at CG instead of the pilot's location -- is there a property?
* add wingflexer.py (to where?)

[[Category:FlightGear feature]]

Wingflexer

2015-03-11T00:23:02Z

Radi: /* How to add to your aircraft */ fix m_fuel

Wings of large aspect ratio tend to behave similar to a spring. They bend under load and oscillate for a while when the load changes, for example in a turn, during turbulence, or on touchdown. This article describes the Wingflexer module, which aims at animating the 3-D model of a wing in a somewhat realistic fashion. The method used is a significant improvement over what has been described [[Howto:Implement_wing_flex|here]]. However, the actual model animation part is identical and will not be covered.

Including this in your aircraft is fairly straightforward, but obtaining plausible parameters can require some research and trial-and-error. We will give an example (the 787) below.

Introduced in FG 3.5, there are two implementations available. The first, which this article is focused on, uses autopilot/property rules. It is therefore very optimized and should be your first choice. The second implementation uses Nasal. It is a bit more flexible in the sense that it could also be applied to AI aircraft.

== Physical model ==
This section describes the physical model. You don't need to fully understand the maths here to be able to use Wingflexer, but you should understand the parameters involved -- you will need to adapt them to your aircraft.

We use a simple spring-mass-damper system sketched below to model a flexible wing:
--> |<---- z --->|
g
+-----+ +-----+
<--- | m_w |---/\/\/\---| |
+-----+ +-----+
Lift wing spring fuselage
force mass

The wing's motion, measured by the deflection z(t), is governed by the following parameters:

k wing stiffness
d damping
m_w = m_dw + fuel_frac * m_fuel
Total wing mass. Because the fuel is distributed over the wing, we use
a fraction of the fuel mass in the calculation.
0.5*F_L lift force/2 (we look at one wing only)
..
z_f acceleration of the frame of reference (fuselage)

We integrate the equation of motion
.. k d . 0.5*F_L ..
0 = -z + --- z + ---- z - ------- - g - z_f
m_w m_w m_w
and write the deflection (z + z_ofs) in meters to /sim/systems/wingflexer/z-m.
The offset z_ofs is calculated automatically and ensures that the dry wing
(which still has a non-zero mass) creates a neutral deflection.

Discretisation by first order finite differences leads to
z_0 - 2 z_1 + z_2 k d (z_0 - z_1) 1/2 F_L ..
----------------- + --- z_1 + --- ----------- - ------- - g - z_f = 0
dt^2 m_w m_w dt m_w
It is convenient to divide k and d by a (constant) reference mass:
K = k / m_dw
D = d / m_dw

== Obtaining plausible parameters ==
To make our model produce a convinving dynamic behaviour, you will need to obtain estimates and fine-tune the parameters.

These include the wing mass m_w, the wing stiffness K, the damping D, and a scaling factor z_fac.
There's a python script wingflexer.py which assists you in fine-tuning. It will quickly simulate the dynamics of the model with your parameters.
So how to estimate the parameters?

1. Assume a dry wing mass m_dw. Research the wing fuel mass m_fuel.

2. Obtain estimates of
* the deflection z_flight in level flight, e.g by comparing photos of the real aircraft on ground and in air,
* the wing's natural frequency, perhaps from videos of the wing's oscillation in turbulence,
* the deflection with full and empty tanks while sitting on the ground.

3. Compute K to match in-flight deflection with full tanks:
K = g * (m_ac / 2 - (fuel_frac * m_fuel)) / (z_in_flight / z_fac) / m_dw
where
m_ac aircraft mass
g 9.81 m/s^2
z_fac scaling factor for the deflection, start with 1

4. Compute the natural frequency of this system for full and empty wing tanks:
f_full = sqrt(K * m_dw / (m_dw + fuel_frac * m_fuel)) / (2 pi)
f_empty = sqrt(K) / (2 pi)

Ideally we want our model to match the wing's natural frequency, the wing's deflection
while sitting on the ground with full or empty tanks, and the deflection (bounce)
during a hard landing. Getting real-world data for the latter is difficult.

Here are some relations:
* a lower wing mass increases the natural frequency, and weakens the touchdown bounce
* a higher stiffness K reduces the deflection and increases the natural frequency

== Enable developer options ==
By default, Wingflexer and the user-tunable parameters live in
/sim/systems/wingflexer/
/sim/systems/wingflexer/params/

There are two properties disabled by default which are only useful when you're tuning the parameters. To enable them, uncomment the developer section in Aircraft/Generic/wingflexer.xml.
This will activate
/sim/systems/wingflexer/params/z-fac
/sim/systems/wingflexer/params/sink-rate-fps
Z-fac simply scales the output. Once you're happy with the results, include this factor in the animation.
Sink-rate-fps allows you to simulate a touchdown at given vertical speed.

It will become clear in the next section why these two settings are useful.

== An example: the 787 ==
The 787 is known for its very flexible wings; the deflection in
unaccelerated flight is quoted as z = 3 m. One wing tank of FG's 787-8 holds
23,000 kg of fuel. Because the fuel is distributed over the wing, we use a
fraction of the fuel mass in the calculation: fuel_frac = 0.75. For the same reason
we don't use the true wing mass, but rather something that makes our model look
plausible.

So assuming a wing mass of 12000 kg, we get K=25.9 and f_empty = 0.5 Hz.
That frequency might be a bit low, videos of a 777 wing in turbulence show about
2-3 Hz. (I didn't research 787 videos).

To increase it, we could either reduce m_dw or increase K. A lower m_dw results
in a rather weak bounce on touchdown which might look odd. A higher K reduces
the deflection z_flight, but we can simply scale the animation to account for
that. We'll multiply the deflection z by a factor z_fac to get an angle for the
<rotate> animation later on anyway. So repeat 3. and 4. using e.g. z_fac = 10.
Now K = 259 and f_empty=2.6 Hz. While our model spring now only deflects
to 0.3 m instead of 3 m, the animation scale factor will make sure the wing
bends to 3 m. This way, we can match both natural frequency and observed deflection,
and still get a realistic bounce on touch down. Finally, adjust D such that an
impulse is damped out after about one or two oscillations; D = 12 seems to work
OK in our example.

It's difficult to get real-world data on the deflection during touchdown.
Touchdown at more than 10 ft/s is considered a hard landing and could result in some significant wing bending.
There's a video of a hard landing of an A346 (http://avherald.com/h?article=471e70e9), showing the
wings bend perhaps 1 m.

To assist you in tuning parameters for the touchdown bounce you can initialize your
wing mass with a (touchdown) vertical speed via /sim/systems/wingflexer/sink-rate-fps, and then observe the deflection and oscillation. This avoids you having to fly too many touch-and-go's while developing ;)

Finally, our model outputs the deflection in meters, but the <rotate> animation expects an
angle. It is up to you convert appropriately, depending on your wing
span and number of segments in the animation. Also don't forget to include z_fac.

== How to add to your aircraft ==
Create a file $YourAircraft/Systems/wingflexer-params.xml which contains the parameters adjusted to your aircraft
<?xml version="1.0" encoding="UTF-8"?>
<PropertyList>
<params>
<m-wing-dry-kg type="double">12000.</m-wing-dry-kg>
<K type="double">259.</K>
<D type="double">12.</D>
<fuel-frac type="double">0.375</fuel-frac>
<lift-node-lbs alias="/fdm/jsbsim/forces/fbz-aero-lbs"/>
<fuel-node-1-kg alias="/consumables/fuel/tank/level-kg"/>
<fuel-node-2-kg alias="/consumables/fuel/tank[1]/level-kg"/>
<fuel-node-3-kg type="double">0.</fuel-node-3-kg>
<fuel-node-4-kg type="double">0.</fuel-node-4-kg>
</params>
</PropertyList>
Also adjust the property node aliases for the wing fuel tanks. Wingflexer supports up to four tanks in total. Since we're currently only solving one equation and hence get only one deflection which is used for both wings, we have to average the wing mass. Internally, m_fuel is simply the sum of all given fuel nodes,
m_fuel = fuel-node-1-kg + fuel-node-2-kg + fuel-node-3-kg + fuel-node-4-kg
so you must include the weighting factor in fuel-frac (e.g. 1/2 if you provide 2 fuel nodes). If you have more than 4 wing tanks in total, use another property rule to compute the average.

In $yourAircraft-set.xml, in <systems> section, load the parameters and the wingflexer module:
<systems>
<wingflexer include="Systems/wingflexer-params.xml"/>
<property-rule n="100">
<name>wing flexer property rule</name>
<path>Aircraft/Generic/wingflexer.xml</path>
</property-rule>
</systems>

The wingflexer writes the deflection to /sim/systems/wingflexer/z-m.
Finally, your model rotate animation has to pick it up and multiply it by z_fac
<animation>
<type>rotate</type>
<property>sim/systems/wingflexer/z-m</property>
<factor>10.</factor>
...
</animation>

If your aircraft uses JSBSim, you're done now. Yasim requires an extra step, described next.

== Yasim ==
Yasim does not write the lift to the property tree. But you can create a helper
function which computes the lift as
lift_force_lbs = aircraft_weight_lbs * load_factor - total_weight_on_wheels_lbs
and point the <lift-node-lbs> alias in wingflexer-params.xml to it.

== Implementation details ==
=== Autopilot/Property rules implementation ===
Code lives in Aircraft/Generic/wingflexer.xml

The ODE x" + ax' + bx + c = 0 is integrated by DampedOsciFilterImplementation in FG/src/autopilot/digitalfilter.cxx.

=== Nasal implementation ===
Code lives in Aircraft/Generic/wingflexer.nas, see comment therein.

== TODO ==
* write Yasim helper
* input for fuselage acceleration should rather be acceleration at CG instead of the pilot's location -- is there a property?
* add wingflexer.py (to where?)

[[Category:FlightGear feature]]

Wingflexer

2015-03-11T00:19:04Z

Radi: nasal implementation, link

Wings of large aspect ratio tend to behave similar to a spring. They bend under load and oscillate for a while when the load changes, for example in a turn, during turbulence, or on touchdown. This article describes the Wingflexer module, which aims at animating the 3-D model of a wing in a somewhat realistic fashion. The method used is a significant improvement over what has been described [[Howto:Implement_wing_flex|here]]. However, the actual model animation part is identical and will not be covered.

Including this in your aircraft is fairly straightforward, but obtaining plausible parameters can require some research and trial-and-error. We will give an example (the 787) below.

Introduced in FG 3.5, there are two implementations available. The first, which this article is focused on, uses autopilot/property rules. It is therefore very optimized and should be your first choice. The second implementation uses Nasal. It is a bit more flexible in the sense that it could also be applied to AI aircraft.

== Physical model ==
This section describes the physical model. You don't need to fully understand the maths here to be able to use Wingflexer, but you should understand the parameters involved -- you will need to adapt them to your aircraft.

We use a simple spring-mass-damper system sketched below to model a flexible wing:
--> |<---- z --->|
g
+-----+ +-----+
<--- | m_w |---/\/\/\---| |
+-----+ +-----+
Lift wing spring fuselage
force mass

The wing's motion, measured by the deflection z(t), is governed by the following parameters:

k wing stiffness
d damping
m_w = m_dw + fuel_frac * m_fuel
Total wing mass. Because the fuel is distributed over the wing, we use
a fraction of the fuel mass in the calculation.
0.5*F_L lift force/2 (we look at one wing only)
..
z_f acceleration of the frame of reference (fuselage)

We integrate the equation of motion
.. k d . 0.5*F_L ..
0 = -z + --- z + ---- z - ------- - g - z_f
m_w m_w m_w
and write the deflection (z + z_ofs) in meters to /sim/systems/wingflexer/z-m.
The offset z_ofs is calculated automatically and ensures that the dry wing
(which still has a non-zero mass) creates a neutral deflection.

Discretisation by first order finite differences leads to
z_0 - 2 z_1 + z_2 k d (z_0 - z_1) 1/2 F_L ..
----------------- + --- z_1 + --- ----------- - ------- - g - z_f = 0
dt^2 m_w m_w dt m_w
It is convenient to divide k and d by a (constant) reference mass:
K = k / m_dw
D = d / m_dw

== Obtaining plausible parameters ==
To make our model produce a convinving dynamic behaviour, you will need to obtain estimates and fine-tune the parameters.

These include the wing mass m_w, the wing stiffness K, the damping D, and a scaling factor z_fac.
There's a python script wingflexer.py which assists you in fine-tuning. It will quickly simulate the dynamics of the model with your parameters.
So how to estimate the parameters?

1. Assume a dry wing mass m_dw. Research the wing fuel mass m_fuel.

2. Obtain estimates of
* the deflection z_flight in level flight, e.g by comparing photos of the real aircraft on ground and in air,
* the wing's natural frequency, perhaps from videos of the wing's oscillation in turbulence,
* the deflection with full and empty tanks while sitting on the ground.

3. Compute K to match in-flight deflection with full tanks:
K = g * (m_ac / 2 - (fuel_frac * m_fuel)) / (z_in_flight / z_fac) / m_dw
where
m_ac aircraft mass
g 9.81 m/s^2
z_fac scaling factor for the deflection, start with 1

4. Compute the natural frequency of this system for full and empty wing tanks:
f_full = sqrt(K * m_dw / (m_dw + fuel_frac * m_fuel)) / (2 pi)
f_empty = sqrt(K) / (2 pi)

Ideally we want our model to match the wing's natural frequency, the wing's deflection
while sitting on the ground with full or empty tanks, and the deflection (bounce)
during a hard landing. Getting real-world data for the latter is difficult.

Here are some relations:
* a lower wing mass increases the natural frequency, and weakens the touchdown bounce
* a higher stiffness K reduces the deflection and increases the natural frequency

== Enable developer options ==
By default, Wingflexer and the user-tunable parameters live in
/sim/systems/wingflexer/
/sim/systems/wingflexer/params/

There are two properties disabled by default which are only useful when you're tuning the parameters. To enable them, uncomment the developer section in Aircraft/Generic/wingflexer.xml.
This will activate
/sim/systems/wingflexer/params/z-fac
/sim/systems/wingflexer/params/sink-rate-fps
Z-fac simply scales the output. Once you're happy with the results, include this factor in the animation.
Sink-rate-fps allows you to simulate a touchdown at given vertical speed.

It will become clear in the next section why these two settings are useful.

== An example: the 787 ==
The 787 is known for its very flexible wings; the deflection in
unaccelerated flight is quoted as z = 3 m. One wing tank of FG's 787-8 holds
23,000 kg of fuel. Because the fuel is distributed over the wing, we use a
fraction of the fuel mass in the calculation: fuel_frac = 0.75. For the same reason
we don't use the true wing mass, but rather something that makes our model look
plausible.

So assuming a wing mass of 12000 kg, we get K=25.9 and f_empty = 0.5 Hz.
That frequency might be a bit low, videos of a 777 wing in turbulence show about
2-3 Hz. (I didn't research 787 videos).

To increase it, we could either reduce m_dw or increase K. A lower m_dw results
in a rather weak bounce on touchdown which might look odd. A higher K reduces
the deflection z_flight, but we can simply scale the animation to account for
that. We'll multiply the deflection z by a factor z_fac to get an angle for the
<rotate> animation later on anyway. So repeat 3. and 4. using e.g. z_fac = 10.
Now K = 259 and f_empty=2.6 Hz. While our model spring now only deflects
to 0.3 m instead of 3 m, the animation scale factor will make sure the wing
bends to 3 m. This way, we can match both natural frequency and observed deflection,
and still get a realistic bounce on touch down. Finally, adjust D such that an
impulse is damped out after about one or two oscillations; D = 12 seems to work
OK in our example.

It's difficult to get real-world data on the deflection during touchdown.
Touchdown at more than 10 ft/s is considered a hard landing and could result in some significant wing bending.
There's a video of a hard landing of an A346 (http://avherald.com/h?article=471e70e9), showing the
wings bend perhaps 1 m.

To assist you in tuning parameters for the touchdown bounce you can initialize your
wing mass with a (touchdown) vertical speed via /sim/systems/wingflexer/sink-rate-fps, and then observe the deflection and oscillation. This avoids you having to fly too many touch-and-go's while developing ;)

Finally, our model outputs the deflection in meters, but the <rotate> animation expects an
angle. It is up to you convert appropriately, depending on your wing
span and number of segments in the animation. Also don't forget to include z_fac.

== How to add to your aircraft ==
Create a file $YourAircraft/Systems/wingflexer-params.xml which contains the parameters adjusted to your aircraft
<?xml version="1.0" encoding="UTF-8"?>
<PropertyList>
<params>
<m-wing-dry-kg type="double">12000.</m-wing-dry-kg>
<K type="double">259.</K>
<D type="double">12.</D>
<fuel-frac type="double">0.375</fuel-frac>
<lift-node-lbs alias="/fdm/jsbsim/forces/fbz-aero-lbs"/>
<fuel-node-1-kg alias="/consumables/fuel/tank/level-kg"/>
<fuel-node-2-kg alias="/consumables/fuel/tank[1]/level-kg"/>
<fuel-node-3-kg type="double">0.</fuel-node-3-kg>
<fuel-node-4-kg type="double">0.</fuel-node-4-kg>
</params>
</PropertyList>
Also adjust the property node aliases for the wing fuel tanks. Wingflexer supports up to four tanks in total. Since we're currently only solving one equation and hence get only one deflection which is used for both wings, we have to average the wing mass. This is done by
m_fuel = fuel-frac * (fuel-node-1-kg + fuel-node-2-kg + fuel-node-3-kg + fuel-node-4-kg).
Include the weighting factor in fuel-frac (e.g. 1/2 if you provide 2 fuel nodes). If you have more than 4 wing tanks in total, use another property rule to compute the average.

In $yourAircraft-set.xml, in <systems> section, load the parameters and the wingflexer module:
<systems>
<wingflexer include="Systems/wingflexer-params.xml"/>
<property-rule n="100">
<name>wing flexer property rule</name>
<path>Aircraft/Generic/wingflexer.xml</path>
</property-rule>
</systems>

The wingflexer writes the deflection to /sim/systems/wingflexer/z-m.
Finally, your model rotate animation has to pick it up and multiply it by z_fac
<animation>
<type>rotate</type>
<property>sim/systems/wingflexer/z-m</property>
<factor>10.</factor>
...
</animation>

If your aircraft uses JSBSim, you're done now. Yasim requires an extra step, described next.

== Yasim ==
Yasim does not write the lift to the property tree. But you can create a helper
function which computes the lift as
lift_force_lbs = aircraft_weight_lbs * load_factor - total_weight_on_wheels_lbs
and point the <lift-node-lbs> alias in wingflexer-params.xml to it.

== Implementation details ==
=== Autopilot/Property rules implementation ===
Code lives in Aircraft/Generic/wingflexer.xml

The ODE x" + ax' + bx + c = 0 is integrated by DampedOsciFilterImplementation in FG/src/autopilot/digitalfilter.cxx.

=== Nasal implementation ===
Code lives in Aircraft/Generic/wingflexer.nas, see comment therein.

== TODO ==
* write Yasim helper
* input for fuselage acceleration should rather be acceleration at CG instead of the pilot's location -- is there a property?
* add wingflexer.py (to where?)

[[Category:FlightGear feature]]

Wingflexer

2015-03-11T00:07:46Z

Radi: /* How to add to your aircraft */ make equation less ambigous, wording

Wings of large aspect ratio tend to behave similar to a spring. They bend under load and oscillate for a while when the load changes, for example in a turn, during turbulence, or on touchdown. This article describes the Wingflexer module, which aims at animating the 3-D model of a wing in a somewhat realistic fashion. The method used is a significant improvement over what has been described here. However, the actual model animation part is identical and will not be covered.

Including this in your aircraft is fairly straightforward, but obtaining plausible parameters can require some research and trial-and-error. We will give an example (the 787) below.

Introduced in FG 3.5, there are two implementations available. One uses autopilot/property rules, is therefore very optimized and should be your first choice. The other uses Nasal. It is a bit more flexible in the sense that it could also be applied to AI aircraft.

== Physical model ==
This section describes the physical model. You don't need to fully understand the maths here to be able to use Wingflexer, but you should understand the parameters involved -- you will need to adapt them to your aircraft.

We use a simple spring-mass-damper system sketched below to model a flexible wing:
--> |<---- z --->|
g
+-----+ +-----+
<--- | m_w |---/\/\/\---| |
+-----+ +-----+
Lift wing spring fuselage
force mass

The wing's motion, measured by the deflection z(t), is governed by the following parameters:

k wing stiffness
d damping
m_w = m_dw + fuel_frac * m_fuel
Total wing mass. Because the fuel is distributed over the wing, we use
a fraction of the fuel mass in the calculation.
0.5*F_L lift force/2 (we look at one wing only)
..
z_f acceleration of the frame of reference (fuselage)

We integrate the equation of motion
.. k d . 0.5*F_L ..
0 = -z + --- z + ---- z - ------- - g - z_f
m_w m_w m_w
and write the deflection (z + z_ofs) in meters to /sim/systems/wingflexer/z-m.
The offset z_ofs is calculated automatically and ensures that the dry wing
(which still has a non-zero mass) creates a neutral deflection.

Discretisation by first order finite differences leads to
z_0 - 2 z_1 + z_2 k d (z_0 - z_1) 1/2 F_L ..
----------------- + --- z_1 + --- ----------- - ------- - g - z_f = 0
dt^2 m_w m_w dt m_w
It is convenient to divide k and d by a (constant) reference mass:
K = k / m_dw
D = d / m_dw

== Obtaining plausible parameters ==
To make our model produce a convinving dynamic behaviour, you will need to obtain estimates and fine-tune the parameters.

These include the wing mass m_w, the wing stiffness K, the damping D, and a scaling factor z_fac.
There's a python script wingflexer.py which assists you in fine-tuning. It will quickly simulate the dynamics of the model with your parameters.
So how to estimate the parameters?

1. Assume a dry wing mass m_dw. Research the wing fuel mass m_fuel.

2. Obtain estimates of
* the deflection z_flight in level flight, e.g by comparing photos of the real aircraft on ground and in air,
* the wing's natural frequency, perhaps from videos of the wing's oscillation in turbulence,
* the deflection with full and empty tanks while sitting on the ground.

3. Compute K to match in-flight deflection with full tanks:
K = g * (m_ac / 2 - (fuel_frac * m_fuel)) / (z_in_flight / z_fac) / m_dw
where
m_ac aircraft mass
g 9.81 m/s^2
z_fac scaling factor for the deflection, start with 1

4. Compute the natural frequency of this system for full and empty wing tanks:
f_full = sqrt(K * m_dw / (m_dw + fuel_frac * m_fuel)) / (2 pi)
f_empty = sqrt(K) / (2 pi)

Ideally we want our model to match the wing's natural frequency, the wing's deflection
while sitting on the ground with full or empty tanks, and the deflection (bounce)
during a hard landing. Getting real-world data for the latter is difficult.

Here are some relations:
* a lower wing mass increases the natural frequency, and weakens the touchdown bounce
* a higher stiffness K reduces the deflection and increases the natural frequency

== Enable developer options ==
By default, Wingflexer and the user-tunable parameters live in
/sim/systems/wingflexer/
/sim/systems/wingflexer/params/

There are two properties disabled by default which are only useful when you're tuning the parameters. To enable them, uncomment the developer section in Aircraft/Generic/wingflexer.xml.
This will activate
/sim/systems/wingflexer/params/z-fac
/sim/systems/wingflexer/params/sink-rate-fps
Z-fac simply scales the output. Once you're happy with the results, include this factor in the animation.
Sink-rate-fps allows you to simulate a touchdown at given vertical speed.

It will become clear in the next section why these two settings are useful.

== An example: the 787 ==
The 787 is known for its very flexible wings; the deflection in
unaccelerated flight is quoted as z = 3 m. One wing tank of FG's 787-8 holds
23,000 kg of fuel. Because the fuel is distributed over the wing, we use a
fraction of the fuel mass in the calculation: fuel_frac = 0.75. For the same reason
we don't use the true wing mass, but rather something that makes our model look
plausible.

So assuming a wing mass of 12000 kg, we get K=25.9 and f_empty = 0.5 Hz.
That frequency might be a bit low, videos of a 777 wing in turbulence show about
2-3 Hz. (I didn't research 787 videos).

To increase it, we could either reduce m_dw or increase K. A lower m_dw results
in a rather weak bounce on touchdown which might look odd. A higher K reduces
the deflection z_flight, but we can simply scale the animation to account for
that. We'll multiply the deflection z by a factor z_fac to get an angle for the
<rotate> animation later on anyway. So repeat 3. and 4. using e.g. z_fac = 10.
Now K = 259 and f_empty=2.6 Hz. While our model spring now only deflects
to 0.3 m instead of 3 m, the animation scale factor will make sure the wing
bends to 3 m. This way, we can match both natural frequency and observed deflection,
and still get a realistic bounce on touch down. Finally, adjust D such that an
impulse is damped out after about one or two oscillations; D = 12 seems to work
OK in our example.

It's difficult to get real-world data on the deflection during touchdown.
Touchdown at more than 10 ft/s is considered a hard landing and could result in some significant wing bending.
There's a video of a hard landing of an A346 (http://avherald.com/h?article=471e70e9), showing the
wings bend perhaps 1 m.

To assist you in tuning parameters for the touchdown bounce you can initialize your
wing mass with a (touchdown) vertical speed via /sim/systems/wingflexer/sink-rate-fps, and then observe the deflection and oscillation. This avoids you having to fly too many touch-and-go's while developing ;)

Finally, our model outputs the deflection in meters, but the <rotate> animation expects an
angle. It is up to you convert appropriately, depending on your wing
span and number of segments in the animation. Also don't forget to include z_fac.

== How to add to your aircraft ==
Create a file $YourAircraft/Systems/wingflexer-params.xml which contains the parameters adjusted to your aircraft
<?xml version="1.0" encoding="UTF-8"?>
<PropertyList>
<params>
<m-wing-dry-kg type="double">12000.</m-wing-dry-kg>
<K type="double">259.</K>
<D type="double">12.</D>
<fuel-frac type="double">0.375</fuel-frac>
<lift-node-lbs alias="/fdm/jsbsim/forces/fbz-aero-lbs"/>
<fuel-node-1-kg alias="/consumables/fuel/tank/level-kg"/>
<fuel-node-2-kg alias="/consumables/fuel/tank[1]/level-kg"/>
<fuel-node-3-kg type="double">0.</fuel-node-3-kg>
<fuel-node-4-kg type="double">0.</fuel-node-4-kg>
</params>
</PropertyList>
Also adjust the property node aliases for the wing fuel tanks. Wingflexer supports up to four tanks in total. Since we're currently only solving one equation and hence get only one deflection which is used for both wings, we have to average the wing mass. This is done by
m_fuel = fuel-frac * (fuel-node-1-kg + fuel-node-2-kg + fuel-node-3-kg + fuel-node-4-kg).
Include the weighting factor in fuel-frac (e.g. 1/2 if you provide 2 fuel nodes). If you have more than 4 wing tanks in total, use another property rule to compute the average.

In $yourAircraft-set.xml, in <systems> section, load the parameters and the wingflexer module:
<systems>
<wingflexer include="Systems/wingflexer-params.xml"/>
<property-rule n="100">
<name>wing flexer property rule</name>
<path>Aircraft/Generic/wingflexer.xml</path>
</property-rule>
</systems>

The wingflexer writes the deflection to /sim/systems/wingflexer/z-m.
Finally, your model rotate animation has to pick it up and multiply it by z_fac
<animation>
<type>rotate</type>
<property>sim/systems/wingflexer/z-m</property>
<factor>10.</factor>
...
</animation>

If your aircraft uses JSBSim, you're done now. Yasim requires an extra step, described next.

== Yasim ==
Yasim does not write the lift to the property tree. But you can create a helper
function which computes the lift as
lift_force_lbs = aircraft_weight_lbs * load_factor - total_weight_on_wheels_lbs
and point the <lift-node-lbs> alias in wingflexer-params.xml to it.

== Implementation details ==
=== Autopilot/Property rules implementation ===
Code lives in Aircraft/Generic/wingflexer.xml

The ODE x" + ax' + bx + c = 0 is integrated by DampedOsciFilterImplementation in FG/src/autopilot/digitalfilter.cxx.

=== Nasal implementation ===
Code lives in Aircraft/Generic/wingflexer.nas

== TODO ==
* write Yasim helper
* input for fuselage acceleration should rather be acceleration at CG instead of the pilot's location -- is there a property?
* add wingflexer.py (to where?)

[[Category:FlightGear feature]]

Wingflexer

2015-03-11T00:03:14Z

Radi: /* Autopilot/Property rules implementation */ line break

Wings of large aspect ratio tend to behave similar to a spring. They bend under load and oscillate for a while when the load changes, for example in a turn, during turbulence, or on touchdown. This article describes the Wingflexer module, which aims at animating the 3-D model of a wing in a somewhat realistic fashion. The method used is a significant improvement over what has been described here. However, the actual model animation part is identical and will not be covered.

Including this in your aircraft is fairly straightforward, but obtaining plausible parameters can require some research and trial-and-error. We will give an example (the 787) below.

Introduced in FG 3.5, there are two implementations available. One uses autopilot/property rules, is therefore very optimized and should be your first choice. The other uses Nasal. It is a bit more flexible in the sense that it could also be applied to AI aircraft.

== Physical model ==
This section describes the physical model. You don't need to fully understand the maths here to be able to use Wingflexer, but you should understand the parameters involved -- you will need to adapt them to your aircraft.

We use a simple spring-mass-damper system sketched below to model a flexible wing:
--> |<---- z --->|
g
+-----+ +-----+
<--- | m_w |---/\/\/\---| |
+-----+ +-----+
Lift wing spring fuselage
force mass

The wing's motion, measured by the deflection z(t), is governed by the following parameters:

k wing stiffness
d damping
m_w = m_dw + fuel_frac * m_fuel
Total wing mass. Because the fuel is distributed over the wing, we use
a fraction of the fuel mass in the calculation.
0.5*F_L lift force/2 (we look at one wing only)
..
z_f acceleration of the frame of reference (fuselage)

We integrate the equation of motion
.. k d . 0.5*F_L ..
0 = -z + --- z + ---- z - ------- - g - z_f
m_w m_w m_w
and write the deflection (z + z_ofs) in meters to /sim/systems/wingflexer/z-m.
The offset z_ofs is calculated automatically and ensures that the dry wing
(which still has a non-zero mass) creates a neutral deflection.

Discretisation by first order finite differences leads to
z_0 - 2 z_1 + z_2 k d (z_0 - z_1) 1/2 F_L ..
----------------- + --- z_1 + --- ----------- - ------- - g - z_f = 0
dt^2 m_w m_w dt m_w
It is convenient to divide k and d by a (constant) reference mass:
K = k / m_dw
D = d / m_dw

== Obtaining plausible parameters ==
To make our model produce a convinving dynamic behaviour, you will need to obtain estimates and fine-tune the parameters.

These include the wing mass m_w, the wing stiffness K, the damping D, and a scaling factor z_fac.
There's a python script wingflexer.py which assists you in fine-tuning. It will quickly simulate the dynamics of the model with your parameters.
So how to estimate the parameters?

1. Assume a dry wing mass m_dw. Research the wing fuel mass m_fuel.

2. Obtain estimates of
* the deflection z_flight in level flight, e.g by comparing photos of the real aircraft on ground and in air,
* the wing's natural frequency, perhaps from videos of the wing's oscillation in turbulence,
* the deflection with full and empty tanks while sitting on the ground.

3. Compute K to match in-flight deflection with full tanks:
K = g * (m_ac / 2 - (fuel_frac * m_fuel)) / (z_in_flight / z_fac) / m_dw
where
m_ac aircraft mass
g 9.81 m/s^2
z_fac scaling factor for the deflection, start with 1

4. Compute the natural frequency of this system for full and empty wing tanks:
f_full = sqrt(K * m_dw / (m_dw + fuel_frac * m_fuel)) / (2 pi)
f_empty = sqrt(K) / (2 pi)

Ideally we want our model to match the wing's natural frequency, the wing's deflection
while sitting on the ground with full or empty tanks, and the deflection (bounce)
during a hard landing. Getting real-world data for the latter is difficult.

Here are some relations:
* a lower wing mass increases the natural frequency, and weakens the touchdown bounce
* a higher stiffness K reduces the deflection and increases the natural frequency

== Enable developer options ==
By default, Wingflexer and the user-tunable parameters live in
/sim/systems/wingflexer/
/sim/systems/wingflexer/params/

There are two properties disabled by default which are only useful when you're tuning the parameters. To enable them, uncomment the developer section in Aircraft/Generic/wingflexer.xml.
This will activate
/sim/systems/wingflexer/params/z-fac
/sim/systems/wingflexer/params/sink-rate-fps
Z-fac simply scales the output. Once you're happy with the results, include this factor in the animation.
Sink-rate-fps allows you to simulate a touchdown at given vertical speed.

It will become clear in the next section why these two settings are useful.

== An example: the 787 ==
The 787 is known for its very flexible wings; the deflection in
unaccelerated flight is quoted as z = 3 m. One wing tank of FG's 787-8 holds
23,000 kg of fuel. Because the fuel is distributed over the wing, we use a
fraction of the fuel mass in the calculation: fuel_frac = 0.75. For the same reason
we don't use the true wing mass, but rather something that makes our model look
plausible.

So assuming a wing mass of 12000 kg, we get K=25.9 and f_empty = 0.5 Hz.
That frequency might be a bit low, videos of a 777 wing in turbulence show about
2-3 Hz. (I didn't research 787 videos).

To increase it, we could either reduce m_dw or increase K. A lower m_dw results
in a rather weak bounce on touchdown which might look odd. A higher K reduces
the deflection z_flight, but we can simply scale the animation to account for
that. We'll multiply the deflection z by a factor z_fac to get an angle for the
<rotate> animation later on anyway. So repeat 3. and 4. using e.g. z_fac = 10.
Now K = 259 and f_empty=2.6 Hz. While our model spring now only deflects
to 0.3 m instead of 3 m, the animation scale factor will make sure the wing
bends to 3 m. This way, we can match both natural frequency and observed deflection,
and still get a realistic bounce on touch down. Finally, adjust D such that an
impulse is damped out after about one or two oscillations; D = 12 seems to work
OK in our example.

It's difficult to get real-world data on the deflection during touchdown.
Touchdown at more than 10 ft/s is considered a hard landing and could result in some significant wing bending.
There's a video of a hard landing of an A346 (http://avherald.com/h?article=471e70e9), showing the
wings bend perhaps 1 m.

To assist you in tuning parameters for the touchdown bounce you can initialize your
wing mass with a (touchdown) vertical speed via /sim/systems/wingflexer/sink-rate-fps, and then observe the deflection and oscillation. This avoids you having to fly too many touch-and-go's while developing ;)

Finally, our model outputs the deflection in meters, but the <rotate> animation expects an
angle. It is up to you convert appropriately, depending on your wing
span and number of segments in the animation. Also don't forget to include z_fac.

== How to add to your aircraft ==
Create a file $YourAircraft/Systems/wingflexer-params.xml which contains the parameters adjusted to your aircraft
<?xml version="1.0" encoding="UTF-8"?>
<PropertyList>
<params>
<m-wing-dry-kg type="double">12000.</m-wing-dry-kg>
<K type="double">259.</K>
<D type="double">12.</D>
<fuel-frac type="double">0.375</fuel-frac>
<lift-node-lbs alias="/fdm/jsbsim/forces/fbz-aero-lbs"/>
<fuel-node-1-kg alias="/consumables/fuel/tank/level-kg"/>
<fuel-node-2-kg alias="/consumables/fuel/tank[1]/level-kg"/>
<fuel-node-3-kg type="double">0.</fuel-node-3-kg>
<fuel-node-4-kg type="double">0.</fuel-node-4-kg>
</params>
</PropertyList>
Also adjust the property node aliases for the wing fuel tanks. Wingflexer supports up to four tanks in total. Since we're currently only solving one equation and hence get only one deflection which is used for both wings, we have to average the wing mass. This is done by
m_fuel = fuel-frac * (fuel-node-1 + fuel-node-2 + fuel-node-3 + fuel-node-4).
Include the averaging weight factor in fuel-frac (e.g. 1/2 if you provide 2 fuel nodes). If you have more than 4 wing tanks in total, use another property rule to compute the average.

In $yourAircraft-set.xml, in <systems> section, load the parameters and the wingflexer module:
<systems>
<wingflexer include="Systems/wingflexer-params.xml"/>
<property-rule n="100">
<name>wing flexer property rule</name>
<path>Aircraft/Generic/wingflexer.xml</path>
</property-rule>
</systems>

The wingflexer writes the deflection to /sim/systems/wingflexer/z-m.
Finally, your model rotate animation has to pick it up and multiply it by z_fac
<animation>
<type>rotate</type>
<property>sim/systems/wingflexer/z-m</property>
<factor>10.</factor>
...
</animation>

If your aircraft uses JSBSim, you're done now. Yasim requires an extra step, described next.

== Yasim ==
Yasim does not write the lift to the property tree. But you can create a helper
function which computes the lift as
lift_force_lbs = aircraft_weight_lbs * load_factor - total_weight_on_wheels_lbs
and point the <lift-node-lbs> alias in wingflexer-params.xml to it.

== Implementation details ==
=== Autopilot/Property rules implementation ===
Code lives in Aircraft/Generic/wingflexer.xml

The ODE x" + ax' + bx + c = 0 is integrated by DampedOsciFilterImplementation in FG/src/autopilot/digitalfilter.cxx.

=== Nasal implementation ===
Code lives in Aircraft/Generic/wingflexer.nas

== TODO ==
* write Yasim helper
* input for fuselage acceleration should rather be acceleration at CG instead of the pilot's location -- is there a property?
* add wingflexer.py (to where?)

[[Category:FlightGear feature]]

Wingflexer

2015-03-10T23:54:33Z

Radi: final version

Wings of large aspect ratio tend to behave similar to a spring. They bend under load and oscillate for a while when the load changes, for example in a turn, during turbulence, or on touchdown. This article describes the Wingflexer module, which aims at animating the 3-D model of a wing in a somewhat realistic fashion. The method used is a significant improvement over what has been described here. However, the actual model animation part is identical and will not be covered.

Including this in your aircraft is fairly straightforward, but obtaining plausible parameters can require some research and trial-and-error. We will give an example (the 787) below.

Introduced in FG 3.5, there are two implementations available. One uses autopilot/property rules, is therefore very optimized and should be your first choice. The other uses Nasal. It is a bit more flexible in the sense that it could also be applied to AI aircraft.

== Physical model ==
This section describes the physical model. You don't need to fully understand the maths here to be able to use Wingflexer, but you should understand the parameters involved -- you will need to adapt them to your aircraft.

We use a simple spring-mass-damper system sketched below to model a flexible wing:
--> |<---- z --->|
g
+-----+ +-----+
<--- | m_w |---/\/\/\---| |
+-----+ +-----+
Lift wing spring fuselage
force mass

The wing's motion, measured by the deflection z(t), is governed by the following parameters:

k wing stiffness
d damping
m_w = m_dw + fuel_frac * m_fuel
Total wing mass. Because the fuel is distributed over the wing, we use
a fraction of the fuel mass in the calculation.
0.5*F_L lift force/2 (we look at one wing only)
..
z_f acceleration of the frame of reference (fuselage)

We integrate the equation of motion
.. k d . 0.5*F_L ..
0 = -z + --- z + ---- z - ------- - g - z_f
m_w m_w m_w
and write the deflection (z + z_ofs) in meters to /sim/systems/wingflexer/z-m.
The offset z_ofs is calculated automatically and ensures that the dry wing
(which still has a non-zero mass) creates a neutral deflection.

Discretisation by first order finite differences leads to
z_0 - 2 z_1 + z_2 k d (z_0 - z_1) 1/2 F_L ..
----------------- + --- z_1 + --- ----------- - ------- - g - z_f = 0
dt^2 m_w m_w dt m_w
It is convenient to divide k and d by a (constant) reference mass:
K = k / m_dw
D = d / m_dw

== Obtaining plausible parameters ==
To make our model produce a convinving dynamic behaviour, you will need to obtain estimates and fine-tune the parameters.

These include the wing mass m_w, the wing stiffness K, the damping D, and a scaling factor z_fac.
There's a python script wingflexer.py which assists you in fine-tuning. It will quickly simulate the dynamics of the model with your parameters.
So how to estimate the parameters?

1. Assume a dry wing mass m_dw. Research the wing fuel mass m_fuel.

2. Obtain estimates of
* the deflection z_flight in level flight, e.g by comparing photos of the real aircraft on ground and in air,
* the wing's natural frequency, perhaps from videos of the wing's oscillation in turbulence,
* the deflection with full and empty tanks while sitting on the ground.

3. Compute K to match in-flight deflection with full tanks:
K = g * (m_ac / 2 - (fuel_frac * m_fuel)) / (z_in_flight / z_fac) / m_dw
where
m_ac aircraft mass
g 9.81 m/s^2
z_fac scaling factor for the deflection, start with 1

4. Compute the natural frequency of this system for full and empty wing tanks:
f_full = sqrt(K * m_dw / (m_dw + fuel_frac * m_fuel)) / (2 pi)
f_empty = sqrt(K) / (2 pi)

Ideally we want our model to match the wing's natural frequency, the wing's deflection
while sitting on the ground with full or empty tanks, and the deflection (bounce)
during a hard landing. Getting real-world data for the latter is difficult.

Here are some relations:
* a lower wing mass increases the natural frequency, and weakens the touchdown bounce
* a higher stiffness K reduces the deflection and increases the natural frequency

== Enable developer options ==
By default, Wingflexer and the user-tunable parameters live in
/sim/systems/wingflexer/
/sim/systems/wingflexer/params/

There are two properties disabled by default which are only useful when you're tuning the parameters. To enable them, uncomment the developer section in Aircraft/Generic/wingflexer.xml.
This will activate
/sim/systems/wingflexer/params/z-fac
/sim/systems/wingflexer/params/sink-rate-fps
Z-fac simply scales the output. Once you're happy with the results, include this factor in the animation.
Sink-rate-fps allows you to simulate a touchdown at given vertical speed.

It will become clear in the next section why these two settings are useful.

== An example: the 787 ==
The 787 is known for its very flexible wings; the deflection in
unaccelerated flight is quoted as z = 3 m. One wing tank of FG's 787-8 holds
23,000 kg of fuel. Because the fuel is distributed over the wing, we use a
fraction of the fuel mass in the calculation: fuel_frac = 0.75. For the same reason
we don't use the true wing mass, but rather something that makes our model look
plausible.

So assuming a wing mass of 12000 kg, we get K=25.9 and f_empty = 0.5 Hz.
That frequency might be a bit low, videos of a 777 wing in turbulence show about
2-3 Hz. (I didn't research 787 videos).

To increase it, we could either reduce m_dw or increase K. A lower m_dw results
in a rather weak bounce on touchdown which might look odd. A higher K reduces
the deflection z_flight, but we can simply scale the animation to account for
that. We'll multiply the deflection z by a factor z_fac to get an angle for the
<rotate> animation later on anyway. So repeat 3. and 4. using e.g. z_fac = 10.
Now K = 259 and f_empty=2.6 Hz. While our model spring now only deflects
to 0.3 m instead of 3 m, the animation scale factor will make sure the wing
bends to 3 m. This way, we can match both natural frequency and observed deflection,
and still get a realistic bounce on touch down. Finally, adjust D such that an
impulse is damped out after about one or two oscillations; D = 12 seems to work
OK in our example.

It's difficult to get real-world data on the deflection during touchdown.
Touchdown at more than 10 ft/s is considered a hard landing and could result in some significant wing bending.
There's a video of a hard landing of an A346 (http://avherald.com/h?article=471e70e9), showing the
wings bend perhaps 1 m.

To assist you in tuning parameters for the touchdown bounce you can initialize your
wing mass with a (touchdown) vertical speed via /sim/systems/wingflexer/sink-rate-fps, and then observe the deflection and oscillation. This avoids you having to fly too many touch-and-go's while developing ;)

Finally, our model outputs the deflection in meters, but the <rotate> animation expects an
angle. It is up to you convert appropriately, depending on your wing
span and number of segments in the animation. Also don't forget to include z_fac.

== How to add to your aircraft ==
Create a file $YourAircraft/Systems/wingflexer-params.xml which contains the parameters adjusted to your aircraft
<?xml version="1.0" encoding="UTF-8"?>
<PropertyList>
<params>
<m-wing-dry-kg type="double">12000.</m-wing-dry-kg>
<K type="double">259.</K>
<D type="double">12.</D>
<fuel-frac type="double">0.375</fuel-frac>
<lift-node-lbs alias="/fdm/jsbsim/forces/fbz-aero-lbs"/>
<fuel-node-1-kg alias="/consumables/fuel/tank/level-kg"/>
<fuel-node-2-kg alias="/consumables/fuel/tank[1]/level-kg"/>
<fuel-node-3-kg type="double">0.</fuel-node-3-kg>
<fuel-node-4-kg type="double">0.</fuel-node-4-kg>
</params>
</PropertyList>
Also adjust the property node aliases for the wing fuel tanks. Wingflexer supports up to four tanks in total. Since we're currently only solving one equation and hence get only one deflection which is used for both wings, we have to average the wing mass. This is done by
m_fuel = fuel-frac * (fuel-node-1 + fuel-node-2 + fuel-node-3 + fuel-node-4).
Include the averaging weight factor in fuel-frac (e.g. 1/2 if you provide 2 fuel nodes). If you have more than 4 wing tanks in total, use another property rule to compute the average.

In $yourAircraft-set.xml, in <systems> section, load the parameters and the wingflexer module:
<systems>
<wingflexer include="Systems/wingflexer-params.xml"/>
<property-rule n="100">
<name>wing flexer property rule</name>
<path>Aircraft/Generic/wingflexer.xml</path>
</property-rule>
</systems>

The wingflexer writes the deflection to /sim/systems/wingflexer/z-m.
Finally, your model rotate animation has to pick it up and multiply it by z_fac
<animation>
<type>rotate</type>
<property>sim/systems/wingflexer/z-m</property>
<factor>10.</factor>
...
</animation>

If your aircraft uses JSBSim, you're done now. Yasim requires an extra step, described next.

== Yasim ==
Yasim does not write the lift to the property tree. But you can create a helper
function which computes the lift as
lift_force_lbs = aircraft_weight_lbs * load_factor - total_weight_on_wheels_lbs
and point the <lift-node-lbs> alias in wingflexer-params.xml to it.

== Implementation details ==
=== Autopilot/Property rules implementation ===
Code lives in Aircraft/Generic/wingflexer.xml
The ODE x" + ax' + bx + c = 0 is integrated by DampedOsciFilterImplementation in FG/src/autopilot/digitalfilter.cxx.

=== Nasal implementation ===
Code lives in Aircraft/Generic/wingflexer.nas

== TODO ==
* write Yasim helper
* input for fuselage acceleration should rather be acceleration at CG instead of the pilot's location -- is there a property?
* add wingflexer.py (to where?)

[[Category:FlightGear feature]]

Wingflexer

2015-03-09T10:58:52Z

Radi: initial import

Wingflexer intro text

This article describes how to add wingflex to your aircraft and how to obtain plausible parameters. The physical model is given at the end.

= How to add to your aircraft =

= Obtain plausible parameters =
To make our model produce a convinving dynamic behaviour, you will need to obtain estimates (and fine-tune) a number of parameters. These include the wing mass m_w, the wing stiffness K, the damping D, and a scaling factor z_fac.

1. Assume a dry wing mass m_dw. Research the wing fuel mass m_fuel.

2. Obtain estimates of
* the deflection z_flight in level flight, e.g by comparing photos of the real aircraft on ground and in air,
* the wing's eigenfrequency, perhaps from videos of the wing's oscillation in turbulence,
* the deflection with full and empty tanks while sitting on the ground.

3. Compute K to match in-flight deflection with full tanks:
K = g * (m_ac / 2 - (fuel_frac * m_fuel)) / (z_in_flight / z_fac) / m_dw

where

m_ac : aircraft mass
g : 9.81 m/s^2
z_fac: scaling factor for the deflection, start with 1

4. Compute the eigenfrequency of this system for full and empty wing tanks:
f_full = sqrt(K * m_dw / (m_dw + fuel_frac * m_fuel)) / (2 pi)
f_empty = sqrt(K) / (2 pi)

Ideally we want our model to match the eigenfrequency, the deflection
while sitting on the ground with full or empty tanks, and the deflection
during a hard landing. Getting real-world data for the latter is difficult.

Here are some relations:
- a lower wing mass increases the eigenfrequency, and weakens the touchdown bounce
- a higher stiffness K reduces the deflection and increases the eigenfrequency

= Physical model =
-->
g
+-----+ +-----+
<--- | m_w |---/\/\/\---| |
+-----+ +-----+
Lift wing spring fuselage
force mass
We integrate
.. k d . 0.5*F_L ..
0 = -z + --- z + ---- z - ------- - g - z_f
m_w m_w m_w
where
z : deflection
k : wing stiffness
d : damping
m_w = m_dw + fuel_frac * m_fuel
Total wing mass. Because the fuel is distributed over the wing, we use
a fraction of the fuel mass in the calculation.
0.5*F_L : lift force/2 (we look at one wing only)
..
z_f : acceleration of the frame of reference (fuselage)
and write the deflection (z + z_ofs) in meters to /sim/model/wing-flex/z-m.
The offset z_ofs is calculated automatically and ensures that the dry wing
(which still has a non-zero mass) creates neutral deflection.

Discretisation by first order finite differences:
z_0 - 2 z_1 + z_2 k d (z_0 - z_1) 1/2 F_L ..
----------------- + --- z_1 + --- ----------- - ------- - g - z_f = 0
dt^2 m_w m_w dt m_w
It is convenient to divide k and d by a (constant) reference mass:
K = k / m_dw
D = d / m_dw

Project Hong Kong

2015-03-06T04:47:22Z

Radi: /* Airports he are planning to work on */ spelling

Project Hong Kong is aimed to improve the Hong Kong scenery in FlightGear.

== Airports we are planning to work on ==
* VHHH
* VHXX
* VHSK

== Hong Kong terrain improvements ==
We also will fix the FG terrain in Hong Kong to be close as possible to Real Hong Kong

=== To Do List ===
* New Models for all airports and sounding areas
* Adding Detailed markings on runways and taxiways
* Moving existing models to their correct possessions
* Replacing inaccurate models
* Building the Victoria Harbor skyline
* Building Kowloon City
* Urbanizing the City
* Regenerating the Hong Kong terrain using TerraGear
* Building realistic roads with moving traffic
* Building realistic tracks with moving trains

== Volunteers are welcomed ==
If you wish to help in this project, please contact Pakistan-1 or Radi on the FlightGear Forum.

[[Category:Community|Hong Kong |Development| ]]

Osm2city.py textures

2015-03-05T01:33:08Z

Radi: /* Install texture and lightmap */ reflect recent code changes

This article describes how you can prepare and register your own textures for use with osm2city.py.
It assumes you already have a texture image file. If not, see [[Howto:Create_textures_from_photos]].

== Introduction ==
To texture a facade or a roof, you need
* two image files: the texture itself and a lightmap
* the texture's dimensions in meters
* locations in pixels at which osm2city.py may cut the texture to fit it to a given facade geometry, e.g. to apply a photo of a 15-storey building to a 12 storey model without shrinking it.
* 'provides' and 'requires' tags, e.g., a texture could require a black roof, while providing a commercial facade.

Osm2city uses a texture atlas. This improves performance, but has two drawbacks:
# Textures can wrap around in at most one direction.
# Textures are scaled to one width (currently hardcoded 256 px)

== texGUI.py ==
The script texGUI.py eases calibration and finding the cut locations. Run the GUI and supply your texture file:
<syntaxhighlight lang="bash">
texGUI.py facade.png
</syntaxhighlight>

[[File:TexGUI calibrating width.jpg|thumb|texGUI: Calibrating a texture's width using an aircon as a reference object. Note the red line.]]
[[File:TexGUI added cut locations.jpg|thumb|texGUI: Added horizontal and vertical cut locations.]]

It is generally a good idea to use descriptive names, such as "facade_industrial_old_white.png", but for this example we simply use "facade.png".

# Calibrate the image width/height. Find a feature in the image whose dimensions you know or can estimate. For example, simple windows are typically about 0.8 m wide. Here, we're using the aircon's width, estimated 0.82 m. Left drag to select that horizontal feature, then enter its length. Right drag for a vertical feature. You need only one of them. If both are given, both are used (e.g. if your image is stretched in one direction).
# Mark locations at which osm2city.py may cut the texture. Use left and right mouse buttons. Shift+click removes the last marker.
# Once you're satisfied, click "dump and quit". This writes calibration/cut data to a file "facade_24x19m.py". Note that texGUI added "_24x19m" to the texture file name (the original file is still in place), since you're likely to have more than one texture for an industrial facade.

== Texture metadata ==

Now edit facade_24x19m.py:

<syntaxhighlight lang="python">
facades.append(Texture('tex.src/facade_24x19m.png',
23.8, [364, 742, 1086], h_can_repeat=True,
18.5, [295, 565, 842], v_can_repeat=False,
v_align_bottom = True,
requires=[],
provides=[]))
</syntaxhighlight>

Usually you need to change very little here.
* You can set the texture to wrap around in at most one direction using ''h_can_repeat'' or ''v_can_repeat''
* If ''v_align_bottom'' is True, osm2city.py will align the bottom part of the texture with the ground and cut away the top part if neccessary. Otherwise, it will align the top part with the roof and cut away the bottom.

For reference, we now descibe the format in a bit more detail. You might want to skip to the [[Osm2city.py_Textures#Texture_compatibility|next section]].

First line is the path to our texture.
Second line says the texture
* is 23.8m wide
* can be cut at u = 364, 742, and 1068 px, where u is the horizontal coordinate. The last value 1086 also gives the width in px. Note that the .ac file uses normalized coordinates (0 ... 1). Internally, osm2city.py divides all coordinates by the last value. Therefore, when preparing the textures, you can work with the highest resolution possible and register those numbers, then just downscale the texture for actual flightgear use. Once the next generation of graphics cards arrives you just replace the textures with higher resolution ones without touching the cut locations.
* the texture can repeat in horizontal direction.

The third line gives the same information for the vertical direction:
* 18.5m height
* can cut at 295, 565, 842 px,
* the texture cannot repeat in vertical direction

== Texture compatibility ==

The fourth and fifth line state compatibility with other textures. TexGUI.py just creates an empty template here. A useful example could look like this:

<syntaxhighlight lang="python">
requires=['roof:color:black'],
provides=['shape:industrial','age:old','compat:roof-flat','compat:roof-gable']))
</syntaxhighlight>

This facade texture requires a black roof. It provides an old-aged, industrial facade, and is compatible with both flat and gable roofs. TODO: describe details on our requires/provides mechanism.

== Lightmap ==

A lightmap <del>is required for every texture, having</del>has the same file name with a postfix "_LM". So for our example this would be
"facade_24x19m_LM.png"

Osm2city uses
* red channel for window lights
* green channel for ambient street lights shining onto facade
* blue and alpha unused

TODO describe add_streetlight.py

== Install texture and lightmap ==
* copy texture and lightmap to tex.src/
* add the snippet from "facade_24x19m.py" to textures/catalog.py

If you're adding a roof, name your texture "roof_something.png" and append it to the list of ''roofs'' (instead of ''facades'')
<syntaxhighlight lang="python">
roofs.append(Texture('tex.src/roof_something.png',
</syntaxhighlight>

See roof examples starting around line 400. Note that also roofs need a lightmap.

Finally, run
<syntaxhighlight lang="bash">
osm2city.py -A
</syntaxhighlight>

to re-create the texture atlas. If there are no errors, your texture is registered and will be used next time you run osm2city.py. If your texture is GPL compatible, please consider
sending it (along with the meta data) to one of the osm2city.py devs to have it included in the official distribution.

[[Category:Modeling]]
[[Category:OpenStreetMap]]

Osm2city.py textures

2015-03-05T01:30:25Z

Radi: /* Lightmap */ we can work without LM, but then we won't have lighting, of course

This article describes how you can prepare and register your own textures for use with osm2city.py.
It assumes you already have a texture image file. If not, see [[Howto:Create_textures_from_photos]].

== Introduction ==
To texture a facade or a roof, you need
* two image files: the texture itself and a lightmap
* the texture's dimensions in meters
* locations in pixels at which osm2city.py may cut the texture to fit it to a given facade geometry, e.g. to apply a photo of a 15-storey building to a 12 storey model without shrinking it.
* 'provides' and 'requires' tags, e.g., a texture could require a black roof, while providing a commercial facade.

Osm2city uses a texture atlas. This improves performance, but has two drawbacks:
# Textures can wrap around in at most one direction.
# Textures are scaled to one width (currently hardcoded 256 px)

== texGUI.py ==
The script texGUI.py eases calibration and finding the cut locations. Run the GUI and supply your texture file:
<syntaxhighlight lang="bash">
texGUI.py facade.png
</syntaxhighlight>

[[File:TexGUI calibrating width.jpg|thumb|texGUI: Calibrating a texture's width using an aircon as a reference object. Note the red line.]]
[[File:TexGUI added cut locations.jpg|thumb|texGUI: Added horizontal and vertical cut locations.]]

It is generally a good idea to use descriptive names, such as "facade_industrial_old_white.png", but for this example we simply use "facade.png".

# Calibrate the image width/height. Find a feature in the image whose dimensions you know or can estimate. For example, simple windows are typically about 0.8 m wide. Here, we're using the aircon's width, estimated 0.82 m. Left drag to select that horizontal feature, then enter its length. Right drag for a vertical feature. You need only one of them. If both are given, both are used (e.g. if your image is stretched in one direction).
# Mark locations at which osm2city.py may cut the texture. Use left and right mouse buttons. Shift+click removes the last marker.
# Once you're satisfied, click "dump and quit". This writes calibration/cut data to a file "facade_24x19m.py". Note that texGUI added "_24x19m" to the texture file name (the original file is still in place), since you're likely to have more than one texture for an industrial facade.

== Texture metadata ==

Now edit facade_24x19m.py:

<syntaxhighlight lang="python">
facades.append(Texture('tex.src/facade_24x19m.png',
23.8, [364, 742, 1086], h_can_repeat=True,
18.5, [295, 565, 842], v_can_repeat=False,
v_align_bottom = True,
requires=[],
provides=[]))
</syntaxhighlight>

Usually you need to change very little here.
* You can set the texture to wrap around in at most one direction using ''h_can_repeat'' or ''v_can_repeat''
* If ''v_align_bottom'' is True, osm2city.py will align the bottom part of the texture with the ground and cut away the top part if neccessary. Otherwise, it will align the top part with the roof and cut away the bottom.

For reference, we now descibe the format in a bit more detail. You might want to skip to the [[Osm2city.py_Textures#Texture_compatibility|next section]].

First line is the path to our texture.
Second line says the texture
* is 23.8m wide
* can be cut at u = 364, 742, and 1068 px, where u is the horizontal coordinate. The last value 1086 also gives the width in px. Note that the .ac file uses normalized coordinates (0 ... 1). Internally, osm2city.py divides all coordinates by the last value. Therefore, when preparing the textures, you can work with the highest resolution possible and register those numbers, then just downscale the texture for actual flightgear use. Once the next generation of graphics cards arrives you just replace the textures with higher resolution ones without touching the cut locations.
* the texture can repeat in horizontal direction.

The third line gives the same information for the vertical direction:
* 18.5m height
* can cut at 295, 565, 842 px,
* the texture cannot repeat in vertical direction

== Texture compatibility ==

The fourth and fifth line state compatibility with other textures. TexGUI.py just creates an empty template here. A useful example could look like this:

<syntaxhighlight lang="python">
requires=['roof:color:black'],
provides=['shape:industrial','age:old','compat:roof-flat','compat:roof-gable']))
</syntaxhighlight>

This facade texture requires a black roof. It provides an old-aged, industrial facade, and is compatible with both flat and gable roofs. TODO: describe details on our requires/provides mechanism.

== Lightmap ==

A lightmap <del>is required for every texture, having</del>has the same file name with a postfix "_LM". So for our example this would be
"facade_24x19m_LM.png"

Osm2city uses
* red channel for window lights
* green channel for ambient street lights shining onto facade
* blue and alpha unused

TODO describe add_streetlight.py

== Install texture and lightmap ==
* copy texture and lightmap to tex.src/
* add the snippet from "facade_24x19m.py" to textures.py:init() starting around line 300

If you're adding a roof, name your texture "roof_something.png" and append it to the list of ''roofs'' (instead of ''facades'')
<syntaxhighlight lang="python">
roofs.append(Texture('tex.src/roof_something.png',
</syntaxhighlight>

See roof examples starting around line 400. Note that also roofs need a lightmap.

Finally, run
<syntaxhighlight lang="bash">
textures.py
</syntaxhighlight>

If there are no errors, your texture is registered and will be used next time you run osm2city.py. If your texture is GPL compatible, please consider
sending it (along with the meta data) to one of the osm2city.py devs to have it included in the official distribution.

[[Category:Modeling]]
[[Category:OpenStreetMap]]

Osm2city.py

2015-03-04T23:19:47Z

Radi: /* Probe elevation */ quote strings

{{OSM Navigation}}
[[File:LOWI with OSM buildings.jpg|thumb|LOWI with OSM buildings]]

This Python script takes OpenStreetMap floorplans and creates 3d buildings ready for use in FlightGear.

The development [https://gitorious.org/fg-radi/osm2city repository] is hosted on gitorious.
Forum thread [http://forum.flightgear.org/viewtopic.php?f=5&t=22809 osm2city.py development]
Written in Python 2.7, developed on GNU/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 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.

== News ==
=== Status 10/2014 ===
New features:
* textures reside in a separate [https://gitorious.org/fg-radi/osm2city-data repository]
* the recommended elevation probing method is ELEV_MODE=FgelevCaching
* roads.py is now quite usable
* SKIP_LIST can contain OSM_IDs

=== Status 06/2014 ===
I'm currently adding textured roads, railroads, intersections and bridges.

{{FGCquote
| the shader is now on osm2city's git (in fgdata/). Again -- all credit goes to Emilian. He is improving the shader side, I will continue on the model side. So this is very much work in progress. The shader requires the default renderer. No ALS/Rembrandt yet. Get the LOWI roads pack (including the shader) here: [https://dl.dropboxusercontent.com/u/24846517/fg/osm2city/LOWI_roads.tar.gz https://dl.dropboxusercontent.com/u/24846517/fg/osm2city/LOWI_roads.tar.gz] The fgdata/ folder goes to your $FGDATA. In roads.xml enable either the lightmap or the traffic shader.
|{{cite web |url=http://forum.flightgear.org/viewtopic.php?p=212460#p212460
|title=<nowiki>Re: osm2city.py development</nowiki>
|author=<nowiki>radi</nowiki>
|date=<nowiki>Fri Jun 13</nowiki>
}}
}}

{{FGCquote
|Creating your own road network is a bit cumbersome ATM, I'll try to make it more general in the next few days. But if you're really, really keen on it: <ul><li> get latest osm2city git</li><li> run roads.py -f your-parameters-file.</li><li> if you also create buildings, make sure to use the same BOUNDARY_* parameters for both osm2city.py and roads.py. Otherwise, buildings and roads might be misaligned. Basically, if your OSM file contains both roads and buildings, you can just use one parameters file.</li><li> roads.py will print an OBJECT_STATIC line, add this to your .stg (appears to add itself)</li><li> copy roads.ac to your scenery</li><li> copy roads.xml and tex/ from the LOWI roads pack to your scenery (roads.ac and .xml copy themselves)</li></ul>
|{{cite web |url=http://forum.flightgear.org/viewtopic.php?p=212460#p212460
|title=<nowiki>Re: osm2city.py development</nowiki>
|author=<nowiki>radi</nowiki>
|date=<nowiki>Fri Jun 13</nowiki>
}}
}}

=== Status 04/2014 ===
[[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. 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]]
The second scene, approaching LOWI from the east, went from 30 fps without buildings down to 20 fps.

=== Status 10/2013 ===
Currently data is processed offline beforehand. 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. <del>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.
</del> (Some optimization gave a huge speedup).

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
use some heuristics (some OSM buildings are labeled "Terminal 1" or so) to apply
terminal/hangar textures to buildings at airports. This way we could rather easily populate some airports with
'semi-generic' terminal/hangar buildings.

== Features ==
* 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 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)
* 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
:* ~10 different, hi-res facade textures, some roof textures
:* find matching texture for given building (number of levels, modern/old building, etc)
:* find matching roof texture for given facade texture
* basic lightmap support
* obstruction lights on tall buildings
* command line interface and parameters file (thanks to forum user vanosten)
* shows statistics on processed buildings
* 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 {{done}}
* 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|50}}
:* 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 ==
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
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 ==
* nearby hi-rise objects of similar shape get same texture? Probably too special a feature.
* 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 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 ==
1. dependencies: Install the following packages (names from Debian packages):
python-numpy python-shapely python-matplotlib python-scipy python-pil python-networkx
2. get [https://gitorious.org/fg-radi/osm2city osm2city] and [https://gitorious.org/fg-radi/osm2city-data osm2city-data] from gitorious

3. 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))

4. soft link osm2city-data/tex and osm2city-data/tex.src into osm2city/ such that it appears as a sub-directory of osm2city
<syntaxhighlight lang="bash">
osm2city/
tex.src/
tex/
osm2city.py
textures.py
...
</syntaxhighlight>

If you're running FG >= 3.3, or git newer than 10 Oct 2014, and have more than 4 GB RAM, you're done installing now. Otherwise, you will most likely need to set-up and use the old-fashioned way of elevation probing, which requires you to

5. copy elev.nas to $FGDATA/Nasal/

6. Open elev.nas in a text editor. Change the out variable to a directory with write access (e.g. $FG_HOME/Export). See [[IORules]] and [[$FG_HOME]]

== Install on Windows ==
In general, you'll want to follow the above install section. This section lists some additional Windows particularities.

Osm2city is pure python.

https://www.python.org/downloads/release/python-278/

{{caution|Python 2.7 is recommended unless you're an experienced Python developer willing to update the Python scripts to support Python 3. Also pay attention to versions and cpu builds of the below helper files. Make sure they match your OS build and Python version.}}

Install the following packages, then proceed with [[Osm2city.py#Install|step 2. above]].

http://www.lfd.uci.edu/~gohlke/pythonlibs/#numpy

http://www.lfd.uci.edu/~gohlke/pythonlibs/#shapely

http://www.lfd.uci.edu/~gohlke/pythonlibs/#scipy-stack

https://pypi.python.org/pypi/Pillow/2.5.0#downloads

== Workflow ==
There are five main steps:
* get OSM data
* adjust input file
* if neccessary, create elevation grid and run FG to probe elevation data.
* run osm2city
* <del>install the generated scenery</del>installs itself

We'll now walk through these steps in detail:
=== get OSM data ===
* decide on a region you want to populate. Get its lon/lat coordinates.
* create a project directory. We will use LOWI/ in this example.
* get corresponding OSM data in its native .xml format.
There are several options to get OSM data. You may find the [http://harrywood.co.uk/maps/uixapi/xapi.html XAPI Query Builder] helpful, it will generate a download URL that you can fetch with wget:
wget -O buildings.osm http://www.overpass-api.de/api/xapi?map?bbox=11.16898,47.20837,11.79108,47.38161

If you use [http://wiki.openstreetmap.org/wiki/Osmosis Osmosis] and cut the area with ''--bounding-box'' then you need to use ''completeWays=yes''.

Put this data into LOWI/buildings.osm

=== Adjust input file ===
* Now adjust the input file. You can generate a commented default parameters file by
<syntaxhighlight lang="bash">
parameters.py -d > LOWI/params.ini
</syntaxhighlight>

Edit this file, adjusting (at least) the following:
:* PREFIX = "LOWI" (the project directory)
:* BOUNDARY_EAST, BOUNDARY_NORTH, BOUNDARY_SOUTH, BOUNDARY_WEST
:* OSM_FILE = "buildings.osm"
:* set PATH_TO_SCENERY to a standard [[$FG_SCENERY]] path. This is the path where we'll get the elevation from. Most likely you'll want to use your TerraSync path here. Suppose the area you want to populate is /home/user/fgfs/scenery/TerraSync/Objects/e010n40/e011n47/, PATH_TO_SCENERY would then be "/home/user/fgfs/scenery/TerraSync" .
:* set PATH_TO_OUTPUT to a ''different'' scenery path, e.g. "/home/user/fgfs/scenery/osm2city" . Osm2city will generate its objects there. First, this avoids TerraSync overwriting the generated scenery. Second, you can easily remove that folder in case you're not happy with the result. Make sure to include that path in your [[$FG_SCENERY]].
:* you might want to set MAX_OBJECTS to a small number (say, 100) for your first try. This will limit the number of buildings parsed, and speed up the whole process.
:* you also need to set up elevation probing in the parameters file, described in the next section.

{{note|Python does not recognize environment variables, please use full paths in the parameters file (no $HOME etc).}}

=== Probe elevation ===
Probe elevation for your region. Pick one of the three available modes for ELEV_MODE in params.ini. If you have enough memory (4GB should be fine, but YMMV) and run FG git later than 10 Oct 2014, try FgelevCaching. Failing that, try Manual. (portreekid, what's the 3rd mode good for?)

{{caution|1=There are a lot of problems reported currently with fgelev. I can't really test for the next month or so. See troubleshooting or use ELEV_MODE = "Manual".}}

* ELEV_MODE = "FgelevCaching"
:* Set FG_ELEV to your fgelev executable. For example: FG_ELEV = "/usr/local/fg/bin/fgelev" or just FG_ELEV = "fgelev" if fgelev is already in your OS's path.
:* Set PATH_TO_SCENERY (Missing terrain will result in error message)
:* make sure the environment variable [[$FG ROOT]] points to your FG base path, (e.g. export FG_ROOT=/usr/share/games/flightgear/ on Linux)

* ELEV_MODE = "Manual"
:* run tools.py (tools.py -f LOWI/params.ini), this will create a file elev.in. Copy elev.in to $FG_ROOT/Nasal/
:* Open $FG_ROOT/Nasal/elev.nas in a text editor. Point the in variable to your elev.in file e.g. var in = "/path/to/$FG_ROOT/Nasal/elev.in".
:* tools.py will tell you to hide a certain scenery/Objects/... folder, to prevent probing elevation on top of existing objects. Simply rename the folder
:* run FG, open debug->nasal console, enter: elev.get_elevation(), press execute. Might take a long time, depending on the area scanned. This will write elevation data to /tmp/elev.out (which is actually just plain 5 column data: lon,lat,x,y,elevation). Put elev.out into LOWI/
:* unhide, rename the objects folder

* ELEV_MODE = "Telnet"
:* Run setup.py
:* Start FG with the properties service on Port 5501
:* Run tools.py, this will create a elev.in, start the nasal script and copy the elev.out back to your project directory

=== Run osm2city ===
* Make sure you're in osm2city's directory and run

python osm2city.py -f LOWI/params.ini.

The parsed OSM data is cached to file LOWI/buildings.osm.pkl which is used on next startup if you set USE_PKL = 1.
If all goes well, files like LOWIcity0101.ac and their corresponding .xml, along with .stg files, were created and moved to the correct location in $FG_SCENERY
* copy or link the tex/ folder into the objects folder where these files were created

=== Roads ===
* run roads.py in the same fashion for roads
* <del>copy roads.eff to the same Objects\e0XXnXX\e0XXnXX\ directory</del> roads.eff is copied automatically
* Band-aid fix for the roads is to adjust their height in roads.py change AGL_ofs to a higher number e.g. 0.5
* the moving cars (TRAFFIC_SHADER_ENABLE = True) are only visible when you disable Atmospheric light scattering (ALS)

== Support and troubleshooting ==
Time permitting, we can provide limited support on the [http://forum.flightgear.org/viewtopic.php?f=5&t=22809 Forums]. Please don't use PM for support questions.

Before you ask a question, make sure you read this wiki page. If your question is not covered here, tell us as much as possible about the problem you're facing. Which steps have you taken to solve it? What is the exact error message? What operating system? Screenshots?

We will not cover general questions like "I don't know how to install XY" -- search the Internet.

=== FGElev crashes ===

<syntaxhighlight lang="bash">
CRITICAL:root:1173 -95.5767 37.0965
CRITICAL:root:fgelev returned <>, resulting in list index out of range. Did fgelev start OK (Record : 1173)?
</syntaxhighlight>
The first line is the last input to fgelev.
Try running fgelev directly:
<syntaxhighlight lang="bash">
/path/to/fgelev --expire 1000 --fg-root $FG_ROOT --fg-scenery $FG_SCENERY
</syntaxhighlight>
then enter the line last sent to fgelev.
<syntaxhighlight lang="bash">
1173 -95.5767 37.0965
</syntaxhighlight>
The response should look like
<syntaxhighlight lang="bash">
1173: 226.793
</syntaxhighlight>

=== Buildings are generated, but they sit below the ground. I'm using ELEV_MODE = FgelevCaching. ===

Try running fgelev directly:
<syntaxhighlight lang="bash">
/path/to/fgelev --expire 1000 --fg-root $FG_ROOT --fg-scenery $FG_SCENERY
</syntaxhighlight>
then enter
<syntaxhighlight lang="bash">
0 $lon $lat
</syntaxhighlight>
where $lon and $lat are coordinates in the area you want to generate. See if it returns a sane value. If it does, double-check PATH_TO_SCENERY and $FG_ROOT.

=== Buildings/roads have no texture. I get errors "osgDB ac3d reader: could not find texture "tex/atlas_facades.png". ===

Copy or link the tex/ folder into the objects folder where the .stg files were created, such that you have $FG_SCENERY/Objects/eXXXnXX/eXXXnXX/tex/. Note that buildings might have been created in more than one folder, e.g. in e011n47 and e011n48. You must have a tex/ folder in each of them.

== Improve frame rate ==
* adjust LOD ranges in FG
* decrease MAX_OBJECTS, increase LOD_*
(- use larger/smaller tiles? Tradeoff between distance calculations/xml parsing and GPU)

== Contributing ==
You know some python? Or you're keen on writing docs? Contact radi on the FG forum.
None of the above? Take [[Howto:Create_textures_from_photos|pictures]] of buildings where you live and [[Osm2city.py Textures|create textures]]! I'm especially interested in south-east asian style architecture, as I'm planning to populate Hong Kong Kai Tak (VHXX) in the future.

== Related ==
* [[Using OSM Vector Data in FlightGear]]
* [[OpenStreetMap buildings]]
* [[AutoGen Scenery for FlightGear]]
* [[Random Buildings]]
* [http://forum.flightgear.org/viewtopic.php?f=5&t=21131#p192198 OSM buidings EHLE]
* [http://forum.flightgear.org/viewtopic.php?f=5&t=22809 osm2city.py development]
* [http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg40092.html Osm2city.py]
* http://forum.flightgear.org/viewtopic.php?f=5&t=19625
* [http://forum.flightgear.org/viewtopic.php?f=38&t=8837 PixelCity]
* [http://forum.flightgear.org/viewtopic.php?p=166794#p166681 Procedural OSM buildings]

[[Category:Scenery software]]

Osm2city.py

2015-03-04T23:17:56Z

Radi: /* Adjust input file */ new params file requires quoted strings

{{OSM Navigation}}
[[File:LOWI with OSM buildings.jpg|thumb|LOWI with OSM buildings]]

This Python script takes OpenStreetMap floorplans and creates 3d buildings ready for use in FlightGear.

The development [https://gitorious.org/fg-radi/osm2city repository] is hosted on gitorious.
Forum thread [http://forum.flightgear.org/viewtopic.php?f=5&t=22809 osm2city.py development]
Written in Python 2.7, developed on GNU/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 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.

== News ==
=== Status 10/2014 ===
New features:
* textures reside in a separate [https://gitorious.org/fg-radi/osm2city-data repository]
* the recommended elevation probing method is ELEV_MODE=FgelevCaching
* roads.py is now quite usable
* SKIP_LIST can contain OSM_IDs

=== Status 06/2014 ===
I'm currently adding textured roads, railroads, intersections and bridges.

{{FGCquote
| the shader is now on osm2city's git (in fgdata/). Again -- all credit goes to Emilian. He is improving the shader side, I will continue on the model side. So this is very much work in progress. The shader requires the default renderer. No ALS/Rembrandt yet. Get the LOWI roads pack (including the shader) here: [https://dl.dropboxusercontent.com/u/24846517/fg/osm2city/LOWI_roads.tar.gz https://dl.dropboxusercontent.com/u/24846517/fg/osm2city/LOWI_roads.tar.gz] The fgdata/ folder goes to your $FGDATA. In roads.xml enable either the lightmap or the traffic shader.
|{{cite web |url=http://forum.flightgear.org/viewtopic.php?p=212460#p212460
|title=<nowiki>Re: osm2city.py development</nowiki>
|author=<nowiki>radi</nowiki>
|date=<nowiki>Fri Jun 13</nowiki>
}}
}}

{{FGCquote
|Creating your own road network is a bit cumbersome ATM, I'll try to make it more general in the next few days. But if you're really, really keen on it: <ul><li> get latest osm2city git</li><li> run roads.py -f your-parameters-file.</li><li> if you also create buildings, make sure to use the same BOUNDARY_* parameters for both osm2city.py and roads.py. Otherwise, buildings and roads might be misaligned. Basically, if your OSM file contains both roads and buildings, you can just use one parameters file.</li><li> roads.py will print an OBJECT_STATIC line, add this to your .stg (appears to add itself)</li><li> copy roads.ac to your scenery</li><li> copy roads.xml and tex/ from the LOWI roads pack to your scenery (roads.ac and .xml copy themselves)</li></ul>
|{{cite web |url=http://forum.flightgear.org/viewtopic.php?p=212460#p212460
|title=<nowiki>Re: osm2city.py development</nowiki>
|author=<nowiki>radi</nowiki>
|date=<nowiki>Fri Jun 13</nowiki>
}}
}}

=== Status 04/2014 ===
[[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. 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]]
The second scene, approaching LOWI from the east, went from 30 fps without buildings down to 20 fps.

=== Status 10/2013 ===
Currently data is processed offline beforehand. 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. <del>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.
</del> (Some optimization gave a huge speedup).

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
use some heuristics (some OSM buildings are labeled "Terminal 1" or so) to apply
terminal/hangar textures to buildings at airports. This way we could rather easily populate some airports with
'semi-generic' terminal/hangar buildings.

== Features ==
* 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 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)
* 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
:* ~10 different, hi-res facade textures, some roof textures
:* find matching texture for given building (number of levels, modern/old building, etc)
:* find matching roof texture for given facade texture
* basic lightmap support
* obstruction lights on tall buildings
* command line interface and parameters file (thanks to forum user vanosten)
* shows statistics on processed buildings
* 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 {{done}}
* 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|50}}
:* 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 ==
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
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 ==
* nearby hi-rise objects of similar shape get same texture? Probably too special a feature.
* 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 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 ==
1. dependencies: Install the following packages (names from Debian packages):
python-numpy python-shapely python-matplotlib python-scipy python-pil python-networkx
2. get [https://gitorious.org/fg-radi/osm2city osm2city] and [https://gitorious.org/fg-radi/osm2city-data osm2city-data] from gitorious

3. 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))

4. soft link osm2city-data/tex and osm2city-data/tex.src into osm2city/ such that it appears as a sub-directory of osm2city
<syntaxhighlight lang="bash">
osm2city/
tex.src/
tex/
osm2city.py
textures.py
...
</syntaxhighlight>

If you're running FG >= 3.3, or git newer than 10 Oct 2014, and have more than 4 GB RAM, you're done installing now. Otherwise, you will most likely need to set-up and use the old-fashioned way of elevation probing, which requires you to

5. copy elev.nas to $FGDATA/Nasal/

6. Open elev.nas in a text editor. Change the out variable to a directory with write access (e.g. $FG_HOME/Export). See [[IORules]] and [[$FG_HOME]]

== Install on Windows ==
In general, you'll want to follow the above install section. This section lists some additional Windows particularities.

Osm2city is pure python.

https://www.python.org/downloads/release/python-278/

{{caution|Python 2.7 is recommended unless you're an experienced Python developer willing to update the Python scripts to support Python 3. Also pay attention to versions and cpu builds of the below helper files. Make sure they match your OS build and Python version.}}

Install the following packages, then proceed with [[Osm2city.py#Install|step 2. above]].

http://www.lfd.uci.edu/~gohlke/pythonlibs/#numpy

http://www.lfd.uci.edu/~gohlke/pythonlibs/#shapely

http://www.lfd.uci.edu/~gohlke/pythonlibs/#scipy-stack

https://pypi.python.org/pypi/Pillow/2.5.0#downloads

== Workflow ==
There are five main steps:
* get OSM data
* adjust input file
* if neccessary, create elevation grid and run FG to probe elevation data.
* run osm2city
* <del>install the generated scenery</del>installs itself

We'll now walk through these steps in detail:
=== get OSM data ===
* decide on a region you want to populate. Get its lon/lat coordinates.
* create a project directory. We will use LOWI/ in this example.
* get corresponding OSM data in its native .xml format.
There are several options to get OSM data. You may find the [http://harrywood.co.uk/maps/uixapi/xapi.html XAPI Query Builder] helpful, it will generate a download URL that you can fetch with wget:
wget -O buildings.osm http://www.overpass-api.de/api/xapi?map?bbox=11.16898,47.20837,11.79108,47.38161

If you use [http://wiki.openstreetmap.org/wiki/Osmosis Osmosis] and cut the area with ''--bounding-box'' then you need to use ''completeWays=yes''.

Put this data into LOWI/buildings.osm

=== Adjust input file ===
* Now adjust the input file. You can generate a commented default parameters file by
<syntaxhighlight lang="bash">
parameters.py -d > LOWI/params.ini
</syntaxhighlight>

Edit this file, adjusting (at least) the following:
:* PREFIX = "LOWI" (the project directory)
:* BOUNDARY_EAST, BOUNDARY_NORTH, BOUNDARY_SOUTH, BOUNDARY_WEST
:* OSM_FILE = "buildings.osm"
:* set PATH_TO_SCENERY to a standard [[$FG_SCENERY]] path. This is the path where we'll get the elevation from. Most likely you'll want to use your TerraSync path here. Suppose the area you want to populate is /home/user/fgfs/scenery/TerraSync/Objects/e010n40/e011n47/, PATH_TO_SCENERY would then be "/home/user/fgfs/scenery/TerraSync" .
:* set PATH_TO_OUTPUT to a ''different'' scenery path, e.g. "/home/user/fgfs/scenery/osm2city" . Osm2city will generate its objects there. First, this avoids TerraSync overwriting the generated scenery. Second, you can easily remove that folder in case you're not happy with the result. Make sure to include that path in your [[$FG_SCENERY]].
:* you might want to set MAX_OBJECTS to a small number (say, 100) for your first try. This will limit the number of buildings parsed, and speed up the whole process.
:* you also need to set up elevation probing in the parameters file, described in the next section.

{{note|Python does not recognize environment variables, please use full paths in the parameters file (no $HOME etc).}}

=== Probe elevation ===
Probe elevation for your region. Pick one of the three available modes for ELEV_MODE in params.ini. If you have enough memory (4GB should be fine, but YMMV) and run FG git later than 10 Oct 2014, try FgelevCaching. Failing that, try Manual. (portreekid, what's the 3rd mode good for?)

{{caution|1=There are a lot of problems reported currently with fgelev. I can't really test for the next month or so. See troubleshooting or use ELEV_MODE = Manual.}}

* ELEV_MODE = FgelevCaching
:* Set FG_ELEV to your fgelev executable. For example: FG_ELEV = /usr/local/fg/bin/fgelev or just FG_ELEV = fgelev if fgelev is already in your OS's path.
:* Set PATH_TO_SCENERY (Missing terrain will result in error message)
:* make sure the environment variable [[$FG ROOT]] points to your FG base path, (e.g. export FG_ROOT=/usr/share/games/flightgear/ on Linux)

* ELEV_MODE = Manual
:* run tools.py (tools.py -f LOWI/params.ini), this will create a file elev.in. Copy elev.in to $FG_ROOT/Nasal/
:* Open $FG_ROOT/Nasal/elev.nas in a text editor. Point the in variable to your elev.in file e.g. var in = "/path/to/$FG_ROOT/Nasal/elev.in".
:* tools.py will tell you to hide a certain scenery/Objects/... folder, to prevent probing elevation on top of existing objects. Simply rename the folder
:* run FG, open debug->nasal console, enter: elev.get_elevation(), press execute. Might take a long time, depending on the area scanned. This will write elevation data to /tmp/elev.out (which is actually just plain 5 column data: lon,lat,x,y,elevation). Put elev.out into LOWI/
:* unhide, rename the objects folder

* ELEV_MODE = Telnet
:* Run setup.py
:* Start FG with the properties service on Port 5501
:* Run tools.py, this will create a elev.in, start the nasal script and copy the elev.out back to your project directory

=== Run osm2city ===
* Make sure you're in osm2city's directory and run

python osm2city.py -f LOWI/params.ini.

The parsed OSM data is cached to file LOWI/buildings.osm.pkl which is used on next startup if you set USE_PKL = 1.
If all goes well, files like LOWIcity0101.ac and their corresponding .xml, along with .stg files, were created and moved to the correct location in $FG_SCENERY
* copy or link the tex/ folder into the objects folder where these files were created

=== Roads ===
* run roads.py in the same fashion for roads
* <del>copy roads.eff to the same Objects\e0XXnXX\e0XXnXX\ directory</del> roads.eff is copied automatically
* Band-aid fix for the roads is to adjust their height in roads.py change AGL_ofs to a higher number e.g. 0.5
* the moving cars (TRAFFIC_SHADER_ENABLE = True) are only visible when you disable Atmospheric light scattering (ALS)

== Support and troubleshooting ==
Time permitting, we can provide limited support on the [http://forum.flightgear.org/viewtopic.php?f=5&t=22809 Forums]. Please don't use PM for support questions.

Before you ask a question, make sure you read this wiki page. If your question is not covered here, tell us as much as possible about the problem you're facing. Which steps have you taken to solve it? What is the exact error message? What operating system? Screenshots?

We will not cover general questions like "I don't know how to install XY" -- search the Internet.

=== FGElev crashes ===

<syntaxhighlight lang="bash">
CRITICAL:root:1173 -95.5767 37.0965
CRITICAL:root:fgelev returned <>, resulting in list index out of range. Did fgelev start OK (Record : 1173)?
</syntaxhighlight>
The first line is the last input to fgelev.
Try running fgelev directly:
<syntaxhighlight lang="bash">
/path/to/fgelev --expire 1000 --fg-root $FG_ROOT --fg-scenery $FG_SCENERY
</syntaxhighlight>
then enter the line last sent to fgelev.
<syntaxhighlight lang="bash">
1173 -95.5767 37.0965
</syntaxhighlight>
The response should look like
<syntaxhighlight lang="bash">
1173: 226.793
</syntaxhighlight>

=== Buildings are generated, but they sit below the ground. I'm using ELEV_MODE = FgelevCaching. ===

Try running fgelev directly:
<syntaxhighlight lang="bash">
/path/to/fgelev --expire 1000 --fg-root $FG_ROOT --fg-scenery $FG_SCENERY
</syntaxhighlight>
then enter
<syntaxhighlight lang="bash">
0 $lon $lat
</syntaxhighlight>
where $lon and $lat are coordinates in the area you want to generate. See if it returns a sane value. If it does, double-check PATH_TO_SCENERY and $FG_ROOT.

=== Buildings/roads have no texture. I get errors "osgDB ac3d reader: could not find texture "tex/atlas_facades.png". ===

Copy or link the tex/ folder into the objects folder where the .stg files were created, such that you have $FG_SCENERY/Objects/eXXXnXX/eXXXnXX/tex/. Note that buildings might have been created in more than one folder, e.g. in e011n47 and e011n48. You must have a tex/ folder in each of them.

== Improve frame rate ==
* adjust LOD ranges in FG
* decrease MAX_OBJECTS, increase LOD_*
(- use larger/smaller tiles? Tradeoff between distance calculations/xml parsing and GPU)

== Contributing ==
You know some python? Or you're keen on writing docs? Contact radi on the FG forum.
None of the above? Take [[Howto:Create_textures_from_photos|pictures]] of buildings where you live and [[Osm2city.py Textures|create textures]]! I'm especially interested in south-east asian style architecture, as I'm planning to populate Hong Kong Kai Tak (VHXX) in the future.

== Related ==
* [[Using OSM Vector Data in FlightGear]]
* [[OpenStreetMap buildings]]
* [[AutoGen Scenery for FlightGear]]
* [[Random Buildings]]
* [http://forum.flightgear.org/viewtopic.php?f=5&t=21131#p192198 OSM buidings EHLE]
* [http://forum.flightgear.org/viewtopic.php?f=5&t=22809 osm2city.py development]
* [http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg40092.html Osm2city.py]
* http://forum.flightgear.org/viewtopic.php?f=5&t=19625
* [http://forum.flightgear.org/viewtopic.php?f=38&t=8837 PixelCity]
* [http://forum.flightgear.org/viewtopic.php?p=166794#p166681 Procedural OSM buildings]

[[Category:Scenery software]]

Howto:Convert objects from X-Plane

2015-02-16T05:27:41Z

Radi: Announce new scripts

This [[:Category:Howto|tutorial]] explains how to '''convert X-Plane scenery objects''' to the [[File Formats#.2A.ac|AC3D format]] (.ac) used by [[FlightGear]] (mostly) automatically using the xplane2fg collection of scripts. To convert '''Microsoft (R) Flight Simulator scenery objects''', first convert them to X-Plane format using [http://marginal.org.uk/x-planescenery/tools.html FS2XPlane], then follow the method described below.

'''Note: [[Howto:Convert objects with ModelConverterX|ModelConverterX]] also seems well suited for this task, having even more features and is probably easier to set up.'''

'''Note 2: MCX doesnt't work for me on Linux (tried with Wine + Mono). As of Feb 2015, I'm re-writing conversion scripts. The new version will come bundled with everything you need, be a lot easier to set-up, and be almost 100% automated.'''

These scripts were developed on Linux and should work fine on any Unix system including Mac ([[Howto: Convert objects from MSFS#Note to Windows Users|note to Windows users]]).

The conversion consists of three steps, all conveniently handled by scripts:
* convert the actual 3-D objects from .obj to .ac format using blender,
* extract position of objects (longitude, latitude, altitude, and heading) from .dsf file(s) and write them to FlightGear's .stg file(s),
* copy the objects and their textures to the respective tile folders.

This Howto assumes that you
* are able to use the command line to enter basic commands
* know where FlightGear, its scenery, and its source code are installed

'''Please note: objects that are uploaded to the [[FlightGear Scenery Database]] (and thus official FG scenery) must be released under the [[GNU GPL]] license. Most X-Plane/MSFS scenery does ''not'' comply with this license. Therefore, it cannot be included with the official scenery, unless the author granted you permission to release his work under GNU GPL. Basically, it mostly means that it is for your own private use only.'''

== Installation and setup ==
=== Prerequisites ===
Besides a Unix environment, you'll need the following tools:

* [http://ubuntuone.com/0sAOY4lB1OVCWP3zy8jfn8 xplane2fg]
* [http://www.blender.org Blender] (tested with ver. 2.48a-r3)
* XPlane2blender from [http://marginal.org.uk/x-planescenery/tools.html Jonathan Harris' page], tested with ver. 3.09
* [http://winehq.com Wine]
* [http://scenery.x-plane.com/tools.php X-Plane scenery tools]
* [[FlightGear]]
* perl helpers from FlightGear's [http://www.flightgear.org/Downloads/source.shtml source code]:
** calc-tile.pl
** find_elevations.pl
* telnet

Optionally (if the scenery to convert contains .dds textures)
* convert (from [http://www.imagemagick.org ImageMagick])

=== Installation ===
Install xplane2fg:

mkdir -p ~/fgfs/convert/
cd ~/fgfs/convert/
tar xzf /path/to/xplane2fg.tgz

Copy the autoimport.py helper to Blender's scripts folder:
cp ~/fgfs/convert/xplane2fg/lib/autoimport.py ~/.blender/scripts

Install X-Plane tools in $HOME/convert/xptools

=== Hack the tools ===
For the first step - importing objects into blender - we use Jonathan Harris' XPlane2Blender import filter. The .ac export filter shipped with Blender does the export. As we will batch convert a large number of objects, both import and export filters need to be 'hacked' as to not stop and wait for user interaction on warnings etc:

Open XPlaneImport.py in a text editor, change line 466 (of ver. 3.09) to:
self.verbose = 0
Save this file as XPlaneImportVerbose0.py

Open ac3d_export.py (part of Blender, located for example in /usr/share/blender/scripts/) in a text editor, replace line 823:
Blender.Draw.PupMenu('ERROR: no objects selected')
with
pass
Make sure you keep indention. Save this file as ac3d_export_hack.py

=== Setting up the environment according to your system ===
The xplane2fg scripts glue together a number of tools. To have the scripts find these tools, you have to adjust the paths in $HOME/fgfs/convert/xplane2fg/profile according to your system (using a text editor).

Now everything should be set up to actually convert scenery!

== Conversion ==
First load xplane2fg's environment profile:
source $HOME/fgfs/convert/xplane2fg/profile

=== Prepare X-Plane scenery ===
In the following, we assume the X-Plane scenery we want to convert is named EDDN (make sure it contains no spaces!) and lives in
$HOME/fgfs/convert/EDDN/
with the following sub folders
Earth nav data
objects
textures

Those sub folders may have slightly different names. If so, rename them to fit the above scheme. Remember that Unix file names are case sensitive.

=== Prepare FlightGear ===
X-Plane objects are positioned using [http://en.wikipedia.org/wiki/Above_ground_level AGL], while FlightGear's .stg files expect [http://en.wikipedia.org/wiki/Above_mean_sea_level AMSL]. We will use FlightGear to automatically query the elevation at the object's postition. Therefore, the corresponding scenery tile must be installed. Find out on which tile the scenery you want to convert is located. See [[Howto: Install scenery]] for details on how to install FlightGear scenery. The most convenient way may be to use [[TerraSync]].

=== Convert ===
Now run the main conversion script:
cd $HOME/fgfs/convert/
xplane2fg.sh EDDN EDDN.fg

The converted scenery will be written to the path indicated by the second argument, EDDN.fg. It should '''not''' point to FG's actual scenery paths.

After some seconds, this will stop and ask you to run blender. By that time, it should have created an input file for blender named
blender-autoimport-source.py
in the current directory.

Now open a second terminal and run blender from that directory.
cd $HOME/fgfs/convert
blender

Click file -> import -> autoimport, it should now convert all objects, this may take a while.
When finished, close blender (and the second terminal), and press {{Key press|Enter}} in the xplane2fg terminal.

xplane2fg will now fire up FlightGear. Press {{Key press|Enter}} when FlightGear is up and running.
The script then queries the elevation for all objects; this might take a while.
During this process, .stg files are written to their respective tile paths under EDDN.fg. Also, xplane2fg searches for texture files used by the scenery objects, copies them to EDDN.fg or complains in case they're missing.

When xplane2fg is finished, you should have something like
ls $HOME/fgfs/convert/EDDN.fg/Objects/e000n40/e006n46/
3056136.stg
3056139.stg
Terminal.ac
...

We're almost done!

=== Check textures ===
X-Plane may use .dds textures, which '''can''' be converted to .png format. However, following recent discussion on the developers mailing list, FlightGear/OSG can also use .dds textures. Hence, you may also skip this step. I have not tested using .dds textures with FlightGear. Your milage may vary.

Go to the converted scenery folder
cd EDDN.fg/Objects/e000n40/e006n46/
and run
check_and_fix_textures.sh *.ac
You may want to remove .dds files afterwards to save space:
rm *.dds

=== Integrate the converted files into FlightGear scenery ===
Finally you have to copy the converted scenery to FlightGear's scenery folder. Make sure to backup the respective scenery folder beforehand.

The .stg files should be '''appended''' instead of overwritten should they exist already in FlightGear's Scenery folder; otherwise you'll lose previously defined scenery objects. You may want to use a file manager such as Konqueror, Nautilus, or Midnight Commander for this step, as they tend to ask whether to overwrite or append existing files.

Now you can fire up FlightGear and enjoy the converted scenery!

== Final steps ==
=== Cleanup ===
Temporary files were written to $HOME/fgfs/convert/tmp. You can remove them now:
rm -rf $HOME/fgfs/convert/tmp

=== Share the converted scenery ===
If you want to publish the scenery you need to obtain authorization to do so from the scenery's original authors.

If you want it to be included in FlightGear's official scenery via the [[FlightGear Scenery Database]], the converted scenery (including all textures) must comply with the [[GNU GPL]].

=== Optional ===
You may use

xplane2fg.sh --prefix EDDN_ EDDN EDDN.fg

to prepend all converted objects with a prefix, e.g., EDDN_objectname.ac

=== Troubleshooting ===
xplane2fg.sh may complain about funny elevations reported by FlightGear:

WARNING: Zero alt for LSGS-grasss-1.ac?

I suspect this happens when a tile is just being loaded in background, as subsequent calls would return correct elevation. However, since we might query objects floating on water, I did not implement automatic retrying (yet). Instead, you should manually query these objects. Start Flightgear

xplane2fg.sh --run-fgfs

then run

xplane2fg.sh --query-alt LSGS-grasss-1.ac

which would return something like

OBJECT_STATIC LSGS-grasss-1.ac 7.3416857 46.2201743 482.24 357.99
in /e000n40/e007n46/3072521.stg

and correct the respective line in the indicated .stg file.

=== Note to Windows Users ===
I developed these scripts on Linux. They are written in bash and make heavy use of GNU utilities (sed, awk, grep etc.). Some helpers require Perl.
To run these scripts on Windows, you will need to install cygwin and perl (at least). You will have to fix some further issues yourself; the wine part, for example, is probably not necessary on Windows ;)

[[Category:Howto|Convert objects from X-Plane]]
[[Category:Scenery enhancement|Convert objects from X-Plane]]

Osm2city.py

2014-12-30T11:21:17Z

Radi: /* Support and troubleshooting */ included error msg, formatting

{{OSM Navigation}}
[[File:LOWI with OSM buildings.jpg|thumb|LOWI with OSM buildings]]

This Python script takes OpenStreetMap floorplans and creates 3d buildings ready for use in FlightGear.

The development [https://gitorious.org/fg-radi/osm2city repository] is hosted on gitorious.
Forum thread [http://forum.flightgear.org/viewtopic.php?f=5&t=22809 osm2city.py development]
Written in Python 2.7, developed on GNU/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 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.

== News ==
=== Status 10/2014 ===
New features:
* textures reside in a separate [https://gitorious.org/fg-radi/osm2city-data repository]
* the recommended elevation probing method is ELEV_MODE=FgelevCaching
* roads.py is now quite usable
* SKIP_LIST can contain OSM_IDs

=== Status 06/2014 ===
I'm currently adding textured roads, railroads, intersections and bridges.

{{FGCquote
| the shader is now on osm2city's git (in fgdata/). Again -- all credit goes to Emilian. He is improving the shader side, I will continue on the model side. So this is very much work in progress. The shader requires the default renderer. No ALS/Rembrandt yet. Get the LOWI roads pack (including the shader) here: [https://dl.dropboxusercontent.com/u/24846517/fg/osm2city/LOWI_roads.tar.gz https://dl.dropboxusercontent.com/u/24846517/fg/osm2city/LOWI_roads.tar.gz] The fgdata/ folder goes to your $FGDATA. In roads.xml enable either the lightmap or the traffic shader.
|{{cite web |url=http://forum.flightgear.org/viewtopic.php?p=212460#p212460
|title=<nowiki>Re: osm2city.py development</nowiki>
|author=<nowiki>radi</nowiki>
|date=<nowiki>Fri Jun 13</nowiki>
}}
}}

{{FGCquote
|Creating your own road network is a bit cumbersome ATM, I'll try to make it more general in the next few days. But if you're really, really keen on it: <ul><li> get latest osm2city git</li><li> run roads.py -f your-parameters-file.</li><li> if you also create buildings, make sure to use the same BOUNDARY_* parameters for both osm2city.py and roads.py. Otherwise, buildings and roads might be misaligned. Basically, if your OSM file contains both roads and buildings, you can just use one parameters file.</li><li> roads.py will print an OBJECT_STATIC line, add this to your .stg (appears to add itself)</li><li> copy roads.ac to your scenery</li><li> copy roads.xml and tex/ from the LOWI roads pack to your scenery (roads.ac and .xml copy themselves)</li></ul>
|{{cite web |url=http://forum.flightgear.org/viewtopic.php?p=212460#p212460
|title=<nowiki>Re: osm2city.py development</nowiki>
|author=<nowiki>radi</nowiki>
|date=<nowiki>Fri Jun 13</nowiki>
}}
}}

=== Status 04/2014 ===
[[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. 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]]
The second scene, approaching LOWI from the east, went from 30 fps without buildings down to 20 fps.

=== Status 10/2013 ===
Currently data is processed offline beforehand. 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. <del>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.
</del> (Some optimization gave a huge speedup).

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
use some heuristics (some OSM buildings are labeled "Terminal 1" or so) to apply
terminal/hangar textures to buildings at airports. This way we could rather easily populate some airports with
'semi-generic' terminal/hangar buildings.

== Features ==
* 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 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)
* 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
:* ~10 different, hi-res facade textures, some roof textures
:* find matching texture for given building (number of levels, modern/old building, etc)
:* find matching roof texture for given facade texture
* basic lightmap support
* obstruction lights on tall buildings
* command line interface and parameters file (thanks to forum user vanosten)
* shows statistics on processed buildings
* 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 {{done}}
* 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|50}}
:* 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 ==
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
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 ==
* nearby hi-rise objects of similar shape get same texture? Probably too special a feature.
* 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 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 ==
1. dependencies: Install the following packages (names from Debian packages):
python-numpy python-shapely python-matplotlib python-scipy python-pil python-networkx
2. get [https://gitorious.org/fg-radi/osm2city osm2city] and [https://gitorious.org/fg-radi/osm2city-data osm2city-data] from gitorious

3. 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))

4. soft link osm2city-data/tex and osm2city-data/tex.src into osm2city/ such that it appears as a sub-directory of osm2city
<syntaxhighlight lang="bash">
osm2city/
tex.src/
tex/
osm2city.py
textures.py
...
</syntaxhighlight>

If you're running FG >= 3.3, or git newer than 10 Oct 2014, and have more than 4 GB RAM, you're done installing now. Otherwise, you will most likely need to set-up and use the old-fashioned way of elevation probing, which requires you to

5. copy elev.nas to $FGDATA/Nasal/

6. Open elev.nas in a text editor. Change the out variable to a directory with write access (e.g. $FG_HOME/Export). See [[IORules]] and [[$FG_HOME]]

== Install on Windows ==
In general, you'll want to follow the above install section. This section lists some additional Windows particularities.

Osm2city is pure python.

https://www.python.org/downloads/release/python-278/

{{caution|Python 2.7 is recommended unless you're an experienced Python developer willing to update the Python scripts to support Python 3. Also pay attention to versions and cpu builds of the below helper files. Make sure they match your OS build and Python version.}}

Install the following packages, then proceed with [[Osm2city.py#Install|step 2. above]].

http://www.lfd.uci.edu/~gohlke/pythonlibs/#numpy

http://www.lfd.uci.edu/~gohlke/pythonlibs/#shapely

http://www.lfd.uci.edu/~gohlke/pythonlibs/#scipy-stack

https://pypi.python.org/pypi/Pillow/2.5.0#downloads

== Workflow ==
There are five main steps:
* get OSM data
* adjust input file
* if neccessary, create elevation grid and run FG to probe elevation data.
* run osm2city
* <del>install the generated scenery</del>installs itself

We'll now walk through these steps in detail:
=== get OSM data ===
* decide on a region you want to populate. Get its lon/lat coordinates.
* create a project directory. We will use LOWI/ in this example.
* get corresponding OSM data in its native .xml format.
There are several options to get OSM data. You may find the [http://harrywood.co.uk/maps/uixapi/xapi.html XAPI Query Builder] helpful, it will generate a download URL that you can fetch with wget:
wget -O buildings.osm http://www.overpass-api.de/api/xapi?map?bbox=11.16898,47.20837,11.79108,47.38161

If you use [http://wiki.openstreetmap.org/wiki/Osmosis Osmosis] and cut the area with ''--bounding-box'' then you need to use ''completeWays=yes''.

Put this data into LOWI/buildings.osm

=== Adjust input file ===
* Now adjust the input file. You can generate a commented default parameters file by
<syntaxhighlight lang="bash">
parameters.py -d > LOWI/params.ini
</syntaxhighlight>

Edit this file, adjusting (at least) the following:
:* PREFIX = LOWI (the project directory)
:* BOUNDARY_EAST, BOUNDARY_NORTH, BOUNDARY_SOUTH, BOUNDARY_WEST
:* OSM_FILE = buildings.osm
:* set PATH_TO_SCENERY to a standard [[$FG_SCENERY]] path. This is the path where we'll get the elevation from. Most likely you'll want to use your TerraSync path here. Suppose the area you want to populate is /home/user/fgfs/scenery/TerraSync/Objects/e010n40/e011n47/, PATH_TO_SCENERY would then be /home/user/fgfs/scenery/TerraSync .
:* set PATH_TO_OUTPUT to a ''different'' scenery path, e.g. /home/user/fgfs/scenery/osm2city . Osm2city will generate its objects there. First, this avoids TerraSync overwriting the generated scenery. Second, you can easily remove that folder in case you're not happy with the result. Make sure to include that path in your [[$FG_SCENERY]].
:* you might want to set MAX_OBJECTS to a small number (say, 100) for your first try. This will limit the number of buildings parsed, and speed up the whole process.
:* you also need to set up elevation probing in the parameters file, described in the next section.

{{note|Python does not recognize environment variables, please use full paths in the parameters file (no $HOME etc).}}

=== Probe elevation ===
Probe elevation for your region. Pick one of the three available modes for ELEV_MODE in params.ini. If you have enough memory (4GB should be fine, but YMMV) and run FG git later than 10 Oct 2014, try FgelevCaching. Failing that, try Manual. (portreekid, what's the 3rd mode good for?)

{{caution|1=There are a lot of problems reported currently with fgelev. I can't really test for the next month or so. See troubleshooting or use ELEV_MODE = Manual.}}

* ELEV_MODE = FgelevCaching
:* Set FG_ELEV to your fgelev executable. For example: FG_ELEV = /usr/local/fg/bin/fgelev or just FG_ELEV = fgelev if fgelev is already in your OS's path.
:* Set PATH_TO_SCENERY (Missing terrain will result in error message)
:* make sure the environment variable [[$FG ROOT]] points to your FG base path, (e.g. export FG_ROOT=/usr/share/games/flightgear/ on Linux)

* ELEV_MODE = Manual
:* run tools.py (tools.py -f LOWI/params.ini), this will create a file elev.in. Copy elev.in to $FGDATA/Nasal/
:* Open $FGDATA/Nasal/elev.nas in a text editor. Point the in variable to your elev.in file e.g. var in = "/path/to/$FG_DATA/Nasal/elev.in".
:* tools.py will tell you to hide a certain scenery/Objects/... folder, to prevent probing elevation on top of existing objects. Simply rename the folder
:* run FG, open debug->nasal console, enter: elev.get_elevation(), press execute. Might take a long time, depending on the area scanned. This will write elevation data to /tmp/elev.out (which is actually just plain 5 column data: lon,lat,x,y,elevation). Put elev.out into LOWI/
:* unhide, rename the objects folder

* ELEV_MODE = Telnet
:* Run setup.py
:* Start FG with the properties service on Port 5501
:* Run tools.py, this will create a elev.in, start the nasal script and copy the elev.out back to your project directory

=== Run osm2city ===
* Make sure you're in osm2city's directory and run

python osm2city.py -f LOWI/params.ini.

The parsed OSM data is cached to file LOWI/buildings.osm.pkl which is used on next startup if you set USE_PKL = 1.
If all goes well, files like LOWIcity0101.ac and their corresponding .xml, along with .stg files, were created and moved to the correct location in $FG_SCENERY
* copy or link the tex/ folder into the objects folder where these files were created

=== Roads ===
* run roads.py in the same fashion for roads
* <del>copy roads.eff to the same Objects\e0XXnXX\e0XXnXX\ directory</del> roads.eff is copied automatically
* Band-aid fix for the roads is to adjust their height in roads.py change AGL_ofs to a higher number e.g. 0.5
* the moving cars (TRAFFIC_SHADER_ENABLE = True) are only visible when you disable Atmospheric light scattering (ALS)

== Support and troubleshooting ==
Time permitting, we can provide limited support on the [http://forum.flightgear.org/viewtopic.php?f=5&t=22809 Forums]. Please don't use PM for support questions.

Before you ask a question, make sure you read this wiki page. If your question is not covered here, tell us as much as possible about the problem you're facing. Which steps have you taken to solve it? What is the exact error message? What operating system? Screenshots?

We will not cover general questions like "I don't know how to install XY" -- search the Internet.

=== FGElev crashes ===

<syntaxhighlight lang="bash">
CRITICAL:root:1173 -95.5767 37.0965
CRITICAL:root:fgelev returned <>, resulting in list index out of range. Did fgelev start OK (Record : 1173)?
</syntaxhighlight>
The first line is the last input to fgelev.
Try running fgelev directly:
<syntaxhighlight lang="bash">
/path/to/fgelev --expire 1000 --fg-root $FG_ROOT --fg-scenery $FG_SCENERY
</syntaxhighlight>
then enter the line last sent to fgelev.
<syntaxhighlight lang="bash">
1173 -95.5767 37.0965
</syntaxhighlight>
The response should look like
<syntaxhighlight lang="bash">
1173: 226.793
</syntaxhighlight>

=== Buildings are generated, but they sit below the ground. I'm using ELEV_MODE = FgelevCaching. ===

Try running fgelev directly:
<syntaxhighlight lang="bash">
/path/to/fgelev --expire 1000 --fg-root $FG_ROOT --fg-scenery $FG_SCENERY
</syntaxhighlight>
then enter
<syntaxhighlight lang="bash">
0 $lon $lat
</syntaxhighlight>
where $lon and $lat are coordinates in the area you want to generate. See if it returns a sane value. If it does, double-check PATH_TO_SCENERY and $FG_ROOT.

=== Buildings/roads have no texture. I get errors "osgDB ac3d reader: could not find texture "tex/atlas_facades.png". ===

Copy or link the tex/ folder into the objects folder where the .stg files were created, such that you have $FG_SCENERY/Objects/eXXXnXX/eXXXnXX/tex/. Note that buildings might have been created in more than one folder, e.g. in e011n47 and e011n48. You must have a tex/ folder in each of them.

== Improve frame rate ==
* adjust LOD ranges in FG
* decrease MAX_OBJECTS, increase LOD_*
(- use larger/smaller tiles? Tradeoff between distance calculations/xml parsing and GPU)

== Contributing ==
You know some python? Or you're keen on writing docs? Contact radi on the FG forum.
None of the above? Take [[Howto:Create_textures_from_photos|pictures]] of buildings where you live and [[Osm2city.py Textures|create textures]]! I'm especially interested in south-east asian style architecture, as I'm planning to populate Hong Kong Kai Tak (VHXX) in the future.

== Related ==
* [[Using OSM Vector Data in FlightGear]]
* [[OpenStreetMap buildings]]
* [[AutoGen Scenery for FlightGear]]
* [[Random Buildings]]
* [http://forum.flightgear.org/viewtopic.php?f=5&t=21131#p192198 OSM buidings EHLE]
* [http://forum.flightgear.org/viewtopic.php?f=5&t=22809 osm2city.py development]
* [http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg40092.html Osm2city.py]
* http://forum.flightgear.org/viewtopic.php?f=5&t=19625
* [http://forum.flightgear.org/viewtopic.php?f=38&t=8837 PixelCity]
* [http://forum.flightgear.org/viewtopic.php?p=166794#p166681 Procedural OSM buildings]

[[Category:Scenery software]]

Osm2city.py

2014-12-23T22:07:10Z

Radi: /* Run osm2city */ should run directly from osm2city's dir

{{OSM Navigation}}
[[File:LOWI with OSM buildings.jpg|thumb|LOWI with OSM buildings]]

This Python script takes OpenStreetMap floorplans and creates 3d buildings ready for use in FlightGear.

The development [https://gitorious.org/fg-radi/osm2city repository] is hosted on gitorious.
Forum thread [http://forum.flightgear.org/viewtopic.php?f=5&t=22809 osm2city.py development]
Written in Python 2.7, developed on GNU/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 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.

== News ==
=== Status 10/2014 ===
New features:
* textures reside in a separate [https://gitorious.org/fg-radi/osm2city-data repository]
* the recommended elevation probing method is ELEV_MODE=FgelevCaching
* roads.py is now quite usable
* SKIP_LIST can contain OSM_IDs

=== Status 06/2014 ===
I'm currently adding textured roads, railroads, intersections and bridges.

{{FGCquote
| the shader is now on osm2city's git (in fgdata/). Again -- all credit goes to Emilian. He is improving the shader side, I will continue on the model side. So this is very much work in progress. The shader requires the default renderer. No ALS/Rembrandt yet. Get the LOWI roads pack (including the shader) here: [https://dl.dropboxusercontent.com/u/24846517/fg/osm2city/LOWI_roads.tar.gz https://dl.dropboxusercontent.com/u/24846517/fg/osm2city/LOWI_roads.tar.gz] The fgdata/ folder goes to your $FGDATA. In roads.xml enable either the lightmap or the traffic shader.
|{{cite web |url=http://forum.flightgear.org/viewtopic.php?p=212460#p212460
|title=<nowiki>Re: osm2city.py development</nowiki>
|author=<nowiki>radi</nowiki>
|date=<nowiki>Fri Jun 13</nowiki>
}}
}}

{{FGCquote
|Creating your own road network is a bit cumbersome ATM, I'll try to make it more general in the next few days. But if you're really, really keen on it: <ul><li> get latest osm2city git</li><li> run roads.py -f your-parameters-file.</li><li> if you also create buildings, make sure to use the same BOUNDARY_* parameters for both osm2city.py and roads.py. Otherwise, buildings and roads might be misaligned. Basically, if your OSM file contains both roads and buildings, you can just use one parameters file.</li><li> roads.py will print an OBJECT_STATIC line, add this to your .stg (appears to add itself)</li><li> copy roads.ac to your scenery</li><li> copy roads.xml and tex/ from the LOWI roads pack to your scenery (roads.ac and .xml copy themselves)</li></ul>
|{{cite web |url=http://forum.flightgear.org/viewtopic.php?p=212460#p212460
|title=<nowiki>Re: osm2city.py development</nowiki>
|author=<nowiki>radi</nowiki>
|date=<nowiki>Fri Jun 13</nowiki>
}}
}}

=== Status 04/2014 ===
[[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. 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]]
The second scene, approaching LOWI from the east, went from 30 fps without buildings down to 20 fps.

=== Status 10/2013 ===
Currently data is processed offline beforehand. 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. <del>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.
</del> (Some optimization gave a huge speedup).

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
use some heuristics (some OSM buildings are labeled "Terminal 1" or so) to apply
terminal/hangar textures to buildings at airports. This way we could rather easily populate some airports with
'semi-generic' terminal/hangar buildings.

== Features ==
* 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 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)
* 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
:* ~10 different, hi-res facade textures, some roof textures
:* find matching texture for given building (number of levels, modern/old building, etc)
:* find matching roof texture for given facade texture
* basic lightmap support
* obstruction lights on tall buildings
* command line interface and parameters file (thanks to forum user vanosten)
* shows statistics on processed buildings
* 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 {{done}}
* 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|50}}
:* 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 ==
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
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 ==
* nearby hi-rise objects of similar shape get same texture? Probably too special a feature.
* 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 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 ==
1. dependencies: Install the following packages (names from Debian packages):
python-numpy python-shapely python-matplotlib python-scipy python-pil python-networkx
2. get [https://gitorious.org/fg-radi/osm2city osm2city] and [https://gitorious.org/fg-radi/osm2city-data osm2city-data] from gitorious

3. 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))

4. soft link osm2city-data/tex and osm2city-data/tex.src into osm2city/ such that it appears as a sub-directory of osm2city
<syntaxhighlight lang="bash">
osm2city/
tex.src/
tex/
osm2city.py
textures.py
...
</syntaxhighlight>

If you're running FG >= 3.3, or git newer than 10 Oct 2014, and have more than 4 GB RAM, you're done installing now. Otherwise, you will most likely need to set-up and use the old-fashioned way of elevation probing, which requires you to

5. copy elev.nas to $FGDATA/Nasal/

6. Open elev.nas in a text editor. Change the out variable to a directory with write access (e.g. $FG_HOME/Export). See [[IORules]] and [[$FG_HOME]]

== Install on Windows ==
In general, you'll want to follow the above install section. This section lists some additional Windows particularities.

Osm2city is pure python.

https://www.python.org/downloads/release/python-278/

{{warning|Python 2.7 is recommended unless you're an experienced Python developer willing to update the Python scripts to support Python 3. Also pay attention to versions and cpu builds of the below helper files. Make sure they match your OS build and Python version.}}

Install the following packages, then proceed with [[Osm2city.py#Install|step 2. above]].

http://www.lfd.uci.edu/~gohlke/pythonlibs/#numpy

http://www.lfd.uci.edu/~gohlke/pythonlibs/#shapely

http://www.lfd.uci.edu/~gohlke/pythonlibs/#scipy-stack

https://pypi.python.org/pypi/Pillow/2.5.0#downloads

== Workflow ==
There are five main steps:
* get OSM data
* adjust input file
* if neccessary, create elevation grid and run FG to probe elevation data.
* run osm2city
* <del>install the generated scenery</del>installs itself

We'll now walk through these steps in detail:
=== get OSM data ===
* decide on a region you want to populate. Get its lon/lat coordinates.
* create a project directory. We will use LOWI/ in this example.
* get corresponding OSM data in its native .xml format.
There are several options to get OSM data. You may find the [http://harrywood.co.uk/maps/uixapi/xapi.html XAPI Query Builder] helpful, it will generate a download URL that you can fetch with wget:
wget -O buildings.osm http://www.overpass-api.de/api/xapi?map?bbox=11.16898,47.20837,11.79108,47.38161

If you use [http://wiki.openstreetmap.org/wiki/Osmosis Osmosis] and cut the area with ''--bounding-box'' then you need to use ''completeWays=yes''.

Put this data into LOWI/buildings.osm

=== Adjust input file ===
* Now adjust the input file. You can generate a commented default parameters file by
<syntaxhighlight lang="bash">
parameters.py -d > LOWI/params.ini
</syntaxhighlight>

Edit this file, adjusting (at least) the following:
:* PREFIX = LOWI (the project directory)
:* BOUNDARY_EAST, BOUNDARY_NORTH, BOUNDARY_SOUTH, BOUNDARY_WEST
:* OSM_FILE = buildings.osm
:* set PATH_TO_SCENERY to a standard [[$FG_SCENERY]] path. This is the path where we'll get the elevation from. Most likely you'll want to use your TerraSync path here. Suppose the area you want to populate is /home/user/fgfs/scenery/TerraSync/Objects/e010n40/e011n47/, PATH_TO_SCENERY would then be /home/user/fgfs/scenery/TerraSync .
:* set PATH_TO_OUTPUT to a ''different'' scenery path, e.g. /home/user/fgfs/scenery/osm2city . Osm2city will generate its objects there. First, this avoids TerraSync overwriting the generated scenery. Second, you can easily remove that folder in case you're not happy with the result. Make sure to include that path in your [[$FG_SCENERY]].
:* you might want to set MAX_OBJECTS to a small number (say, 100) for your first try. This will limit the number of buildings parsed, and speed up the whole process.
:* you also need to set up elevation probing in the parameters file, described in the next section.

=== Probe elevation ===
Probe elevation for your region. Pick one of the three available modes for ELEV_MODE in params.ini. If you have enough memory (4GB should be fine, but YMMV) and run FG git later than 10 Oct 2014, try FgelevCaching. Failing that, try Manual. (portreekid, what's the 3rd mode good for?)

'''There are a lot of problems reported currently with fgelev. I can't really test for the next month or so. See troubleshooting or use ELEV_MODE = Manual.'''

* ELEV_MODE = FgelevCaching
:* Set FG_ELEV to your fgelev executable. For example: FG_ELEV = /usr/local/fg/bin/fgelev or just FG_ELEV = fgelev if fgelev is already in your OS's path.
:* Set PATH_TO_SCENERY (Missing terrain will result in error message)
:* make sure the environment variable [[$FG ROOT]] points to your FG base path, (e.g. export FG_ROOT=/usr/share/games/flightgear/ on Linux)

* ELEV_MODE = Manual
:* run tools.py (tools.py -f LOWI/params.ini), this will create a file elev.in. Copy elev.in to $FGDATA/Nasal/
:* Open $FGDATA/Nasal/elev.nas in a text editor. Point the in variable to your elev.in file e.g. var in = "/path/to/$FG_DATA/Nasal/elev.in".
:* tools.py will tell you to hide a certain scenery/Objects/... folder, to prevent probing elevation on top of existing objects. Simply rename the folder
:* run FG, open debug->nasal console, enter: elev.get_elevation(), press execute. Might take a long time, depending on the area scanned. This will write elevation data to /tmp/elev.out (which is actually just plain 5 column data: lon,lat,x,y,elevation). Put elev.out into LOWI/
:* unhide, rename the objects folder

* ELEV_MODE = Telnet
:* Run setup.py
:* Start FG with the properties service on Port 5501
:* Run tools.py, this will create a elev.in, start the nasal script and copy the elev.out back to your project directory

=== Run osm2city ===
* Make sure you're in osm2city's directory and run

python osm2city.py -f LOWI/params.ini.

The parsed OSM data is cached to file LOWI/buildings.osm.pkl which is used on next startup if you set USE_PKL = 1.
If all goes well, files like LOWIcity0101.ac and their corresponding .xml, along with .stg files, were created and moved to the correct location in $FG_SCENERY
* copy or link the tex/ folder into the objects folder where these files were created

=== Roads ===
* run roads.py in the same fashion for roads
* <del>copy roads.eff to the same Objects\e0XXnXX\e0XXnXX\ directory</del> roads.eff is copied automatically
* Band-aid fix for the roads is to adjust their height in roads.py change AGL_ofs to a higher number e.g. 0.5
* the moving cars (TRAFFIC_SHADER_ENABLE = True) are only visible when you disable Atmospheric light scattering (ALS)

== Support and troubleshooting ==
Time permitting, we can provide limited support on the [http://forum.flightgear.org/viewtopic.php?f=5&t=22809 Forums]. Please don't use PM for support questions.

Before you ask a question, make sure you read this wiki page. If your question is not covered here, tell us as much as possible about the problem you're facing. Which steps have you taken to solve it? What is the exact error message? What operating system? Screenshots?

We will not cover general questions like "I don't know how to install XY" -- search the Internet.

* FGElev crashes

<syntaxhighlight lang="bash">
CRITICAL:root:1173 -95.5767 37.0965
CRITICAL:root:fgelev returned <>, resulting in list index out of range. Did fgelev start OK (Record : 1173)?
</syntaxhighlight>
The first line is the last input to fgelev.
Try running fgelev directly:
<syntaxhighlight lang="bash">
/path/to/fgelev --expire 1000 --fg-root $FG_ROOT --fg-scenery $FG_SCENERY
</syntaxhighlight>
then enter the line last sent to fgelev.
<syntaxhighlight lang="bash">
1173 -95.5767 37.0965
</syntaxhighlight>
The response should look like
<syntaxhighlight lang="bash">
1173: 226.793
</syntaxhighlight>

* Buildings are generated, but they sit below the ground. I'm using ELEV_MODE = FgelevCaching.

Try running fgelev directly:
<syntaxhighlight lang="bash">
/path/to/fgelev --expire 1000 --fg-root $FG_ROOT --fg-scenery $FG_SCENERY
</syntaxhighlight>
then enter
<syntaxhighlight lang="bash">
0 $lon $lat
</syntaxhighlight>
where $lon and $lat are coordinates in the area you want to generate. See if it returns a sane value. If it does, double-check PATH_TO_SCENERY and $FG_ROOT.

* Buildings/roads have no texture.
copy or link the tex/ folder into the objects folder where the .stg files were created, such that you have $FG_SCENERY/Objects/eXXXnXX/eXXXnXX/tex/.

== Improve frame rate ==
* adjust LOD ranges in FG
* decrease MAX_OBJECTS, increase LOD_*
(- use larger/smaller tiles? Tradeoff between distance calculations/xml parsing and GPU)

== Contributing ==
You know some python? Or you're keen on writing docs? Contact radi on the FG forum.
None of the above? Take [[Howto:Create_textures_from_photos|pictures]] of buildings where you live and [[Osm2city.py Textures|create textures]]! I'm especially interested in south-east asian style architecture, as I'm planning to populate Hong Kong Kai Tak (VHXX) in the future.

== Related ==
* [[Using OSM Vector Data in FlightGear]]
* [[OpenStreetMap buildings]]
* [[AutoGen Scenery for FlightGear]]
* [[Random Buildings]]
* [http://forum.flightgear.org/viewtopic.php?f=5&t=21131#p192198 OSM buidings EHLE]
* [http://forum.flightgear.org/viewtopic.php?f=5&t=22809 osm2city.py development]
* [http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg40092.html Osm2city.py]
* http://forum.flightgear.org/viewtopic.php?f=5&t=19625
* [http://forum.flightgear.org/viewtopic.php?f=38&t=8837 PixelCity]
* [http://forum.flightgear.org/viewtopic.php?p=166794#p166681 Procedural OSM buildings]

[[Category:Scenery software]]

Osm2city.py

2014-12-23T21:42:35Z

Radi: clarified tex.src/ instructions

{{OSM Navigation}}
[[File:LOWI with OSM buildings.jpg|thumb|LOWI with OSM buildings]]

This Python script takes OpenStreetMap floorplans and creates 3d buildings ready for use in FlightGear.

The development [https://gitorious.org/fg-radi/osm2city repository] is hosted on gitorious.
Forum thread [http://forum.flightgear.org/viewtopic.php?f=5&t=22809 osm2city.py development]
Written in Python 2.7, developed on GNU/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 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.

== News ==
=== Status 10/2014 ===
New features:
* textures reside in a separate [https://gitorious.org/fg-radi/osm2city-data repository]
* the recommended elevation probing method is ELEV_MODE=FgelevCaching
* roads.py is now quite usable
* SKIP_LIST can contain OSM_IDs

=== Status 06/2014 ===
I'm currently adding textured roads, railroads, intersections and bridges.

{{FGCquote
| the shader is now on osm2city's git (in fgdata/). Again -- all credit goes to Emilian. He is improving the shader side, I will continue on the model side. So this is very much work in progress. The shader requires the default renderer. No ALS/Rembrandt yet. Get the LOWI roads pack (including the shader) here: [https://dl.dropboxusercontent.com/u/24846517/fg/osm2city/LOWI_roads.tar.gz https://dl.dropboxusercontent.com/u/24846517/fg/osm2city/LOWI_roads.tar.gz] The fgdata/ folder goes to your $FGDATA. In roads.xml enable either the lightmap or the traffic shader.
|{{cite web |url=http://forum.flightgear.org/viewtopic.php?p=212460#p212460
|title=<nowiki>Re: osm2city.py development</nowiki>
|author=<nowiki>radi</nowiki>
|date=<nowiki>Fri Jun 13</nowiki>
}}
}}

{{FGCquote
|Creating your own road network is a bit cumbersome ATM, I'll try to make it more general in the next few days. But if you're really, really keen on it: <ul><li> get latest osm2city git</li><li> run roads.py -f your-parameters-file.</li><li> if you also create buildings, make sure to use the same BOUNDARY_* parameters for both osm2city.py and roads.py. Otherwise, buildings and roads might be misaligned. Basically, if your OSM file contains both roads and buildings, you can just use one parameters file.</li><li> roads.py will print an OBJECT_STATIC line, add this to your .stg (appears to add itself)</li><li> copy roads.ac to your scenery</li><li> copy roads.xml and tex/ from the LOWI roads pack to your scenery (roads.ac and .xml copy themselves)</li></ul>
|{{cite web |url=http://forum.flightgear.org/viewtopic.php?p=212460#p212460
|title=<nowiki>Re: osm2city.py development</nowiki>
|author=<nowiki>radi</nowiki>
|date=<nowiki>Fri Jun 13</nowiki>
}}
}}

=== Status 04/2014 ===
[[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. 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]]
The second scene, approaching LOWI from the east, went from 30 fps without buildings down to 20 fps.

=== Status 10/2013 ===
Currently data is processed offline beforehand. 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. <del>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.
</del> (Some optimization gave a huge speedup).

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
use some heuristics (some OSM buildings are labeled "Terminal 1" or so) to apply
terminal/hangar textures to buildings at airports. This way we could rather easily populate some airports with
'semi-generic' terminal/hangar buildings.

== Features ==
* 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 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)
* 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
:* ~10 different, hi-res facade textures, some roof textures
:* find matching texture for given building (number of levels, modern/old building, etc)
:* find matching roof texture for given facade texture
* basic lightmap support
* obstruction lights on tall buildings
* command line interface and parameters file (thanks to forum user vanosten)
* shows statistics on processed buildings
* 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 {{done}}
* 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|50}}
:* 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 ==
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
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 ==
* nearby hi-rise objects of similar shape get same texture? Probably too special a feature.
* 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 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 ==
1. dependencies: Install the following packages (names from Debian packages):
python-numpy python-shapely python-matplotlib python-scipy python-pil python-networkx
2. get [https://gitorious.org/fg-radi/osm2city osm2city] and [https://gitorious.org/fg-radi/osm2city-data osm2city-data] from gitorious

3. 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))

4. soft link osm2city-data/tex and osm2city-data/tex.src into osm2city/ such that it appears as a sub-directory of osm2city
<syntaxhighlight lang="bash">
osm2city/
tex.src/
tex/
osm2city.py
textures.py
...
</syntaxhighlight>

If you're running FG >= 3.3, or git newer than 10 Oct 2014, and have more than 4 GB RAM, you're done installing now. Otherwise, you will most likely need to set-up and use the old-fashioned way of elevation probing, which requires you to

5. copy elev.nas to $FGDATA/Nasal/

6. Open elev.nas in a text editor. Change the out variable to a directory with write access (e.g. $FG_HOME/Export). See [[IORules]] and [[$FG_HOME]]

== Install on Windows ==
In general, you'll want to follow the above install section. This section lists some additional Windows particularities.

Osm2city is pure python.

https://www.python.org/downloads/release/python-278/

{{warning|Python 2.7 is recommended unless you're an experienced Python developer willing to update the Python scripts to support Python 3. Also pay attention to versions and cpu builds of the below helper files. Make sure they match your OS build and Python version.}}

Install the following packages, then proceed with [[Osm2city.py#Install|step 2. above]].

http://www.lfd.uci.edu/~gohlke/pythonlibs/#numpy

http://www.lfd.uci.edu/~gohlke/pythonlibs/#shapely

http://www.lfd.uci.edu/~gohlke/pythonlibs/#scipy-stack

https://pypi.python.org/pypi/Pillow/2.5.0#downloads

== Workflow ==
There are five main steps:
* get OSM data
* adjust input file
* if neccessary, create elevation grid and run FG to probe elevation data.
* run osm2city
* <del>install the generated scenery</del>installs itself

We'll now walk through these steps in detail:
=== get OSM data ===
* decide on a region you want to populate. Get its lon/lat coordinates.
* create a project directory. We will use LOWI/ in this example.
* get corresponding OSM data in its native .xml format.
There are several options to get OSM data. You may find the [http://harrywood.co.uk/maps/uixapi/xapi.html XAPI Query Builder] helpful, it will generate a download URL that you can fetch with wget:
wget -O buildings.osm http://www.overpass-api.de/api/xapi?map?bbox=11.16898,47.20837,11.79108,47.38161

If you use [http://wiki.openstreetmap.org/wiki/Osmosis Osmosis] and cut the area with ''--bounding-box'' then you need to use ''completeWays=yes''.

Put this data into LOWI/buildings.osm

=== Adjust input file ===
* Now adjust the input file. You can generate a commented default parameters file by
<syntaxhighlight lang="bash">
parameters.py -d > LOWI/params.ini
</syntaxhighlight>

Edit this file, adjusting (at least) the following:
:* PREFIX = LOWI (the project directory)
:* BOUNDARY_EAST, BOUNDARY_NORTH, BOUNDARY_SOUTH, BOUNDARY_WEST
:* OSM_FILE = buildings.osm
:* set PATH_TO_SCENERY to a standard [[$FG_SCENERY]] path. This is the path where we'll get the elevation from. Most likely you'll want to use your TerraSync path here. Suppose the area you want to populate is /home/user/fgfs/scenery/TerraSync/Objects/e010n40/e011n47/, PATH_TO_SCENERY would then be /home/user/fgfs/scenery/TerraSync .
:* set PATH_TO_OUTPUT to a ''different'' scenery path, e.g. /home/user/fgfs/scenery/osm2city . Osm2city will generate its objects there. First, this avoids TerraSync overwriting the generated scenery. Second, you can easily remove that folder in case you're not happy with the result. Make sure to include that path in your [[$FG_SCENERY]].
:* you might want to set MAX_OBJECTS to a small number (say, 100) for your first try. This will limit the number of buildings parsed, and speed up the whole process.
:* you also need to set up elevation probing in the parameters file, described in the next section.

=== Probe elevation ===
Probe elevation for your region. Pick one of the three available modes for ELEV_MODE in params.ini. If you have enough memory (4GB should be fine, but YMMV) and run FG git later than 10 Oct 2014, try FgelevCaching. Failing that, try Manual. (portreekid, what's the 3rd mode good for?)

'''There are a lot of problems reported currently with fgelev. I can't really test for the next month or so. See troubleshooting or use ELEV_MODE = Manual.'''

* ELEV_MODE = FgelevCaching
:* Set FG_ELEV to your fgelev executable. For example: FG_ELEV = /usr/local/fg/bin/fgelev or just FG_ELEV = fgelev if fgelev is already in your OS's path.
:* Set PATH_TO_SCENERY (Missing terrain will result in error message)
:* make sure the environment variable [[$FG ROOT]] points to your FG base path, (e.g. export FG_ROOT=/usr/share/games/flightgear/ on Linux)

* ELEV_MODE = Manual
:* run tools.py (tools.py -f LOWI/params.ini), this will create a file elev.in. Copy elev.in to $FGDATA/Nasal/
:* Open $FGDATA/Nasal/elev.nas in a text editor. Point the in variable to your elev.in file e.g. var in = "/path/to/$FG_DATA/Nasal/elev.in".
:* tools.py will tell you to hide a certain scenery/Objects/... folder, to prevent probing elevation on top of existing objects. Simply rename the folder
:* run FG, open debug->nasal console, enter: elev.get_elevation(), press execute. Might take a long time, depending on the area scanned. This will write elevation data to /tmp/elev.out (which is actually just plain 5 column data: lon,lat,x,y,elevation). Put elev.out into LOWI/
:* unhide, rename the objects folder

* ELEV_MODE = Telnet
:* Run setup.py
:* Start FG with the properties service on Port 5501
:* Run tools.py, this will create a elev.in, start the nasal script and copy the elev.out back to your project directory

=== Run osm2city ===
* run osm2city.py -f LOWI/prams.ini. Parsing OSM data <del>again takes quite looong (10 minutes or more for 50k buildings)</del> is now pretty fast, but the result is cached to file buildings.pkl. Next startup will be <del>much faster if you move buildings.pkl to LOWI/buildings.pkl and</del> even faster if you set USE_PKL = 1.

If all goes well, files like LOWIcity0101.ac and their corresponding .xml, along with .stg files, were created and moved to the correct location in $FG_SCENERY
* copy or link the tex/ folder into the objects folder where these files were created

=== Roads ===
* run roads.py in the same fashion for roads
* <del>copy roads.eff to the same Objects\e0XXnXX\e0XXnXX\ directory</del> roads.eff is copied automatically
* Band-aid fix for the roads is to adjust their height in roads.py change AGL_ofs to a higher number e.g. 0.5
* the moving cars (TRAFFIC_SHADER_ENABLE = True) are only visible when you disable Atmospheric light scattering (ALS)

== Support and troubleshooting ==
Time permitting, we can provide limited support on the [http://forum.flightgear.org/viewtopic.php?f=5&t=22809 Forums]. Please don't use PM for support questions.

Before you ask a question, make sure you read this wiki page. If your question is not covered here, tell us as much as possible about the problem you're facing. Which steps have you taken to solve it? What is the exact error message? What operating system? Screenshots?

We will not cover general questions like "I don't know how to install XY" -- search the Internet.

* FGElev crashes

<syntaxhighlight lang="bash">
CRITICAL:root:1173 -95.5767 37.0965
CRITICAL:root:fgelev returned <>, resulting in list index out of range. Did fgelev start OK (Record : 1173)?
</syntaxhighlight>
The first line is the last input to fgelev.
Try running fgelev directly:
<syntaxhighlight lang="bash">
/path/to/fgelev --expire 1000 --fg-root $FG_ROOT --fg-scenery $FG_SCENERY
</syntaxhighlight>
then enter the line last sent to fgelev.
<syntaxhighlight lang="bash">
1173 -95.5767 37.0965
</syntaxhighlight>
The response should look like
<syntaxhighlight lang="bash">
1173: 226.793
</syntaxhighlight>

* Buildings are generated, but they sit below the ground. I'm using ELEV_MODE = FgelevCaching.

Try running fgelev directly:
<syntaxhighlight lang="bash">
/path/to/fgelev --expire 1000 --fg-root $FG_ROOT --fg-scenery $FG_SCENERY
</syntaxhighlight>
then enter
<syntaxhighlight lang="bash">
0 $lon $lat
</syntaxhighlight>
where $lon and $lat are coordinates in the area you want to generate. See if it returns a sane value. If it does, double-check PATH_TO_SCENERY and $FG_ROOT.

* Buildings/roads have no texture.
copy or link the tex/ folder into the objects folder where the .stg files were created, such that you have $FG_SCENERY/Objects/eXXXnXX/eXXXnXX/tex/.

== Improve frame rate ==
* adjust LOD ranges in FG
* decrease MAX_OBJECTS, increase LOD_*
(- use larger/smaller tiles? Tradeoff between distance calculations/xml parsing and GPU)

== Contributing ==
You know some python? Or you're keen on writing docs? Contact radi on the FG forum.
None of the above? Take [[Howto:Create_textures_from_photos|pictures]] of buildings where you live and [[Osm2city.py Textures|create textures]]! I'm especially interested in south-east asian style architecture, as I'm planning to populate Hong Kong Kai Tak (VHXX) in the future.

== Related ==
* [[Using OSM Vector Data in FlightGear]]
* [[OpenStreetMap buildings]]
* [[AutoGen Scenery for FlightGear]]
* [[Random Buildings]]
* [http://forum.flightgear.org/viewtopic.php?f=5&t=21131#p192198 OSM buidings EHLE]
* [http://forum.flightgear.org/viewtopic.php?f=5&t=22809 osm2city.py development]
* [http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg40092.html Osm2city.py]
* http://forum.flightgear.org/viewtopic.php?f=5&t=19625
* [http://forum.flightgear.org/viewtopic.php?f=38&t=8837 PixelCity]
* [http://forum.flightgear.org/viewtopic.php?p=166794#p166681 Procedural OSM buildings]

[[Category:Scenery software]]

Osm2city.py

2014-11-20T19:40:35Z

Radi: Undo revision 77917 by Radi (talk)

{{OSM Navigation}}
[[File:LOWI with OSM buildings.jpg|thumb|LOWI with OSM buildings]]

This Python script takes OpenStreetMap floorplans and creates 3d buildings ready for use in FlightGear.

The development [https://gitorious.org/fg-radi/osm2city repository] is hosted on gitorious.
Forum thread [http://forum.flightgear.org/viewtopic.php?f=5&t=22809 osm2city.py development]
Written in Python 2.7, developed on GNU/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 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.

== News ==
=== Status 10/2014 ===
New features:
* textures reside in a separate [https://gitorious.org/fg-radi/osm2city-data repository]
* the recommended elevation probing method is ELEV_MODE=FgelevCaching
* roads.py is now quite usable
* SKIP_LIST can contain OSM_IDs

=== Status 06/2014 ===
I'm currently adding textured roads, railroads, intersections and bridges.

{{FGCquote
| the shader is now on osm2city's git (in fgdata/). Again -- all credit goes to Emilian. He is improving the shader side, I will continue on the model side. So this is very much work in progress. The shader requires the default renderer. No ALS/Rembrandt yet. Get the LOWI roads pack (including the shader) here: [https://dl.dropboxusercontent.com/u/24846517/fg/osm2city/LOWI_roads.tar.gz https://dl.dropboxusercontent.com/u/24846517/fg/osm2city/LOWI_roads.tar.gz] The fgdata/ folder goes to your $FGDATA. In roads.xml enable either the lightmap or the traffic shader.
|{{cite web |url=http://forum.flightgear.org/viewtopic.php?p=212460#p212460
|title=<nowiki>Re: osm2city.py development</nowiki>
|author=<nowiki>radi</nowiki>
|date=<nowiki>Fri Jun 13</nowiki>
}}
}}

{{FGCquote
|Creating your own road network is a bit cumbersome ATM, I'll try to make it more general in the next few days. But if you're really, really keen on it: <ul><li> get latest osm2city git</li><li> run roads.py -f your-parameters-file.</li><li> if you also create buildings, make sure to use the same BOUNDARY_* parameters for both osm2city.py and roads.py. Otherwise, buildings and roads might be misaligned. Basically, if your OSM file contains both roads and buildings, you can just use one parameters file.</li><li> roads.py will print an OBJECT_STATIC line, add this to your .stg (appears to add itself)</li><li> copy roads.ac to your scenery</li><li> copy roads.xml and tex/ from the LOWI roads pack to your scenery (roads.ac and .xml copy themselves)</li></ul>
|{{cite web |url=http://forum.flightgear.org/viewtopic.php?p=212460#p212460
|title=<nowiki>Re: osm2city.py development</nowiki>
|author=<nowiki>radi</nowiki>
|date=<nowiki>Fri Jun 13</nowiki>
}}
}}

=== Status 04/2014 ===
[[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. 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]]
The second scene, approaching LOWI from the east, went from 30 fps without buildings down to 20 fps.

=== Status 10/2013 ===
Currently data is processed offline beforehand. 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. <del>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.
</del> (Some optimization gave a huge speedup).

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
use some heuristics (some OSM buildings are labeled "Terminal 1" or so) to apply
terminal/hangar textures to buildings at airports. This way we could rather easily populate some airports with
'semi-generic' terminal/hangar buildings.

== Features ==
* 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 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)
* 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
:* ~10 different, hi-res facade textures, some roof textures
:* find matching texture for given building (number of levels, modern/old building, etc)
:* find matching roof texture for given facade texture
* basic lightmap support
* obstruction lights on tall buildings
* command line interface and parameters file (thanks to forum user vanosten)
* shows statistics on processed buildings
* 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 {{done}}
* 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|50}}
:* 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 ==
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
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 ==
* nearby hi-rise objects of similar shape get same texture? Probably too special a feature.
* 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 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 ==
1. dependencies: Install the following packages (names from Debian packages):
python-numpy python-shapely python-matplotlib python-scipy python-pil python-networkx
2. get [https://gitorious.org/fg-radi/osm2city osm2city] and [https://gitorious.org/fg-radi/osm2city-data osm2city-data] from gitorious

3. 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))

4. link osm2city-data/tex and osm2city-data/tex.src into osm2city/

If you're running FG >= 3.3, or git newer than 10 Oct 2014, and have more than 4 GB RAM, you're done installing now. Otherwise, you will most likely need to set-up and use the old-fashioned way of elevation probing, which requires you to

5. copy elev.nas to $FGDATA/Nasal/

6. Open elev.nas in a text editor. Change the out variable to a directory with write access (e.g. $FG_HOME/Export). See [[IORules]] and [[$FG_HOME]]

== Install on Windows ==
In general, you'll want to follow the above install section. This section lists some additional Windows particularities.

Osm2city is pure python.

https://www.python.org/downloads/release/python-278/

{{warning|Python 2.7 is recommended unless you're an experienced Python developer willing to update the Python scripts to support Python 3. Also pay attention to versions and cpu builds of the below helper files. Make sure they match your OS build and Python version.}}

Install the following packages, then proceed with [[Osm2city.py#Install|step 2. above]].

http://www.lfd.uci.edu/~gohlke/pythonlibs/#numpy

http://www.lfd.uci.edu/~gohlke/pythonlibs/#shapely

http://www.lfd.uci.edu/~gohlke/pythonlibs/#scipy-stack

https://pypi.python.org/pypi/Pillow/2.5.0#downloads

== Workflow ==
There are five main steps:
* get OSM data
* adjust input file
* if neccessary, create elevation grid and run FG to probe elevation data.
* run osm2city
* <del>install the generated scenery</del>installs itself

We'll now walk through these steps in detail:
=== get OSM data ===
* decide on a region you want to populate. Get its lon/lat coordinates.
* create a project directory. We will use LOWI/ in this example.
* get corresponding OSM data in its native .xml format.
There are several options to get OSM data. You may find the [http://harrywood.co.uk/maps/uixapi/xapi.html XAPI Query Builder] helpful, it will generate a download URL that you can fetch with wget:
wget -O buildings.osm http://www.overpass-api.de/api/xapi?map?bbox=11.16898,47.20837,11.79108,47.38161

If you use [http://wiki.openstreetmap.org/wiki/Osmosis Osmosis] and cut the area with ''--bounding-box'' then you need to use ''completeWays=yes''.

Put this data into LOWI/buildings.osm

=== Adjust input file ===
* Now adjust the input file. You can generate a commented default parameters file by
<syntaxhighlight lang="bash">
parameters.py -d > LOWI/params.ini
</syntaxhighlight>

Edit this file, adjusting (at least) the following:
:* PREFIX = LOWI (the project directory)
:* BOUNDARY_EAST, BOUNDARY_NORTH, BOUNDARY_SOUTH, BOUNDARY_WEST
:* OSM_FILE = buildings.osm
:* set PATH_TO_SCENERY to a standard [[$FG_SCENERY]] path. This is the path where we'll get the elevation from. Most likely you'll want to use your TerraSync path here. Suppose the area you want to populate is /home/user/fgfs/scenery/TerraSync/Objects/e010n40/e011n47/, PATH_TO_SCENERY would then be /home/user/fgfs/scenery/TerraSync .
:* set PATH_TO_OUTPUT to a ''different'' scenery path, e.g. /home/user/fgfs/scenery/osm2city . Osm2city will generate its objects there. First, this avoids TerraSync overwriting the generated scenery. Second, you can easily remove that folder in case you're not happy with the result. Make sure to include that path in your [[$FG_SCENERY]].
:* you might want to set MAX_OBJECTS to a small number (say, 100) for your first try. This will limit the number of buildings parsed, and speed up the whole process.
:* you also need to set up elevation probing in the parameters file, described in the next section.

=== Probe elevation ===
Probe elevation for your region. Pick one of the three available modes for ELEV_MODE in params.ini. If you have enough memory (4GB should be fine, but YMMV) and run FG git later than 10 Oct 2014, try FgelevCaching. Failing that, try Manual. (portreekid, what's the 3rd mode good for?)

'''There are a lot of problems reported currently with fgelev. I can't really test for the next month or so. See troubleshooting or use ELEV_MODE = Manual.'''

* ELEV_MODE = FgelevCaching
:* Set FG_ELEV to your fgelev executable. For example: FG_ELEV = /usr/local/fg/bin/fgelev or just FG_ELEV = fgelev if fgelev is already in your OS's path.
:* Set PATH_TO_SCENERY (Missing terrain will result in error message)
:* make sure the environment variable [[$FG ROOT]] points to your FG base path, (e.g. export FG_ROOT=/usr/share/games/flightgear/ on Linux)

* ELEV_MODE = Manual
:* run tools.py (tools.py -f LOWI/params.ini), this will create a file elev.in. Copy elev.in to $FGDATA/Nasal/
:* Open $FGDATA/Nasal/elev.nas in a text editor. Point the in variable to your elev.in file e.g. var in = "/path/to/$FG_DATA/Nasal/elev.in".
:* tools.py will tell you to hide a certain scenery/Objects/... folder, to prevent probing elevation on top of existing objects. Simply rename the folder
:* run FG, open debug->nasal console, enter: elev.get_elevation(), press execute. Might take a long time, depending on the area scanned. This will write elevation data to /tmp/elev.out (which is actually just plain 5 column data: lon,lat,x,y,elevation). Put elev.out into LOWI/
:* unhide, rename the objects folder

* ELEV_MODE = Telnet
:* Run setup.py
:* Start FG with the properties service on Port 5501
:* Run tools.py, this will create a elev.in, start the nasal script and copy the elev.out back to your project directory

=== Run osm2city ===
* run osm2city.py -f LOWI/prams.ini. Parsing OSM data <del>again takes quite looong (10 minutes or more for 50k buildings)</del> is now pretty fast, but the result is cached to file buildings.pkl. Next startup will be <del>much faster if you move buildings.pkl to LOWI/buildings.pkl and</del> even faster if you set USE_PKL = 1.

If all goes well, files like LOWIcity0101.ac and their corresponding .xml, along with .stg files, were created and moved to the correct location in $FG_SCENERY
* copy or link the tex/ folder into the objects folder where these files were created

=== Roads ===
* run roads.py in the same fashion for roads
* <del>copy roads.eff to the same Objects\e0XXnXX\e0XXnXX\ directory</del> roads.eff is copied automatically
* Band-aid fix for the roads is to adjust their height in roads.py change AGL_ofs to a higher number e.g. 0.5
* the moving cars (TRAFFIC_SHADER_ENABLE = True) are only visible when you disable Atmospheric light scattering (ALS)

== Support and troubleshooting ==
Time permitting, we can provide limited support on the [http://forum.flightgear.org/viewtopic.php?f=5&t=22809 Forums]. Please don't use PM for support questions.

Before you ask a question, make sure you read this wiki page. If your question is not covered here, tell us as much as possible about the problem you're facing. Which steps have you taken to solve it? What is the exact error message? What operating system? Screenshots?

We will not cover general questions like "I don't know how to install XY" -- search the Internet.

* Buildings are generated, but they sit below the ground. I'm using ELEV_MODE = FgelevCaching.

Try running fgelev directly:
<syntaxhighlight lang="bash">
/path/to/fgelev --expire 1000 --fg-root $FG_ROOT --fg-scenery $FG_SCENERY
</syntaxhighlight>
then enter
<syntaxhighlight lang="bash">
0 $lon $lat
</syntaxhighlight>
where $lon and $lat are coordinates in the area you want to generate. See if it returns a sane value. If it does, double-check PATH_TO_SCENERY and $FG_ROOT.

* Buildings/roads have no texture.
copy or link the tex/ folder into the objects folder where the .stg files were created, such that you have $FG_SCENERY/Objects/eXXXnXX/eXXXnXX/tex/.

== Improve frame rate ==
* adjust LOD ranges in FG
* decrease MAX_OBJECTS, increase LOD_*
(- use larger/smaller tiles? Tradeoff between distance calculations/xml parsing and GPU)

== Contributing ==
You know some python? Or you're keen on writing docs? Contact radi on the FG forum.
None of the above? Take [[Howto:Create_textures_from_photos|pictures]] of buildings where you live and [[Osm2city.py Textures|create textures]]! I'm especially interested in south-east asian style architecture, as I'm planning to populate Hong Kong Kai Tak (VHXX) in the future.

== Related ==
* [[Using OSM Vector Data in FlightGear]]
* [[OpenStreetMap buildings]]
* [[AutoGen Scenery for FlightGear]]
* [[Random Buildings]]
* [http://forum.flightgear.org/viewtopic.php?f=5&t=21131#p192198 OSM buidings EHLE]
* [http://forum.flightgear.org/viewtopic.php?f=5&t=22809 osm2city.py development]
* [http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg40092.html Osm2city.py]
* http://forum.flightgear.org/viewtopic.php?f=5&t=19625
* [http://forum.flightgear.org/viewtopic.php?f=38&t=8837 PixelCity]
* [http://forum.flightgear.org/viewtopic.php?p=166794#p166681 Procedural OSM buildings]

[[Category:Scenery software]]

Osm2city.py

2014-11-20T19:38:27Z

Radi: /* Contributing */ link devel thread

{{OSM Navigation}}
[[File:LOWI with OSM buildings.jpg|thumb|LOWI with OSM buildings]]

This Python script takes OpenStreetMap floorplans and creates 3d buildings ready for use in FlightGear.

The development [https://gitorious.org/fg-radi/osm2city repository] is hosted on gitorious.
Forum thread [http://forum.flightgear.org/viewtopic.php?f=5&t=22809 osm2city.py development]
Written in Python 2.7, developed on GNU/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 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.

== News ==
=== Status 10/2014 ===
New features:
* textures reside in a separate [https://gitorious.org/fg-radi/osm2city-data repository]
* the recommended elevation probing method is ELEV_MODE=FgelevCaching
* roads.py is now quite usable
* SKIP_LIST can contain OSM_IDs

=== Status 06/2014 ===
I'm currently adding textured roads, railroads, intersections and bridges.

{{FGCquote
| the shader is now on osm2city's git (in fgdata/). Again -- all credit goes to Emilian. He is improving the shader side, I will continue on the model side. So this is very much work in progress. The shader requires the default renderer. No ALS/Rembrandt yet. Get the LOWI roads pack (including the shader) here: [https://dl.dropboxusercontent.com/u/24846517/fg/osm2city/LOWI_roads.tar.gz https://dl.dropboxusercontent.com/u/24846517/fg/osm2city/LOWI_roads.tar.gz] The fgdata/ folder goes to your $FGDATA. In roads.xml enable either the lightmap or the traffic shader.
|{{cite web |url=http://forum.flightgear.org/viewtopic.php?p=212460#p212460
|title=<nowiki>Re: osm2city.py development</nowiki>
|author=<nowiki>radi</nowiki>
|date=<nowiki>Fri Jun 13</nowiki>
}}
}}

{{FGCquote
|Creating your own road network is a bit cumbersome ATM, I'll try to make it more general in the next few days. But if you're really, really keen on it: <ul><li> get latest osm2city git</li><li> run roads.py -f your-parameters-file.</li><li> if you also create buildings, make sure to use the same BOUNDARY_* parameters for both osm2city.py and roads.py. Otherwise, buildings and roads might be misaligned. Basically, if your OSM file contains both roads and buildings, you can just use one parameters file.</li><li> roads.py will print an OBJECT_STATIC line, add this to your .stg (appears to add itself)</li><li> copy roads.ac to your scenery</li><li> copy roads.xml and tex/ from the LOWI roads pack to your scenery (roads.ac and .xml copy themselves)</li></ul>
|{{cite web |url=http://forum.flightgear.org/viewtopic.php?p=212460#p212460
|title=<nowiki>Re: osm2city.py development</nowiki>
|author=<nowiki>radi</nowiki>
|date=<nowiki>Fri Jun 13</nowiki>
}}
}}

=== Status 04/2014 ===
[[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. 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]]
The second scene, approaching LOWI from the east, went from 30 fps without buildings down to 20 fps.

=== Status 10/2013 ===
Currently data is processed offline beforehand. 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. <del>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.
</del> (Some optimization gave a huge speedup).

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
use some heuristics (some OSM buildings are labeled "Terminal 1" or so) to apply
terminal/hangar textures to buildings at airports. This way we could rather easily populate some airports with
'semi-generic' terminal/hangar buildings.

== Features ==
* 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 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)
* 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
:* ~10 different, hi-res facade textures, some roof textures
:* find matching texture for given building (number of levels, modern/old building, etc)
:* find matching roof texture for given facade texture
* basic lightmap support
* obstruction lights on tall buildings
* command line interface and parameters file (thanks to forum user vanosten)
* shows statistics on processed buildings
* 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 {{done}}
* 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|50}}
:* 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 ==
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
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 ==
* nearby hi-rise objects of similar shape get same texture? Probably too special a feature.
* 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 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 ==
1. dependencies: Install the following packages (names from Debian packages):
python-numpy python-shapely python-matplotlib python-scipy python-pil python-networkx
2. get [https://gitorious.org/fg-radi/osm2city osm2city] and [https://gitorious.org/fg-radi/osm2city-data osm2city-data] from gitorious

3. 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))

4. link osm2city-data/tex and osm2city-data/tex.src into osm2city/

If you're running FG >= 3.3, or git newer than 10 Oct 2014, and have more than 4 GB RAM, you're done installing now. Otherwise, you will most likely need to set-up and use the old-fashioned way of elevation probing, which requires you to

5. copy elev.nas to $FGDATA/Nasal/

6. Open elev.nas in a text editor. Change the out variable to a directory with write access (e.g. $FG_HOME/Export). See [[IORules]] and [[$FG_HOME]]

== Install on Windows ==
In general, you'll want to follow the above install section. This section lists some additional Windows particularities.

Osm2city is pure python.

https://www.python.org/downloads/release/python-278/

{{warning|Python 2.7 is recommended unless you're an experienced Python developer willing to update the Python scripts to support Python 3. Also pay attention to versions and cpu builds of the below helper files. Make sure they match your OS build and Python version.}}

Install the following packages, then proceed with [[Osm2city.py#Install|step 2. above]].

http://www.lfd.uci.edu/~gohlke/pythonlibs/#numpy

http://www.lfd.uci.edu/~gohlke/pythonlibs/#shapely

http://www.lfd.uci.edu/~gohlke/pythonlibs/#scipy-stack

https://pypi.python.org/pypi/Pillow/2.5.0#downloads

== Workflow ==
There are five main steps:
* get OSM data
* adjust input file
* if neccessary, create elevation grid and run FG to probe elevation data.
* run osm2city
* <del>install the generated scenery</del>installs itself

We'll now walk through these steps in detail:
=== get OSM data ===
* decide on a region you want to populate. Get its lon/lat coordinates.
* create a project directory. We will use LOWI/ in this example.
* get corresponding OSM data in its native .xml format.
There are several options to get OSM data. You may find the [http://harrywood.co.uk/maps/uixapi/xapi.html XAPI Query Builder] helpful, it will generate a download URL that you can fetch with wget:
wget -O buildings.osm http://www.overpass-api.de/api/xapi?map?bbox=11.16898,47.20837,11.79108,47.38161

If you use [http://wiki.openstreetmap.org/wiki/Osmosis Osmosis] and cut the area with ''--bounding-box'' then you need to use ''completeWays=yes''.

Put this data into LOWI/buildings.osm

=== Adjust input file ===
* Now adjust the input file. You can generate a commented default parameters file by
<syntaxhighlight lang="bash">
parameters.py -d > LOWI/params.ini
</syntaxhighlight>

Edit this file, adjusting (at least) the following:
:* PREFIX = LOWI (the project directory)
:* BOUNDARY_EAST, BOUNDARY_NORTH, BOUNDARY_SOUTH, BOUNDARY_WEST
:* OSM_FILE = buildings.osm
:* set PATH_TO_SCENERY to a standard [[$FG_SCENERY]] path. This is the path where we'll get the elevation from. Most likely you'll want to use your TerraSync path here. Suppose the area you want to populate is /home/user/fgfs/scenery/TerraSync/Objects/e010n40/e011n47/, PATH_TO_SCENERY would then be /home/user/fgfs/scenery/TerraSync .
:* set PATH_TO_OUTPUT to a ''different'' scenery path, e.g. /home/user/fgfs/scenery/osm2city . Osm2city will generate its objects there. First, this avoids TerraSync overwriting the generated scenery. Second, you can easily remove that folder in case you're not happy with the result. Make sure to include that path in your [[$FG_SCENERY]].
:* you might want to set MAX_OBJECTS to a small number (say, 100) for your first try. This will limit the number of buildings parsed, and speed up the whole process.
:* you also need to set up elevation probing in the parameters file, described in the next section.

=== Probe elevation ===
Probe elevation for your region. Pick one of the three available modes for ELEV_MODE in params.ini. If you have enough memory (4GB should be fine, but YMMV) and run FG git later than 10 Oct 2014, try FgelevCaching. Failing that, try Manual. (portreekid, what's the 3rd mode good for?)

'''There are a lot of problems reported currently with fgelev. I can't really test for the next month or so. See troubleshooting or use ELEV_MODE = Manual.'''

* ELEV_MODE = FgelevCaching
:* Set FG_ELEV to your fgelev executable. For example: FG_ELEV = /usr/local/fg/bin/fgelev or just FG_ELEV = fgelev if fgelev is already in your OS's path.
:* Set PATH_TO_SCENERY (Missing terrain will result in error message)
:* make sure the environment variable [[$FG ROOT]] points to your FG base path, (e.g. export FG_ROOT=/usr/share/games/flightgear/ on Linux)

* ELEV_MODE = Manual
:* run tools.py (tools.py -f LOWI/params.ini), this will create a file elev.in. Copy elev.in to $FGDATA/Nasal/
:* Open $FGDATA/Nasal/elev.nas in a text editor. Point the in variable to your elev.in file e.g. var in = "/path/to/$FG_DATA/Nasal/elev.in".
:* tools.py will tell you to hide a certain scenery/Objects/... folder, to prevent probing elevation on top of existing objects. Simply rename the folder
:* run FG, open debug->nasal console, enter: elev.get_elevation(), press execute. Might take a long time, depending on the area scanned. This will write elevation data to /tmp/elev.out (which is actually just plain 5 column data: lon,lat,x,y,elevation). Put elev.out into LOWI/
:* unhide, rename the objects folder

* ELEV_MODE = Telnet
:* Run setup.py
:* Start FG with the properties service on Port 5501
:* Run tools.py, this will create a elev.in, start the nasal script and copy the elev.out back to your project directory

=== Run osm2city ===
* run osm2city.py -f LOWI/prams.ini. Parsing OSM data <del>again takes quite looong (10 minutes or more for 50k buildings)</del> is now pretty fast, but the result is cached to file buildings.pkl. Next startup will be <del>much faster if you move buildings.pkl to LOWI/buildings.pkl and</del> even faster if you set USE_PKL = 1.

If all goes well, files like LOWIcity0101.ac and their corresponding .xml, along with .stg files, were created and moved to the correct location in $FG_SCENERY
* copy or link the tex/ folder into the objects folder where these files were created

=== Roads ===
* run roads.py in the same fashion for roads
* <del>copy roads.eff to the same Objects\e0XXnXX\e0XXnXX\ directory</del> roads.eff is copied automatically
* Band-aid fix for the roads is to adjust their height in roads.py change AGL_ofs to a higher number e.g. 0.5
* the moving cars (TRAFFIC_SHADER_ENABLE = True) are only visible when you disable Atmospheric light scattering (ALS)

== Support and troubleshooting ==
Time permitting, we can provide limited support on the [http://forum.flightgear.org/viewtopic.php?f=5&t=22809 Forums]. Please don't use PM for support questions.

Before you ask a question, make sure you read this wiki page. If your question is not covered here, tell us as much as possible about the problem you're facing. Which steps have you taken to solve it? What is the exact error message? What operating system? Screenshots?

We will not cover general questions like "I don't know how to install XY" -- search the Internet.

* Buildings are generated, but they sit below the ground. I'm using ELEV_MODE = FgelevCaching.

Try running fgelev directly:
<syntaxhighlight lang="bash">
/path/to/fgelev --expire 1000 --fg-root $FG_ROOT --fg-scenery $FG_SCENERY
</syntaxhighlight>
then enter
<syntaxhighlight lang="bash">
0 $lon $lat
</syntaxhighlight>
where $lon and $lat are coordinates in the area you want to generate. See if it returns a sane value. If it does, double-check PATH_TO_SCENERY and $FG_ROOT.

* Buildings/roads have no texture.
copy or link the tex/ folder into the objects folder where the .stg files were created, such that you have $FG_SCENERY/Objects/eXXXnXX/eXXXnXX/tex/.

== Improve frame rate ==
* adjust LOD ranges in FG
* decrease MAX_OBJECTS, increase LOD_*
(- use larger/smaller tiles? Tradeoff between distance calculations/xml parsing and GPU)

== Contributing ==
You know some python? Or you're keen on writing docs? Or just want to use osm2city, but got stuck somewhere? Use the forum development [http://forum.flightgear.org/viewtopic.php?f=5&t=22809 thread].
None of the above? Take [[Howto:Create_textures_from_photos|pictures]] of buildings where you live and [[Osm2city.py Textures|create textures]]! I'm especially interested in south-east asian style architecture, as I'm planning to populate Hong Kong Kai Tak (VHXX) in the future.

== Related ==
* [[Using OSM Vector Data in FlightGear]]
* [[OpenStreetMap buildings]]
* [[AutoGen Scenery for FlightGear]]
* [[Random Buildings]]
* [http://forum.flightgear.org/viewtopic.php?f=5&t=21131#p192198 OSM buidings EHLE]
* [http://forum.flightgear.org/viewtopic.php?f=5&t=22809 osm2city.py development]
* [http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg40092.html Osm2city.py]
* http://forum.flightgear.org/viewtopic.php?f=5&t=19625
* [http://forum.flightgear.org/viewtopic.php?f=38&t=8837 PixelCity]
* [http://forum.flightgear.org/viewtopic.php?p=166794#p166681 Procedural OSM buildings]

[[Category:Scenery software]]

Osm2city.py

2014-11-18T16:32:26Z

Radi: /* Probe elevation */ moved in var edit to probe elevation section

{{OSM Navigation}}
[[File:LOWI with OSM buildings.jpg|thumb|LOWI with OSM buildings]]

This Python script takes OpenStreetMap floorplans and creates 3d buildings ready for use in FlightGear.

The development [https://gitorious.org/fg-radi/osm2city repository] is hosted on gitorious.
Forum thread [http://forum.flightgear.org/viewtopic.php?f=5&t=22809 osm2city.py development]
Written in Python 2.7, developed on GNU/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 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.

== News ==
=== Status 10/2014 ===
New features:
* textures reside in a separate [https://gitorious.org/fg-radi/osm2city-data repository]
* the recommended elevation probing method is ELEV_MODE=FgelevCaching
* roads.py is now quite usable
* SKIP_LIST can contain OSM_IDs

=== Status 06/2014 ===
I'm currently adding textured roads, railroads, intersections and bridges.

{{FGCquote
| the shader is now on osm2city's git (in fgdata/). Again -- all credit goes to Emilian. He is improving the shader side, I will continue on the model side. So this is very much work in progress. The shader requires the default renderer. No ALS/Rembrandt yet. Get the LOWI roads pack (including the shader) here: [https://dl.dropboxusercontent.com/u/24846517/fg/osm2city/LOWI_roads.tar.gz https://dl.dropboxusercontent.com/u/24846517/fg/osm2city/LOWI_roads.tar.gz] The fgdata/ folder goes to your $FGDATA. In roads.xml enable either the lightmap or the traffic shader.
|{{cite web |url=http://forum.flightgear.org/viewtopic.php?p=212460#p212460
|title=<nowiki>Re: osm2city.py development</nowiki>
|author=<nowiki>radi</nowiki>
|date=<nowiki>Fri Jun 13</nowiki>
}}
}}

{{FGCquote
|Creating your own road network is a bit cumbersome ATM, I'll try to make it more general in the next few days. But if you're really, really keen on it: <ul><li> get latest osm2city git</li><li> run roads.py -f your-parameters-file.</li><li> if you also create buildings, make sure to use the same BOUNDARY_* parameters for both osm2city.py and roads.py. Otherwise, buildings and roads might be misaligned. Basically, if your OSM file contains both roads and buildings, you can just use one parameters file.</li><li> roads.py will print an OBJECT_STATIC line, add this to your .stg (appears to add itself)</li><li> copy roads.ac to your scenery</li><li> copy roads.xml and tex/ from the LOWI roads pack to your scenery (roads.ac and .xml copy themselves)</li></ul>
|{{cite web |url=http://forum.flightgear.org/viewtopic.php?p=212460#p212460
|title=<nowiki>Re: osm2city.py development</nowiki>
|author=<nowiki>radi</nowiki>
|date=<nowiki>Fri Jun 13</nowiki>
}}
}}

=== Status 04/2014 ===
[[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. 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]]
The second scene, approaching LOWI from the east, went from 30 fps without buildings down to 20 fps.

=== Status 10/2013 ===
Currently data is processed offline beforehand. 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. <del>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.
</del> (Some optimization gave a huge speedup).

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
use some heuristics (some OSM buildings are labeled "Terminal 1" or so) to apply
terminal/hangar textures to buildings at airports. This way we could rather easily populate some airports with
'semi-generic' terminal/hangar buildings.

== Features ==
* 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 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)
* 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
:* ~10 different, hi-res facade textures, some roof textures
:* find matching texture for given building (number of levels, modern/old building, etc)
:* find matching roof texture for given facade texture
* basic lightmap support
* obstruction lights on tall buildings
* command line interface and parameters file (thanks to forum user vanosten)
* shows statistics on processed buildings
* 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 {{done}}
* 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|50}}
:* 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 ==
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
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 ==
* nearby hi-rise objects of similar shape get same texture? Probably too special a feature.
* 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 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 ==
1. dependencies: Install the following packages (names from Debian packages):
python-numpy python-shapely python-matplotlib python-scipy python-pil python-networkx
2. get [https://gitorious.org/fg-radi/osm2city osm2city] and [https://gitorious.org/fg-radi/osm2city-data osm2city-data] from gitorious

3. 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))

4. link osm2city-data/tex and osm2city-data/tex.src into osm2city/

If you're running FG >= 3.3, or git newer than 10 Oct 2014, and have more than 4 GB RAM, you're done installing now. Otherwise, you will most likely need to set-up and use the old-fashioned way of elevation probing, which requires you to

5. copy elev.nas to $FGDATA/Nasal/

6. Open elev.nas in a text editor. Change the out variable to a directory with write access (e.g. $FG_HOME/Export). See [[IORules]] and [[$FG_HOME]]

== Install on Windows ==
In general, you'll want to follow the above install section. This section lists some additional Windows particularities.

Osm2city is pure python.

https://www.python.org/downloads/release/python-278/

{{warning|Python 2.7 is recommended unless you're an experienced Python developer willing to update the Python scripts to support Python 3. Also pay attention to versions and cpu builds of the below helper files. Make sure they match your OS build and Python version.}}

Install the following packages, then proceed with [[Osm2city.py#Install|step 2. above]].

http://www.lfd.uci.edu/~gohlke/pythonlibs/#numpy

http://www.lfd.uci.edu/~gohlke/pythonlibs/#shapely

http://www.lfd.uci.edu/~gohlke/pythonlibs/#scipy-stack

https://pypi.python.org/pypi/Pillow/2.5.0#downloads

== Workflow ==
There are five main steps:
* get OSM data
* adjust input file
* if neccessary, create elevation grid and run FG to probe elevation data.
* run osm2city
* <del>install the generated scenery</del>installs itself

We'll now walk through these steps in detail:
=== get OSM data ===
* decide on a region you want to populate. Get its lon/lat coordinates.
* create a project directory. We will use LOWI/ in this example.
* get corresponding OSM data in its native .xml format.
There are several options to get OSM data. You may find the [http://harrywood.co.uk/maps/uixapi/xapi.html XAPI Query Builder] helpful, it will generate a download URL that you can fetch with wget:
wget -O buildings.osm http://www.overpass-api.de/api/xapi?map?bbox=11.16898,47.20837,11.79108,47.38161

If you use [http://wiki.openstreetmap.org/wiki/Osmosis Osmosis] and cut the area with ''--bounding-box'' then you need to use ''completeWays=yes''.

Put this data into LOWI/buildings.osm

=== Adjust input file ===
* Now adjust the input file. You can generate a commented default parameters file by
<syntaxhighlight lang="bash">
parameters.py -d > LOWI/params.ini
</syntaxhighlight>

Edit this file, adjusting (at least) the following:
:* PREFIX = LOWI (the project directory)
:* BOUNDARY_EAST, BOUNDARY_NORTH, BOUNDARY_SOUTH, BOUNDARY_WEST
:* OSM_FILE = buildings.osm
:* set PATH_TO_SCENERY to a standard [[$FG_SCENERY]] path. This is the path where we'll get the elevation from. Most likely you'll want to use your TerraSync path here. Suppose the area you want to populate is /home/user/fgfs/scenery/TerraSync/Objects/e010n40/e011n47/, PATH_TO_SCENERY would then be /home/user/fgfs/scenery/TerraSync .
:* set PATH_TO_OUTPUT to a ''different'' scenery path, e.g. /home/user/fgfs/scenery/osm2city . Osm2city will generate its objects there. First, this avoids TerraSync overwriting the generated scenery. Second, you can easily remove that folder in case you're not happy with the result. Make sure to include that path in your [[$FG_SCENERY]].
:* you might want to set MAX_OBJECTS to a small number (say, 100) for your first try. This will limit the number of buildings parsed, and speed up the whole process.
:* you also need to set up elevation probing in the parameters file, described in the next section.

=== Probe elevation ===
Probe elevation for your region. Pick one of the three available modes for ELEV_MODE in params.ini. If you have enough memory (4GB should be fine, but YMMV) and run FG git later than 10 Oct 2014, try FgelevCaching. Failing that, try Manual. (portreekid, what's the 3rd mode good for?)

'''There are a lot of problems reported currently with fgelev. I can't really test for the next month or so. See troubleshooting or use ELEV_MODE = Manual.'''

* ELEV_MODE = FgelevCaching
:* Set FG_ELEV to your fgelev executable. For example: FG_ELEV = /usr/local/fg/bin/fgelev or just FG_ELEV = fgelev if fgelev is already in your OS's path.
:* Set PATH_TO_SCENERY (Missing terrain will result in error message)
:* make sure the environment variable [[$FG ROOT]] points to your FG base path, (e.g. export FG_ROOT=/usr/share/games/flightgear/ on Linux)

* ELEV_MODE = Manual
:* run tools.py (tools.py -f LOWI/params.ini), this will create a file elev.in. Copy elev.in to $FGDATA/Nasal/
:* Open $FGDATA/Nasal/elev.nas in a text editor. Point the in variable to your elev.in file e.g. var in = "/path/to/$FG_DATA/Nasal/elev.in".
:* tools.py will tell you to hide a certain scenery/Objects/... folder, to prevent probing elevation on top of existing objects. Simply rename the folder
:* run FG, open debug->nasal console, enter: elev.get_elevation(), press execute. Might take a long time, depending on the area scanned. This will write elevation data to /tmp/elev.out (which is actually just plain 5 column data: lon,lat,x,y,elevation). Put elev.out into LOWI/
:* unhide, rename the objects folder

* ELEV_MODE = Telnet
:* Run setup.py
:* Start FG with the properties service on Port 5501
:* Run tools.py, this will create a elev.in, start the nasal script and copy the elev.out back to your project directory

=== Run osm2city ===
* run osm2city.py -f LOWI/prams.ini. Parsing OSM data <del>again takes quite looong (10 minutes or more for 50k buildings)</del> is now pretty fast, but the result is cached to file buildings.pkl. Next startup will be <del>much faster if you move buildings.pkl to LOWI/buildings.pkl and</del> even faster if you set USE_PKL = 1.

If all goes well, files like LOWIcity0101.ac and their corresponding .xml, along with .stg files, were created and moved to the correct location in $FG_SCENERY
* copy or link the tex/ folder into the objects folder where these files were created

=== Roads ===
* run roads.py in the same fashion for roads
* <del>copy roads.eff to the same Objects\e0XXnXX\e0XXnXX\ directory</del> roads.eff is copied automatically
* Band-aid fix for the roads is to adjust their height in roads.py change AGL_ofs to a higher number e.g. 0.5
* the moving cars (TRAFFIC_SHADER_ENABLE = True) are only visible when you disable Atmospheric light scattering (ALS)

== Support and troubleshooting ==
Time permitting, we can provide limited support on the [http://forum.flightgear.org/viewtopic.php?f=5&t=22809 Forums]. Please don't use PM for support questions.

Before you ask a question, make sure you read this wiki page. If your question is not covered here, tell us as much as possible about the problem you're facing. Which steps have you taken to solve it? What is the exact error message? What operating system? Screenshots?

We will not cover general questions like "I don't know how to install XY" -- search the Internet.

* Buildings are generated, but they sit below the ground. I'm using ELEV_MODE = FgelevCaching.

Try running fgelev directly:
<syntaxhighlight lang="bash">
/path/to/fgelev --expire 1000 --fg-root $FG_ROOT --fg-scenery $FG_SCENERY
</syntaxhighlight>
then enter
<syntaxhighlight lang="bash">
0 $lon $lat
</syntaxhighlight>
where $lon and $lat are coordinates in the area you want to generate. See if it returns a sane value. If it does, double-check PATH_TO_SCENERY and $FG_ROOT.

* Buildings/roads have no texture.
copy or link the tex/ folder into the objects folder where the .stg files were created, such that you have $FG_SCENERY/Objects/eXXXnXX/eXXXnXX/tex/.

== Improve frame rate ==
* adjust LOD ranges in FG
* decrease MAX_OBJECTS, increase LOD_*
(- use larger/smaller tiles? Tradeoff between distance calculations/xml parsing and GPU)

== Contributing ==
You know some python? Or you're keen on writing docs? Or just want to use osm2city, but got stuck somewhere? Contact radi on the FG forum.
None of the above? Take [[Howto:Create_textures_from_photos|pictures]] of buildings where you live and [[Osm2city.py Textures|create textures]]! I'm especially interested in south-east asian style architecture, as I'm planning to populate Hong Kong Kai Tak (VHXX) in the future.

== Related ==
* [[Using OSM Vector Data in FlightGear]]
* [[OpenStreetMap buildings]]
* [[AutoGen Scenery for FlightGear]]
* [[Random Buildings]]
* [http://forum.flightgear.org/viewtopic.php?f=5&t=21131#p192198 OSM buidings EHLE]
* [http://forum.flightgear.org/viewtopic.php?f=5&t=22809 osm2city.py development]
* [http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg40092.html Osm2city.py]
* http://forum.flightgear.org/viewtopic.php?f=5&t=19625
* [http://forum.flightgear.org/viewtopic.php?f=38&t=8837 PixelCity]
* [http://forum.flightgear.org/viewtopic.php?p=166794#p166681 Procedural OSM buildings]

[[Category:Scenery software]]

Osm2city.py

2014-11-18T16:26:45Z

Radi: /* Install */ moved elev.in var edit

{{OSM Navigation}}
[[File:LOWI with OSM buildings.jpg|thumb|LOWI with OSM buildings]]

This Python script takes OpenStreetMap floorplans and creates 3d buildings ready for use in FlightGear.

The development [https://gitorious.org/fg-radi/osm2city repository] is hosted on gitorious.
Forum thread [http://forum.flightgear.org/viewtopic.php?f=5&t=22809 osm2city.py development]
Written in Python 2.7, developed on GNU/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 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.

== News ==
=== Status 10/2014 ===
New features:
* textures reside in a separate [https://gitorious.org/fg-radi/osm2city-data repository]
* the recommended elevation probing method is ELEV_MODE=FgelevCaching
* roads.py is now quite usable
* SKIP_LIST can contain OSM_IDs

=== Status 06/2014 ===
I'm currently adding textured roads, railroads, intersections and bridges.

{{FGCquote
| the shader is now on osm2city's git (in fgdata/). Again -- all credit goes to Emilian. He is improving the shader side, I will continue on the model side. So this is very much work in progress. The shader requires the default renderer. No ALS/Rembrandt yet. Get the LOWI roads pack (including the shader) here: [https://dl.dropboxusercontent.com/u/24846517/fg/osm2city/LOWI_roads.tar.gz https://dl.dropboxusercontent.com/u/24846517/fg/osm2city/LOWI_roads.tar.gz] The fgdata/ folder goes to your $FGDATA. In roads.xml enable either the lightmap or the traffic shader.
|{{cite web |url=http://forum.flightgear.org/viewtopic.php?p=212460#p212460
|title=<nowiki>Re: osm2city.py development</nowiki>
|author=<nowiki>radi</nowiki>
|date=<nowiki>Fri Jun 13</nowiki>
}}
}}

{{FGCquote
|Creating your own road network is a bit cumbersome ATM, I'll try to make it more general in the next few days. But if you're really, really keen on it: <ul><li> get latest osm2city git</li><li> run roads.py -f your-parameters-file.</li><li> if you also create buildings, make sure to use the same BOUNDARY_* parameters for both osm2city.py and roads.py. Otherwise, buildings and roads might be misaligned. Basically, if your OSM file contains both roads and buildings, you can just use one parameters file.</li><li> roads.py will print an OBJECT_STATIC line, add this to your .stg (appears to add itself)</li><li> copy roads.ac to your scenery</li><li> copy roads.xml and tex/ from the LOWI roads pack to your scenery (roads.ac and .xml copy themselves)</li></ul>
|{{cite web |url=http://forum.flightgear.org/viewtopic.php?p=212460#p212460
|title=<nowiki>Re: osm2city.py development</nowiki>
|author=<nowiki>radi</nowiki>
|date=<nowiki>Fri Jun 13</nowiki>
}}
}}

=== Status 04/2014 ===
[[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. 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]]
The second scene, approaching LOWI from the east, went from 30 fps without buildings down to 20 fps.

=== Status 10/2013 ===
Currently data is processed offline beforehand. 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. <del>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.
</del> (Some optimization gave a huge speedup).

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
use some heuristics (some OSM buildings are labeled "Terminal 1" or so) to apply
terminal/hangar textures to buildings at airports. This way we could rather easily populate some airports with
'semi-generic' terminal/hangar buildings.

== Features ==
* 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 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)
* 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
:* ~10 different, hi-res facade textures, some roof textures
:* find matching texture for given building (number of levels, modern/old building, etc)
:* find matching roof texture for given facade texture
* basic lightmap support
* obstruction lights on tall buildings
* command line interface and parameters file (thanks to forum user vanosten)
* shows statistics on processed buildings
* 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 {{done}}
* 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|50}}
:* 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 ==
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
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 ==
* nearby hi-rise objects of similar shape get same texture? Probably too special a feature.
* 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 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 ==
1. dependencies: Install the following packages (names from Debian packages):
python-numpy python-shapely python-matplotlib python-scipy python-pil python-networkx
2. get [https://gitorious.org/fg-radi/osm2city osm2city] and [https://gitorious.org/fg-radi/osm2city-data osm2city-data] from gitorious

3. 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))

4. link osm2city-data/tex and osm2city-data/tex.src into osm2city/

If you're running FG >= 3.3, or git newer than 10 Oct 2014, and have more than 4 GB RAM, you're done installing now. Otherwise, you will most likely need to set-up and use the old-fashioned way of elevation probing, which requires you to

5. copy elev.nas to $FGDATA/Nasal/

6. Open elev.nas in a text editor. Change the out variable to a directory with write access (e.g. $FG_HOME/Export). See [[IORules]] and [[$FG_HOME]]

== Install on Windows ==
In general, you'll want to follow the above install section. This section lists some additional Windows particularities.

Osm2city is pure python.

https://www.python.org/downloads/release/python-278/

{{warning|Python 2.7 is recommended unless you're an experienced Python developer willing to update the Python scripts to support Python 3. Also pay attention to versions and cpu builds of the below helper files. Make sure they match your OS build and Python version.}}

Install the following packages, then proceed with [[Osm2city.py#Install|step 2. above]].

http://www.lfd.uci.edu/~gohlke/pythonlibs/#numpy

http://www.lfd.uci.edu/~gohlke/pythonlibs/#shapely

http://www.lfd.uci.edu/~gohlke/pythonlibs/#scipy-stack

https://pypi.python.org/pypi/Pillow/2.5.0#downloads

== Workflow ==
There are five main steps:
* get OSM data
* adjust input file
* if neccessary, create elevation grid and run FG to probe elevation data.
* run osm2city
* <del>install the generated scenery</del>installs itself

We'll now walk through these steps in detail:
=== get OSM data ===
* decide on a region you want to populate. Get its lon/lat coordinates.
* create a project directory. We will use LOWI/ in this example.
* get corresponding OSM data in its native .xml format.
There are several options to get OSM data. You may find the [http://harrywood.co.uk/maps/uixapi/xapi.html XAPI Query Builder] helpful, it will generate a download URL that you can fetch with wget:
wget -O buildings.osm http://www.overpass-api.de/api/xapi?map?bbox=11.16898,47.20837,11.79108,47.38161

If you use [http://wiki.openstreetmap.org/wiki/Osmosis Osmosis] and cut the area with ''--bounding-box'' then you need to use ''completeWays=yes''.

Put this data into LOWI/buildings.osm

=== Adjust input file ===
* Now adjust the input file. You can generate a commented default parameters file by
<syntaxhighlight lang="bash">
parameters.py -d > LOWI/params.ini
</syntaxhighlight>

Edit this file, adjusting (at least) the following:
:* PREFIX = LOWI (the project directory)
:* BOUNDARY_EAST, BOUNDARY_NORTH, BOUNDARY_SOUTH, BOUNDARY_WEST
:* OSM_FILE = buildings.osm
:* set PATH_TO_SCENERY to a standard [[$FG_SCENERY]] path. This is the path where we'll get the elevation from. Most likely you'll want to use your TerraSync path here. Suppose the area you want to populate is /home/user/fgfs/scenery/TerraSync/Objects/e010n40/e011n47/, PATH_TO_SCENERY would then be /home/user/fgfs/scenery/TerraSync .
:* set PATH_TO_OUTPUT to a ''different'' scenery path, e.g. /home/user/fgfs/scenery/osm2city . Osm2city will generate its objects there. First, this avoids TerraSync overwriting the generated scenery. Second, you can easily remove that folder in case you're not happy with the result. Make sure to include that path in your [[$FG_SCENERY]].
:* you might want to set MAX_OBJECTS to a small number (say, 100) for your first try. This will limit the number of buildings parsed, and speed up the whole process.
:* you also need to set up elevation probing in the parameters file, described in the next section.

=== Probe elevation ===
Probe elevation for your region. Pick one of the three available modes for ELEV_MODE in params.ini. If you have enough memory (4GB should be fine, but YMMV) and run FG git later than 10 Oct 2014, try FgelevCaching. Failing that, try Manual. (portreekid, what's the 3rd mode good for?)

'''There are a lot of problems reported currently with fgelev. I can't really test for the next month or so. See troubleshooting or use ELEV_MODE = Manual.'''

* ELEV_MODE = FgelevCaching
:* Set FG_ELEV to your fgelev executable. For example: FG_ELEV = /usr/local/fg/bin/fgelev or just FG_ELEV = fgelev if fgelev is already in your OS's path.
:* Set PATH_TO_SCENERY (Missing terrain will result in error message)
:* make sure the environment variable [[$FG ROOT]] points to your FG base path, (e.g. export FG_ROOT=/usr/share/games/flightgear/ on Linux)

* ELEV_MODE = Manual
:* run tools.py (tools.py -f LOWI/params.ini), this will create a file elev.in. Copy elev.in to $FGDATA/Nasal/
:* tools.py will tell you to hide a certain scenery/Objects/... folder, to prevent probing elevation on top of existing objects. Simply rename the folder
:* run FG, open debug->nasal console, enter: elev.get_elevation(), press execute. Might take a long time, depending on the area scanned. This will write elevation data to /tmp/elev.out (which is actually just plain 5 column data: lon,lat,x,y,elevation). Put elev.out into LOWI/
:* unhide, rename the objects folder

* ELEV_MODE = Telnet
:* Run setup.py
:* Start FG with the properties service on Port 5501
:* Run tools.py, this will create a elev.in, start the nasal script and copy the elev.out back to your project directory

=== Run osm2city ===
* run osm2city.py -f LOWI/prams.ini. Parsing OSM data <del>again takes quite looong (10 minutes or more for 50k buildings)</del> is now pretty fast, but the result is cached to file buildings.pkl. Next startup will be <del>much faster if you move buildings.pkl to LOWI/buildings.pkl and</del> even faster if you set USE_PKL = 1.

If all goes well, files like LOWIcity0101.ac and their corresponding .xml, along with .stg files, were created and moved to the correct location in $FG_SCENERY
* copy or link the tex/ folder into the objects folder where these files were created

=== Roads ===
* run roads.py in the same fashion for roads
* <del>copy roads.eff to the same Objects\e0XXnXX\e0XXnXX\ directory</del> roads.eff is copied automatically
* Band-aid fix for the roads is to adjust their height in roads.py change AGL_ofs to a higher number e.g. 0.5
* the moving cars (TRAFFIC_SHADER_ENABLE = True) are only visible when you disable Atmospheric light scattering (ALS)

== Support and troubleshooting ==
Time permitting, we can provide limited support on the [http://forum.flightgear.org/viewtopic.php?f=5&t=22809 Forums]. Please don't use PM for support questions.

Before you ask a question, make sure you read this wiki page. If your question is not covered here, tell us as much as possible about the problem you're facing. Which steps have you taken to solve it? What is the exact error message? What operating system? Screenshots?

We will not cover general questions like "I don't know how to install XY" -- search the Internet.

* Buildings are generated, but they sit below the ground. I'm using ELEV_MODE = FgelevCaching.

Try running fgelev directly:
<syntaxhighlight lang="bash">
/path/to/fgelev --expire 1000 --fg-root $FG_ROOT --fg-scenery $FG_SCENERY
</syntaxhighlight>
then enter
<syntaxhighlight lang="bash">
0 $lon $lat
</syntaxhighlight>
where $lon and $lat are coordinates in the area you want to generate. See if it returns a sane value. If it does, double-check PATH_TO_SCENERY and $FG_ROOT.

* Buildings/roads have no texture.
copy or link the tex/ folder into the objects folder where the .stg files were created, such that you have $FG_SCENERY/Objects/eXXXnXX/eXXXnXX/tex/.

== Improve frame rate ==
* adjust LOD ranges in FG
* decrease MAX_OBJECTS, increase LOD_*
(- use larger/smaller tiles? Tradeoff between distance calculations/xml parsing and GPU)

== Contributing ==
You know some python? Or you're keen on writing docs? Or just want to use osm2city, but got stuck somewhere? Contact radi on the FG forum.
None of the above? Take [[Howto:Create_textures_from_photos|pictures]] of buildings where you live and [[Osm2city.py Textures|create textures]]! I'm especially interested in south-east asian style architecture, as I'm planning to populate Hong Kong Kai Tak (VHXX) in the future.

== Related ==
* [[Using OSM Vector Data in FlightGear]]
* [[OpenStreetMap buildings]]
* [[AutoGen Scenery for FlightGear]]
* [[Random Buildings]]
* [http://forum.flightgear.org/viewtopic.php?f=5&t=21131#p192198 OSM buidings EHLE]
* [http://forum.flightgear.org/viewtopic.php?f=5&t=22809 osm2city.py development]
* [http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg40092.html Osm2city.py]
* http://forum.flightgear.org/viewtopic.php?f=5&t=19625
* [http://forum.flightgear.org/viewtopic.php?f=38&t=8837 PixelCity]
* [http://forum.flightgear.org/viewtopic.php?p=166794#p166681 Procedural OSM buildings]

[[Category:Scenery software]]

Osm2city.py

2014-11-16T01:24:20Z

Radi: /* Troubleshooting */ support rules

{{OSM Navigation}}
[[File:LOWI with OSM buildings.jpg|thumb|LOWI with OSM buildings]]

This Python script takes OpenStreetMap floorplans and creates 3d buildings ready for use in FlightGear.

The development [https://gitorious.org/fg-radi/osm2city repository] is hosted on gitorious.
Forum thread [http://forum.flightgear.org/viewtopic.php?f=5&t=22809 osm2city.py development]
Written in Python 2.7, developed on GNU/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 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.

== News ==
=== Status 10/2014 ===
New features:
* textures reside in a separate [https://gitorious.org/fg-radi/osm2city-data repository]
* the recommended elevation probing method is ELEV_MODE=FgelevCaching
* roads.py is now quite usable
* SKIP_LIST can contain OSM_IDs

=== Status 06/2014 ===
I'm currently adding textured roads, railroads, intersections and bridges.

{{FGCquote
| the shader is now on osm2city's git (in fgdata/). Again -- all credit goes to Emilian. He is improving the shader side, I will continue on the model side. So this is very much work in progress. The shader requires the default renderer. No ALS/Rembrandt yet. Get the LOWI roads pack (including the shader) here: [https://dl.dropboxusercontent.com/u/24846517/fg/osm2city/LOWI_roads.tar.gz https://dl.dropboxusercontent.com/u/24846517/fg/osm2city/LOWI_roads.tar.gz] The fgdata/ folder goes to your $FGDATA. In roads.xml enable either the lightmap or the traffic shader.
|{{cite web |url=http://forum.flightgear.org/viewtopic.php?p=212460#p212460
|title=<nowiki>Re: osm2city.py development</nowiki>
|author=<nowiki>radi</nowiki>
|date=<nowiki>Fri Jun 13</nowiki>
}}
}}

{{FGCquote
|Creating your own road network is a bit cumbersome ATM, I'll try to make it more general in the next few days. But if you're really, really keen on it: <ul><li> get latest osm2city git</li><li> run roads.py -f your-parameters-file.</li><li> if you also create buildings, make sure to use the same BOUNDARY_* parameters for both osm2city.py and roads.py. Otherwise, buildings and roads might be misaligned. Basically, if your OSM file contains both roads and buildings, you can just use one parameters file.</li><li> roads.py will print an OBJECT_STATIC line, add this to your .stg (appears to add itself)</li><li> copy roads.ac to your scenery</li><li> copy roads.xml and tex/ from the LOWI roads pack to your scenery (roads.ac and .xml copy themselves)</li></ul>
|{{cite web |url=http://forum.flightgear.org/viewtopic.php?p=212460#p212460
|title=<nowiki>Re: osm2city.py development</nowiki>
|author=<nowiki>radi</nowiki>
|date=<nowiki>Fri Jun 13</nowiki>
}}
}}

=== Status 04/2014 ===
[[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. 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]]
The second scene, approaching LOWI from the east, went from 30 fps without buildings down to 20 fps.

=== Status 10/2013 ===
Currently data is processed offline beforehand. 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. <del>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.
</del> (Some optimization gave a huge speedup).

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
use some heuristics (some OSM buildings are labeled "Terminal 1" or so) to apply
terminal/hangar textures to buildings at airports. This way we could rather easily populate some airports with
'semi-generic' terminal/hangar buildings.

== Features ==
* 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 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)
* 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
:* ~10 different, hi-res facade textures, some roof textures
:* find matching texture for given building (number of levels, modern/old building, etc)
:* find matching roof texture for given facade texture
* basic lightmap support
* obstruction lights on tall buildings
* command line interface and parameters file (thanks to forum user vanosten)
* shows statistics on processed buildings
* 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 {{done}}
* 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|50}}
:* 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 ==
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
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 ==
* nearby hi-rise objects of similar shape get same texture? Probably too special a feature.
* 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 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 ==
1. dependencies: Install the following packages (names from Debian packages):
python-numpy python-shapely python-matplotlib python-scipy python-pil python-networkx
2. get [https://gitorious.org/fg-radi/osm2city osm2city] and [https://gitorious.org/fg-radi/osm2city-data osm2city-data] from gitorious

3. 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))

4. link osm2city-data/tex and osm2city-data/tex.src into osm2city/

If you're running FG >= 3.3, or git newer than 10 Oct 2014, and have more than 4 GB RAM, you're done installing now. Otherwise, you will most likely need to set-up and use the old-fashioned way of elevation probing, which requires you to

5. copy elev.nas to $FGDATA/Nasal/

6. Change the in variable of elev.nas to match the elev.in file e.g. $FG_DATA/Nasal/elev.in

7. Change the out variable of elev.nas to the export directory with a filename with write access (e.g. $FG_HOME/Export). See [[IORules]] and [[$FG_HOME]]

== Install on Windows ==
In general, you'll want to follow the above install section. This section lists some additional Windows particularities.

Osm2city is pure python.

https://www.python.org/downloads/release/python-278/

{{warning|Python 2.7 is recommended unless you're an experienced Python developer willing to update the Python scripts to support Python 3. Also pay attention to versions and cpu builds of the below helper files. Make sure they match your OS build and Python version.}}

Install the following packages, then proceed with [[Osm2city.py#Install|step 2. above]].

http://www.lfd.uci.edu/~gohlke/pythonlibs/#numpy

http://www.lfd.uci.edu/~gohlke/pythonlibs/#shapely

http://www.lfd.uci.edu/~gohlke/pythonlibs/#scipy-stack

https://pypi.python.org/pypi/Pillow/2.5.0#downloads

== Workflow ==
There are five main steps:
* get OSM data
* adjust input file
* if neccessary, create elevation grid and run FG to probe elevation data.
* run osm2city
* <del>install the generated scenery</del>installs itself

We'll now walk through these steps in detail:
=== get OSM data ===
* decide on a region you want to populate. Get its lon/lat coordinates.
* create a project directory. We will use LOWI/ in this example.
* get corresponding OSM data in its native .xml format.
There are several options to get OSM data. You may find the [http://harrywood.co.uk/maps/uixapi/xapi.html XAPI Query Builder] helpful, it will generate a download URL that you can fetch with wget:
wget -O buildings.osm http://www.overpass-api.de/api/xapi?map?bbox=11.16898,47.20837,11.79108,47.38161

If you use [http://wiki.openstreetmap.org/wiki/Osmosis Osmosis] and cut the area with ''--bounding-box'' then you need to use ''completeWays=yes''.

Put this data into LOWI/buildings.osm

=== Adjust input file ===
* Now adjust the input file. You can generate a commented default parameters file by
<syntaxhighlight lang="bash">
parameters.py -d > LOWI/params.ini
</syntaxhighlight>

Edit this file, adjusting (at least) the following:
:* PREFIX = LOWI (the project directory)
:* BOUNDARY_EAST, BOUNDARY_NORTH, BOUNDARY_SOUTH, BOUNDARY_WEST
:* OSM_FILE = buildings.osm
:* set PATH_TO_SCENERY to a standard [[$FG_SCENERY]] path. This is the path where we'll get the elevation from. Most likely you'll want to use your TerraSync path here. Suppose the area you want to populate is /home/user/fgfs/scenery/TerraSync/Objects/e010n40/e011n47/, PATH_TO_SCENERY would then be /home/user/fgfs/scenery/TerraSync .
:* set PATH_TO_OUTPUT to a ''different'' scenery path, e.g. /home/user/fgfs/scenery/osm2city . Osm2city will generate its objects there. First, this avoids TerraSync overwriting the generated scenery. Second, you can easily remove that folder in case you're not happy with the result. Make sure to include that path in your [[$FG_SCENERY]].
:* you might want to set MAX_OBJECTS to a small number (say, 100) for your first try. This will limit the number of buildings parsed, and speed up the whole process.
:* you also need to set up elevation probing in the parameters file, described in the next section.

=== Probe elevation ===
Probe elevation for your region. Pick one of the three available modes for ELEV_MODE in params.ini. If you have enough memory (4GB should be fine, but YMMV) and run FG git later than 10 Oct 2014, try FgelevCaching. Failing that, try Manual. (portreekid, what's the 3rd mode good for?)

'''There are a lot of problems reported currently with fgelev. I can't really test for the next month or so. See troubleshooting or use ELEV_MODE = Manual.'''

* ELEV_MODE = FgelevCaching
:* Set FG_ELEV to your fgelev executable. For example: FG_ELEV = /usr/local/fg/bin/fgelev or just FG_ELEV = fgelev if fgelev is already in your OS's path.
:* Set PATH_TO_SCENERY (Missing terrain will result in error message)
:* make sure the environment variable [[$FG ROOT]] points to your FG base path, (e.g. export FG_ROOT=/usr/share/games/flightgear/ on Linux)

* ELEV_MODE = Manual
:* run tools.py (tools.py -f LOWI/params.ini), this will create a file elev.in. Copy elev.in to $FGDATA/Nasal/
:* tools.py will tell you to hide a certain scenery/Objects/... folder, to prevent probing elevation on top of existing objects. Simply rename the folder
:* run FG, open debug->nasal console, enter: elev.get_elevation(), press execute. Might take a long time, depending on the area scanned. This will write elevation data to /tmp/elev.out (which is actually just plain 5 column data: lon,lat,x,y,elevation). Put elev.out into LOWI/
:* unhide, rename the objects folder

* ELEV_MODE = Telnet
:* Run setup.py
:* Start FG with the properties service on Port 5501
:* Run tools.py, this will create a elev.in, start the nasal script and copy the elev.out back to your project directory

=== Run osm2city ===
* run osm2city.py -f LOWI/prams.ini. Parsing OSM data <del>again takes quite looong (10 minutes or more for 50k buildings)</del> is now pretty fast, but the result is cached to file buildings.pkl. Next startup will be <del>much faster if you move buildings.pkl to LOWI/buildings.pkl and</del> even faster if you set USE_PKL = 1.

If all goes well, files like LOWIcity0101.ac and their corresponding .xml, along with .stg files, were created and moved to the correct location in $FG_SCENERY
* copy or link the tex/ folder into the objects folder where these files were created

=== Roads ===
* run roads.py in the same fashion for roads
* <del>copy roads.eff to the same Objects\e0XXnXX\e0XXnXX\ directory</del> roads.eff is copied automatically
* Band-aid fix for the roads is to adjust their height in roads.py change AGL_ofs to a higher number e.g. 0.5

== Support and troubleshooting ==
Time permitting, we can provide limited support on the [http://forum.flightgear.org/viewtopic.php?f=5&t=22809 Forums]. Please don't use PM for support questions.

Before you ask a question, make sure you read this wiki page. If your question is not covered here, tell us as much as possible about the problem you're facing. Which steps have you taken to solve it? What is the exact error message? What operating system? Screenshots?

We will not cover general questions like "I don't know how to install XY" -- search the Internet.

* Buildings are generated, but they sit below the ground. I'm using ELEV_MODE = FgelevCaching.

Try running fgelev directly:
<syntaxhighlight lang="bash">
/path/to/fgelev --expire 1000 --fg-root $FG_ROOT --fg-scenery $FG_SCENERY
</syntaxhighlight>
then enter
<syntaxhighlight lang="bash">
0 $lon $lat
</syntaxhighlight>
where $lon and $lat are coordinates in the area you want to generate. See if it returns a sane value. If it does, double-check PATH_TO_SCENERY and $FG_ROOT.

* Buildings/roads have no texture.
copy or link the tex/ folder into the objects folder where the .stg files were created, such that you have $FG_SCENERY/Objects/eXXXnXX/eXXXnXX/tex/.

== Improve frame rate ==
* adjust LOD ranges in FG
* decrease MAX_OBJECTS, increase LOD_*
(- use larger/smaller tiles? Tradeoff between distance calculations/xml parsing and GPU)

== Contributing ==
You know some python? Or you're keen on writing docs? Or just want to use osm2city, but got stuck somewhere? Contact radi on the FG forum.
None of the above? Take [[Howto:Create_textures_from_photos|pictures]] of buildings where you live and [[Osm2city.py Textures|create textures]]! I'm especially interested in south-east asian style architecture, as I'm planning to populate Hong Kong Kai Tak (VHXX) in the future.

== Related ==
* [[Using OSM Vector Data in FlightGear]]
* [[OpenStreetMap buildings]]
* [[AutoGen Scenery for FlightGear]]
* [[Random Buildings]]
* [http://forum.flightgear.org/viewtopic.php?f=5&t=21131#p192198 OSM buidings EHLE]
* [http://forum.flightgear.org/viewtopic.php?f=5&t=22809 osm2city.py development]
* [http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg40092.html Osm2city.py]
* http://forum.flightgear.org/viewtopic.php?f=5&t=19625
* [http://forum.flightgear.org/viewtopic.php?f=38&t=8837 PixelCity]
* [http://forum.flightgear.org/viewtopic.php?p=166794#p166681 Procedural OSM buildings]

[[Category:Scenery software]]

Osm2city.py

2014-11-10T11:42:16Z

Radi: /* Install */ fix numbering

{{OSM Navigation}}
[[File:LOWI with OSM buildings.jpg|thumb|LOWI with OSM buildings]]

This Python script takes OpenStreetMap floorplans and creates 3d buildings ready for use in FlightGear.

The development [https://gitorious.org/fg-radi/osm2city repository] is hosted on gitorious.
Forum thread [http://forum.flightgear.org/viewtopic.php?f=5&t=22809 osm2city.py development]
Written in Python 2.7, developed on GNU/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 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.

== News ==
=== Status 10/2014 ===
New features:
* textures reside in a separate [https://gitorious.org/fg-radi/osm2city-data repository]
* the recommended elevation probing method is ELEV_MODE=FgelevCaching
* roads.py is now quite usable
* SKIP_LIST can contain OSM_IDs

=== Status 06/2014 ===
I'm currently adding textured roads, railroads, intersections and bridges.

{{FGCquote
| the shader is now on osm2city's git (in fgdata/). Again -- all credit goes to Emilian. He is improving the shader side, I will continue on the model side. So this is very much work in progress. The shader requires the default renderer. No ALS/Rembrandt yet. Get the LOWI roads pack (including the shader) here: [https://dl.dropboxusercontent.com/u/24846517/fg/osm2city/LOWI_roads.tar.gz https://dl.dropboxusercontent.com/u/24846517/fg/osm2city/LOWI_roads.tar.gz] The fgdata/ folder goes to your $FGDATA. In roads.xml enable either the lightmap or the traffic shader.
|{{cite web |url=http://forum.flightgear.org/viewtopic.php?p=212460#p212460
|title=<nowiki>Re: osm2city.py development</nowiki>
|author=<nowiki>radi</nowiki>
|date=<nowiki>Fri Jun 13</nowiki>
}}
}}

{{FGCquote
|Creating your own road network is a bit cumbersome ATM, I'll try to make it more general in the next few days. But if you're really, really keen on it: <ul><li> get latest osm2city git</li><li> run roads.py -f your-parameters-file.</li><li> if you also create buildings, make sure to use the same BOUNDARY_* parameters for both osm2city.py and roads.py. Otherwise, buildings and roads might be misaligned. Basically, if your OSM file contains both roads and buildings, you can just use one parameters file.</li><li> roads.py will print an OBJECT_STATIC line, add this to your .stg (appears to add itself)</li><li> copy roads.ac to your scenery</li><li> copy roads.xml and tex/ from the LOWI roads pack to your scenery (roads.ac and .xml copy themselves)</li></ul>
|{{cite web |url=http://forum.flightgear.org/viewtopic.php?p=212460#p212460
|title=<nowiki>Re: osm2city.py development</nowiki>
|author=<nowiki>radi</nowiki>
|date=<nowiki>Fri Jun 13</nowiki>
}}
}}

=== Status 04/2014 ===
[[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. 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]]
The second scene, approaching LOWI from the east, went from 30 fps without buildings down to 20 fps.

=== Status 10/2013 ===
Currently data is processed offline beforehand. 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. <del>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.
</del> (Some optimization gave a huge speedup).

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
use some heuristics (some OSM buildings are labeled "Terminal 1" or so) to apply
terminal/hangar textures to buildings at airports. This way we could rather easily populate some airports with
'semi-generic' terminal/hangar buildings.

== Features ==
* 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 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)
* 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
:* ~10 different, hi-res facade textures, some roof textures
:* find matching texture for given building (number of levels, modern/old building, etc)
:* find matching roof texture for given facade texture
* basic lightmap support
* obstruction lights on tall buildings
* command line interface and parameters file (thanks to forum user vanosten)
* shows statistics on processed buildings
* 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 {{done}}
* 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|50}}
:* 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 ==
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
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 ==
* nearby hi-rise objects of similar shape get same texture? Probably too special a feature.
* 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 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 ==
1. dependencies: Install the following packages (names from Debian packages):
python-numpy python-shapely python-matplotlib python-scipy python-pil python-networkx
2. get [https://gitorious.org/fg-radi/osm2city osm2city] and [https://gitorious.org/fg-radi/osm2city-data osm2city-data] from gitorious

3. 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))

4. link osm2city-data/tex and osm2city-data/tex.src into osm2city/

If you're running FG >= 3.3, or git newer than 10 Oct 2014, and have more than 4 GB RAM, you're done installing now. Otherwise, you will most likely need to set-up and use the old-fashioned way of elevation probing, which requires you to

5. copy elev.nas to $FGDATA/Nasal/

6. Change the in variable of elev.nas to match the elev.in file e.g. $FG_DATA/Nasal/elev.in

7. Change the out variable of elev.nas to the export directory with a filename with write access (e.g. $FG_HOME/Export). See [[IORules]] and [[$FG_HOME]]

== Install on Windows ==
In general, you'll want to follow the above install section. This section lists some additional Windows particularities.

Osm2city is pure python.

https://www.python.org/downloads/release/python-278/

{{warning|Python 2.7 is recommended unless you're an experienced Python developer willing to update the Python scripts to support Python 3. Also pay attention to versions and cpu builds of the below helper files. Make sure they match your OS build and Python version.}}

Install the following packages, then proceed with [[Osm2city.py#Install|step 2. above]].

http://www.lfd.uci.edu/~gohlke/pythonlibs/#numpy

http://www.lfd.uci.edu/~gohlke/pythonlibs/#shapely

http://www.lfd.uci.edu/~gohlke/pythonlibs/#scipy-stack

https://pypi.python.org/pypi/Pillow/2.5.0#downloads

== Workflow ==
There are five main steps:
* get OSM data
* adjust input file
* if neccessary, create elevation grid and run FG to probe elevation data.
* run osm2city
* <del>install the generated scenery</del>installs itself

We'll now walk through these steps in detail:
=== get OSM data ===
* decide on a region you want to populate. Get its lon/lat coordinates.
* create a project directory. We will use LOWI/ in this example.
* get corresponding OSM data in its native .xml format.
There are several options to get OSM data. You may find the [http://harrywood.co.uk/maps/uixapi/xapi.html XAPI Query Builder] helpful, it will generate a download URL that you can fetch with wget:
wget -O buildings.osm http://www.overpass-api.de/api/xapi?map?bbox=11.16898,47.20837,11.79108,47.38161

If you use [http://wiki.openstreetmap.org/wiki/Osmosis Osmosis] and cut the area with ''--bounding-box'' then you need to use ''completeWays=yes''.

Put this data into LOWI/buildings.osm

=== Adjust input file ===
* Now adjust the input file. You can generate a commented default parameters file by
<syntaxhighlight lang="bash">
parameters.py -d > LOWI/params.ini
</syntaxhighlight>

Edit this file, adjusting (at least) the following:
:* PREFIX = LOWI (the project directory)
:* BOUNDARY_EAST, BOUNDARY_NORTH, BOUNDARY_SOUTH, BOUNDARY_WEST
:* OSM_FILE = buildings.osm
:* set PATH_TO_SCENERY to a standard [[$FG_SCENERY]] path. This is the path where we'll get the elevation from. Most likely you'll want to use your TerraSync path here. Suppose the area you want to populate is /home/user/fgfs/scenery/TerraSync/Objects/e010n40/e011n47/, PATH_TO_SCENERY would then be /home/user/fgfs/scenery/TerraSync .
:* set PATH_TO_OUTPUT to a ''different'' scenery path, e.g. /home/user/fgfs/scenery/osm2city . Osm2city will generate its objects there. First, this avoids TerraSync overwriting the generated scenery. Second, you can easily remove that folder in case you're not happy with the result. Make sure to include that path in your [[$FG_SCENERY]].
:* you might want to set MAX_OBJECTS to a small number (say, 100) for your first try. This will limit the number of buildings parsed, and speed up the whole process.
:* you also need to set up elevation probing in the parameters file, described in the next section.

=== Probe elevation ===
Probe elevation for your region. Pick one of the three available modes for ELEV_MODE in params.ini. If you have enough memory (4GB should be fine, but YMMV) and run FG git later than 10 Oct 2014, try FgelevCaching. Failing that, try Manual. (portreekid, what's the 3rd mode good for?)

'''There are a lot of problems reported currently with fgelev. I can't really test for the next month or so. See troubleshooting or use ELEV_MODE = Manual.'''

* ELEV_MODE = FgelevCaching
:* Set FG_ELEV to your fgelev executable. For example: FG_ELEV = /usr/local/fg/bin/fgelev or just FG_ELEV = fgelev if fgelev is already in your OS's path.
:* Set PATH_TO_SCENERY (Missing terrain will result in error message)
:* make sure the environment variable [[$FG ROOT]] points to your FG base path, (e.g. export FG_ROOT=/usr/share/games/flightgear/ on Linux)

* ELEV_MODE = Manual
:* run tools.py (tools.py -f LOWI/params.ini), this will create a file elev.in. Copy elev.in to $FGDATA/Nasal/
:* tools.py will tell you to hide a certain scenery/Objects/... folder, to prevent probing elevation on top of existing objects. Simply rename the folder
:* run FG, open debug->nasal console, enter: elev.get_elevation(), press execute. Might take a long time, depending on the area scanned. This will write elevation data to /tmp/elev.out (which is actually just plain 5 column data: lon,lat,x,y,elevation). Put elev.out into LOWI/
:* unhide, rename the objects folder

* ELEV_MODE = Telnet
:* Run setup.py
:* Start FG with the properties service on Port 5501
:* Run tools.py, this will create a elev.in, start the nasal script and copy the elev.out back to your project directory

=== Run osm2city ===
* run osm2city.py -f LOWI/prams.ini. Parsing OSM data <del>again takes quite looong (10 minutes or more for 50k buildings)</del> is now pretty fast, but the result is cached to file buildings.pkl. Next startup will be <del>much faster if you move buildings.pkl to LOWI/buildings.pkl and</del> even faster if you set USE_PKL = 1.

If all goes well, files like LOWIcity0101.ac and their corresponding .xml, along with .stg files, were created and moved to the correct location in $FG_SCENERY
* copy or link the tex/ folder into the objects folder where these files were created

=== Roads ===
* run roads.py in the same fashion for roads
* <del>copy roads.eff to the same Objects\e0XXnXX\e0XXnXX\ directory</del> roads.eff is copied automatically
* Band-aid fix for the roads is to adjust their height in roads.py change AGL_ofs to a higher number e.g. 0.5

== Troubleshooting ==
* Buildings are generated, but they sit below the ground. I'm using ELEV_MODE = FgelevCaching.

Try running fgelev directly:
<syntaxhighlight lang="bash">
/path/to/fgelev --expire 1000 --fg-root $FG_ROOT --fg-scenery $FG_SCENERY
</syntaxhighlight>
then enter
<syntaxhighlight lang="bash">
0 $lon $lat
</syntaxhighlight>
where $lon and $lat are coordinates in the area you want to generate. See if it returns a sane value. If it does, double-check PATH_TO_SCENERY and $FG_ROOT.

* Buildings/roads have no texture.
copy or link the tex/ folder into the objects folder where the .stg files were created, such that you have $FG_SCENERY/Objects/eXXXnXX/eXXXnXX/tex/.

== Improve frame rate ==
* adjust LOD ranges in FG
* decrease MAX_OBJECTS, increase LOD_*
(- use larger/smaller tiles? Tradeoff between distance calculations/xml parsing and GPU)

== Contributing ==
You know some python? Or you're keen on writing docs? Or just want to use osm2city, but got stuck somewhere? Contact radi on the FG forum.
None of the above? Take [[Howto:Create_textures_from_photos|pictures]] of buildings where you live and [[Osm2city.py Textures|create textures]]! I'm especially interested in south-east asian style architecture, as I'm planning to populate Hong Kong Kai Tak (VHXX) in the future.

== Related ==
* [[Using OSM Vector Data in FlightGear]]
* [[OpenStreetMap buildings]]
* [[AutoGen Scenery for FlightGear]]
* [[Random Buildings]]
* [http://forum.flightgear.org/viewtopic.php?f=5&t=21131#p192198 OSM buidings EHLE]
* [http://forum.flightgear.org/viewtopic.php?f=5&t=22809 osm2city.py development]
* [http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg40092.html Osm2city.py]
* http://forum.flightgear.org/viewtopic.php?f=5&t=19625
* [http://forum.flightgear.org/viewtopic.php?f=38&t=8837 PixelCity]
* [http://forum.flightgear.org/viewtopic.php?p=166794#p166681 Procedural OSM buildings]

[[Category:Scenery software]]

Osm2city.py

2014-11-10T11:36:55Z

Radi: /* Install on Windows */ Note to follow install

{{OSM Navigation}}
[[File:LOWI with OSM buildings.jpg|thumb|LOWI with OSM buildings]]

This Python script takes OpenStreetMap floorplans and creates 3d buildings ready for use in FlightGear.

The development [https://gitorious.org/fg-radi/osm2city repository] is hosted on gitorious.
Forum thread [http://forum.flightgear.org/viewtopic.php?f=5&t=22809 osm2city.py development]
Written in Python 2.7, developed on GNU/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 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.

== News ==
=== Status 10/2014 ===
New features:
* textures reside in a separate [https://gitorious.org/fg-radi/osm2city-data repository]
* the recommended elevation probing method is ELEV_MODE=FgelevCaching
* roads.py is now quite usable
* SKIP_LIST can contain OSM_IDs

=== Status 06/2014 ===
I'm currently adding textured roads, railroads, intersections and bridges.

{{FGCquote
| the shader is now on osm2city's git (in fgdata/). Again -- all credit goes to Emilian. He is improving the shader side, I will continue on the model side. So this is very much work in progress. The shader requires the default renderer. No ALS/Rembrandt yet. Get the LOWI roads pack (including the shader) here: [https://dl.dropboxusercontent.com/u/24846517/fg/osm2city/LOWI_roads.tar.gz https://dl.dropboxusercontent.com/u/24846517/fg/osm2city/LOWI_roads.tar.gz] The fgdata/ folder goes to your $FGDATA. In roads.xml enable either the lightmap or the traffic shader.
|{{cite web |url=http://forum.flightgear.org/viewtopic.php?p=212460#p212460
|title=<nowiki>Re: osm2city.py development</nowiki>
|author=<nowiki>radi</nowiki>
|date=<nowiki>Fri Jun 13</nowiki>
}}
}}

{{FGCquote
|Creating your own road network is a bit cumbersome ATM, I'll try to make it more general in the next few days. But if you're really, really keen on it: <ul><li> get latest osm2city git</li><li> run roads.py -f your-parameters-file.</li><li> if you also create buildings, make sure to use the same BOUNDARY_* parameters for both osm2city.py and roads.py. Otherwise, buildings and roads might be misaligned. Basically, if your OSM file contains both roads and buildings, you can just use one parameters file.</li><li> roads.py will print an OBJECT_STATIC line, add this to your .stg (appears to add itself)</li><li> copy roads.ac to your scenery</li><li> copy roads.xml and tex/ from the LOWI roads pack to your scenery (roads.ac and .xml copy themselves)</li></ul>
|{{cite web |url=http://forum.flightgear.org/viewtopic.php?p=212460#p212460
|title=<nowiki>Re: osm2city.py development</nowiki>
|author=<nowiki>radi</nowiki>
|date=<nowiki>Fri Jun 13</nowiki>
}}
}}

=== Status 04/2014 ===
[[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. 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]]
The second scene, approaching LOWI from the east, went from 30 fps without buildings down to 20 fps.

=== Status 10/2013 ===
Currently data is processed offline beforehand. 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. <del>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.
</del> (Some optimization gave a huge speedup).

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
use some heuristics (some OSM buildings are labeled "Terminal 1" or so) to apply
terminal/hangar textures to buildings at airports. This way we could rather easily populate some airports with
'semi-generic' terminal/hangar buildings.

== Features ==
* 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 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)
* 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
:* ~10 different, hi-res facade textures, some roof textures
:* find matching texture for given building (number of levels, modern/old building, etc)
:* find matching roof texture for given facade texture
* basic lightmap support
* obstruction lights on tall buildings
* command line interface and parameters file (thanks to forum user vanosten)
* shows statistics on processed buildings
* 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 {{done}}
* 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|50}}
:* 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 ==
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
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 ==
* nearby hi-rise objects of similar shape get same texture? Probably too special a feature.
* 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 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 ==
1. dependencies: Install the following packages (names from Debian packages):
python-numpy python-shapely python-matplotlib python-scipy python-pil python-networkx
2. get [https://gitorious.org/fg-radi/osm2city osm2city] and [https://gitorious.org/fg-radi/osm2city-data osm2city-data] from gitorious

3. 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))

4. link osm2city-data/tex and osm2city-data/tex.src into osm2city/

If you're running FG < 3.2, or git older than 10 Oct 2014, or have less than 4 GB RAM, you will most likely need to use the old-fashioned way of elevation probing, which requires you to
5. copy elev.nas to $FGDATA/Nasal/

6. Change the in variable of elev.nas to match the elev.in file e.g. $FG_DATA/Nasal/elev.in

7. Change the out variable of elev.nas to the export directory with a filename with write access (e.g. $FG_HOME/Export). See [[IORules]] and [[$FG_HOME]]

== Install on Windows ==
In general, you'll want to follow the above install section. This section lists some additional Windows particularities.

Osm2city is pure python.

https://www.python.org/downloads/release/python-278/

{{warning|Python 2.7 is recommended unless you're an experienced Python developer willing to update the Python scripts to support Python 3. Also pay attention to versions and cpu builds of the below helper files. Make sure they match your OS build and Python version.}}

Install the following packages, then proceed with [[Osm2city.py#Install|step 2. above]].

http://www.lfd.uci.edu/~gohlke/pythonlibs/#numpy

http://www.lfd.uci.edu/~gohlke/pythonlibs/#shapely

http://www.lfd.uci.edu/~gohlke/pythonlibs/#scipy-stack

https://pypi.python.org/pypi/Pillow/2.5.0#downloads

== Workflow ==
There are five main steps:
* get OSM data
* adjust input file
* if neccessary, create elevation grid and run FG to probe elevation data.
* run osm2city
* <del>install the generated scenery</del>installs itself

We'll now walk through these steps in detail:
=== get OSM data ===
* decide on a region you want to populate. Get its lon/lat coordinates.
* create a project directory. We will use LOWI/ in this example.
* get corresponding OSM data in its native .xml format.
There are several options to get OSM data. You may find the [http://harrywood.co.uk/maps/uixapi/xapi.html XAPI Query Builder] helpful, it will generate a download URL that you can fetch with wget:
wget -O buildings.osm http://www.overpass-api.de/api/xapi?map?bbox=11.16898,47.20837,11.79108,47.38161

If you use [http://wiki.openstreetmap.org/wiki/Osmosis Osmosis] and cut the area with ''--bounding-box'' then you need to use ''completeWays=yes''.

Put this data into LOWI/buildings.osm

=== Adjust input file ===
* Now adjust the input file. You can generate a commented default parameters file by
<syntaxhighlight lang="bash">
parameters.py -d > LOWI/params.ini
</syntaxhighlight>

Edit this file, adjusting (at least) the following:
:* PREFIX = LOWI (the project directory)
:* BOUNDARY_EAST, BOUNDARY_NORTH, BOUNDARY_SOUTH, BOUNDARY_WEST
:* OSM_FILE = buildings.osm
:* set PATH_TO_SCENERY to a standard [[$FG_SCENERY]] path. This is the path where we'll get the elevation from. Most likely you'll want to use your TerraSync path here. Suppose the area you want to populate is /home/user/fgfs/scenery/TerraSync/Objects/e010n40/e011n47/, PATH_TO_SCENERY would then be /home/user/fgfs/scenery/TerraSync .
:* set PATH_TO_OUTPUT to a ''different'' scenery path, e.g. /home/user/fgfs/scenery/osm2city . Osm2city will generate its objects there. First, this avoids TerraSync overwriting the generated scenery. Second, you can easily remove that folder in case you're not happy with the result. Make sure to include that path in your [[$FG_SCENERY]].
:* you might want to set MAX_OBJECTS to a small number (say, 100) for your first try. This will limit the number of buildings parsed, and speed up the whole process.
:* you also need to set up elevation probing in the parameters file, described in the next section.

=== Probe elevation ===
Probe elevation for your region. Pick one of the three available modes for ELEV_MODE in params.ini. If you have enough memory (4GB should be fine, but YMMV) and run FG git later than 10 Oct 2014, try FgelevCaching. Failing that, try Manual. (portreekid, what's the 3rd mode good for?)

'''There are a lot of problems reported currently with fgelev. I can't really test for the next month or so. See troubleshooting or use ELEV_MODE = Manual.'''

* ELEV_MODE = FgelevCaching
:* Set FG_ELEV to your fgelev executable. For example: FG_ELEV = /usr/local/fg/bin/fgelev or just FG_ELEV = fgelev if fgelev is already in your OS's path.
:* Set PATH_TO_SCENERY (Missing terrain will result in error message)
:* make sure the environment variable [[$FG ROOT]] points to your FG base path, (e.g. export FG_ROOT=/usr/share/games/flightgear/ on Linux)

* ELEV_MODE = Manual
:* run tools.py (tools.py -f LOWI/params.ini), this will create a file elev.in. Copy elev.in to $FGDATA/Nasal/
:* tools.py will tell you to hide a certain scenery/Objects/... folder, to prevent probing elevation on top of existing objects. Simply rename the folder
:* run FG, open debug->nasal console, enter: elev.get_elevation(), press execute. Might take a long time, depending on the area scanned. This will write elevation data to /tmp/elev.out (which is actually just plain 5 column data: lon,lat,x,y,elevation). Put elev.out into LOWI/
:* unhide, rename the objects folder

* ELEV_MODE = Telnet
:* Run setup.py
:* Start FG with the properties service on Port 5501
:* Run tools.py, this will create a elev.in, start the nasal script and copy the elev.out back to your project directory

=== Run osm2city ===
* run osm2city.py -f LOWI/prams.ini. Parsing OSM data <del>again takes quite looong (10 minutes or more for 50k buildings)</del> is now pretty fast, but the result is cached to file buildings.pkl. Next startup will be <del>much faster if you move buildings.pkl to LOWI/buildings.pkl and</del> even faster if you set USE_PKL = 1.

If all goes well, files like LOWIcity0101.ac and their corresponding .xml, along with .stg files, were created and moved to the correct location in $FG_SCENERY
* copy or link the tex/ folder into the objects folder where these files were created

=== Roads ===
* run roads.py in the same fashion for roads
* <del>copy roads.eff to the same Objects\e0XXnXX\e0XXnXX\ directory</del> roads.eff is copied automatically
* Band-aid fix for the roads is to adjust their height in roads.py change AGL_ofs to a higher number e.g. 0.5

== Troubleshooting ==
* Buildings are generated, but they sit below the ground. I'm using ELEV_MODE = FgelevCaching.

Try running fgelev directly:
<syntaxhighlight lang="bash">
/path/to/fgelev --expire 1000 --fg-root $FG_ROOT --fg-scenery $FG_SCENERY
</syntaxhighlight>
then enter
<syntaxhighlight lang="bash">
0 $lon $lat
</syntaxhighlight>
where $lon and $lat are coordinates in the area you want to generate. See if it returns a sane value. If it does, double-check PATH_TO_SCENERY and $FG_ROOT.

* Buildings/roads have no texture.
copy or link the tex/ folder into the objects folder where the .stg files were created, such that you have $FG_SCENERY/Objects/eXXXnXX/eXXXnXX/tex/.

== Improve frame rate ==
* adjust LOD ranges in FG
* decrease MAX_OBJECTS, increase LOD_*
(- use larger/smaller tiles? Tradeoff between distance calculations/xml parsing and GPU)

== Contributing ==
You know some python? Or you're keen on writing docs? Or just want to use osm2city, but got stuck somewhere? Contact radi on the FG forum.
None of the above? Take [[Howto:Create_textures_from_photos|pictures]] of buildings where you live and [[Osm2city.py Textures|create textures]]! I'm especially interested in south-east asian style architecture, as I'm planning to populate Hong Kong Kai Tak (VHXX) in the future.

== Related ==
* [[Using OSM Vector Data in FlightGear]]
* [[OpenStreetMap buildings]]
* [[AutoGen Scenery for FlightGear]]
* [[Random Buildings]]
* [http://forum.flightgear.org/viewtopic.php?f=5&t=21131#p192198 OSM buidings EHLE]
* [http://forum.flightgear.org/viewtopic.php?f=5&t=22809 osm2city.py development]
* [http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg40092.html Osm2city.py]
* http://forum.flightgear.org/viewtopic.php?f=5&t=19625
* [http://forum.flightgear.org/viewtopic.php?f=38&t=8837 PixelCity]
* [http://forum.flightgear.org/viewtopic.php?p=166794#p166681 Procedural OSM buildings]

[[Category:Scenery software]]

Osm2city.py

2014-11-10T11:32:02Z

Radi: link

{{OSM Navigation}}
[[File:LOWI with OSM buildings.jpg|thumb|LOWI with OSM buildings]]

This Python script takes OpenStreetMap floorplans and creates 3d buildings ready for use in FlightGear.

The development [https://gitorious.org/fg-radi/osm2city repository] is hosted on gitorious.
Forum thread [http://forum.flightgear.org/viewtopic.php?f=5&t=22809 osm2city.py development]
Written in Python 2.7, developed on GNU/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 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.

== News ==
=== Status 10/2014 ===
New features:
* textures reside in a separate [https://gitorious.org/fg-radi/osm2city-data repository]
* the recommended elevation probing method is ELEV_MODE=FgelevCaching
* roads.py is now quite usable
* SKIP_LIST can contain OSM_IDs

=== Status 06/2014 ===
I'm currently adding textured roads, railroads, intersections and bridges.

{{FGCquote
| the shader is now on osm2city's git (in fgdata/). Again -- all credit goes to Emilian. He is improving the shader side, I will continue on the model side. So this is very much work in progress. The shader requires the default renderer. No ALS/Rembrandt yet. Get the LOWI roads pack (including the shader) here: [https://dl.dropboxusercontent.com/u/24846517/fg/osm2city/LOWI_roads.tar.gz https://dl.dropboxusercontent.com/u/24846517/fg/osm2city/LOWI_roads.tar.gz] The fgdata/ folder goes to your $FGDATA. In roads.xml enable either the lightmap or the traffic shader.
|{{cite web |url=http://forum.flightgear.org/viewtopic.php?p=212460#p212460
|title=<nowiki>Re: osm2city.py development</nowiki>
|author=<nowiki>radi</nowiki>
|date=<nowiki>Fri Jun 13</nowiki>
}}
}}

{{FGCquote
|Creating your own road network is a bit cumbersome ATM, I'll try to make it more general in the next few days. But if you're really, really keen on it: <ul><li> get latest osm2city git</li><li> run roads.py -f your-parameters-file.</li><li> if you also create buildings, make sure to use the same BOUNDARY_* parameters for both osm2city.py and roads.py. Otherwise, buildings and roads might be misaligned. Basically, if your OSM file contains both roads and buildings, you can just use one parameters file.</li><li> roads.py will print an OBJECT_STATIC line, add this to your .stg (appears to add itself)</li><li> copy roads.ac to your scenery</li><li> copy roads.xml and tex/ from the LOWI roads pack to your scenery (roads.ac and .xml copy themselves)</li></ul>
|{{cite web |url=http://forum.flightgear.org/viewtopic.php?p=212460#p212460
|title=<nowiki>Re: osm2city.py development</nowiki>
|author=<nowiki>radi</nowiki>
|date=<nowiki>Fri Jun 13</nowiki>
}}
}}

=== Status 04/2014 ===
[[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. 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]]
The second scene, approaching LOWI from the east, went from 30 fps without buildings down to 20 fps.

=== Status 10/2013 ===
Currently data is processed offline beforehand. 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. <del>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.
</del> (Some optimization gave a huge speedup).

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
use some heuristics (some OSM buildings are labeled "Terminal 1" or so) to apply
terminal/hangar textures to buildings at airports. This way we could rather easily populate some airports with
'semi-generic' terminal/hangar buildings.

== Features ==
* 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 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)
* 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
:* ~10 different, hi-res facade textures, some roof textures
:* find matching texture for given building (number of levels, modern/old building, etc)
:* find matching roof texture for given facade texture
* basic lightmap support
* obstruction lights on tall buildings
* command line interface and parameters file (thanks to forum user vanosten)
* shows statistics on processed buildings
* 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 {{done}}
* 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|50}}
:* 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 ==
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
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 ==
* nearby hi-rise objects of similar shape get same texture? Probably too special a feature.
* 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 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 ==
1. dependencies: Install the following packages (names from Debian packages):
python-numpy python-shapely python-matplotlib python-scipy python-pil python-networkx
2. get [https://gitorious.org/fg-radi/osm2city osm2city] and [https://gitorious.org/fg-radi/osm2city-data osm2city-data] from gitorious

3. 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))

4. link osm2city-data/tex and osm2city-data/tex.src into osm2city/

If you're running FG < 3.2, or git older than 10 Oct 2014, or have less than 4 GB RAM, you will most likely need to use the old-fashioned way of elevation probing, which requires you to
5. copy elev.nas to $FGDATA/Nasal/

6. Change the in variable of elev.nas to match the elev.in file e.g. $FG_DATA/Nasal/elev.in

7. Change the out variable of elev.nas to the export directory with a filename with write access (e.g. $FG_HOME/Export). See [[IORules]] and [[$FG_HOME]]

== Install on Windows ==
osm2city is pure python.

https://www.python.org/downloads/release/python-278/

{{warning|Python 2.7 is recommended unless your an experienced Python developer willing to update the Python scripts to support Python 3. Also pay attention to versions and cpu builds of the below helper files. Make sure they match your OS build and Python version.}}

Install the following packages, then proceed with [[Osm2city.py#Install|step 2. above]]

http://www.lfd.uci.edu/~gohlke/pythonlibs/#numpy

http://www.lfd.uci.edu/~gohlke/pythonlibs/#shapely

http://www.lfd.uci.edu/~gohlke/pythonlibs/#scipy-stack

https://pypi.python.org/pypi/Pillow/2.5.0#downloads

== Workflow ==
There are five main steps:
* get OSM data
* adjust input file
* if neccessary, create elevation grid and run FG to probe elevation data.
* run osm2city
* <del>install the generated scenery</del>installs itself

We'll now walk through these steps in detail:
=== get OSM data ===
* decide on a region you want to populate. Get its lon/lat coordinates.
* create a project directory. We will use LOWI/ in this example.
* get corresponding OSM data in its native .xml format.
There are several options to get OSM data. You may find the [http://harrywood.co.uk/maps/uixapi/xapi.html XAPI Query Builder] helpful, it will generate a download URL that you can fetch with wget:
wget -O buildings.osm http://www.overpass-api.de/api/xapi?map?bbox=11.16898,47.20837,11.79108,47.38161

If you use [http://wiki.openstreetmap.org/wiki/Osmosis Osmosis] and cut the area with ''--bounding-box'' then you need to use ''completeWays=yes''.

Put this data into LOWI/buildings.osm

=== Adjust input file ===
* Now adjust the input file. You can generate a commented default parameters file by
<syntaxhighlight lang="bash">
parameters.py -d > LOWI/params.ini
</syntaxhighlight>

Edit this file, adjusting (at least) the following:
:* PREFIX = LOWI (the project directory)
:* BOUNDARY_EAST, BOUNDARY_NORTH, BOUNDARY_SOUTH, BOUNDARY_WEST
:* OSM_FILE = buildings.osm
:* set PATH_TO_SCENERY to a standard [[$FG_SCENERY]] path. This is the path where we'll get the elevation from. Most likely you'll want to use your TerraSync path here. Suppose the area you want to populate is /home/user/fgfs/scenery/TerraSync/Objects/e010n40/e011n47/, PATH_TO_SCENERY would then be /home/user/fgfs/scenery/TerraSync .
:* set PATH_TO_OUTPUT to a ''different'' scenery path, e.g. /home/user/fgfs/scenery/osm2city . Osm2city will generate its objects there. First, this avoids TerraSync overwriting the generated scenery. Second, you can easily remove that folder in case you're not happy with the result. Make sure to include that path in your [[$FG_SCENERY]].
:* you might want to set MAX_OBJECTS to a small number (say, 100) for your first try. This will limit the number of buildings parsed, and speed up the whole process.
:* you also need to set up elevation probing in the parameters file, described in the next section.

=== Probe elevation ===
Probe elevation for your region. Pick one of the three available modes for ELEV_MODE in params.ini. If you have enough memory (4GB should be fine, but YMMV) and run FG git later than 10 Oct 2014, try FgelevCaching. Failing that, try Manual. (portreekid, what's the 3rd mode good for?)

'''There are a lot of problems reported currently with fgelev. I can't really test for the next month or so. See troubleshooting or use ELEV_MODE = Manual.'''

* ELEV_MODE = FgelevCaching
:* Set FG_ELEV to your fgelev executable. For example: FG_ELEV = /usr/local/fg/bin/fgelev or just FG_ELEV = fgelev if fgelev is already in your OS's path.
:* Set PATH_TO_SCENERY (Missing terrain will result in error message)
:* make sure the environment variable [[$FG ROOT]] points to your FG base path, (e.g. export FG_ROOT=/usr/share/games/flightgear/ on Linux)

* ELEV_MODE = Manual
:* run tools.py (tools.py -f LOWI/params.ini), this will create a file elev.in. Copy elev.in to $FGDATA/Nasal/
:* tools.py will tell you to hide a certain scenery/Objects/... folder, to prevent probing elevation on top of existing objects. Simply rename the folder
:* run FG, open debug->nasal console, enter: elev.get_elevation(), press execute. Might take a long time, depending on the area scanned. This will write elevation data to /tmp/elev.out (which is actually just plain 5 column data: lon,lat,x,y,elevation). Put elev.out into LOWI/
:* unhide, rename the objects folder

* ELEV_MODE = Telnet
:* Run setup.py
:* Start FG with the properties service on Port 5501
:* Run tools.py, this will create a elev.in, start the nasal script and copy the elev.out back to your project directory

=== Run osm2city ===
* run osm2city.py -f LOWI/prams.ini. Parsing OSM data <del>again takes quite looong (10 minutes or more for 50k buildings)</del> is now pretty fast, but the result is cached to file buildings.pkl. Next startup will be <del>much faster if you move buildings.pkl to LOWI/buildings.pkl and</del> even faster if you set USE_PKL = 1.

If all goes well, files like LOWIcity0101.ac and their corresponding .xml, along with .stg files, were created and moved to the correct location in $FG_SCENERY
* copy or link the tex/ folder into the objects folder where these files were created

=== Roads ===
* run roads.py in the same fashion for roads
* <del>copy roads.eff to the same Objects\e0XXnXX\e0XXnXX\ directory</del> roads.eff is copied automatically
* Band-aid fix for the roads is to adjust their height in roads.py change AGL_ofs to a higher number e.g. 0.5

== Troubleshooting ==
* Buildings are generated, but they sit below the ground. I'm using ELEV_MODE = FgelevCaching.

Try running fgelev directly:
<syntaxhighlight lang="bash">
/path/to/fgelev --expire 1000 --fg-root $FG_ROOT --fg-scenery $FG_SCENERY
</syntaxhighlight>
then enter
<syntaxhighlight lang="bash">
0 $lon $lat
</syntaxhighlight>
where $lon and $lat are coordinates in the area you want to generate. See if it returns a sane value. If it does, double-check PATH_TO_SCENERY and $FG_ROOT.

* Buildings/roads have no texture.
copy or link the tex/ folder into the objects folder where the .stg files were created, such that you have $FG_SCENERY/Objects/eXXXnXX/eXXXnXX/tex/.

== Improve frame rate ==
* adjust LOD ranges in FG
* decrease MAX_OBJECTS, increase LOD_*
(- use larger/smaller tiles? Tradeoff between distance calculations/xml parsing and GPU)

== Contributing ==
You know some python? Or you're keen on writing docs? Or just want to use osm2city, but got stuck somewhere? Contact radi on the FG forum.
None of the above? Take [[Howto:Create_textures_from_photos|pictures]] of buildings where you live and [[Osm2city.py Textures|create textures]]! I'm especially interested in south-east asian style architecture, as I'm planning to populate Hong Kong Kai Tak (VHXX) in the future.

== Related ==
* [[Using OSM Vector Data in FlightGear]]
* [[OpenStreetMap buildings]]
* [[AutoGen Scenery for FlightGear]]
* [[Random Buildings]]
* [http://forum.flightgear.org/viewtopic.php?f=5&t=21131#p192198 OSM buidings EHLE]
* [http://forum.flightgear.org/viewtopic.php?f=5&t=22809 osm2city.py development]
* [http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg40092.html Osm2city.py]
* http://forum.flightgear.org/viewtopic.php?f=5&t=19625
* [http://forum.flightgear.org/viewtopic.php?f=38&t=8837 PixelCity]
* [http://forum.flightgear.org/viewtopic.php?p=166794#p166681 Procedural OSM buildings]

[[Category:Scenery software]]

Osm2city.py

2014-11-10T11:22:51Z

Radi: /* Install */ fix numbering (maybe there's a better way?)

{{OSM Navigation}}
[[File:LOWI with OSM buildings.jpg|thumb|LOWI with OSM buildings]]

This Python script takes OpenStreetMap floorplans and creates 3d buildings ready for use in FlightGear.

The development [https://gitorious.org/fg-radi/osm2city repository] is hosted on gitorious.
Forum thread [http://forum.flightgear.org/viewtopic.php?f=5&t=22809 osm2city.py development]
Written in Python 2.7, developed on GNU/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 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.

== News ==
=== Status 10/2014 ===
New features:
* textures reside in a separate [https://gitorious.org/fg-radi/osm2city-data repository]
* the recommended elevation probing method is ELEV_MODE=FgelevCaching
* roads.py is now quite usable
* SKIP_LIST can contain OSM_IDs

=== Status 06/2014 ===
I'm currently adding textured roads, railroads, intersections and bridges.

{{FGCquote
| the shader is now on osm2city's git (in fgdata/). Again -- all credit goes to Emilian. He is improving the shader side, I will continue on the model side. So this is very much work in progress. The shader requires the default renderer. No ALS/Rembrandt yet. Get the LOWI roads pack (including the shader) here: [https://dl.dropboxusercontent.com/u/24846517/fg/osm2city/LOWI_roads.tar.gz https://dl.dropboxusercontent.com/u/24846517/fg/osm2city/LOWI_roads.tar.gz] The fgdata/ folder goes to your $FGDATA. In roads.xml enable either the lightmap or the traffic shader.
|{{cite web |url=http://forum.flightgear.org/viewtopic.php?p=212460#p212460
|title=<nowiki>Re: osm2city.py development</nowiki>
|author=<nowiki>radi</nowiki>
|date=<nowiki>Fri Jun 13</nowiki>
}}
}}

{{FGCquote
|Creating your own road network is a bit cumbersome ATM, I'll try to make it more general in the next few days. But if you're really, really keen on it: <ul><li> get latest osm2city git</li><li> run roads.py -f your-parameters-file.</li><li> if you also create buildings, make sure to use the same BOUNDARY_* parameters for both osm2city.py and roads.py. Otherwise, buildings and roads might be misaligned. Basically, if your OSM file contains both roads and buildings, you can just use one parameters file.</li><li> roads.py will print an OBJECT_STATIC line, add this to your .stg (appears to add itself)</li><li> copy roads.ac to your scenery</li><li> copy roads.xml and tex/ from the LOWI roads pack to your scenery (roads.ac and .xml copy themselves)</li></ul>
|{{cite web |url=http://forum.flightgear.org/viewtopic.php?p=212460#p212460
|title=<nowiki>Re: osm2city.py development</nowiki>
|author=<nowiki>radi</nowiki>
|date=<nowiki>Fri Jun 13</nowiki>
}}
}}

=== Status 04/2014 ===
[[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. 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]]
The second scene, approaching LOWI from the east, went from 30 fps without buildings down to 20 fps.

=== Status 10/2013 ===
Currently data is processed offline beforehand. 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. <del>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.
</del> (Some optimization gave a huge speedup).

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
use some heuristics (some OSM buildings are labeled "Terminal 1" or so) to apply
terminal/hangar textures to buildings at airports. This way we could rather easily populate some airports with
'semi-generic' terminal/hangar buildings.

== Features ==
* 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 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)
* 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
:* ~10 different, hi-res facade textures, some roof textures
:* find matching texture for given building (number of levels, modern/old building, etc)
:* find matching roof texture for given facade texture
* basic lightmap support
* obstruction lights on tall buildings
* command line interface and parameters file (thanks to forum user vanosten)
* shows statistics on processed buildings
* 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 {{done}}
* 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|50}}
:* 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 ==
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
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 ==
* nearby hi-rise objects of similar shape get same texture? Probably too special a feature.
* 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 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 ==
1. dependencies: Install the following packages (names from Debian packages):
python-numpy python-shapely python-matplotlib python-scipy python-pil python-networkx
2. get [https://gitorious.org/fg-radi/osm2city osm2city] and [https://gitorious.org/fg-radi/osm2city-data osm2city-data] from gitorious

3. 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))

4. link osm2city-data/tex and osm2city-data/tex.src into osm2city/

If you're running FG < 3.2, or git older than 10 Oct 2014, or have less than 4 GB RAM, you will most likely need to use the old-fashioned way of elevation probing, which requires you to
5. copy elev.nas to $FGDATA/Nasal/

6. Change the in variable of elev.nas to match the elev.in file e.g. $FG_DATA/Nasal/elev.in

7. Change the out variable of elev.nas to the export directory with a filename with write access (e.g. $FG_HOME/Export). See [[IORules]] and [[$FG_HOME]]

== Install on Windows ==
osm2city is pure python.

https://www.python.org/downloads/release/python-278/

{{warning|Python 2.?? is recommended unless your an experienced Python developer willing to update the Python scripts to support Python 3. Also pay attention to versions and cpu builds of the below helper files. Make sure they match your OS build and Python version.}}

Install the following packages, then proceed with step 2 above.

http://www.lfd.uci.edu/~gohlke/pythonlibs/#numpy

http://www.lfd.uci.edu/~gohlke/pythonlibs/#shapely

http://www.lfd.uci.edu/~gohlke/pythonlibs/#scipy-stack

https://pypi.python.org/pypi/Pillow/2.5.0#downloads

== Workflow ==
There are five main steps:
* get OSM data
* adjust input file
* if neccessary, create elevation grid and run FG to probe elevation data.
* run osm2city
* <del>install the generated scenery</del>installs itself

We'll now walk through these steps in detail:
=== get OSM data ===
* decide on a region you want to populate. Get its lon/lat coordinates.
* create a project directory. We will use LOWI/ in this example.
* get corresponding OSM data in its native .xml format.
There are several options to get OSM data. You may find the [http://harrywood.co.uk/maps/uixapi/xapi.html XAPI Query Builder] helpful, it will generate a download URL that you can fetch with wget:
wget -O buildings.osm http://www.overpass-api.de/api/xapi?map?bbox=11.16898,47.20837,11.79108,47.38161

If you use [http://wiki.openstreetmap.org/wiki/Osmosis Osmosis] and cut the area with ''--bounding-box'' then you need to use ''completeWays=yes''.

Put this data into LOWI/buildings.osm

=== Adjust input file ===
* Now adjust the input file. You can generate a commented default parameters file by
<syntaxhighlight lang="bash">
parameters.py -d > LOWI/params.ini
</syntaxhighlight>

Edit this file, adjusting (at least) the following:
:* PREFIX = LOWI (the project directory)
:* BOUNDARY_EAST, BOUNDARY_NORTH, BOUNDARY_SOUTH, BOUNDARY_WEST
:* OSM_FILE = buildings.osm
:* set PATH_TO_SCENERY to a standard [[$FG_SCENERY]] path. This is the path where we'll get the elevation from. Most likely you'll want to use your TerraSync path here. Suppose the area you want to populate is /home/user/fgfs/scenery/TerraSync/Objects/e010n40/e011n47/, PATH_TO_SCENERY would then be /home/user/fgfs/scenery/TerraSync .
:* set PATH_TO_OUTPUT to a ''different'' scenery path, e.g. /home/user/fgfs/scenery/osm2city . Osm2city will generate its objects there. First, this avoids TerraSync overwriting the generated scenery. Second, you can easily remove that folder in case you're not happy with the result. Make sure to include that path in your [[$FG_SCENERY]].
:* you might want to set MAX_OBJECTS to a small number (say, 100) for your first try. This will limit the number of buildings parsed, and speed up the whole process.
:* you also need to set up elevation probing in the parameters file, described in the next section.

=== Probe elevation ===
Probe elevation for your region. Pick one of the three available modes for ELEV_MODE in params.ini. If you have enough memory (4GB should be fine, but YMMV) and run FG git later than 10 Oct 2014, try FgelevCaching. Failing that, try Manual. (portreekid, what's the 3rd mode good for?)

'''There are a lot of problems reported currently with fgelev. I can't really test for the next month or so. See troubleshooting or use ELEV_MODE = Manual.'''

* ELEV_MODE = FgelevCaching
:* Set FG_ELEV to your fgelev executable. For example: FG_ELEV = /usr/local/fg/bin/fgelev or just FG_ELEV = fgelev if fgelev is already in your OS's path.
:* Set PATH_TO_SCENERY (Missing terrain will result in error message)
:* make sure the environment variable [[$FG ROOT]] points to your FG base path, (e.g. export FG_ROOT=/usr/share/games/flightgear/ on Linux)

* ELEV_MODE = Manual
:* run tools.py (tools.py -f LOWI/params.ini), this will create a file elev.in. Copy elev.in to $FGDATA/Nasal/
:* tools.py will tell you to hide a certain scenery/Objects/... folder, to prevent probing elevation on top of existing objects. Simply rename the folder
:* run FG, open debug->nasal console, enter: elev.get_elevation(), press execute. Might take a long time, depending on the area scanned. This will write elevation data to /tmp/elev.out (which is actually just plain 5 column data: lon,lat,x,y,elevation). Put elev.out into LOWI/
:* unhide, rename the objects folder

* ELEV_MODE = Telnet
:* Run setup.py
:* Start FG with the properties service on Port 5501
:* Run tools.py, this will create a elev.in, start the nasal script and copy the elev.out back to your project directory

=== Run osm2city ===
* run osm2city.py -f LOWI/prams.ini. Parsing OSM data <del>again takes quite looong (10 minutes or more for 50k buildings)</del> is now pretty fast, but the result is cached to file buildings.pkl. Next startup will be <del>much faster if you move buildings.pkl to LOWI/buildings.pkl and</del> even faster if you set USE_PKL = 1.

If all goes well, files like LOWIcity0101.ac and their corresponding .xml, along with .stg files, were created and moved to the correct location in $FG_SCENERY
* copy or link the tex/ folder into the objects folder where these files were created

=== Roads ===
* run roads.py in the same fashion for roads
* <del>copy roads.eff to the same Objects\e0XXnXX\e0XXnXX\ directory</del> roads.eff is copied automatically
* Band-aid fix for the roads is to adjust their height in roads.py change AGL_ofs to a higher number e.g. 0.5

== Troubleshooting ==
* Buildings are generated, but they sit below the ground. I'm using ELEV_MODE = FgelevCaching.

Try running fgelev directly:
<syntaxhighlight lang="bash">
/path/to/fgelev --expire 1000 --fg-root $FG_ROOT --fg-scenery $FG_SCENERY
</syntaxhighlight>
then enter
<syntaxhighlight lang="bash">
0 $lon $lat
</syntaxhighlight>
where $lon and $lat are coordinates in the area you want to generate. See if it returns a sane value. If it does, double-check PATH_TO_SCENERY and $FG_ROOT.

* Buildings/roads have no texture.
copy or link the tex/ folder into the objects folder where the .stg files were created, such that you have $FG_SCENERY/Objects/eXXXnXX/eXXXnXX/tex/.

== Improve frame rate ==
* adjust LOD ranges in FG
* decrease MAX_OBJECTS, increase LOD_*
(- use larger/smaller tiles? Tradeoff between distance calculations/xml parsing and GPU)

== Contributing ==
You know some python? Or you're keen on writing docs? Or just want to use osm2city, but got stuck somewhere? Contact radi on the FG forum.
None of the above? Take [[Howto:Create_textures_from_photos|pictures]] of buildings where you live and [[Osm2city.py Textures|create textures]]! I'm especially interested in south-east asian style architecture, as I'm planning to populate Hong Kong Kai Tak (VHXX) in the future.

== Related ==
* [[Using OSM Vector Data in FlightGear]]
* [[OpenStreetMap buildings]]
* [[AutoGen Scenery for FlightGear]]
* [[Random Buildings]]
* [http://forum.flightgear.org/viewtopic.php?f=5&t=21131#p192198 OSM buidings EHLE]
* [http://forum.flightgear.org/viewtopic.php?f=5&t=22809 osm2city.py development]
* [http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg40092.html Osm2city.py]
* http://forum.flightgear.org/viewtopic.php?f=5&t=19625
* [http://forum.flightgear.org/viewtopic.php?f=38&t=8837 PixelCity]
* [http://forum.flightgear.org/viewtopic.php?p=166794#p166681 Procedural OSM buildings]

[[Category:Scenery software]]

Osm2city.py

2014-11-10T11:11:28Z

Radi: refer win install to install

{{OSM Navigation}}
[[File:LOWI with OSM buildings.jpg|thumb|LOWI with OSM buildings]]

This Python script takes OpenStreetMap floorplans and creates 3d buildings ready for use in FlightGear.

The development [https://gitorious.org/fg-radi/osm2city repository] is hosted on gitorious.
Forum thread [http://forum.flightgear.org/viewtopic.php?f=5&t=22809 osm2city.py development]
Written in Python 2.7, developed on GNU/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 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.

== News ==
=== Status 10/2014 ===
New features:
* textures reside in a separate [https://gitorious.org/fg-radi/osm2city-data repository]
* the recommended elevation probing method is ELEV_MODE=FgelevCaching
* roads.py is now quite usable
* SKIP_LIST can contain OSM_IDs

=== Status 06/2014 ===
I'm currently adding textured roads, railroads, intersections and bridges.

{{FGCquote
| the shader is now on osm2city's git (in fgdata/). Again -- all credit goes to Emilian. He is improving the shader side, I will continue on the model side. So this is very much work in progress. The shader requires the default renderer. No ALS/Rembrandt yet. Get the LOWI roads pack (including the shader) here: [https://dl.dropboxusercontent.com/u/24846517/fg/osm2city/LOWI_roads.tar.gz https://dl.dropboxusercontent.com/u/24846517/fg/osm2city/LOWI_roads.tar.gz] The fgdata/ folder goes to your $FGDATA. In roads.xml enable either the lightmap or the traffic shader.
|{{cite web |url=http://forum.flightgear.org/viewtopic.php?p=212460#p212460
|title=<nowiki>Re: osm2city.py development</nowiki>
|author=<nowiki>radi</nowiki>
|date=<nowiki>Fri Jun 13</nowiki>
}}
}}

{{FGCquote
|Creating your own road network is a bit cumbersome ATM, I'll try to make it more general in the next few days. But if you're really, really keen on it: <ul><li> get latest osm2city git</li><li> run roads.py -f your-parameters-file.</li><li> if you also create buildings, make sure to use the same BOUNDARY_* parameters for both osm2city.py and roads.py. Otherwise, buildings and roads might be misaligned. Basically, if your OSM file contains both roads and buildings, you can just use one parameters file.</li><li> roads.py will print an OBJECT_STATIC line, add this to your .stg (appears to add itself)</li><li> copy roads.ac to your scenery</li><li> copy roads.xml and tex/ from the LOWI roads pack to your scenery (roads.ac and .xml copy themselves)</li></ul>
|{{cite web |url=http://forum.flightgear.org/viewtopic.php?p=212460#p212460
|title=<nowiki>Re: osm2city.py development</nowiki>
|author=<nowiki>radi</nowiki>
|date=<nowiki>Fri Jun 13</nowiki>
}}
}}

=== Status 04/2014 ===
[[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. 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]]
The second scene, approaching LOWI from the east, went from 30 fps without buildings down to 20 fps.

=== Status 10/2013 ===
Currently data is processed offline beforehand. 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. <del>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.
</del> (Some optimization gave a huge speedup).

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
use some heuristics (some OSM buildings are labeled "Terminal 1" or so) to apply
terminal/hangar textures to buildings at airports. This way we could rather easily populate some airports with
'semi-generic' terminal/hangar buildings.

== Features ==
* 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 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)
* 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
:* ~10 different, hi-res facade textures, some roof textures
:* find matching texture for given building (number of levels, modern/old building, etc)
:* find matching roof texture for given facade texture
* basic lightmap support
* obstruction lights on tall buildings
* command line interface and parameters file (thanks to forum user vanosten)
* shows statistics on processed buildings
* 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 {{done}}
* 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|50}}
:* 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 ==
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
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 ==
* nearby hi-rise objects of similar shape get same texture? Probably too special a feature.
* 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 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 ==
1. dependencies: Install the following packages (names from Debian packages):
python-numpy python-shapely python-matplotlib python-scipy python-pil python-networkx
2. get [https://gitorious.org/fg-radi/osm2city osm2city] and [https://gitorious.org/fg-radi/osm2city-data osm2city-data] from gitorious
3. 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))
4. link osm2city-data/tex and osm2city-data/tex.src into osm2city/
If you're running FG < 3.2, or git older than 10 Oct 2014, or have less than 4 GB RAM, you will most likely need to use the old-fashioned way of elevation probing, which requires you to
5. copy elev.nas to $FGDATA/Nasal/
6. Change the in variable of elev.nas to match the elev.in file e.g. $FG_DATA/Nasal/elev.in
7. Change the out variable of elev.nas to the export directory with a filename with write access (e.g. $FG_HOME/Export). See [[IORules]] and [[$FG_HOME]]

== Install on Windows ==
osm2city is pure python.

https://www.python.org/downloads/release/python-278/

{{warning|Python 2.?? is recommended unless your an experienced Python developer willing to update the Python scripts to support Python 3. Also pay attention to versions and cpu builds of the below helper files. Make sure they match your OS build and Python version.}}

Install the following packages, then proceed with step 2 above.

http://www.lfd.uci.edu/~gohlke/pythonlibs/#numpy

http://www.lfd.uci.edu/~gohlke/pythonlibs/#shapely

http://www.lfd.uci.edu/~gohlke/pythonlibs/#scipy-stack

https://pypi.python.org/pypi/Pillow/2.5.0#downloads

== Workflow ==
There are five main steps:
* get OSM data
* adjust input file
* if neccessary, create elevation grid and run FG to probe elevation data.
* run osm2city
* <del>install the generated scenery</del>installs itself

We'll now walk through these steps in detail:
=== get OSM data ===
* decide on a region you want to populate. Get its lon/lat coordinates.
* create a project directory. We will use LOWI/ in this example.
* get corresponding OSM data in its native .xml format.
There are several options to get OSM data. You may find the [http://harrywood.co.uk/maps/uixapi/xapi.html XAPI Query Builder] helpful, it will generate a download URL that you can fetch with wget:
wget -O buildings.osm http://www.overpass-api.de/api/xapi?map?bbox=11.16898,47.20837,11.79108,47.38161

If you use [http://wiki.openstreetmap.org/wiki/Osmosis Osmosis] and cut the area with ''--bounding-box'' then you need to use ''completeWays=yes''.

Put this data into LOWI/buildings.osm

=== Adjust input file ===
* Now adjust the input file. You can generate a commented default parameters file by
<syntaxhighlight lang="bash">
parameters.py -d > LOWI/params.ini
</syntaxhighlight>

Edit this file, adjusting (at least) the following:
:* PREFIX = LOWI (the project directory)
:* BOUNDARY_EAST, BOUNDARY_NORTH, BOUNDARY_SOUTH, BOUNDARY_WEST
:* OSM_FILE = buildings.osm
:* set PATH_TO_SCENERY to a standard [[$FG_SCENERY]] path. This is the path where we'll get the elevation from. Most likely you'll want to use your TerraSync path here. Suppose the area you want to populate is /home/user/fgfs/scenery/TerraSync/Objects/e010n40/e011n47/, PATH_TO_SCENERY would then be /home/user/fgfs/scenery/TerraSync .
:* set PATH_TO_OUTPUT to a ''different'' scenery path, e.g. /home/user/fgfs/scenery/osm2city . Osm2city will generate its objects there. First, this avoids TerraSync overwriting the generated scenery. Second, you can easily remove that folder in case you're not happy with the result. Make sure to include that path in your [[$FG_SCENERY]].
:* you might want to set MAX_OBJECTS to a small number (say, 100) for your first try. This will limit the number of buildings parsed, and speed up the whole process.
:* you also need to set up elevation probing in the parameters file, described in the next section.

=== Probe elevation ===
Probe elevation for your region. Pick one of the three available modes for ELEV_MODE in params.ini. If you have enough memory (4GB should be fine, but YMMV) and run FG git later than 10 Oct 2014, try FgelevCaching. Failing that, try Manual. (portreekid, what's the 3rd mode good for?)

'''There are a lot of problems reported currently with fgelev. I can't really test for the next month or so. See troubleshooting or use ELEV_MODE = Manual.'''

* ELEV_MODE = FgelevCaching
:* Set FG_ELEV to your fgelev executable. For example: FG_ELEV = /usr/local/fg/bin/fgelev or just FG_ELEV = fgelev if fgelev is already in your OS's path.
:* Set PATH_TO_SCENERY (Missing terrain will result in error message)
:* make sure the environment variable [[$FG ROOT]] points to your FG base path, (e.g. export FG_ROOT=/usr/share/games/flightgear/ on Linux)

* ELEV_MODE = Manual
:* run tools.py (tools.py -f LOWI/params.ini), this will create a file elev.in. Copy elev.in to $FGDATA/Nasal/
:* tools.py will tell you to hide a certain scenery/Objects/... folder, to prevent probing elevation on top of existing objects. Simply rename the folder
:* run FG, open debug->nasal console, enter: elev.get_elevation(), press execute. Might take a long time, depending on the area scanned. This will write elevation data to /tmp/elev.out (which is actually just plain 5 column data: lon,lat,x,y,elevation). Put elev.out into LOWI/
:* unhide, rename the objects folder

* ELEV_MODE = Telnet
:* Run setup.py
:* Start FG with the properties service on Port 5501
:* Run tools.py, this will create a elev.in, start the nasal script and copy the elev.out back to your project directory

=== Run osm2city ===
* run osm2city.py -f LOWI/prams.ini. Parsing OSM data <del>again takes quite looong (10 minutes or more for 50k buildings)</del> is now pretty fast, but the result is cached to file buildings.pkl. Next startup will be <del>much faster if you move buildings.pkl to LOWI/buildings.pkl and</del> even faster if you set USE_PKL = 1.

If all goes well, files like LOWIcity0101.ac and their corresponding .xml, along with .stg files, were created and moved to the correct location in $FG_SCENERY
* copy or link the tex/ folder into the objects folder where these files were created

=== Roads ===
* run roads.py in the same fashion for roads
* <del>copy roads.eff to the same Objects\e0XXnXX\e0XXnXX\ directory</del> roads.eff is copied automatically
* Band-aid fix for the roads is to adjust their height in roads.py change AGL_ofs to a higher number e.g. 0.5

== Troubleshooting ==
* Buildings are generated, but they sit below the ground. I'm using ELEV_MODE = FgelevCaching.

Try running fgelev directly:
<syntaxhighlight lang="bash">
/path/to/fgelev --expire 1000 --fg-root $FG_ROOT --fg-scenery $FG_SCENERY
</syntaxhighlight>
then enter
<syntaxhighlight lang="bash">
0 $lon $lat
</syntaxhighlight>
where $lon and $lat are coordinates in the area you want to generate. See if it returns a sane value. If it does, double-check PATH_TO_SCENERY and $FG_ROOT.

* Buildings/roads have no texture.
copy or link the tex/ folder into the objects folder where the .stg files were created, such that you have $FG_SCENERY/Objects/eXXXnXX/eXXXnXX/tex/.

== Improve frame rate ==
* adjust LOD ranges in FG
* decrease MAX_OBJECTS, increase LOD_*
(- use larger/smaller tiles? Tradeoff between distance calculations/xml parsing and GPU)

== Contributing ==
You know some python? Or you're keen on writing docs? Or just want to use osm2city, but got stuck somewhere? Contact radi on the FG forum.
None of the above? Take [[Howto:Create_textures_from_photos|pictures]] of buildings where you live and [[Osm2city.py Textures|create textures]]! I'm especially interested in south-east asian style architecture, as I'm planning to populate Hong Kong Kai Tak (VHXX) in the future.

== Related ==
* [[Using OSM Vector Data in FlightGear]]
* [[OpenStreetMap buildings]]
* [[AutoGen Scenery for FlightGear]]
* [[Random Buildings]]
* [http://forum.flightgear.org/viewtopic.php?f=5&t=21131#p192198 OSM buidings EHLE]
* [http://forum.flightgear.org/viewtopic.php?f=5&t=22809 osm2city.py development]
* [http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg40092.html Osm2city.py]
* http://forum.flightgear.org/viewtopic.php?f=5&t=19625
* [http://forum.flightgear.org/viewtopic.php?f=38&t=8837 PixelCity]
* [http://forum.flightgear.org/viewtopic.php?p=166794#p166681 Procedural OSM buildings]

[[Category:Scenery software]]

Osm2city.py

2014-11-02T23:35:29Z

Radi: /* Install */ depends on networkx

{{OSM Navigation}}
[[File:LOWI with OSM buildings.jpg|thumb|LOWI with OSM buildings]]

This Python script takes OpenStreetMap floorplans and creates 3d buildings ready for use in FlightGear.

The development [https://gitorious.org/fg-radi/osm2city repository] is hosted on gitorious.
Forum thread [http://forum.flightgear.org/viewtopic.php?f=5&t=22809 osm2city.py development]
Written in Python 2.7, developed on GNU/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 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.

== News ==
=== Status 10/2014 ===
New features:
* textures reside in a separate [https://gitorious.org/fg-radi/osm2city-data repository]
* the recommended elevation probing method is ELEV_MODE=FgelevCaching
* roads.py is now quite usable
* SKIP_LIST can contain OSM_IDs

=== Status 06/2014 ===
I'm currently adding textured roads, railroads, intersections and bridges.

{{FGCquote
| the shader is now on osm2city's git (in fgdata/). Again -- all credit goes to Emilian. He is improving the shader side, I will continue on the model side. So this is very much work in progress. The shader requires the default renderer. No ALS/Rembrandt yet. Get the LOWI roads pack (including the shader) here: [https://dl.dropboxusercontent.com/u/24846517/fg/osm2city/LOWI_roads.tar.gz https://dl.dropboxusercontent.com/u/24846517/fg/osm2city/LOWI_roads.tar.gz] The fgdata/ folder goes to your $FGDATA. In roads.xml enable either the lightmap or the traffic shader.
|{{cite web |url=http://forum.flightgear.org/viewtopic.php?p=212460#p212460
|title=<nowiki>Re: osm2city.py development</nowiki>
|author=<nowiki>radi</nowiki>
|date=<nowiki>Fri Jun 13</nowiki>
}}
}}

{{FGCquote
|Creating your own road network is a bit cumbersome ATM, I'll try to make it more general in the next few days. But if you're really, really keen on it: <ul><li> get latest osm2city git</li><li> run roads.py -f your-parameters-file.</li><li> if you also create buildings, make sure to use the same BOUNDARY_* parameters for both osm2city.py and roads.py. Otherwise, buildings and roads might be misaligned. Basically, if your OSM file contains both roads and buildings, you can just use one parameters file.</li><li> roads.py will print an OBJECT_STATIC line, add this to your .stg (appears to add itself)</li><li> copy roads.ac to your scenery</li><li> copy roads.xml and tex/ from the LOWI roads pack to your scenery (roads.ac and .xml copy themselves)</li></ul>
|{{cite web |url=http://forum.flightgear.org/viewtopic.php?p=212460#p212460
|title=<nowiki>Re: osm2city.py development</nowiki>
|author=<nowiki>radi</nowiki>
|date=<nowiki>Fri Jun 13</nowiki>
}}
}}

=== Status 04/2014 ===
[[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. 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]]
The second scene, approaching LOWI from the east, went from 30 fps without buildings down to 20 fps.

=== Status 10/2013 ===
Currently data is processed offline beforehand. 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. <del>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.
</del> (Some optimization gave a huge speedup).

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
use some heuristics (some OSM buildings are labeled "Terminal 1" or so) to apply
terminal/hangar textures to buildings at airports. This way we could rather easily populate some airports with
'semi-generic' terminal/hangar buildings.

== Features ==
* 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 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)
* 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
:* ~10 different, hi-res facade textures, some roof textures
:* find matching texture for given building (number of levels, modern/old building, etc)
:* find matching roof texture for given facade texture
* basic lightmap support
* obstruction lights on tall buildings
* command line interface and parameters file (thanks to forum user vanosten)
* shows statistics on processed buildings
* 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 {{done}}
* 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|50}}
:* 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 ==
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
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 ==
* nearby hi-rise objects of similar shape get same texture? Probably too special a feature.
* 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 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 ==
* dependencies: Install the following packages (names from Debian packages):
python-numpy python-shapely python-matplotlib python-scipy python-pil python-networkx

* get [https://gitorious.org/fg-radi/osm2city osm2city] and [https://gitorious.org/fg-radi/osm2city-data osm2city-data] 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 . (the dot))
* link osm2city-data/tex and osm2city-data/tex.src into osm2city/

If you're running FG < 3.2, or git older than 10 Oct 2014, or have less than 4 GB RAM, you will most likely need to use the old-fashioned way of elevation probing, which requires you to
* copy elev.nas to $FGDATA/Nasal/
* Change the in variable of elev.nas to match the elev.in file e.g. $FG_DATA/Nasal/elev.in
* Change the out variable of elev.nas to the export directory with a filename with write access (e.g. $FG_HOME/Export). See [[IORules]] and [[$FG_HOME]]

== Install on Windows ==
osm2city is pure python. Install the following packages.

http://www.lfd.uci.edu/~gohlke/pythonlibs/#numpy

http://www.lfd.uci.edu/~gohlke/pythonlibs/#shapely

http://www.lfd.uci.edu/~gohlke/pythonlibs/#scipy-stack

https://pypi.python.org/pypi/Pillow/2.5.0#downloads

== Workflow ==
There are five main steps:
* get OSM data
* adjust input file
* if neccessary, create elevation grid and run FG to probe elevation data.
* run osm2city
* <del>install the generated scenery</del>installs itself

We'll now walk through these steps in detail:
=== get OSM data ===
* decide on a region you want to populate. Get its lon/lat coordinates.
* create a project directory. We will use LOWI/ in this example.
* get corresponding OSM data in its native .xml format.
There are several options to get OSM data. You may find the [http://harrywood.co.uk/maps/uixapi/xapi.html XAPI Query Builder] helpful, it will generate a download URL that you can fetch with wget:
wget -O buildings.osm http://www.overpass-api.de/api/xapi?map?bbox=11.16898,47.20837,11.79108,47.38161

If you use [http://wiki.openstreetmap.org/wiki/Osmosis Osmosis] and cut the area with ''--bounding-box'' then you need to use ''completeWays=yes''.

Put this data into LOWI/buildings.osm

=== Adjust input file ===
* Now adjust the input file. You can generate a commented default parameters file by
<syntaxhighlight lang="bash">
parameters.py -d > LOWI/params.ini
</syntaxhighlight>

Edit this file, adjusting (at least) the following:
:* PREFIX = LOWI (the project directory)
:* BOUNDARY_EAST, BOUNDARY_NORTH, BOUNDARY_SOUTH, BOUNDARY_WEST
:* OSM_FILE = buildings.osm
:* set PATH_TO_SCENERY to a standard [[$FG_SCENERY]] path. This is the path where we'll get the elevation from. Most likely you'll want to use your TerraSync path here. Suppose the area you want to populate is /home/user/fgfs/scenery/TerraSync/Objects/e010n40/e011n47/, PATH_TO_SCENERY would then be /home/user/fgfs/scenery/TerraSync .
:* set PATH_TO_OUTPUT to a ''different'' scenery path, e.g. /home/user/fgfs/scenery/osm2city . Osm2city will generate its objects there. First, this avoids TerraSync overwriting the generated scenery. Second, you can easily remove that folder in case you're not happy with the result. Make sure to include that path in your [[$FG_SCENERY]].
:* you might want to set MAX_OBJECTS to a small number (say, 100) for your first try. This will limit the number of buildings parsed, and speed up the whole process.
:* you also need to set up elevation probing in the parameters file, described in the next section.

=== Probe elevation ===
Probe elevation for your region. Pick one of the three available modes for ELEV_MODE in params.ini. If you have enough memory (4GB should be fine, but YMMV) and run FG git later than 10 Oct 2014, try FgelevCaching. Failing that, try Manual. (portreekid, what's the 3rd mode good for?)

'''There are a lot of problems reported currently with fgelev. I can't really test for the next month or so. See troubleshooting or use ELEV_MODE = Manual.'''

* ELEV_MODE = FgelevCaching
:* Set FG_ELEV to your fgelev executable. For example: FG_ELEV = /usr/local/fg/bin/fgelev or just FG_ELEV = fgelev if fgelev is already in your OS's path.
:* Set PATH_TO_SCENERY (Missing terrain will result in error message)
:* make sure the environment variable [[$FG ROOT]] points to your FG base path, (e.g. export FG_ROOT=/usr/share/games/flightgear/ on Linux)

* ELEV_MODE = Manual
:* run tools.py (tools.py -f LOWI/params.ini), this will create a file elev.in. Copy elev.in to $FGDATA/Nasal/
:* tools.py will tell you to hide a certain scenery/Objects/... folder, to prevent probing elevation on top of existing objects. Simply rename the folder
:* run FG, open debug->nasal console, enter: elev.get_elevation(), press execute. Might take a long time, depending on the area scanned. This will write elevation data to /tmp/elev.out (which is actually just plain 5 column data: lon,lat,x,y,elevation). Put elev.out into LOWI/
:* unhide, rename the objects folder

* ELEV_MODE = Telnet
:* Run setup.py
:* Start FG with the properties service on Port 5501
:* Run tools.py, this will create a elev.in, start the nasal script and copy the elev.out back to your project directory

=== Run osm2city ===
* run osm2city.py -f LOWI/prams.ini. Parsing OSM data <del>again takes quite looong (10 minutes or more for 50k buildings)</del> is now pretty fast, but the result is cached to file buildings.pkl. Next startup will be <del>much faster if you move buildings.pkl to LOWI/buildings.pkl and</del> even faster if you set USE_PKL = 1.

If all goes well, files like LOWIcity0101.ac and their corresponding .xml, along with .stg files, were created and moved to the correct location in $FG_SCENERY
* copy or link the tex/ folder into the objects folder where these files were created

=== Roads ===
* run roads.py in the same fashion for roads
* <del>copy roads.eff to the same Objects\e0XXnXX\e0XXnXX\ directory</del> roads.eff is copied automatically
* Band-aid fix for the roads is to adjust their height in roads.py change AGL_ofs to a higher number e.g. 0.5

== Troubleshooting ==
* Buildings are generated, but they sit below the ground. I'm using ELEV_MODE = FgelevCaching.

Try running fgelev directly:
<syntaxhighlight lang="bash">
/path/to/fgelev --expire 1000 --fg-root $FG_ROOT --fg-scenery $FG_SCENERY
</syntaxhighlight>
then enter
<syntaxhighlight lang="bash">
0 $lon $lat
</syntaxhighlight>
where $lon and $lat are coordinates in the area you want to generate. See if it returns a sane value. If it does, double-check PATH_TO_SCENERY and $FG_ROOT.

* Buildings/roads have no texture.
copy or link the tex/ folder into the objects folder where the .stg files were created, such that you have $FG_SCENERY/Objects/eXXXnXX/eXXXnXX/tex/.

== Improve frame rate ==
* adjust LOD ranges in FG
* decrease MAX_OBJECTS, increase LOD_*
(- use larger/smaller tiles? Tradeoff between distance calculations/xml parsing and GPU)

== Contributing ==
You know some python? Or you're keen on writing docs? Or just want to use osm2city, but got stuck somewhere? Contact radi on the FG forum.
None of the above? Take [[Howto:Create_textures_from_photos|pictures]] of buildings where you live and [[Osm2city.py Textures|create textures]]! I'm especially interested in south-east asian style architecture, as I'm planning to populate Hong Kong Kai Tak (VHXX) in the future.

== Related ==
* [[Using OSM Vector Data in FlightGear]]
* [[OpenStreetMap buildings]]
* [[AutoGen Scenery for FlightGear]]
* [[Random Buildings]]
* [http://forum.flightgear.org/viewtopic.php?f=5&t=21131#p192198 OSM buidings EHLE]
* [http://forum.flightgear.org/viewtopic.php?f=5&t=22809 osm2city.py development]
* [http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg40092.html Osm2city.py]
* http://forum.flightgear.org/viewtopic.php?f=5&t=19625
* [http://forum.flightgear.org/viewtopic.php?f=38&t=8837 PixelCity]
* [http://forum.flightgear.org/viewtopic.php?p=166794#p166681 Procedural OSM buildings]

[[Category:Scenery software]]

Osm2city.py

2014-10-23T21:53:19Z

Radi: /* Adjust input file */ emphasise using different PATH_TO_SCENERY and PATH_TO_OUTPUT

{{OSM Navigation}}
[[File:LOWI with OSM buildings.jpg|thumb|LOWI with OSM buildings]]

This Python script takes OpenStreetMap floorplans and creates 3d buildings ready for use in FlightGear.

The development [https://gitorious.org/fg-radi/osm2city repository] is hosted on gitorious.
Forum thread [http://forum.flightgear.org/viewtopic.php?f=5&t=22809 osm2city.py development]
Written in Python 2.7, developed on GNU/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 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.

== News ==
=== Status 10/2014 ===
New features:
* textures reside in a separate [https://gitorious.org/fg-radi/osm2city-data repository]
* the recommended elevation probing method is ELEV_MODE=FgelevCaching
* roads.py is now quite usable
* SKIP_LIST can contain OSM_IDs

=== Status 06/2014 ===
I'm currently adding textured roads, railroads, intersections and bridges.

{{FGCquote
| the shader is now on osm2city's git (in fgdata/). Again -- all credit goes to Emilian. He is improving the shader side, I will continue on the model side. So this is very much work in progress. The shader requires the default renderer. No ALS/Rembrandt yet. Get the LOWI roads pack (including the shader) here: [https://dl.dropboxusercontent.com/u/24846517/fg/osm2city/LOWI_roads.tar.gz https://dl.dropboxusercontent.com/u/24846517/fg/osm2city/LOWI_roads.tar.gz] The fgdata/ folder goes to your $FGDATA. In roads.xml enable either the lightmap or the traffic shader.
|{{cite web |url=http://forum.flightgear.org/viewtopic.php?p=212460#p212460
|title=<nowiki>Re: osm2city.py development</nowiki>
|author=<nowiki>radi</nowiki>
|date=<nowiki>Fri Jun 13</nowiki>
}}
}}

{{FGCquote
|Creating your own road network is a bit cumbersome ATM, I'll try to make it more general in the next few days. But if you're really, really keen on it: <ul><li> get latest osm2city git</li><li> run roads.py -f your-parameters-file.</li><li> if you also create buildings, make sure to use the same BOUNDARY_* parameters for both osm2city.py and roads.py. Otherwise, buildings and roads might be misaligned. Basically, if your OSM file contains both roads and buildings, you can just use one parameters file.</li><li> roads.py will print an OBJECT_STATIC line, add this to your .stg (appears to add itself)</li><li> copy roads.ac to your scenery</li><li> copy roads.xml and tex/ from the LOWI roads pack to your scenery (roads.ac and .xml copy themselves)</li></ul>
|{{cite web |url=http://forum.flightgear.org/viewtopic.php?p=212460#p212460
|title=<nowiki>Re: osm2city.py development</nowiki>
|author=<nowiki>radi</nowiki>
|date=<nowiki>Fri Jun 13</nowiki>
}}
}}

=== Status 04/2014 ===
[[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. 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]]
The second scene, approaching LOWI from the east, went from 30 fps without buildings down to 20 fps.

=== Status 10/2013 ===
Currently data is processed offline beforehand. 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. <del>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.
</del> (Some optimization gave a huge speedup).

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
use some heuristics (some OSM buildings are labeled "Terminal 1" or so) to apply
terminal/hangar textures to buildings at airports. This way we could rather easily populate some airports with
'semi-generic' terminal/hangar buildings.

== Features ==
* 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 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)
* 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
:* ~10 different, hi-res facade textures, some roof textures
:* find matching texture for given building (number of levels, modern/old building, etc)
:* find matching roof texture for given facade texture
* basic lightmap support
* obstruction lights on tall buildings
* command line interface and parameters file (thanks to forum user vanosten)
* shows statistics on processed buildings
* 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 {{done}}
* 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|50}}
:* 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 ==
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
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 ==
* nearby hi-rise objects of similar shape get same texture? Probably too special a feature.
* 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 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 ==
* 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] and [https://gitorious.org/fg-radi/osm2city-data osm2city-data] 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 . (the dot))
* link osm2city-data/tex and osm2city-data/tex.src into osm2city/

If you're running FG < 3.2, or git older than 10 Oct 2014, or have less than 4 GB RAM, you will most likely need to use the old-fashioned way of elevation probing, which requires you to
* copy elev.nas to $FGDATA/Nasal/
* Change the in variable of elev.nas to match the elev.in file e.g. $FG_DATA/Nasal/elev.in
* Change the out variable of elev.nas to the export directory with a filename with write access (e.g. $FG_HOME/Export). See [[IORules]] and [[$FG_HOME]]

== Install on Windows ==
osm2city is pure python. Install the following packages.

http://www.lfd.uci.edu/~gohlke/pythonlibs/#numpy

http://www.lfd.uci.edu/~gohlke/pythonlibs/#shapely

http://www.lfd.uci.edu/~gohlke/pythonlibs/#scipy-stack

https://pypi.python.org/pypi/Pillow/2.5.0#downloads

== Workflow ==
There are five main steps:
* get OSM data
* adjust input file
* if neccessary, create elevation grid and run FG to probe elevation data.
* run osm2city
* <del>install the generated scenery</del>installs itself

We'll now walk through these steps in detail:
=== get OSM data ===
* decide on a region you want to populate. Get its lon/lat coordinates.
* create a project directory. We will use LOWI/ in this example.
* get corresponding OSM data in its native .xml format.
There are several options to get OSM data. You may find the [http://harrywood.co.uk/maps/uixapi/xapi.html XAPI Query Builder] helpful, it will generate a download URL that you can fetch with wget:
wget -O buildings.osm http://www.overpass-api.de/api/xapi?map?bbox=11.16898,47.20837,11.79108,47.38161

If you use [http://wiki.openstreetmap.org/wiki/Osmosis Osmosis] and cut the area with ''--bounding-box'' then you need to use ''completeWays=yes''.

Put this data into LOWI/buildings.osm

=== Adjust input file ===
* Now adjust the input file. You can generate a commented default parameters file by
<syntaxhighlight lang="bash">
parameters.py -d > LOWI/params.ini
</syntaxhighlight>

Edit this file, adjusting (at least) the following:
:* PREFIX = LOWI (the project directory)
:* BOUNDARY_EAST, BOUNDARY_NORTH, BOUNDARY_SOUTH, BOUNDARY_WEST
:* OSM_FILE = buildings.osm
:* set PATH_TO_SCENERY to a standard [[$FG_SCENERY]] path. This is the path where we'll get the elevation from. Most likely you'll want to use your TerraSync path here. Suppose the area you want to populate is /home/user/fgfs/scenery/TerraSync/Objects/e010n40/e011n47/, PATH_TO_SCENERY would then be /home/user/fgfs/scenery/TerraSync .
:* set PATH_TO_OUTPUT to a ''different'' scenery path, e.g. /home/user/fgfs/scenery/osm2city . Osm2city will generate its objects there. First, this avoids TerraSync overwriting the generated scenery. Second, you can easily remove that folder in case you're not happy with the result. Make sure to include that path in your [[$FG_SCENERY]].
:* you might want to set MAX_OBJECTS to a small number (say, 100) for your first try. This will limit the number of buildings parsed, and speed up the whole process.
:* you also need to set up elevation probing in the parameters file, described in the next section.

=== Probe elevation ===
Probe elevation for your region. Pick one of the three available modes for ELEV_MODE in params.ini. If you have enough memory (4GB should be fine, but YMMV) and run FG git later than 10 Oct 2014, try FgelevCaching. Failing that, try Manual. (portreekid, what's the 3rd mode good for?)

'''There are a lot of problems reported currently with fgelev. I can't really test for the next month or so. See troubleshooting or use ELEV_MODE = Manual.'''

* ELEV_MODE = FgelevCaching
:* Set FG_ELEV to your fgelev executable. For example: FG_ELEV = /usr/local/fg/bin/fgelev or just FG_ELEV = fgelev if fgelev is already in your OS's path.
:* Set PATH_TO_SCENERY (Missing terrain will result in error message)
:* make sure the environment variable [[$FG ROOT]] points to your FG base path, (e.g. export FG_ROOT=/usr/share/games/flightgear/ on Linux)

* ELEV_MODE = Manual
:* run tools.py (tools.py -f LOWI/params.ini), this will create a file elev.in. Copy elev.in to $FGDATA/Nasal/
:* tools.py will tell you to hide a certain scenery/Objects/... folder, to prevent probing elevation on top of existing objects. Simply rename the folder
:* run FG, open debug->nasal console, enter: elev.get_elevation(), press execute. Might take a long time, depending on the area scanned. This will write elevation data to /tmp/elev.out (which is actually just plain 5 column data: lon,lat,x,y,elevation). Put elev.out into LOWI/
:* unhide, rename the objects folder

* ELEV_MODE = Telnet
:* Run setup.py
:* Start FG with the properties service on Port 5501
:* Run tools.py, this will create a elev.in, start the nasal script and copy the elev.out back to your project directory

=== Run osm2city ===
* run osm2city.py -f LOWI/prams.ini. Parsing OSM data <del>again takes quite looong (10 minutes or more for 50k buildings)</del> is now pretty fast, but the result is cached to file buildings.pkl. Next startup will be <del>much faster if you move buildings.pkl to LOWI/buildings.pkl and</del> even faster if you set USE_PKL = 1.

If all goes well, files like LOWIcity0101.ac and their corresponding .xml, along with .stg files, were created and moved to the correct location in $FG_SCENERY
* copy or link the tex/ folder into the objects folder where these files were created

=== Roads ===
* run roads.py in the same fashion for roads
* <del>copy roads.eff to the same Objects\e0XXnXX\e0XXnXX\ directory</del> roads.eff is copied automatically
* Band-aid fix for the roads is to adjust their height in roads.py change AGL_ofs to a higher number e.g. 0.5

== Troubleshooting ==
* Buildings are generated, but they sit below the ground. I'm using ELEV_MODE = FgelevCaching.

Try running fgelev directly:
<syntaxhighlight lang="bash">
/path/to/fgelev --expire 1000 --fg-root $FG_ROOT --fg-scenery $FG_SCENERY
</syntaxhighlight>
then enter
<syntaxhighlight lang="bash">
0 $lon $lat
</syntaxhighlight>
where $lon and $lat are coordinates in the area you want to generate. See if it returns a sane value. If it does, double-check PATH_TO_SCENERY and $FG_ROOT.

* Buildings/roads have no texture.
copy or link the tex/ folder into the objects folder where the .stg files were created, such that you have $FG_SCENERY/Objects/eXXXnXX/eXXXnXX/tex/.

== Improve frame rate ==
* adjust LOD ranges in FG
* decrease MAX_OBJECTS, increase LOD_*
(- use larger/smaller tiles? Tradeoff between distance calculations/xml parsing and GPU)

== Contributing ==
You know some python? Or you're keen on writing docs? Or just want to use osm2city, but got stuck somewhere? Contact radi on the FG forum.
None of the above? Take [[Howto:Create_textures_from_photos|pictures]] of buildings where you live and [[Osm2city.py Textures|create textures]]! I'm especially interested in south-east asian style architecture, as I'm planning to populate Hong Kong Kai Tak (VHXX) in the future.

== Related ==
* [[Using OSM Vector Data in FlightGear]]
* [[OpenStreetMap buildings]]
* [[AutoGen Scenery for FlightGear]]
* [[Random Buildings]]
* [http://forum.flightgear.org/viewtopic.php?f=5&t=21131#p192198 OSM buidings EHLE]
* [http://forum.flightgear.org/viewtopic.php?f=5&t=22809 osm2city.py development]
* [http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg40092.html Osm2city.py]
* http://forum.flightgear.org/viewtopic.php?f=5&t=19625
* [http://forum.flightgear.org/viewtopic.php?f=38&t=8837 PixelCity]
* [http://forum.flightgear.org/viewtopic.php?p=166794#p166681 Procedural OSM buildings]

[[Category:Scenery software]]

Osm2city.py

2014-10-23T11:26:59Z

Radi: maybe FG_ROOT must be set?

{{OSM Navigation}}
[[File:LOWI with OSM buildings.jpg|thumb|LOWI with OSM buildings]]

This Python script takes OpenStreetMap floorplans and creates 3d buildings ready for use in FlightGear.

The development [https://gitorious.org/fg-radi/osm2city repository] is hosted on gitorious.
Forum thread [http://forum.flightgear.org/viewtopic.php?f=5&t=22809 osm2city.py development]
Written in Python 2.7, developed on GNU/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 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.

== News ==
=== Status 10/2014 ===
New features:
* textures reside in a separate [https://gitorious.org/fg-radi/osm2city-data repository]
* the recommended elevation probing method is ELEV_MODE=FgelevCaching
* roads.py is now quite usable
* SKIP_LIST can contain OSM_IDs

=== Status 06/2014 ===
I'm currently adding textured roads, railroads, intersections and bridges.

{{FGCquote
| the shader is now on osm2city's git (in fgdata/). Again -- all credit goes to Emilian. He is improving the shader side, I will continue on the model side. So this is very much work in progress. The shader requires the default renderer. No ALS/Rembrandt yet. Get the LOWI roads pack (including the shader) here: [https://dl.dropboxusercontent.com/u/24846517/fg/osm2city/LOWI_roads.tar.gz https://dl.dropboxusercontent.com/u/24846517/fg/osm2city/LOWI_roads.tar.gz] The fgdata/ folder goes to your $FGDATA. In roads.xml enable either the lightmap or the traffic shader.
|{{cite web |url=http://forum.flightgear.org/viewtopic.php?p=212460#p212460
|title=<nowiki>Re: osm2city.py development</nowiki>
|author=<nowiki>radi</nowiki>
|date=<nowiki>Fri Jun 13</nowiki>
}}
}}

{{FGCquote
|Creating your own road network is a bit cumbersome ATM, I'll try to make it more general in the next few days. But if you're really, really keen on it: <ul><li> get latest osm2city git</li><li> run roads.py -f your-parameters-file.</li><li> if you also create buildings, make sure to use the same BOUNDARY_* parameters for both osm2city.py and roads.py. Otherwise, buildings and roads might be misaligned. Basically, if your OSM file contains both roads and buildings, you can just use one parameters file.</li><li> roads.py will print an OBJECT_STATIC line, add this to your .stg (appears to add itself)</li><li> copy roads.ac to your scenery</li><li> copy roads.xml and tex/ from the LOWI roads pack to your scenery (roads.ac and .xml copy themselves)</li></ul>
|{{cite web |url=http://forum.flightgear.org/viewtopic.php?p=212460#p212460
|title=<nowiki>Re: osm2city.py development</nowiki>
|author=<nowiki>radi</nowiki>
|date=<nowiki>Fri Jun 13</nowiki>
}}
}}

=== Status 04/2014 ===
[[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. 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]]
The second scene, approaching LOWI from the east, went from 30 fps without buildings down to 20 fps.

=== Status 10/2013 ===
Currently data is processed offline beforehand. 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. <del>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.
</del> (Some optimization gave a huge speedup).

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
use some heuristics (some OSM buildings are labeled "Terminal 1" or so) to apply
terminal/hangar textures to buildings at airports. This way we could rather easily populate some airports with
'semi-generic' terminal/hangar buildings.

== Features ==
* 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 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)
* 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
:* ~10 different, hi-res facade textures, some roof textures
:* find matching texture for given building (number of levels, modern/old building, etc)
:* find matching roof texture for given facade texture
* basic lightmap support
* obstruction lights on tall buildings
* command line interface and parameters file (thanks to forum user vanosten)
* shows statistics on processed buildings
* 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 {{done}}
* 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|50}}
:* 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 ==
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
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 ==
* nearby hi-rise objects of similar shape get same texture? Probably too special a feature.
* 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 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 ==
* 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] and [https://gitorious.org/fg-radi/osm2city-data osm2city-data] 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 . (the dot))
* link osm2city-data/tex and osm2city-data/tex.src into osm2city/

If you're running FG < 3.2, or git older than 10 Oct 2014, or have less than 4 GB RAM, you will most likely need to use the old-fashioned way of elevation probing, which requires you to
* copy elev.nas to $FGDATA/Nasal/
* Change the in variable of elev.nas to match the elev.in file e.g. $FG_DATA/Nasal/elev.in
* Change the out variable of elev.nas to the export directory with a filename with write access (e.g. $FG_HOME/Export). See [[IORules]] and [[$FG_HOME]]

== Install on Windows ==
osm2city is pure python. Install the following packages.

http://www.lfd.uci.edu/~gohlke/pythonlibs/#numpy

http://www.lfd.uci.edu/~gohlke/pythonlibs/#shapely

http://www.lfd.uci.edu/~gohlke/pythonlibs/#scipy-stack

https://pypi.python.org/pypi/Pillow/2.5.0#downloads

== Workflow ==
There are five main steps:
* get OSM data
* adjust input file
* if neccessary, create elevation grid and run FG to probe elevation data.
* run osm2city
* <del>install the generated scenery</del>installs itself

We'll now walk through these steps in detail:
=== get OSM data ===
* decide on a region you want to populate. Get its lon/lat coordinates.
* create a project directory. We will use LOWI/ in this example.
* get corresponding OSM data in its native .xml format.
There are several options to get OSM data. You may find the [http://harrywood.co.uk/maps/uixapi/xapi.html XAPI Query Builder] helpful, it will generate a download URL that you can fetch with wget:
wget -O buildings.osm http://www.overpass-api.de/api/xapi?map?bbox=11.16898,47.20837,11.79108,47.38161

If you use [http://wiki.openstreetmap.org/wiki/Osmosis Osmosis] and cut the area with ''--bounding-box'' then you need to use ''completeWays=yes''.

Put this data into LOWI/buildings.osm

=== Adjust input file ===
* Now adjust the input file. You can generate a commented default parameters file by
<syntaxhighlight lang="bash">
parameters.py -d > LOWI/params.ini
</syntaxhighlight>

Edit this file, adjusting (at least) the following:
:* PREFIX = LOWI (the project directory)
:* BOUNDARY_EAST, BOUNDARY_NORTH, BOUNDARY_SOUTH, BOUNDARY_WEST
:* OSM_FILE = buildings.osm
:* set PATH_TO_SCENERY to a standard FG_SCENERY path. Suppose the area you want to populate is /home/user/fgfs/scenery/Objects/e010n40/e011n47/, PATH_TO_SCENERY would then be /home/user/fgfs/scenery/ .
:* you might want to set MAX_OBJECTS to a small number (say, 100) for your first try. This will limit the number of buildings parsed, and speed up the whole process.
:* you also need to set up elevation probing in the parameters file, described in the next section.

=== Probe elevation ===
Probe elevation for your region. Pick one of the three available modes for ELEV_MODE in params.ini. If you have enough memory (4GB should be fine, but YMMV) and run FG git later than 10 Oct 2014, try FgelevCaching. Failing that, try Manual. (portreekid, what's the 3rd mode good for?)

'''There are a lot of problems reported currently with fgelev. I can't really test for the next month or so. See troubleshooting or use ELEV_MODE = Manual.'''

* ELEV_MODE = FgelevCaching
:* Set FG_ELEV to your fgelev executable. For example: FG_ELEV = /usr/local/fg/bin/fgelev or just FG_ELEV = fgelev if fgelev is already in your OS's path.
:* Set PATH_TO_SCENERY (Missing terrain will result in error message)
:* make sure the environment variable [[$FG ROOT]] points to your FG base path, (e.g. export FG_ROOT=/usr/share/games/flightgear/ on Linux)

* ELEV_MODE = Manual
:* run tools.py (tools.py -f LOWI/params.ini), this will create a file elev.in. Copy elev.in to $FGDATA/Nasal/
:* tools.py will tell you to hide a certain scenery/Objects/... folder, to prevent probing elevation on top of existing objects. Simply rename the folder
:* run FG, open debug->nasal console, enter: elev.get_elevation(), press execute. Might take a long time, depending on the area scanned. This will write elevation data to /tmp/elev.out (which is actually just plain 5 column data: lon,lat,x,y,elevation). Put elev.out into LOWI/
:* unhide, rename the objects folder

* ELEV_MODE = Telnet
:* Run setup.py
:* Start FG with the properties service on Port 5501
:* Run tools.py, this will create a elev.in, start the nasal script and copy the elev.out back to your project directory

=== Run osm2city ===
* run osm2city.py -f LOWI/prams.ini. Parsing OSM data <del>again takes quite looong (10 minutes or more for 50k buildings)</del> is now pretty fast, but the result is cached to file buildings.pkl. Next startup will be <del>much faster if you move buildings.pkl to LOWI/buildings.pkl and</del> even faster if you set USE_PKL = 1.

If all goes well, files like LOWIcity0101.ac and their corresponding .xml, along with .stg files, were created and moved to the correct location in $FG_SCENERY
* copy or link the tex/ folder into the objects folder where these files were created

=== Roads ===
* run roads.py in the same fashion for roads
* <del>copy roads.eff to the same Objects\e0XXnXX\e0XXnXX\ directory</del> roads.eff is copied automatically
* Band-aid fix for the roads is to adjust their height in roads.py change AGL_ofs to a higher number e.g. 0.5

== Troubleshooting ==
* Buildings are generated, but they sit below the ground. I'm using ELEV_MODE = FgelevCaching.

Try running fgelev directly:
<syntaxhighlight lang="bash">
/path/to/fgelev --expire 1000 --fg-root $FG_ROOT --fg-scenery $FG_SCENERY
</syntaxhighlight>
then enter
<syntaxhighlight lang="bash">
0 $lon $lat
</syntaxhighlight>
where $lon and $lat are coordinates in the area you want to generate. See if it returns a sane value. If it does, double-check PATH_TO_SCENERY and $FG_ROOT.

* Buildings/roads have no texture.
copy or link the tex/ folder into the objects folder where the .stg files were created, such that you have $FG_SCENERY/Objects/eXXXnXX/eXXXnXX/tex/.

== Improve frame rate ==
* adjust LOD ranges in FG
* decrease MAX_OBJECTS, increase LOD_*
(- use larger/smaller tiles? Tradeoff between distance calculations/xml parsing and GPU)

== Contributing ==
You know some python? Or you're keen on writing docs? Or just want to use osm2city, but got stuck somewhere? Contact radi on the FG forum.
None of the above? Take [[Howto:Create_textures_from_photos|pictures]] of buildings where you live and [[Osm2city.py Textures|create textures]]! I'm especially interested in south-east asian style architecture, as I'm planning to populate Hong Kong Kai Tak (VHXX) in the future.

== Related ==
* [[Using OSM Vector Data in FlightGear]]
* [[OpenStreetMap buildings]]
* [[AutoGen Scenery for FlightGear]]
* [[Random Buildings]]
* [http://forum.flightgear.org/viewtopic.php?f=5&t=21131#p192198 OSM buidings EHLE]
* [http://forum.flightgear.org/viewtopic.php?f=5&t=22809 osm2city.py development]
* [http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg40092.html Osm2city.py]
* http://forum.flightgear.org/viewtopic.php?f=5&t=19625
* [http://forum.flightgear.org/viewtopic.php?f=38&t=8837 PixelCity]
* [http://forum.flightgear.org/viewtopic.php?p=166794#p166681 Procedural OSM buildings]

[[Category:Scenery software]]

Osm2city.py

2014-10-22T23:21:41Z

Radi: /* Probe elevation */ fgelev problems note

{{OSM Navigation}}
[[File:LOWI with OSM buildings.jpg|thumb|LOWI with OSM buildings]]

This Python script takes OpenStreetMap floorplans and creates 3d buildings ready for use in FlightGear.

The development [https://gitorious.org/fg-radi/osm2city repository] is hosted on gitorious.
Forum thread [http://forum.flightgear.org/viewtopic.php?f=5&t=22809 osm2city.py development]
Written in Python 2.7, developed on GNU/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 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.

== News ==
=== Status 10/2014 ===
New features:
* textures reside in a separate [https://gitorious.org/fg-radi/osm2city-data repository]
* the recommended elevation probing method is ELEV_MODE=FgelevCaching
* roads.py is now quite usable
* SKIP_LIST can contain OSM_IDs

=== Status 06/2014 ===
I'm currently adding textured roads, railroads, intersections and bridges.

{{FGCquote
| the shader is now on osm2city's git (in fgdata/). Again -- all credit goes to Emilian. He is improving the shader side, I will continue on the model side. So this is very much work in progress. The shader requires the default renderer. No ALS/Rembrandt yet. Get the LOWI roads pack (including the shader) here: [https://dl.dropboxusercontent.com/u/24846517/fg/osm2city/LOWI_roads.tar.gz https://dl.dropboxusercontent.com/u/24846517/fg/osm2city/LOWI_roads.tar.gz] The fgdata/ folder goes to your $FGDATA. In roads.xml enable either the lightmap or the traffic shader.
|{{cite web |url=http://forum.flightgear.org/viewtopic.php?p=212460#p212460
|title=<nowiki>Re: osm2city.py development</nowiki>
|author=<nowiki>radi</nowiki>
|date=<nowiki>Fri Jun 13</nowiki>
}}
}}

{{FGCquote
|Creating your own road network is a bit cumbersome ATM, I'll try to make it more general in the next few days. But if you're really, really keen on it: <ul><li> get latest osm2city git</li><li> run roads.py -f your-parameters-file.</li><li> if you also create buildings, make sure to use the same BOUNDARY_* parameters for both osm2city.py and roads.py. Otherwise, buildings and roads might be misaligned. Basically, if your OSM file contains both roads and buildings, you can just use one parameters file.</li><li> roads.py will print an OBJECT_STATIC line, add this to your .stg (appears to add itself)</li><li> copy roads.ac to your scenery</li><li> copy roads.xml and tex/ from the LOWI roads pack to your scenery (roads.ac and .xml copy themselves)</li></ul>
|{{cite web |url=http://forum.flightgear.org/viewtopic.php?p=212460#p212460
|title=<nowiki>Re: osm2city.py development</nowiki>
|author=<nowiki>radi</nowiki>
|date=<nowiki>Fri Jun 13</nowiki>
}}
}}

=== Status 04/2014 ===
[[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. 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]]
The second scene, approaching LOWI from the east, went from 30 fps without buildings down to 20 fps.

=== Status 10/2013 ===
Currently data is processed offline beforehand. 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. <del>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.
</del> (Some optimization gave a huge speedup).

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
use some heuristics (some OSM buildings are labeled "Terminal 1" or so) to apply
terminal/hangar textures to buildings at airports. This way we could rather easily populate some airports with
'semi-generic' terminal/hangar buildings.

== Features ==
* 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 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)
* 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
:* ~10 different, hi-res facade textures, some roof textures
:* find matching texture for given building (number of levels, modern/old building, etc)
:* find matching roof texture for given facade texture
* basic lightmap support
* obstruction lights on tall buildings
* command line interface and parameters file (thanks to forum user vanosten)
* shows statistics on processed buildings
* 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 {{done}}
* 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|50}}
:* 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 ==
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
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 ==
* nearby hi-rise objects of similar shape get same texture? Probably too special a feature.
* 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 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 ==
* 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] and [https://gitorious.org/fg-radi/osm2city-data osm2city-data] 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 . (the dot))
* link osm2city-data/tex and osm2city-data/tex.src into osm2city/

If you're running FG < 3.2, or git older than 10 Oct 2014, or have less than 4 GB RAM, you will most likely need to use the old-fashioned way of elevation probing, which requires you to
* copy elev.nas to $FGDATA/Nasal/
* Change the in variable of elev.nas to match the elev.in file e.g. $FG_DATA/Nasal/elev.in
* Change the out variable of elev.nas to the export directory with a filename with write access (e.g. $FG_HOME/Export). See [[IORules]] and [[$FG_HOME]]

== Install on Windows ==
osm2city is pure python. Install the following packages.

http://www.lfd.uci.edu/~gohlke/pythonlibs/#numpy

http://www.lfd.uci.edu/~gohlke/pythonlibs/#shapely

http://www.lfd.uci.edu/~gohlke/pythonlibs/#scipy-stack

https://pypi.python.org/pypi/Pillow/2.5.0#downloads

== Workflow ==
There are five main steps:
* get OSM data
* adjust input file
* if neccessary, create elevation grid and run FG to probe elevation data.
* run osm2city
* <del>install the generated scenery</del>installs itself

We'll now walk through these steps in detail:
=== get OSM data ===
* decide on a region you want to populate. Get its lon/lat coordinates.
* create a project directory. We will use LOWI/ in this example.
* get corresponding OSM data in its native .xml format.
There are several options to get OSM data. You may find the [http://harrywood.co.uk/maps/uixapi/xapi.html XAPI Query Builder] helpful, it will generate a download URL that you can fetch with wget:
wget -O buildings.osm http://www.overpass-api.de/api/xapi?map?bbox=11.16898,47.20837,11.79108,47.38161

If you use [http://wiki.openstreetmap.org/wiki/Osmosis Osmosis] and cut the area with ''--bounding-box'' then you need to use ''completeWays=yes''.

Put this data into LOWI/buildings.osm

=== Adjust input file ===
* Now adjust the input file. You can generate a commented default parameters file by
<syntaxhighlight lang="bash">
parameters.py -d > LOWI/params.ini
</syntaxhighlight>

Edit this file, adjusting (at least) the following:
:* PREFIX = LOWI (the project directory)
:* BOUNDARY_EAST, BOUNDARY_NORTH, BOUNDARY_SOUTH, BOUNDARY_WEST
:* OSM_FILE = buildings.osm
:* set PATH_TO_SCENERY to a standard FG_SCENERY path. Suppose the area you want to populate is /home/user/fgfs/scenery/Objects/e010n40/e011n47/, PATH_TO_SCENERY would then be /home/user/fgfs/scenery/ .
:* you might want to set MAX_OBJECTS to a small number (say, 100) for your first try. This will limit the number of buildings parsed, and speed up the whole process.
:* you also need to set up elevation probing in the parameters file, described in the next section.

=== Probe elevation ===
Probe elevation for your region. Pick one of the three available modes for ELEV_MODE in params.ini. If you have enough memory (4GB should be fine, but YMMV) and run FG git later than 10 Oct 2014, try FgelevCaching. Failing that, try Manual. (portreekid, what's the 3rd mode good for?)

'''There are a lot of problems reported currently with fgelev. I can't really test for the next month or so. See troubleshooting or use ELEV_MODE = Manual.'''

* ELEV_MODE = FgelevCaching
:* Set FG_ELEV to your fgelev executable. For example: FG_ELEV = /usr/local/fg/bin/fgelev or just FG_ELEV = fgelev if fgelev is already in your OS's path.
:* Set PATH_TO_SCENERY (Missing terrain will result in error message)

* ELEV_MODE = Manual
:* run tools.py (tools.py -f LOWI/params.ini), this will create a file elev.in. Copy elev.in to $FGDATA/Nasal/
:* tools.py will tell you to hide a certain scenery/Objects/... folder, to prevent probing elevation on top of existing objects. Simply rename the folder
:* run FG, open debug->nasal console, enter: elev.get_elevation(), press execute. Might take a long time, depending on the area scanned. This will write elevation data to /tmp/elev.out (which is actually just plain 5 column data: lon,lat,x,y,elevation). Put elev.out into LOWI/
:* unhide, rename the objects folder

* ELEV_MODE = Telnet
:* Run setup.py
:* Start FG with the properties service on Port 5501
:* Run tools.py, this will create a elev.in, start the nasal script and copy the elev.out back to your project directory

=== Run osm2city ===
* run osm2city.py -f LOWI/prams.ini. Parsing OSM data <del>again takes quite looong (10 minutes or more for 50k buildings)</del> is now pretty fast, but the result is cached to file buildings.pkl. Next startup will be <del>much faster if you move buildings.pkl to LOWI/buildings.pkl and</del> even faster if you set USE_PKL = 1.

If all goes well, files like LOWIcity0101.ac and their corresponding .xml, along with .stg files, were created and moved to the correct location in $FG_SCENERY
* copy or link the tex/ folder into the objects folder where these files were created

=== Roads ===
* run roads.py in the same fashion for roads
* <del>copy roads.eff to the same Objects\e0XXnXX\e0XXnXX\ directory</del> roads.eff is copied automatically
* Band-aid fix for the roads is to adjust their height in roads.py change AGL_ofs to a higher number e.g. 0.5

== Troubleshooting ==
* Buildings are generated, but they sit below the ground. I'm using ELEV_MODE = FgelevCaching.

Try running fgelev directly:
[code]
/path/to/fgelev --expire 1000 --fg-root $FG_ROOT --fg-scenery $FG_SCENERY
[code]
then enter
[code]
0 $lon $lat
[code]
where $lon and $lat are coordinates in the area you want to generate. See if it returns a sane value. If it does, double-check PATH_TO_SCENERY.

* Buildings/roads have no texture.
copy or link the tex/ folder into the objects folder where the .stg files were created, such that you have $FG_SCENERY/Objects/eXXXnXX/eXXXnXX/tex/.

== Improve frame rate ==
* adjust LOD ranges in FG
* decrease MAX_OBJECTS, increase LOD_*
(- use larger/smaller tiles? Tradeoff between distance calculations/xml parsing and GPU)

== Contributing ==
You know some python? Or you're keen on writing docs? Or just want to use osm2city, but got stuck somewhere? Contact radi on the FG forum.
None of the above? Take [[Howto:Create_textures_from_photos|pictures]] of buildings where you live and [[Osm2city.py Textures|create textures]]! I'm especially interested in south-east asian style architecture, as I'm planning to populate Hong Kong Kai Tak (VHXX) in the future.

== Related ==
* [[Using OSM Vector Data in FlightGear]]
* [[OpenStreetMap buildings]]
* [[AutoGen Scenery for FlightGear]]
* [[Random Buildings]]
* [http://forum.flightgear.org/viewtopic.php?f=5&t=21131#p192198 OSM buidings EHLE]
* [http://forum.flightgear.org/viewtopic.php?f=5&t=22809 osm2city.py development]
* [http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg40092.html Osm2city.py]
* http://forum.flightgear.org/viewtopic.php?f=5&t=19625
* [http://forum.flightgear.org/viewtopic.php?f=38&t=8837 PixelCity]
* [http://forum.flightgear.org/viewtopic.php?p=166794#p166681 Procedural OSM buildings]

[[Category:Scenery software]]

Osm2city.py

2014-10-22T22:12:03Z

Radi: troubleshooting

{{OSM Navigation}}
[[File:LOWI with OSM buildings.jpg|thumb|LOWI with OSM buildings]]

This Python script takes OpenStreetMap floorplans and creates 3d buildings ready for use in FlightGear.

The development [https://gitorious.org/fg-radi/osm2city repository] is hosted on gitorious.
Forum thread [http://forum.flightgear.org/viewtopic.php?f=5&t=22809 osm2city.py development]
Written in Python 2.7, developed on GNU/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 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.

== News ==
=== Status 10/2014 ===
New features:
* textures reside in a separate [https://gitorious.org/fg-radi/osm2city-data repository]
* the recommended elevation probing method is ELEV_MODE=FgelevCaching
* roads.py is now quite usable
* SKIP_LIST can contain OSM_IDs

=== Status 06/2014 ===
I'm currently adding textured roads, railroads, intersections and bridges.

{{FGCquote
| the shader is now on osm2city's git (in fgdata/). Again -- all credit goes to Emilian. He is improving the shader side, I will continue on the model side. So this is very much work in progress. The shader requires the default renderer. No ALS/Rembrandt yet. Get the LOWI roads pack (including the shader) here: [https://dl.dropboxusercontent.com/u/24846517/fg/osm2city/LOWI_roads.tar.gz https://dl.dropboxusercontent.com/u/24846517/fg/osm2city/LOWI_roads.tar.gz] The fgdata/ folder goes to your $FGDATA. In roads.xml enable either the lightmap or the traffic shader.
|{{cite web |url=http://forum.flightgear.org/viewtopic.php?p=212460#p212460
|title=<nowiki>Re: osm2city.py development</nowiki>
|author=<nowiki>radi</nowiki>
|date=<nowiki>Fri Jun 13</nowiki>
}}
}}

{{FGCquote
|Creating your own road network is a bit cumbersome ATM, I'll try to make it more general in the next few days. But if you're really, really keen on it: <ul><li> get latest osm2city git</li><li> run roads.py -f your-parameters-file.</li><li> if you also create buildings, make sure to use the same BOUNDARY_* parameters for both osm2city.py and roads.py. Otherwise, buildings and roads might be misaligned. Basically, if your OSM file contains both roads and buildings, you can just use one parameters file.</li><li> roads.py will print an OBJECT_STATIC line, add this to your .stg (appears to add itself)</li><li> copy roads.ac to your scenery</li><li> copy roads.xml and tex/ from the LOWI roads pack to your scenery (roads.ac and .xml copy themselves)</li></ul>
|{{cite web |url=http://forum.flightgear.org/viewtopic.php?p=212460#p212460
|title=<nowiki>Re: osm2city.py development</nowiki>
|author=<nowiki>radi</nowiki>
|date=<nowiki>Fri Jun 13</nowiki>
}}
}}

=== Status 04/2014 ===
[[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. 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]]
The second scene, approaching LOWI from the east, went from 30 fps without buildings down to 20 fps.

=== Status 10/2013 ===
Currently data is processed offline beforehand. 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. <del>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.
</del> (Some optimization gave a huge speedup).

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
use some heuristics (some OSM buildings are labeled "Terminal 1" or so) to apply
terminal/hangar textures to buildings at airports. This way we could rather easily populate some airports with
'semi-generic' terminal/hangar buildings.

== Features ==
* 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 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)
* 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
:* ~10 different, hi-res facade textures, some roof textures
:* find matching texture for given building (number of levels, modern/old building, etc)
:* find matching roof texture for given facade texture
* basic lightmap support
* obstruction lights on tall buildings
* command line interface and parameters file (thanks to forum user vanosten)
* shows statistics on processed buildings
* 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 {{done}}
* 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|50}}
:* 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 ==
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
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 ==
* nearby hi-rise objects of similar shape get same texture? Probably too special a feature.
* 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 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 ==
* 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] and [https://gitorious.org/fg-radi/osm2city-data osm2city-data] 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 . (the dot))
* link osm2city-data/tex and osm2city-data/tex.src into osm2city/

If you're running FG < 3.2, or git older than 10 Oct 2014, or have less than 4 GB RAM, you will most likely need to use the old-fashioned way of elevation probing, which requires you to
* copy elev.nas to $FGDATA/Nasal/
* Change the in variable of elev.nas to match the elev.in file e.g. $FG_DATA/Nasal/elev.in
* Change the out variable of elev.nas to the export directory with a filename with write access (e.g. $FG_HOME/Export). See [[IORules]] and [[$FG_HOME]]

== Install on Windows ==
osm2city is pure python. Install the following packages.

http://www.lfd.uci.edu/~gohlke/pythonlibs/#numpy

http://www.lfd.uci.edu/~gohlke/pythonlibs/#shapely

http://www.lfd.uci.edu/~gohlke/pythonlibs/#scipy-stack

https://pypi.python.org/pypi/Pillow/2.5.0#downloads

== Workflow ==
There are five main steps:
* get OSM data
* adjust input file
* if neccessary, create elevation grid and run FG to probe elevation data.
* run osm2city
* <del>install the generated scenery</del>installs itself

We'll now walk through these steps in detail:
=== get OSM data ===
* decide on a region you want to populate. Get its lon/lat coordinates.
* create a project directory. We will use LOWI/ in this example.
* get corresponding OSM data in its native .xml format.
There are several options to get OSM data. You may find the [http://harrywood.co.uk/maps/uixapi/xapi.html XAPI Query Builder] helpful, it will generate a download URL that you can fetch with wget:
wget -O buildings.osm http://www.overpass-api.de/api/xapi?map?bbox=11.16898,47.20837,11.79108,47.38161

If you use [http://wiki.openstreetmap.org/wiki/Osmosis Osmosis] and cut the area with ''--bounding-box'' then you need to use ''completeWays=yes''.

Put this data into LOWI/buildings.osm

=== Adjust input file ===
* Now adjust the input file. You can generate a commented default parameters file by
<syntaxhighlight lang="bash">
parameters.py -d > LOWI/params.ini
</syntaxhighlight>

Edit this file, adjusting (at least) the following:
:* PREFIX = LOWI (the project directory)
:* BOUNDARY_EAST, BOUNDARY_NORTH, BOUNDARY_SOUTH, BOUNDARY_WEST
:* OSM_FILE = buildings.osm
:* set PATH_TO_SCENERY to a standard FG_SCENERY path. Suppose the area you want to populate is /home/user/fgfs/scenery/Objects/e010n40/e011n47/, PATH_TO_SCENERY would then be /home/user/fgfs/scenery/ .
:* you might want to set MAX_OBJECTS to a small number (say, 100) for your first try. This will limit the number of buildings parsed, and speed up the whole process.
:* you also need to set up elevation probing in the parameters file, described in the next section.

=== Probe elevation ===
Probe elevation for your region. Pick one of the three available modes for ELEV_MODE in params.ini. If you have enough memory (4GB should be fine, but YMMV) and run FG >= 3.2 or FG git later than 10 Oct 2014, try FgelevCaching. Failing that, try Manual. (portreekid, what's the 3rd mode good for?)

* ELEV_MODE = FgelevCaching
:* Set FG_ELEV to your fgelev executable. For example: FG_ELEV = /usr/local/fg/bin/fgelev or just FG_ELEV = fgelev if fgelev is already in your OS's path.
:* Set PATH_TO_SCENERY (Missing terrain will result in error message)

* ELEV_MODE = Manual
:* run tools.py (tools.py -f LOWI/params.ini), this will create a file elev.in. Copy elev.in to $FGDATA/Nasal/
:* tools.py will tell you to hide a certain scenery/Objects/... folder, to prevent probing elevation on top of existing objects. Simply rename the folder
:* run FG, open debug->nasal console, enter: elev.get_elevation(), press execute. Might take a long time, depending on the area scanned. This will write elevation data to /tmp/elev.out (which is actually just plain 5 column data: lon,lat,x,y,elevation). Put elev.out into LOWI/
:* unhide, rename the objects folder

* ELEV_MODE = Telnet
:* Run setup.py
:* Start FG with the properties service on Port 5501
:* Run tools.py, this will create a elev.in, start the nasal script and copy the elev.out back to your project directory

=== Run osm2city ===
* run osm2city.py -f LOWI/prams.ini. Parsing OSM data <del>again takes quite looong (10 minutes or more for 50k buildings)</del> is now pretty fast, but the result is cached to file buildings.pkl. Next startup will be <del>much faster if you move buildings.pkl to LOWI/buildings.pkl and</del> even faster if you set USE_PKL = 1.

If all goes well, files like LOWIcity0101.ac and their corresponding .xml, along with .stg files, were created and moved to the correct location in $FG_SCENERY
* copy or link the tex/ folder into the objects folder where these files were created

=== Roads ===
* run roads.py in the same fashion for roads
* <del>copy roads.eff to the same Objects\e0XXnXX\e0XXnXX\ directory</del> roads.eff is copied automatically
* Band-aid fix for the roads is to adjust their height in roads.py change AGL_ofs to a higher number e.g. 0.5

== Troubleshooting ==
* Buildings are generated, but they sit below the ground. I'm using ELEV_MODE = FgelevCaching.

Try running fgelev directly:
[code]
/path/to/fgelev --expire 1000 --fg-root $FG_ROOT --fg-scenery $FG_SCENERY
[code]
then enter
[code]
0 $lon $lat
[code]
where $lon and $lat are coordinates in the area you want to generate. See if it returns a sane value. If it does, double-check PATH_TO_SCENERY.

* Buildings/roads have no texture.
copy or link the tex/ folder into the objects folder where the .stg files were created, such that you have $FG_SCENERY/Objects/eXXXnXX/eXXXnXX/tex/.

== Improve frame rate ==
* adjust LOD ranges in FG
* decrease MAX_OBJECTS, increase LOD_*
(- use larger/smaller tiles? Tradeoff between distance calculations/xml parsing and GPU)

== Contributing ==
You know some python? Or you're keen on writing docs? Or just want to use osm2city, but got stuck somewhere? Contact radi on the FG forum.
None of the above? Take [[Howto:Create_textures_from_photos|pictures]] of buildings where you live and [[Osm2city.py Textures|create textures]]! I'm especially interested in south-east asian style architecture, as I'm planning to populate Hong Kong Kai Tak (VHXX) in the future.

== Related ==
* [[Using OSM Vector Data in FlightGear]]
* [[OpenStreetMap buildings]]
* [[AutoGen Scenery for FlightGear]]
* [[Random Buildings]]
* [http://forum.flightgear.org/viewtopic.php?f=5&t=21131#p192198 OSM buidings EHLE]
* [http://forum.flightgear.org/viewtopic.php?f=5&t=22809 osm2city.py development]
* [http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg40092.html Osm2city.py]
* http://forum.flightgear.org/viewtopic.php?f=5&t=19625
* [http://forum.flightgear.org/viewtopic.php?f=38&t=8837 PixelCity]
* [http://forum.flightgear.org/viewtopic.php?p=166794#p166681 Procedural OSM buildings]

[[Category:Scenery software]]

Osm2city.py

2014-10-22T02:23:47Z

Radi: filed status sections under news

{{OSM Navigation}}
[[File:LOWI with OSM buildings.jpg|thumb|LOWI with OSM buildings]]

This Python script takes OpenStreetMap floorplans and creates 3d buildings ready for use in FlightGear.

The development [https://gitorious.org/fg-radi/osm2city repository] is hosted on gitorious.
Forum thread [http://forum.flightgear.org/viewtopic.php?f=5&t=22809 osm2city.py development]
Written in Python 2.7, developed on GNU/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 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.

== News ==
=== Status 10/2014 ===
New features:
* textures reside in a separate [https://gitorious.org/fg-radi/osm2city-data repository]
* the recommended elevation probing method is ELEV_MODE=FgelevCaching
* roads.py is now quite usable
* SKIP_LIST can contain OSM_IDs

=== Status 06/2014 ===
I'm currently adding textured roads, railroads, intersections and bridges.

{{FGCquote
| the shader is now on osm2city's git (in fgdata/). Again -- all credit goes to Emilian. He is improving the shader side, I will continue on the model side. So this is very much work in progress. The shader requires the default renderer. No ALS/Rembrandt yet. Get the LOWI roads pack (including the shader) here: [https://dl.dropboxusercontent.com/u/24846517/fg/osm2city/LOWI_roads.tar.gz https://dl.dropboxusercontent.com/u/24846517/fg/osm2city/LOWI_roads.tar.gz] The fgdata/ folder goes to your $FGDATA. In roads.xml enable either the lightmap or the traffic shader.
|{{cite web |url=http://forum.flightgear.org/viewtopic.php?p=212460#p212460
|title=<nowiki>Re: osm2city.py development</nowiki>
|author=<nowiki>radi</nowiki>
|date=<nowiki>Fri Jun 13</nowiki>
}}
}}

{{FGCquote
|Creating your own road network is a bit cumbersome ATM, I'll try to make it more general in the next few days. But if you're really, really keen on it: <ul><li> get latest osm2city git</li><li> run roads.py -f your-parameters-file.</li><li> if you also create buildings, make sure to use the same BOUNDARY_* parameters for both osm2city.py and roads.py. Otherwise, buildings and roads might be misaligned. Basically, if your OSM file contains both roads and buildings, you can just use one parameters file.</li><li> roads.py will print an OBJECT_STATIC line, add this to your .stg (appears to add itself)</li><li> copy roads.ac to your scenery</li><li> copy roads.xml and tex/ from the LOWI roads pack to your scenery (roads.ac and .xml copy themselves)</li></ul>
|{{cite web |url=http://forum.flightgear.org/viewtopic.php?p=212460#p212460
|title=<nowiki>Re: osm2city.py development</nowiki>
|author=<nowiki>radi</nowiki>
|date=<nowiki>Fri Jun 13</nowiki>
}}
}}

=== Status 04/2014 ===
[[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. 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]]
The second scene, approaching LOWI from the east, went from 30 fps without buildings down to 20 fps.

=== Status 10/2013 ===
Currently data is processed offline beforehand. 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. <del>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.
</del> (Some optimization gave a huge speedup).

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
use some heuristics (some OSM buildings are labeled "Terminal 1" or so) to apply
terminal/hangar textures to buildings at airports. This way we could rather easily populate some airports with
'semi-generic' terminal/hangar buildings.

== Features ==
* 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 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)
* 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
:* ~10 different, hi-res facade textures, some roof textures
:* find matching texture for given building (number of levels, modern/old building, etc)
:* find matching roof texture for given facade texture
* basic lightmap support
* obstruction lights on tall buildings
* command line interface and parameters file (thanks to forum user vanosten)
* shows statistics on processed buildings
* 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 {{done}}
* 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|50}}
:* 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 ==
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
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 ==
* nearby hi-rise objects of similar shape get same texture? Probably too special a feature.
* 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 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 ==
* 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] and [https://gitorious.org/fg-radi/osm2city-data osm2city-data] 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 . (the dot))
* link osm2city-data/tex and osm2city-data/tex.src into osm2city/

If you're running FG < 3.2, or git older than 10 Oct 2014, or have less than 4 GB RAM, you will most likely need to use the old-fashioned way of elevation probing, which requires you to
* copy elev.nas to $FGDATA/Nasal/
* Change the in variable of elev.nas to match the elev.in file e.g. $FG_DATA/Nasal/elev.in
* Change the out variable of elev.nas to the export directory with a filename with write access (e.g. $FG_HOME/Export). See [[IORules]] and [[$FG_HOME]]

== Install on Windows ==
osm2city is pure python. Install the following packages.

http://www.lfd.uci.edu/~gohlke/pythonlibs/#numpy

http://www.lfd.uci.edu/~gohlke/pythonlibs/#shapely

http://www.lfd.uci.edu/~gohlke/pythonlibs/#scipy-stack

https://pypi.python.org/pypi/Pillow/2.5.0#downloads

== Workflow ==
There are five main steps:
* get OSM data
* adjust input file
* if neccessary, create elevation grid and run FG to probe elevation data.
* run osm2city
* <del>install the generated scenery</del>installs itself

We'll now walk through these steps in detail:
=== get OSM data ===
* decide on a region you want to populate. Get its lon/lat coordinates.
* create a project directory. We will use LOWI/ in this example.
* get corresponding OSM data in its native .xml format.
There are several options to get OSM data. You may find the [http://harrywood.co.uk/maps/uixapi/xapi.html XAPI Query Builder] helpful, it will generate a download URL that you can fetch with wget:
wget -O buildings.osm http://www.overpass-api.de/api/xapi?map?bbox=11.16898,47.20837,11.79108,47.38161

If you use [http://wiki.openstreetmap.org/wiki/Osmosis Osmosis] and cut the area with ''--bounding-box'' then you need to use ''completeWays=yes''.

Put this data into LOWI/buildings.osm

=== Adjust input file ===
* Now adjust the input file. You can generate a commented default parameters file by
<syntaxhighlight lang="bash">
parameters.py -d > LOWI/params.ini
</syntaxhighlight>

Edit this file, adjusting (at least) the following:
:* PREFIX = LOWI (the project directory)
:* BOUNDARY_EAST, BOUNDARY_NORTH, BOUNDARY_SOUTH, BOUNDARY_WEST
:* OSM_FILE = buildings.osm
:* set PATH_TO_SCENERY to a standard FG_SCENERY path. Suppose the area you want to populate is /home/user/fgfs/scenery/Objects/e010n40/e011n47/, PATH_TO_SCENERY would then be /home/user/fgfs/scenery/ .
:* you might want to set MAX_OBJECTS to a small number (say, 100) for your first try. This will limit the number of buildings parsed, and speed up the whole process.
:* you also need to set up elevation probing in the parameters file, described in the next section.

=== Probe elevation ===
Probe elevation for your region. Pick one of the three available modes for ELEV_MODE in params.ini. If you have enough memory (4GB should be fine, but YMMV) and run FG >= 3.2 or FG git later than 10 Oct 2014, try FgelevCaching. Failing that, try Manual. (portreekid, what's the 3rd mode good for?)

* ELEV_MODE = FgelevCaching
:* Set FG_ELEV to your fgelev executable. For example: FG_ELEV = /usr/local/fg/bin/fgelev or just FG_ELEV = fgelev if fgelev is already in your OS's path.
:* Set PATH_TO_SCENERY (Missing terrain will result in error message)

* ELEV_MODE = Manual
:* run tools.py (tools.py -f LOWI/params.ini), this will create a file elev.in. Copy elev.in to $FGDATA/Nasal/
:* tools.py will tell you to hide a certain scenery/Objects/... folder, to prevent probing elevation on top of existing objects. Simply rename the folder
:* run FG, open debug->nasal console, enter: elev.get_elevation(), press execute. Might take a long time, depending on the area scanned. This will write elevation data to /tmp/elev.out (which is actually just plain 5 column data: lon,lat,x,y,elevation). Put elev.out into LOWI/
:* unhide, rename the objects folder

* ELEV_MODE = Telnet
:* Run setup.py
:* Start FG with the properties service on Port 5501
:* Run tools.py, this will create a elev.in, start the nasal script and copy the elev.out back to your project directory

=== Run osm2city ===
* run osm2city.py -f LOWI/prams.ini. Parsing OSM data <del>again takes quite looong (10 minutes or more for 50k buildings)</del> is now pretty fast, but the result is cached to file buildings.pkl. Next startup will be <del>much faster if you move buildings.pkl to LOWI/buildings.pkl and</del> even faster if you set USE_PKL = 1.

If all goes well, files like LOWIcity0101.ac and their corresponding .xml, along with .stg files, were created and moved to the correct location in $FG_SCENERY
* copy or link the tex/ folder into the objects folder where these files were created

=== Roads ===
* run roads.py in the same fashion for roads
* <del>copy roads.eff to the same Objects\e0XXnXX\e0XXnXX\ directory</del> roads.eff is copied automatically
* Band-aid fix for the roads is to adjust their height in roads.py change AGL_ofs to a higher number e.g. 0.5

== Improve frame rate ==
* adjust LOD ranges in FG
* decrease MAX_OBJECTS, increase LOD_*
(- use larger/smaller tiles? Tradeoff between distance calculations/xml parsing and GPU)

== Contributing ==
You know some python? Or you're keen on writing docs? Or just want to use osm2city, but got stuck somewhere? Contact radi on the FG forum.
None of the above? Take [[Howto:Create_textures_from_photos|pictures]] of buildings where you live and [[Osm2city.py Textures|create textures]]! I'm especially interested in south-east asian style architecture, as I'm planning to populate Hong Kong Kai Tak (VHXX) in the future.

== Related ==
* [[Using OSM Vector Data in FlightGear]]
* [[OpenStreetMap buildings]]
* [[AutoGen Scenery for FlightGear]]
* [[Random Buildings]]
* [http://forum.flightgear.org/viewtopic.php?f=5&t=21131#p192198 OSM buidings EHLE]
* [http://forum.flightgear.org/viewtopic.php?f=5&t=22809 osm2city.py development]
* [http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg40092.html Osm2city.py]
* http://forum.flightgear.org/viewtopic.php?f=5&t=19625
* [http://forum.flightgear.org/viewtopic.php?f=38&t=8837 PixelCity]
* [http://forum.flightgear.org/viewtopic.php?p=166794#p166681 Procedural OSM buildings]

[[Category:Scenery software]]

Osm2city.py

2014-10-22T02:21:05Z

Radi: /* Features */ LM works

{{OSM Navigation}}
[[File:LOWI with OSM buildings.jpg|thumb|LOWI with OSM buildings]]

This Python script takes OpenStreetMap floorplans and creates 3d buildings ready for use in FlightGear.

The development [https://gitorious.org/fg-radi/osm2city repository] is hosted on gitorious.
Forum thread [http://forum.flightgear.org/viewtopic.php?f=5&t=22809 osm2city.py development]
Written in Python 2.7, developed on GNU/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 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.

== Status 10/2014 ==
New features:
* textures reside in a separate [https://gitorious.org/fg-radi/osm2city-data repository]
* the recommended elevation probing method is ELEV_MODE=FgelevCaching
* roads.py is now quite usable
* SKIP_LIST can contain OSM_IDs

== Status 06/2014 ==
I'm currently adding textured roads, railroads, intersections and bridges.

{{FGCquote
| the shader is now on osm2city's git (in fgdata/). Again -- all credit goes to Emilian. He is improving the shader side, I will continue on the model side. So this is very much work in progress. The shader requires the default renderer. No ALS/Rembrandt yet. Get the LOWI roads pack (including the shader) here: [https://dl.dropboxusercontent.com/u/24846517/fg/osm2city/LOWI_roads.tar.gz https://dl.dropboxusercontent.com/u/24846517/fg/osm2city/LOWI_roads.tar.gz] The fgdata/ folder goes to your $FGDATA. In roads.xml enable either the lightmap or the traffic shader.
|{{cite web |url=http://forum.flightgear.org/viewtopic.php?p=212460#p212460
|title=<nowiki>Re: osm2city.py development</nowiki>
|author=<nowiki>radi</nowiki>
|date=<nowiki>Fri Jun 13</nowiki>
}}
}}

{{FGCquote
|Creating your own road network is a bit cumbersome ATM, I'll try to make it more general in the next few days. But if you're really, really keen on it: <ul><li> get latest osm2city git</li><li> run roads.py -f your-parameters-file.</li><li> if you also create buildings, make sure to use the same BOUNDARY_* parameters for both osm2city.py and roads.py. Otherwise, buildings and roads might be misaligned. Basically, if your OSM file contains both roads and buildings, you can just use one parameters file.</li><li> roads.py will print an OBJECT_STATIC line, add this to your .stg (appears to add itself)</li><li> copy roads.ac to your scenery</li><li> copy roads.xml and tex/ from the LOWI roads pack to your scenery (roads.ac and .xml copy themselves)</li></ul>
|{{cite web |url=http://forum.flightgear.org/viewtopic.php?p=212460#p212460
|title=<nowiki>Re: osm2city.py development</nowiki>
|author=<nowiki>radi</nowiki>
|date=<nowiki>Fri Jun 13</nowiki>
}}
}}

== Status 04/2014 ==
[[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. 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]]
The second scene, approaching LOWI from the east, went from 30 fps without buildings down to 20 fps.

== Status 10/2013 ==
Currently data is processed offline beforehand. 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. <del>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.
</del> (Some optimization gave a huge speedup).

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
use some heuristics (some OSM buildings are labeled "Terminal 1" or so) to apply
terminal/hangar textures to buildings at airports. This way we could rather easily populate some airports with
'semi-generic' terminal/hangar buildings.

== Features ==
* 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 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)
* 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
:* ~10 different, hi-res facade textures, some roof textures
:* find matching texture for given building (number of levels, modern/old building, etc)
:* find matching roof texture for given facade texture
* basic lightmap support
* obstruction lights on tall buildings
* command line interface and parameters file (thanks to forum user vanosten)
* shows statistics on processed buildings
* 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 {{done}}
* 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|50}}
:* 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 ==
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
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 ==
* nearby hi-rise objects of similar shape get same texture? Probably too special a feature.
* 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 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 ==
* 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] and [https://gitorious.org/fg-radi/osm2city-data osm2city-data] 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 . (the dot))
* link osm2city-data/tex and osm2city-data/tex.src into osm2city/

If you're running FG < 3.2, or git older than 10 Oct 2014, or have less than 4 GB RAM, you will most likely need to use the old-fashioned way of elevation probing, which requires you to
* copy elev.nas to $FGDATA/Nasal/
* Change the in variable of elev.nas to match the elev.in file e.g. $FG_DATA/Nasal/elev.in
* Change the out variable of elev.nas to the export directory with a filename with write access (e.g. $FG_HOME/Export). See [[IORules]] and [[$FG_HOME]]

== Install on Windows ==
osm2city is pure python. Install the following packages.

http://www.lfd.uci.edu/~gohlke/pythonlibs/#numpy

http://www.lfd.uci.edu/~gohlke/pythonlibs/#shapely

http://www.lfd.uci.edu/~gohlke/pythonlibs/#scipy-stack

https://pypi.python.org/pypi/Pillow/2.5.0#downloads

== Workflow ==
There are five main steps:
* get OSM data
* adjust input file
* if neccessary, create elevation grid and run FG to probe elevation data.
* run osm2city
* <del>install the generated scenery</del>installs itself

We'll now walk through these steps in detail:
=== get OSM data ===
* decide on a region you want to populate. Get its lon/lat coordinates.
* create a project directory. We will use LOWI/ in this example.
* get corresponding OSM data in its native .xml format.
There are several options to get OSM data. You may find the [http://harrywood.co.uk/maps/uixapi/xapi.html XAPI Query Builder] helpful, it will generate a download URL that you can fetch with wget:
wget -O buildings.osm http://www.overpass-api.de/api/xapi?map?bbox=11.16898,47.20837,11.79108,47.38161

If you use [http://wiki.openstreetmap.org/wiki/Osmosis Osmosis] and cut the area with ''--bounding-box'' then you need to use ''completeWays=yes''.

Put this data into LOWI/buildings.osm

=== Adjust input file ===
* Now adjust the input file. You can generate a commented default parameters file by
<syntaxhighlight lang="bash">
parameters.py -d > LOWI/params.ini
</syntaxhighlight>

Edit this file, adjusting (at least) the following:
:* PREFIX = LOWI (the project directory)
:* BOUNDARY_EAST, BOUNDARY_NORTH, BOUNDARY_SOUTH, BOUNDARY_WEST
:* OSM_FILE = buildings.osm
:* set PATH_TO_SCENERY to a standard FG_SCENERY path. Suppose the area you want to populate is /home/user/fgfs/scenery/Objects/e010n40/e011n47/, PATH_TO_SCENERY would then be /home/user/fgfs/scenery/ .
:* you might want to set MAX_OBJECTS to a small number (say, 100) for your first try. This will limit the number of buildings parsed, and speed up the whole process.
:* you also need to set up elevation probing in the parameters file, described in the next section.

=== Probe elevation ===
Probe elevation for your region. Pick one of the three available modes for ELEV_MODE in params.ini. If you have enough memory (4GB should be fine, but YMMV) and run FG >= 3.2 or FG git later than 10 Oct 2014, try FgelevCaching. Failing that, try Manual. (portreekid, what's the 3rd mode good for?)

* ELEV_MODE = FgelevCaching
:* Set FG_ELEV to your fgelev executable. For example: FG_ELEV = /usr/local/fg/bin/fgelev or just FG_ELEV = fgelev if fgelev is already in your OS's path.
:* Set PATH_TO_SCENERY (Missing terrain will result in error message)

* ELEV_MODE = Manual
:* run tools.py (tools.py -f LOWI/params.ini), this will create a file elev.in. Copy elev.in to $FGDATA/Nasal/
:* tools.py will tell you to hide a certain scenery/Objects/... folder, to prevent probing elevation on top of existing objects. Simply rename the folder
:* run FG, open debug->nasal console, enter: elev.get_elevation(), press execute. Might take a long time, depending on the area scanned. This will write elevation data to /tmp/elev.out (which is actually just plain 5 column data: lon,lat,x,y,elevation). Put elev.out into LOWI/
:* unhide, rename the objects folder

* ELEV_MODE = Telnet
:* Run setup.py
:* Start FG with the properties service on Port 5501
:* Run tools.py, this will create a elev.in, start the nasal script and copy the elev.out back to your project directory

=== Run osm2city ===
* run osm2city.py -f LOWI/prams.ini. Parsing OSM data <del>again takes quite looong (10 minutes or more for 50k buildings)</del> is now pretty fast, but the result is cached to file buildings.pkl. Next startup will be <del>much faster if you move buildings.pkl to LOWI/buildings.pkl and</del> even faster if you set USE_PKL = 1.

If all goes well, files like LOWIcity0101.ac and their corresponding .xml, along with .stg files, were created and moved to the correct location in $FG_SCENERY
* copy or link the tex/ folder into the objects folder where these files were created

=== Roads ===
* run roads.py in the same fashion for roads
* <del>copy roads.eff to the same Objects\e0XXnXX\e0XXnXX\ directory</del> roads.eff is copied automatically
* Band-aid fix for the roads is to adjust their height in roads.py change AGL_ofs to a higher number e.g. 0.5

== Improve frame rate ==
* adjust LOD ranges in FG
* decrease MAX_OBJECTS, increase LOD_*
(- use larger/smaller tiles? Tradeoff between distance calculations/xml parsing and GPU)

== Contributing ==
You know some python? Or you're keen on writing docs? Or just want to use osm2city, but got stuck somewhere? Contact radi on the FG forum.
None of the above? Take [[Howto:Create_textures_from_photos|pictures]] of buildings where you live and [[Osm2city.py Textures|create textures]]! I'm especially interested in south-east asian style architecture, as I'm planning to populate Hong Kong Kai Tak (VHXX) in the future.

== Related ==
* [[Using OSM Vector Data in FlightGear]]
* [[OpenStreetMap buildings]]
* [[AutoGen Scenery for FlightGear]]
* [[Random Buildings]]
* [http://forum.flightgear.org/viewtopic.php?f=5&t=21131#p192198 OSM buidings EHLE]
* [http://forum.flightgear.org/viewtopic.php?f=5&t=22809 osm2city.py development]
* [http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg40092.html Osm2city.py]
* http://forum.flightgear.org/viewtopic.php?f=5&t=19625
* [http://forum.flightgear.org/viewtopic.php?f=38&t=8837 PixelCity]
* [http://forum.flightgear.org/viewtopic.php?p=166794#p166681 Procedural OSM buildings]

[[Category:Scenery software]]

Osm2city.py

2014-10-22T02:20:20Z

Radi: Status 10/2014

{{OSM Navigation}}
[[File:LOWI with OSM buildings.jpg|thumb|LOWI with OSM buildings]]

This Python script takes OpenStreetMap floorplans and creates 3d buildings ready for use in FlightGear.

The development [https://gitorious.org/fg-radi/osm2city repository] is hosted on gitorious.
Forum thread [http://forum.flightgear.org/viewtopic.php?f=5&t=22809 osm2city.py development]
Written in Python 2.7, developed on GNU/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 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.

== Status 10/2014 ==
New features:
* textures reside in a separate [https://gitorious.org/fg-radi/osm2city-data repository]
* the recommended elevation probing method is ELEV_MODE=FgelevCaching
* roads.py is now quite usable
* SKIP_LIST can contain OSM_IDs

== Status 06/2014 ==
I'm currently adding textured roads, railroads, intersections and bridges.

{{FGCquote
| the shader is now on osm2city's git (in fgdata/). Again -- all credit goes to Emilian. He is improving the shader side, I will continue on the model side. So this is very much work in progress. The shader requires the default renderer. No ALS/Rembrandt yet. Get the LOWI roads pack (including the shader) here: [https://dl.dropboxusercontent.com/u/24846517/fg/osm2city/LOWI_roads.tar.gz https://dl.dropboxusercontent.com/u/24846517/fg/osm2city/LOWI_roads.tar.gz] The fgdata/ folder goes to your $FGDATA. In roads.xml enable either the lightmap or the traffic shader.
|{{cite web |url=http://forum.flightgear.org/viewtopic.php?p=212460#p212460
|title=<nowiki>Re: osm2city.py development</nowiki>
|author=<nowiki>radi</nowiki>
|date=<nowiki>Fri Jun 13</nowiki>
}}
}}

{{FGCquote
|Creating your own road network is a bit cumbersome ATM, I'll try to make it more general in the next few days. But if you're really, really keen on it: <ul><li> get latest osm2city git</li><li> run roads.py -f your-parameters-file.</li><li> if you also create buildings, make sure to use the same BOUNDARY_* parameters for both osm2city.py and roads.py. Otherwise, buildings and roads might be misaligned. Basically, if your OSM file contains both roads and buildings, you can just use one parameters file.</li><li> roads.py will print an OBJECT_STATIC line, add this to your .stg (appears to add itself)</li><li> copy roads.ac to your scenery</li><li> copy roads.xml and tex/ from the LOWI roads pack to your scenery (roads.ac and .xml copy themselves)</li></ul>
|{{cite web |url=http://forum.flightgear.org/viewtopic.php?p=212460#p212460
|title=<nowiki>Re: osm2city.py development</nowiki>
|author=<nowiki>radi</nowiki>
|date=<nowiki>Fri Jun 13</nowiki>
}}
}}

== Status 04/2014 ==
[[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. 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]]
The second scene, approaching LOWI from the east, went from 30 fps without buildings down to 20 fps.

== Status 10/2013 ==
Currently data is processed offline beforehand. 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. <del>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.
</del> (Some optimization gave a huge speedup).

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
use some heuristics (some OSM buildings are labeled "Terminal 1" or so) to apply
terminal/hangar textures to buildings at airports. This way we could rather easily populate some airports with
'semi-generic' terminal/hangar buildings.

== Features ==
* 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 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)
* 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
:* ~10 different, hi-res facade textures, some roof textures
:* find matching texture for given building (number of levels, modern/old building, etc)
:* find matching roof texture for given facade texture
* basic lightmap support (currently broken)
* obstruction lights on tall buildings
* command line interface and parameters file (thanks to forum user vanosten)
* shows statistics on processed buildings
* 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 {{done}}
* 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|50}}
:* 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 ==
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
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 ==
* nearby hi-rise objects of similar shape get same texture? Probably too special a feature.
* 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 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 ==
* 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] and [https://gitorious.org/fg-radi/osm2city-data osm2city-data] 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 . (the dot))
* link osm2city-data/tex and osm2city-data/tex.src into osm2city/

If you're running FG < 3.2, or git older than 10 Oct 2014, or have less than 4 GB RAM, you will most likely need to use the old-fashioned way of elevation probing, which requires you to
* copy elev.nas to $FGDATA/Nasal/
* Change the in variable of elev.nas to match the elev.in file e.g. $FG_DATA/Nasal/elev.in
* Change the out variable of elev.nas to the export directory with a filename with write access (e.g. $FG_HOME/Export). See [[IORules]] and [[$FG_HOME]]

== Install on Windows ==
osm2city is pure python. Install the following packages.

http://www.lfd.uci.edu/~gohlke/pythonlibs/#numpy

http://www.lfd.uci.edu/~gohlke/pythonlibs/#shapely

http://www.lfd.uci.edu/~gohlke/pythonlibs/#scipy-stack

https://pypi.python.org/pypi/Pillow/2.5.0#downloads

== Workflow ==
There are five main steps:
* get OSM data
* adjust input file
* if neccessary, create elevation grid and run FG to probe elevation data.
* run osm2city
* <del>install the generated scenery</del>installs itself

We'll now walk through these steps in detail:
=== get OSM data ===
* decide on a region you want to populate. Get its lon/lat coordinates.
* create a project directory. We will use LOWI/ in this example.
* get corresponding OSM data in its native .xml format.
There are several options to get OSM data. You may find the [http://harrywood.co.uk/maps/uixapi/xapi.html XAPI Query Builder] helpful, it will generate a download URL that you can fetch with wget:
wget -O buildings.osm http://www.overpass-api.de/api/xapi?map?bbox=11.16898,47.20837,11.79108,47.38161

If you use [http://wiki.openstreetmap.org/wiki/Osmosis Osmosis] and cut the area with ''--bounding-box'' then you need to use ''completeWays=yes''.

Put this data into LOWI/buildings.osm

=== Adjust input file ===
* Now adjust the input file. You can generate a commented default parameters file by
<syntaxhighlight lang="bash">
parameters.py -d > LOWI/params.ini
</syntaxhighlight>

Edit this file, adjusting (at least) the following:
:* PREFIX = LOWI (the project directory)
:* BOUNDARY_EAST, BOUNDARY_NORTH, BOUNDARY_SOUTH, BOUNDARY_WEST
:* OSM_FILE = buildings.osm
:* set PATH_TO_SCENERY to a standard FG_SCENERY path. Suppose the area you want to populate is /home/user/fgfs/scenery/Objects/e010n40/e011n47/, PATH_TO_SCENERY would then be /home/user/fgfs/scenery/ .
:* you might want to set MAX_OBJECTS to a small number (say, 100) for your first try. This will limit the number of buildings parsed, and speed up the whole process.
:* you also need to set up elevation probing in the parameters file, described in the next section.

=== Probe elevation ===
Probe elevation for your region. Pick one of the three available modes for ELEV_MODE in params.ini. If you have enough memory (4GB should be fine, but YMMV) and run FG >= 3.2 or FG git later than 10 Oct 2014, try FgelevCaching. Failing that, try Manual. (portreekid, what's the 3rd mode good for?)

* ELEV_MODE = FgelevCaching
:* Set FG_ELEV to your fgelev executable. For example: FG_ELEV = /usr/local/fg/bin/fgelev or just FG_ELEV = fgelev if fgelev is already in your OS's path.
:* Set PATH_TO_SCENERY (Missing terrain will result in error message)

* ELEV_MODE = Manual
:* run tools.py (tools.py -f LOWI/params.ini), this will create a file elev.in. Copy elev.in to $FGDATA/Nasal/
:* tools.py will tell you to hide a certain scenery/Objects/... folder, to prevent probing elevation on top of existing objects. Simply rename the folder
:* run FG, open debug->nasal console, enter: elev.get_elevation(), press execute. Might take a long time, depending on the area scanned. This will write elevation data to /tmp/elev.out (which is actually just plain 5 column data: lon,lat,x,y,elevation). Put elev.out into LOWI/
:* unhide, rename the objects folder

* ELEV_MODE = Telnet
:* Run setup.py
:* Start FG with the properties service on Port 5501
:* Run tools.py, this will create a elev.in, start the nasal script and copy the elev.out back to your project directory

=== Run osm2city ===
* run osm2city.py -f LOWI/prams.ini. Parsing OSM data <del>again takes quite looong (10 minutes or more for 50k buildings)</del> is now pretty fast, but the result is cached to file buildings.pkl. Next startup will be <del>much faster if you move buildings.pkl to LOWI/buildings.pkl and</del> even faster if you set USE_PKL = 1.

If all goes well, files like LOWIcity0101.ac and their corresponding .xml, along with .stg files, were created and moved to the correct location in $FG_SCENERY
* copy or link the tex/ folder into the objects folder where these files were created

=== Roads ===
* run roads.py in the same fashion for roads
* <del>copy roads.eff to the same Objects\e0XXnXX\e0XXnXX\ directory</del> roads.eff is copied automatically
* Band-aid fix for the roads is to adjust their height in roads.py change AGL_ofs to a higher number e.g. 0.5

== Improve frame rate ==
* adjust LOD ranges in FG
* decrease MAX_OBJECTS, increase LOD_*
(- use larger/smaller tiles? Tradeoff between distance calculations/xml parsing and GPU)

== Contributing ==
You know some python? Or you're keen on writing docs? Or just want to use osm2city, but got stuck somewhere? Contact radi on the FG forum.
None of the above? Take [[Howto:Create_textures_from_photos|pictures]] of buildings where you live and [[Osm2city.py Textures|create textures]]! I'm especially interested in south-east asian style architecture, as I'm planning to populate Hong Kong Kai Tak (VHXX) in the future.

== Related ==
* [[Using OSM Vector Data in FlightGear]]
* [[OpenStreetMap buildings]]
* [[AutoGen Scenery for FlightGear]]
* [[Random Buildings]]
* [http://forum.flightgear.org/viewtopic.php?f=5&t=21131#p192198 OSM buidings EHLE]
* [http://forum.flightgear.org/viewtopic.php?f=5&t=22809 osm2city.py development]
* [http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg40092.html Osm2city.py]
* http://forum.flightgear.org/viewtopic.php?f=5&t=19625
* [http://forum.flightgear.org/viewtopic.php?f=38&t=8837 PixelCity]
* [http://forum.flightgear.org/viewtopic.php?p=166794#p166681 Procedural OSM buildings]

[[Category:Scenery software]]