# A Spatio-Temporal Building Exposure Database and Information Life-Cycle Management Solution
## 6 Application Scenarios
### Scenario II: Real-World Changes and Object Life-Cycle  
In the second scenario, the building stock of a city is modelled in space and time throughout different phases of disaster risk management, from pre-event mitigation to post-event response and long-term recovery. Real world changes to the building stock (e.g., retrofit of buildings) and information updates (e.g., new information becomes available about existing buildings) are considered in the scenario. The GEM Building Taxonomy has been fully implemented into the database structure to characterize the building stock in a standardized and comparable way. Additional attributes relating to a building's structural vulnerability and damage grades were implemented based on the European Macro-seismic Scale 1998 (EMS-98) [31]. Data acquisition is simulated, exploiting different information sources at varying spatial resolution. The data that are used in this scenario have been imported from independent acquisition campaigns. The combination of building attributes and geometries does not represent the actual inventory of a real city but has been assembled to clearly exemplify several application scenarios of interest for risk management. The building footprints have been imported  
Figure 6: (**a**) Shows the integrated building inventory at release 3 (R3); (**b**) shows the database state at transaction time 2 after the update of Earth Observation (EO) geometries with geometries from OpenStreetMap (OSM). from OpenStreetMap (OSM) by selecting 500 buildings from a German city. The building attributes were extracted from a database of buildings that were inspected by structural engineers by using the Remote Rapid Visual Screening (RRVS) procedure described in [27]. Further attributes were derived from census data. Figure 7 depicts the timeline of events that are considered in the scenario. Both transaction (tt) and valid (vt) timelines are represented. At tt0, the database is populated with 500 building geometries from OSM and attribute values from RRVS at per-building resolution and with a zonation of the city from Earth Observation (EO) data at a neighborhood resolution. At tt1/vt0, a Rapid Visual Screening (RVS) survey [6] indicates 50 buildings that did not comply with the available building code and that were retrofitted to improve their seismic resistance. At tt2/vt1, another RVS survey highlights 20 buildings that were modified since the previous survey. The owners added an additional story to their house, which is not compliant with the existing building code for seismic resistant construction. At tt3, more information about the buildings becomes available from a newly released census report that, for the first time, includes information about the occupancy of buildings in the city. The information is used to update the database. At tt4/vt2, a major earthquake occurs in the region, which leads to structural failures and total collapses as well as a large number of damaged buildings in the city. As part of a first damage detection survey, only total collapses (125 buildings) are recorded and stored in the database. From a second damage survey, more information about the damage grades of 200 buildings relating to the same event (vt2) becomes available and is stored in the database at tt5. As response to the disaster, at tt6/vt3, 100 temporary shelters are constructed to host people who lost their homes as a consequence of the earthquake. As part of the long-term recovery, permanent housing starts and 95 new buildings are constructed at tt7/vt4. Finally, after all displaced people received support from the government and were able to settle down in permanent housing, the temporary shelters are removed at tt8/vt5. The information about the evolution of the recovery phase could be detected by change detection analysis of EO data and in-situ surveys, as is described in [44]. Figure 7: Transaction and valid timelines of the application scenario and overview of the events considered in the application scenario.