Visualize the anatomy of an incident

[hannahkane]

For example, illustrate the comings and goings of the various responders to the gas explosion on NW 23rd on October 19th (incident _id = 1281359)

@matthino's suggestion: could use this to educate users about the various definitions and nuances of "response time"

[qingdatascience]

I will try to compute some metrics related to this incident.

[BrianHGrant]

Based on this document:

https://docs.google.com/document/d/1HI9nmg3PAHEtctEtipIVkCF7W185helYNW7cglsO0pk/edit#

I have begun to look at what we would need to accomplish the related Card #1 Bagel Shop Incident from an API stand point, and have come up with a few user stories:

1. A user will want to be able to query the api for all the data about a given incident using a specified characteristic (incident_id?)

2. A user will want to retrieve all the incident data in as few queries as possible ie one single incident/info endpoint will retrieve incident data, incident times data, and responder info in single query as oppose to 3 or more separate queries

3. A user will want to retrieve the response time of the incident calculated based on realtime of the initial call received vs. realtime of the first on_scene entry.

4. A user may also want more information about the responder unit types.

Based on these user stories I have created an incident/info/ endpoint and view set:

endpoint: get('/incident/info/?=incident_id=') for example, the bagelshop incident: get('/incident/info/?=incident_id=1281359')

this will then return a response formatted as

response: { "data": [ { "incident_id": 1281359, "responderunit": 122, "deptrespond_id": 13, "runnumber": "RP160078324", "incdate": "2016-10-19", "typenaturecode": 74, "foundsituation": 63, "incsitfoundprm": 111, "alarmlevel": 5, "callreceived_id": 1, "censustract": "4700", "fmarespcomp": "03", "career": 132, "engresp": 19, "aaresp": 7, "medresp": 13, "othervehiclesresp": 28, "firstonscene": "T3", "quad": "NW", "streettype": "AV", "streetname": "23RD", "quad2": null, "streetname2": "", "streettype2": null, "city": "PORTLAND", "state": "OR", "zip": "97210 ", "neighborassoc": "NWEST", "fireblock": "0360" } ], 'incident_times': [ (incident times that match incident id, ordered by realtime, earliest first) { "inctimes_id": 20573551, "timedesc": 0, "responder_id": null, "realtime": "2016-10-19T09:07:06" }, { "inctimes_id": 20573552, "timedesc": 1, "responder_id": null, "realtime": "2016-10-19T09:07:19" },... ], 'responders': [ (responders that match incident id) { "responder_id": 1, "responderunit": 7, "codetosc": 3 }, { "responder_id": 2, "responderunit": 8, "codetosc": 3 },... ], "response_time": 280.0, this calculation is in seconds based on: a = realtime of incident_time matching timedesc of 0 (received) b = realtime of first incident_time matching timedesc of 5 (on scene), ordered by realtime (b-a).total_seconds }

I believe this would fulfill user requirements for stories 1,2,3

So questions I would have to move forward/complete on the api side:

1. To get further information about responder units a user can query the responderunit table to retrieve information about the responder units, as there are some issues with the use of composite keys in django and the size of the incident object, it feels correct to separate out this concern into its own endpoint. Looking for feedback on whether this would be acceptable?

2. Are there further user stories to fulfill for this card?

3. Any existing data that would need to be added to the endpoint?

4. If we are wanting to focus on a specific incident such as the bagel shop do we want a specific endpoint for the incident ie: 'incident/bagelshop' that will have the incident id hardcoded in, or is it easy enough to just pass on the incident id to the front end devs and use generic endpoint?

5. Do we want to build out the serializer for incidents to return the descriptions for things like: 'typenaturecode', 'foundsituation', 'incsitfoundprm', that have foreign key, and maybe more human friendly responses like the description, so would be a single query to get info or do we want to return just the primary key, and have user query the other tables for more info (Really I assume this is going to be the first of the two, would be easier. Probably where I will start next).

Anyway over the course of the next week, the API team will continue to look at the cards/user stories to sink up and see whats possible, as we move towards an mvp and deployed api, will open issues for each of the cards if not already.

[futurechris]

Good work, Brian.

I think it's still unclear whether the card in question would actively pull data or just reference a static table of some sort, but either way these endpoints will likely be valuable for other cards and exploration.

We should discuss the questions during a meeting, but a quick rundown of my opinions on them:

1. I think a separate endpoint works fine. The API hasn't grown to a monstrous number of endpoints yet, so I think it's OK to add separate ones where the cost of merging functionality into existing endpoints seems excessive. That seems to be the case here.

2. Most of this card, I think, is about separating out exactly what happens when, so there may be some stories there. This might be related to the previous question's answer - perhaps we want . Would have to wait for folks working on it to really turn up what needs they have.

3. Ditto to (2), will need to see what the product demands as it gets developed.

4. We may ultimately want a bagelshop endpoint, if we end up creating pre-computed data for the incident. For actual querying, I think it's fine to stick to passing an incident id to a generic endpoint.

5. I think we agree - a single query would be great. The normalization of the table isn't important from an end-user perspective, and should be transparent to them.

We'll have to talk more on this at the next meeting.

[qingdatascience]

I updated the bagelshop notebook. Basically, I just displayed the responders list. Unfortunately, I did not find any descriptive description in the database. They are just bunch of codes, I don't know what they really means. Bagelshop incident is not anything that is typical, the mean/median response time is longer than usual. So I went ahead to calculate the mean/median response time for other incidents happened in the very day. They look pretty "usual". This just manifests how do we calculate mean/median response time.

[futurechris]

When you calculated mean/median response times for the bagel shop incident, were you calculating it over all responders, or per-responder? (I forget how much information we have about when someone is dispatched and when they arrive...)

I'm thinking that overall response times may have been long because:

• responders had to come from further away
• the incident changed, and changed in severity as it progressed (so units weren't even being dispatched until it was well underway)
• Perhaps there just weren't enough people even on-duty at that time. Mornings tend to not have a lot of incidents, so they may not have been fully staffed. Thus, you have to call people who are off-duty and have them get ready and come in to the station before being dispatched. (This is common for small, rural fire departments, but uncommon for PF&D.)

Any or all of those, or something else entirely, could have bumped up the times.

[qingdatascience]

The mean/median response times for the bagel shop incident were calculated over all responders. The mean/median response time is longer is due to the fact that there were many other type of activities related to this incident, such as investigators, ..., and they were all counted as responders. I discussed this problem in the notebook, and I also calculated the mean/median response time for other incidents happened in the same day, and they are in the normal range.