wiki:BluePrintBuildingInformationSystem

Version 37 (modified by jero321, 11 years ago) ( diff )

--

Table of Contents

  1. Concept
  2. Linked Information
  3. Users
  4. Project Management
  5. Description
  6. Requirements
  7. Use-Cases
  8. Design
  9. Implementation
  10. References
  11. Notes
      1. Wireframe (ported to eden)

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.

Project Management

Description

User story:

  • A an emergency response agency learns of an imminent disaster say a Tsunami, and the following are the steps they take up:
  • In Eden's CAP interface the operator chooses the CAP Profile for their region
  • He then chooses a CAP Template specific for Tsunami
  • He then edits the blanked out fields in the template (for example, area description, severity) and also sets a few flags (these are provided as per the CAP 1.2 specification)
  • He will then optionally attach files (eg. containing pre-decided evacuation instructions etc) and also add a few more language templates and edit them
  • He then sends the CAP Alert as a "Public" alert which everyone subscribed or added in the contacts is notified about
  • Since CAP is an XML standard it can be easily picked up by automated systems and required actions maybe performed (eg. Sirens)

Sahana Agasti has a CAP broker implementation

Requirements

  • Functional:
    • CAP Profiles and CAP Templates: Data model and user interface assisting easy and correct implementation of CAP profiles and create/edit of CAP templates
    • CAP Editing: Data model and user interface for creation of CAP alerts compliant with the EDXL-CAP 1.2 standard.(see this ticket on templates)
    • CAP subscriber: data model and GUIs to manage intended users and groups when disseminating alerts via SMS and Email. (we can use s3msg module here)
  • Interoperability:
    • CAP Broadcasting: Use XSL and XSLT to generate text suitable for distribution. Generate broadcast events, broadcast media can be added by hooking up to these events generated in the system: tap in to s3msg module
    • CAP Reception: Expose a PuSH end point and allow Eden instances to subscribe to each other. Handling cancellation and update alerts gracefully.
    • Import and Export facility for CAP and CAP Profiles: Enable importing of CAP Alerts from XML files with CAP Alert elements. Allow Exporting. Use the Survey module as a reference here. Also these should be implemented inside the s3export module.

Use-Cases

Actor Use-case Description
CAP profile implementer Implement CAP profile CAP Profile defines a class of CAP alerts which may provide a structure to the CAP alert and speed up the creation of CAP Alerts and templates, for example a Profile may specify a region, a set of languages and generic templates in each language. This can be used during CAP alert creation for centering the map for example and for fast creation of alert messages
CAP template implementer Implements CAP templates CAP templates are Abstract CAP alerts with blanks that need to can be filled really fast in case of an imminent disaster to produce a CAP alert, for example a Tsunami CAP template might be of help in a coastal area, hence an implementer will create the same
CAP message editor Send a CAP alert a message editor can pick a CAP template and fill the blanks in it to send out a CAP alert (user story in description)
CAP alert subscriber Subscribes to CAP Alerts when a CAP alert is created and the subscriber is in the audience, a notification will be issued via modes prescribed by the subscriber

Design

  • The Models: The table definitions go are in modules/s3db/cap.py. Place some functions which will help in the creation, sending and receiving of CAP XML files in s3msg module where it might best fit.
  • The GUI
    • index: A map and a table of alerts sortable by the various fields of an alert. Clicking on a row on the table centers the map to the <Area> associated with the alert.
    • profiles:
      • index: View a listing of templates (We should ship some country-specific profiles by default in Eden since this is recommended)
      • edit & create: Editing / creating a profile. This should allow for specification of constraints for each field of the cap message.
    • templates:
      • index: View a listing of all templates grouped by their pertinent profiles.
      • edit & create: Allow users to create templates: This will allow for creating multiple <info> elements with placeholders for canned inputs such as [AREA] [SEVERITY] etc.which will then be substituted to produce text consumable via various media like SMS and IVR
    • create alert: A map with ability for easy input of polygons and circles, A drop-down for picking profiles and templates to use. A way to specify recipients for restricted alerts.
    • Reference and mockups: http://eden.sahanafoundation.org/ticket/1026

Implementation

References

Notes

Common Alerting Protocol:

Originating CAP alerts is one need, receiving them and using them to actuate alerting systems, be they SMS drivers or sirens or whatever is another. Another is a message broker that can interoperate with the commercial boxes. Authentication systems are also a factor, especially where cross-jurisdictional reciprocity is required

Ideally the CAP XML should be signed end-to-end, especially in a federated system where there's more than one authority running servers/aggregators. Our current implementations sign the alerts at the originating server, so they're at least traceable to the source server but not necessarily the individual operator. Current servers check integrity when they get a message from another server, but there isn't a regional PKI.

Wireframe (ported to eden)

  • The wireframe built using Python and Eden frameworks.​ The code is here. Anyone can use this as the basis to continue the CAP Broker developments.
  • This ticket contains some of the screen shots and initial GUI layouts with some descriptions.

BluePrints

Note: See TracWiki for help on using the wiki.