Incident Reporting

Allow the public to report Incidents, with associated locations on the map.

Optionally, provide the ability for admin to approve the Reports.

Usability Suggestion for IRS.doc

• All points for this document have been actioned, except:
• "Put a “search” button after the search column" for irs/report. This might not be required as the search will happen automatically on key-press and this will involve going into DataTables API.

Simplified Categories

• #508

Currently db.irs_ireport.category uses a dict of categories from the Candian ems.incident. name space (defined in models/irs.py):

irs_incident_type_opts = {
    1:T("animalHealth.animalDieOff"),
    2:T("animalHealth.animalFeed"),
    3:T("aviation.aircraftCrash"),
    4:T("aviation.aircraftHijacking"),
    5:T("aviation.airportClosure"),
    6:T("aviation.airspaceClosure"),
    7:T("aviation.noticeToAirmen"),
    8:T("aviation.spaceDebris"),
    9:T("civil.demonstrations"),
    10:T("civil.dignitaryVisit"),
    11:T("civil.displacedPopulations"),
    12:T("civil.emergency"),
    13:T("civil.looting"),
    14:T("civil.publicEvent"),
    15:T("civil.riot"),
    16:T("civil.volunteerRequest"),
    17:T("crime.bomb"),
    18:T("crime.bombExplosion"),
    19:T("crime.bombThreat"),
    20:T("crime.dangerousPerson"),
    21:T("crime.drugs"),
    22:T("crime.homeCrime"),
    23:T("crime.illegalImmigrant"),
    24:T("crime.industrialCrime"),
    25:T("crime.poisoning"),
    26:T("crime.retailCrime"),
    27:T("crime.shooting"),
    28:T("crime.stowaway"),
    29:T("crime.terrorism"),
    30:T("crime.vehicleCrime"),
    31:T("fire.forestFire"),
    32:T("fire.hotSpot"),
    33:T("fire.industryFire"),
    34:T("fire.smoke"),
    35:T("fire.urbanFire"),
    36:T("fire.wildFire"),
    37:T("flood.damOverflow"),
    38:T("flood.flashFlood"),
    39:T("flood.highWater"),
    40:T("flood.overlandFlowFlood"),
    41:T("flood.tsunami"),
    42:T("geophysical.avalanche"),
    43:T("geophysical.earthquake"),
    44:T("geophysical.lahar"),
    45:T("geophysical.landslide"),
    46:T("geophysical.magneticStorm"),
    47:T("geophysical.meteorite"),
    48:T("geophysical.pyroclasticFlow"),
    49:T("geophysical.pyroclasticSurge"),
    50:T("geophysical.volcanicAshCloud"),
    51:T("geophysical.volcanicEvent"),
    52:T("hazardousMaterial.biologicalHazard"),
    53:T("hazardousMaterial.chemicalHazard"),
    54:T("hazardousMaterial.explosiveHazard"),
    55:T("hazardousMaterial.fallingObjectHazard"),
    56:T("hazardousMaterial.infectiousDisease"),
    57:T("hazardousMaterial.poisonousGas"),
    58:T("hazardousMaterial.radiologicalHazard"),
    59:T("health.infectiousDisease"),
    60:T("health.infestation"),
    61:T("ice.iceberg"),
    62:T("ice.icePressure"),
    63:T("ice.rapidCloseLead"),
    64:T("ice.specialIce"),
    65:T("marine.marineSecurity"),
    66:T("marine.nauticalAccident"),
    67:T("marine.nauticalHijacking"),
    68:T("marine.portClosure"),
    69:T("marine.specialMarine"),
    70:T("meteorological.blizzard"),
    71:T("meteorological.blowingSnow"),
    72:T("meteorological.drought"),
    73:T("meteorological.dustStorm"),
    74:T("meteorological.fog"),
    75:T("meteorological.freezingDrizzle"),
    76:T("meteorological.freezingRain"),
    77:T("meteorological.freezingSpray"),
    78:T("meteorological.hail"),
    79:T("meteorological.hurricane"),
    80:T("meteorological.rainFall"),
    81:T("meteorological.snowFall"),
    82:T("meteorological.snowSquall"),
    83:T("meteorological.squall"),
    84:T("meteorological.stormSurge"),
    85:T("meteorological.thunderstorm"),
    86:T("meteorological.tornado"),
    87:T("meteorological.tropicalStorm"),
    88:T("meteorological.waterspout"),
    89:T("meteorological.winterStorm"),
    90:T("missingPerson.amberAlert"),
    91:T("missingPerson.missingVulnerablePerson"),
    92:T("missingPerson.silver"),
    93:T("publicService.emergencySupportFacility"),
    94:T("publicService.emergencySupportService"),
    95:T("publicService.schoolClosure"),
    96:T("publicService.schoolLockdown"),
    97:T("publicService.serviceOrFacility"),
    98:T("publicService.transit"),
    99:T("railway.railwayAccident"),
    100:T("railway.railwayHijacking"),
    101:T("roadway.bridgeClosure"),
    102:T("roadway.hazardousRoadConditions"),
    103:T("roadway.roadwayAccident"),
    104:T("roadway.roadwayClosure"),
    105:T("roadway.roadwayDelay"),
    106:T("roadway.roadwayHijacking"),
    107:T("roadway.roadwayUsageCondition"),
    108:T("roadway.trafficReport"),
    109:T("temperature.arcticOutflow"),
    110:T("temperature.coldWave"),
    111:T("temperature.flashFreeze"),
    112:T("temperature.frost"),
    113:T("temperature.heatAndHumidity"),
    114:T("temperature.heatWave"),
    115:T("temperature.windChill"),
    116:T("wind.galeWind"),
    117:T("wind.hurricaneForceWind"),
    118:T("wind.stormForceWind"),
    119:T("wind.strongWind")
}

We need a simplified version of these to be presented to users whilst keeping the full sets available for EM professionals ('Editors' in a simple use case). A mapping needs to be maintained between the different lists. We should have a (personalisable) configuration option to show which list to use (& hence which symbology set to display on the map).

The back-end should NOT be easily customised as otherwise it is hard to share data between instances.

Proposal

Change to something more like this (doesn't yet handle the mapping - needs work!):

irs_incident_type_opts = Storage (
    INTERNAL_FORMAT_1 ={
        simple: T("Broken Road"),
        canada: "roadway.roadwayClosure"
    },
    INTERNAL_FORMAT_2 = {
        simple: T("Broken Bridge"),
        canada: "roadway.bridgeClosure"
    },
)

A subclass of IS_IN_SET() is created to handle this data structure, providing access to full list to a role (default to 'Editor'), but the sub-set to normal users' dropdowns.

• Q: Should .represent also be modified for Display of records?

Proposal (nursix)

a) keep the original dict, but change the values of the dict into tuples like:

irs_incident_type_opts = {
        101: ("roadway.bridgeClosure", T("Broken Road")),
}

b) make the .represent towards normal users show the second item in the tuple rather than the first (easy tweak), while admin users may see both (the controller can switch between those two)

c) have a admin-only-accessible DB table irs_incident_type_opts with the options available for the "normal" user like:

define_table("irs_incident_type_opts",
             Field("code", "integer", requires=IS_IN_SET(irs_incident_type_opts)))

d) In the model, make .requires the normal IS_IN_SET (To allow Sync of records with any of the options):

.requires = IS_IN_SET(irs_incident_type_opts)

f) In the controller, if "normal" user, override this requires by:

allowed_options = [opt.code for opt in db().select(db.irs_incident_type_opts.code)]
.requires = IS_IN_SET(allowed_opts)

Proposal (keith, marr)

A config screen for admin/editor to map "simple category" to "canadian category". Assume that total number for simple category options is small and limited, say 6 for Taiwan's case. In IRS report adding screen, default menu using simple category, user can switch via radio-button to canadian category.

Note that if the category code options differ from instance to instance then you cannot exchange the incident reports anymore - therefore I suggested to keep the original options dictionary keys, and just add a second "user-friendly" category title (nursix)

Proposal (keith)

To define "Incident Category" isn't an easy work. The Candian ems.incident seems too detail for a large disaster management system. e.g. It should be "Transport/Railway" instead of "Railway/Hijacking" We might start from small to define our own incident categories to increasing user experience without missing the flexibility and accuracy.

The way to category is using preemptive way "number range":

    irs_incident_type_opts = {
        1:T("Natural Disaster"),
        2:T("Transport"),
        3:T("Collapse, Illness, Injury, Trapped"),
        4:T("Industrial"),
    }

    irs_incident_subtype_opts = {
        100:(1, T("Flood")),
        101:(1, T("Landslide")),
        200:(2, T("Roads Brodken")),
        201:(2, T("Bridges Broken ")),
        300:(3, T("Buildings Collapsed")),
        301:(3, T("People Trapped")),
        400:(4, T("Power Failures")),
    }

So ID 1~99 are major categories. ID 100~199 are under 1st Category "Nature Disaster". 200~299 are under "Transport".

If someone gonna create a new category, he *should* have a look at "THE NATIONAL STANDARD FOR INCIDENT RECORDING" ​http://rds.homeoffice.gov.uk/rds/pdfs08/countnsir08.pdf

TODO: There should be "Please refer to the link of 'Make a request' for the need of helps" in the page before creating a incident report.

It is what I can think of now to get most benefit for current usage and fine for future development.

For now the code will only show the sub categories.

If it's ok, the diff code is on ​http://bazaar.launchpad.net/~keitheis/sahana-eden/edentrunk/revision/1073

If we had much more time and the amount of categories went out of control, we can try the top-down way of selecting gis location. (I've tried and find it needs much more effort to make it work.)

Questions

Where there are hierarchies (such as roadway.roadwayClosure) provide a JS widget to split this into a hierarchical selector.

---

BluePrints