| Version 25 (modified by , 11 years ago) ( diff ) |
|---|
Table of Contents
Overview
This blueprint is based on the need to manage multiple types of information about buildings pre- and post-event. This blueprint is based largely on Gavin Treadgold's experiences with post-earthquake building damage assessment following the Canterbury Earthquake Sequence that started on 4 September 2010, and included the 22 February 2011 aftershock that killed 185 people, as well as the June 13 2011 aftershock that caused considerable more damage to the built environment.
Concept
The broad concept of the Building Information System is to provide an overview page for each building. The page will contain a header with key information about the building e.g. name, current status, type of construction, number of floors, type of occupany, primary contact, a small embedded map, and a small embedded photo to set the context.
The rest of the page would be similar to a blog, or social media wall, whereby there a log entries with the newest at the top. These log entries can conceivably be quite diverse forms of information. Early on in response, it may be as simple as adding a note e.g. media reports that a building has partially collapsed, later followed by photos, and eventually by various and multiple forms of building assessment. Each building would require various forms of media to be uploaded ranging from photos (some geotagged) to documents (e.g. scanned pdfs of survey forms, and engineering firm technical reports).
The concept is meant to be fairly similar to Facebook, but the focus is on buildings - effectively creating a wall or page for each building, and allowing all the relevant people and organisations to follow that particular building.
Linked Information
As mentioned, there are a wide variety of information that will be added and linked to a building's record over time.
- Notes - e.g. phone or news reports recorded as a simple text note.
- Photos - from publicly submitted photos soon after the event to potentially hundreds as first rescue teams, and later engineers and building inspectors visit.
- Documents - such as plans converted to pdf, or reports, or correspondence in a word processing format.
- Assessments - a building will potentially undergo a number of assessments over time (e.g. in Christchurch many buildings had to be reassessed after every m5.0 eathquake which meant 20+ assessments). This will include different types of assessments - some of which will be implemented as assessments in Eden.
- Status Changes - some of the key information, such as the building state, needs every state change to be recorded. E.g. when a building was marked as 'yellow/restricted access', and when this was later changed to 'red/no access', or 'green/no restriction on access'. These state changes, that are usually triggered by an assessment, need to be recorded.
It isn't the responsibility for the BIS module to provide all the tools, but rather to integrate and produce an overview from information contained in other Eden applications. Assessment, for example, will be links to the actual assessments in the Assessment application
Users
The primary user will be the local authority that has the regulatory authority to manage the built environment e.g. a local council. Secondary users will include, but not be limited to the building owner, the building manager, the tenants, and the insurers. All of these users will potentially need access to multiple buildings in the system. If the BIS is publicly deployed, then many of these individuals and organisations will need the ability to self-register, and start linking themselves to buildings in the database e.g. an engineering firm may register, and then identify all the buildings that they are acting as the engineer for. It would be the building owners responsibility to approve their request to be 'added' to the building.
It should be possible for some information to be publicly accessible, as some information such as photos and status may be used to communicate building information to the public.
