BluePrint for supporting multiple regions or incidents in one server

Motivation

Regions

Humanity Road works on events in more than one area, each with different GIS characteristics. For instance, in one area, a complete GIS hierarchy may be available, and we can associate individual locations with the hierarchy location they fall in. In another case, we may not have hierarchy data other than the country, but perhaps we can designate a general area by a bounding polygon, or by radius around a point.

A person using the site would like to quickly select which region they're working on, and have the map centered on that spot, and search results and drop-down selectors filtered for that region or incident. Selecting a region to work on should not interfere with the site's overall GIS configuration, nor the user's own personal configuration.

Incidents

An "incident" is a more fine-grained concept, involving not just location but also time and assigned personnel and resources. Don Cameron points out the importance of being able to specify an incident and identify what's associated with it, in order to implement an ICS (incident command system).

Incidents can overlap in time, region, personnel, and resources.

Common features

Regions and incidents touch on each other in several ways:

The user will want a way to select which they're working on at the moment.

The definition of a region or incident should be shared among (appropriate) users. That is, a site admin should be able to configure a region or incident.

And incident will probably need a region as part of its specification.

Region proposal

(Note this part is being implemented as we speak. Its design is not expected to be controversial. It does not break or alter any existing functionality.)

In order to support configuring and selecting regions:

• Move any region-specific configuration into gis_config. This currently means:
  • A location representing a region (see below).
  • The hierarchy labels, depth, and settings appropriate for that area. (Language translation is not sufficient here. E.g we don't have "provinces" and "districts" in the US but those are perfectly legal US English words. Different areas also have different depths of hierarchy, and different choices about a "strict" hierarchy.) Hierarchy settings are:
    • "Strict" -- specific locations can only be attached to the hierarchy at its maximum level.
    • "Parent required" -- specific locations need a parent location selected from the hierarchy. (This is used to assist forming regions in the absence of boundary data -- see below.)
  • A flag for whether this gis_config represents a region.
  • A label to use on a menu of regions.
  • Already present in gis_config, and needed for region selection:
    • Map center and zoom (so map can be positioned appropriately for the region).
• Generate a regions menu from the gis_config table. Add site config options to enable the regions menu and specify a label for the menu head.
• The selected region persists for the session only (or until the user selects another or clears the selection).
  • Selecting a region records the associated gis_config in the session.
  • To find the gis_config currently in effect look for it in these places in this order:
    • In the session.
    • The user's personal gis_config.
    • The generic gis_config.
• Filter entities that have locations by region.
  • Filter drop-down menus and other selectors.
  • Filter search results.
  • Filter lists.
  • Perhaps provide an option to view all entities? (This isn't necessary as one can deselect the region but might be convenient if one wants to find nearby entities.)

The "region location" associates specific locations to the region. There are four main ways a region location can specify this association:

• The region location can be in the hierarchy, and specific locations can have the region location as an ancestor. (E.g. the region might be a city.) Turning on the "parent required" flag means selecting a parent is mandatory, which would be appropriate in this case.
• The region location can contain a boundary polygon. Specific locations with point or polygon data can be tested for overlapping the region polygon.
• The region can specify a point and a radius. Specific locations with point or polygon data can be tested for overlapping this circle.
• The region location can be a "location group" (a list of locations that are each appropriate as region locations). (For instance, the region might consist of several counties in a state.) A specific location is tested against each of the locations in the group. (This would allow recursion, if we permit a location group to be a member of a location group. That's not required, though.)

Incident discussion

This is open for ideas -- please add suggestions here.

An incident involves:

• Personnel
  • Teams
  • Projects / work assignments
• Material resources
  • Vehicles assigned
  • Inventory allocated
• Associated entities
  • Hospitals
  • Shelters
  • Other orgs involved
  • Assessments
• Information (e.g. work logs, instructions)

Use an org

Fran considered creating an org for each incident, as it has fields and components that would be appropriate, but says that may not be sufficient. Probably need at least a region in addition.

Use relationship tables

Many types of things are associated with an incident. The "relational" way to do this, without adding fields to entities, is to add relationship tables that associate an incident with each of the types. That is, there would be an "incident assessments" table that says which assessments go with which incident, and so-on for the other associated types. This allows overlap. When an entity is no longer needed for an incident, it's relationship can be deleted or "expired" by setting an end date.

(If a "paper trail" is needed, i.e. a record of what was used for each incident, there are several ways of providing that. One is to add start and end dates to the relationship. Since those could clutter the table, one could dump / pickle historical data, or move them to a parallel set of "expired" relationship tables. Keeping it online would be more convenient for preparing reports. Simplest is to leave them in the main incident relationship tables but set their end dates.)