Building Assessments blueprint initially based on requirements for the February 2011 Christchurch earthquake.

References

This application is designed to implement the Building Safety Evaluation in a State of Emergency: Guidelines for Territorial Authorities. These guidelines were produced by the New Zealand Society for Earthquake Engineering, and were based on the US Applied Technology Councils ATC-20 assessment process.

• ​http://db.nzsee.org.nz/Publications.xml - see the section titled Bulding Safety Evaluation.

Note that the forms contained on the NZSEE webpage are outdated, as newer draft updated forms (that had yet to be published) were used for both the 4 SEP 2010 Canterbury, and 22 FEB 2011 Christchurch earthquakes. The forms that should be used, in addition to the updated guidelines, are contained below:

• ​http://www.kestrel.co.nz/files/NZSEE-BSE-201008-update.zip

Capabilities

This is a list of desired capabilities, and some notes about why they are required and how they are intended to work. Approximate priorities are outlined (1 being highest), as well as idealised timelines for implementation.

• (1/immediate) Triage Data Entry Form - the complete forms (both Level 1 and 2) contain a lot of data and fields. Not all of this information is needed to be entered straight away. The intent is that initial entry of prioritised fields will be made, with later fields to be completed as more time/data operators become available. Priority fields are:
  • Date+Time
  • Building Name (+any aka)
  • Address
  • Contact Name+Phone
  • Status
  • Further Actions (Barricade, Assessment (Geotechnical/Structural))
  • Estimated Damage (%)
    • DONE (FPB)

• (1/immediate) Normalise Inspector Name/Mobile - would be good to have a picker for Inspector Name+Mobile in the form entry to ensure we minimise dupes of their assessments.
  • Status: We have a Picker for Inspector Name, Mobile is put into the RHeader automatically, where available

• (1/immediate) Generate Unique ID - Forms won't come with a unique ID, and it will be essential when triaging the form, form the system to generate a unique ID that can be written on the form, so that when the form is entered in full, or perhaps scanned versions uploaded, that we can link back to the correct initial assessment.

• (1/immediate) Turk Geocoding of Addresses - initially no lat/long will be provided of the building assessed. It would be great to have a simple form interface that serves up an address+building name from the database, and allows a (remote) user to use Google Maps to search the address and add latitude/longitude to the address to enable mapping. This can be done without providing access to any data other than the name of the building and the address. Note that this ideally needs to be a manual process as quite a few addresses will be ambiguous, and we may require some people with local knowledge to properly geocode them. This is essential to have immediate mapping of assessments - following SEP 4 it took 4-5 days to map, it will be a big win if we can do this near instantaneously (e.g. as soon as someone geocodes a submitted address).
  • Basic interface DONE (FPB): ​http://nz.sahanafoundation.org/eden/gis/geocode_manual
    • Need clarity on ACL

• (1/immediate) Map Geocoded Addresses - it is critical that we able able to map all geocoded assessments basically as they are entered. The real value in this system will be in the near realtime mapping (assessment will show on map once triage form entered and geocoded).
  • DONE (FPB) - Feature Layer added to Map (ACL-locked to authenticated users)

• (1/immediate) Stats Reporting - we had a lot of requests for information about number of assessments undertaken, growth over time etc, and this will happen again. We would like a couple of key reports to be able to point public information officers and media to:
  • A report providing assessment totals, and breakdown by assessment type and status (e.g. Level 1 (red, yellow, green) Level 2 (R1-R3, Y1-Y2, G1-G2)).
    • Simple L1 Report DONE (FPB)
  • An hourly record of assessments - to provide a quick report of growth over time. My thought here is that an hourly cron job or similar would be run at the top of the hour that polls the number of assessments of each class, and records these in a table. The report would then present these so we can show activity over time. Highest priority is a table, graphs would be a bonus.

• (2/24-36 hours) Full Data Entry Form - complete form as outlined in the documents.

• (2/few days) Turk Council Identifiers - we need at least two council identifiers to enable Christchurch City Council to link the data we're collecting back to their business-as-usual information systems. Ideally want to support adding of n unique identifiers. Currently, there are two valuable identifiers we will need to link to. I may need to clarify what their ideal names are for export via CSV and the like. It would be good to have a simple turking process as above that pops up an address, and asks user to enter these IDs. These will be done be people here in Christchurch that have access to the councils mapping system to look up these IDs. This won't be a publis process, but will be similar to Turk Geocoding of Addresses.
  • 'prupi' - this is a reference to the property in the council system
  • 'gisratingid' - this is a reference to a polygon of the rating unit
    • Status: Fields added (FPB). No Task-Turking interface yet

• (2/week) Map Thousands of Points - Within a few days we are likely to have a thousand of assessment points. I'm not sure if the current map renderer is capable of scaling to rendering thousands of points in a browser (I know this has been an issue with some mapping libraries in the past). One approach I've seen in the past is to use a Flash map viewer that can happily scale to render thousands of points. We will probably get to a thousand assessments in 2-3 days (we start in about 12 hours time) and it is very important that we can scale to efficiently render thousands of points.
  • Shouldn't be an issue as we have the Cluster Strategy enabled (FPB)

• (2/days) Print Assessment Forms - It would be good to be able to generate forms from the application. Ideally, it would be possible to have addresses (and if we had them prupi's/gisratingid's) preprinted on forms. This would be nice to have, but is lower priority that a number of the above capabilities. For a bonus gold star, being able to draw a polygon, and have forms printed out for all entries in the polygon would be wickedly useful. We often assign assessments by block.

Considerations

• System may need to scale to potentially handle 100k assessment records after 1 month.
  • This shouldn't be an issue.

Security

• All assessment information should be protected to registered and admin-approved users. We will probably look at providing some public information from this site over time, but initially it needs to be closed and protected.
  • DONE (FPB)

Clarifications

• Currently all Buildings are set to be within Christchurch L1.
  • Do we want the list of L2s to be available as a dropdown? (list imported from Wikipedia, but only a couple have Lat/Lon currently)
• Is the Postcode field useful?
• Will the Geocoding be done by anonymous users?
• How many concurrent users are expected?