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

Locations Hierarchy

• L0 = New Zealand (hard-coded)
• L1 = Canterbury District (not a District, should just just be Canterbury)
• L2 = Christchurch City Council
• L3 = Locality (Same as Wikipedia suburbs? These are currently loaded - only the 1st 2 in WP have had their Lat/Lons copied across) GT - not sure yet what the best approach to L3 will be. Waiting on getting date from Council to see what their localities are (pretty similar to suburbs I believe).

Workflow

• All buildings will first undergo a Triage report (mandatory fields only).
• Many buildings will have a Level 1 initially (external assessment) followed by a Level 2 (internal, structural), and may have multiple L1 or L2 over time.
  • e.g. if there is another significant earthquake, the whole process will be restarted.

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: Authentication requires Email Confirmation & Approval. Buildings data also requires the Buildings role. (FPB)
    • Normal Authenticated users can only do the Geocoding task.

ToDo

1. Improve the Usability of the main frontpage & the module homepage: ​http://nz.sahanafoundation.org/eden/building
2. Improve the Usability of the Geocoding application which will we'll put out a call for help on: ​http://nz.sahanafoundation.org/eden/gis/geocode_manual
   • add help text
   • hook into Google Geocoder (e.g. using the geocoder() function in controllers/gis.py)
3. Unique identifier visible on forms (Dominic?)
4. Provide the historic reports scheduled task
   • 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.

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 - The ATC-20 Rapid form has a simple 'triage' checkbox to hide all optional fields (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 (see Clarifications below)
    • Could use some online help on the page

• (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 to/modified in Location (FPB). Task-Turking interface not complete 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.
  • The map-panning performance shouldn't be an issue as we have the Cluster Strategy enabled (FPB)
  • However we need to move away from the current model of writing the Features into the webpage as this will make the initial map download too large. I have already started work on replacing this with a dynamic download of features using GeoJSON which can make use of the BBOX Strategy to minimise downloads...I will progress this. (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.
  • Status: Form is printable in a near OCR-compliant way, although currently these forms won't be OCRable (fix by Monday? Fix will only work with new forms, not ones printed today) (FPB)
  • To be able to pre-print forms, we'd need a dump of that database available to load. If we get this database then we can take a look at being able to do this. Map-based selection of records is on the roadmap, but is unlikely to get done within the timeframe for this response, I'm afraid. (FPB)

Considerations

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

• How many concurrent users are expected?
  • Hard to know at this point. May be just a few to start with, but could scale to a 20-40 over time. But as we scale, more of these will be spending more time entering data e.g. as numbers increase, load on system won't increase in proportion, as it will take longer for users to enter full forms.

Clarifications/Questions

• Is the Postcode field useful?
  • Yes. We may not use it straight away, but it could be useful.

Feedback

This is additional feedback based on testing with real data entry.

• ​http://nz.sahanafoundation.org/eden/building/index
  • 'Create New Level 1' - should be 'Submit new Level 1 assessment (full form)'
  • 'Create New Triage' - should be 'Submit new Level 1 assessment (triage)' and show appear above the full form. Initial emphasis will be strongly on submitting the forms as triage e.g. just entering the essential information.

• ​http://nz.sahanafoundation.org/eden/building/nzseel1/create?triage=1
  • Inspection Time - must allow time (24hr) to be entered e.g. 11:35 or 1135 or 1524 or NULL (hopefully not too many of those).
  • Time and Date - is it possible to have these on the same line to save vertical space?
  • Location - is there any way this can be rendered as more of a breadcrumb trail on the same line? It would make more sense to have something like Canterbury > Christchurch City Council > 'selection'.
  • If there are any Local Levels that have only 1 entry, then these should be selected by default, and the first Location hierarchy level with options should be selected. E.g. as Canterbury and Christchurch City Council are the only options, the Location hierarchy should automatically default to selecting suburbs.
  • Location - 'District' should be 'Region'. 'City Council' should be 'Local Authority'. Locality is fine :)

• Label and tickbox formatting is not intuitive for the 'further action recommended' section