Analyzing Fire Department Response with PostGIS
This is a modal window.
Das Video konnte nicht geladen werden, da entweder ein Server- oder Netzwerkfehler auftrat oder das Format nicht unterstützt wird.
Formale Metadaten
Titel |
| |
Serientitel | ||
Anzahl der Teile | 183 | |
Autor | ||
Lizenz | CC-Namensnennung - keine kommerzielle Nutzung - Weitergabe unter gleichen Bedingungen 3.0 Deutschland: Sie dürfen das Werk bzw. den Inhalt zu jedem legalen und nicht-kommerziellen Zweck nutzen, verändern und in unveränderter oder veränderter Form vervielfältigen, verbreiten und öffentlich zugänglich machen, sofern Sie den Namen des Autors/Rechteinhabers in der von ihm festgelegten Weise nennen und das Werk bzw. diesen Inhalt auch in veränderter Form nur unter den Bedingungen dieser Lizenz weitergeben. | |
Identifikatoren | 10.5446/32145 (DOI) | |
Herausgeber | ||
Erscheinungsjahr | ||
Sprache | ||
Produzent | ||
Produktionsjahr | 2015 | |
Produktionsort | Seoul, South Korea |
Inhaltliche Metadaten
Fachgebiet | ||
Genre | ||
Abstract |
|
FOSS4G Seoul 2015118 / 183
7
8
47
53
54
65
73
74
79
82
84
92
102
103
105
124
126
127
130
141
142
143
156
161
162
170
176
178
181
183
00:00
Exogene VariableKrümmungsmaßDatenbankClientCASE <Informatik>ComputerNichtlinearer OperatorArbeit <Physik>Spezielle unitäre GruppeRandwertURLInformationPhysikalisches SystemSystemaufrufTypentheorieInzidenzalgebraQuick-SortGüte der AnpassungBitDatenbankExogene VariableLeistung <Physik>MultiplikationsoperatorCoxeter-GruppeDifferenteEreignishorizontCursorResultanteWorkstation <Musikinstrument>TabelleZahlenbereichDienst <Informatik>TouchscreenProzess <Informatik>ClientFlächeninhaltSelbst organisierendes SystemNotepad-ComputerOrdnung <Mathematik>Kontextbezogenes SystemArithmetisches MittelKrümmungsmaßGeradeWechselseitige InformationSpannweite <Stochastik>Varietät <Mathematik>ThumbnailRandwertPhysikalischer EffektKategorie <Mathematik>Mechanismus-Design-TheorieUmwandlungsenthalpieE-MailCASE <Informatik>Twitter <Softwareplattform>HilfesystemFortsetzung <Mathematik>Computeranimation
07:45
WarteschlangeDemoszene <Programmierung>Exogene VariableKraftLokales MinimumComputerRandwertWechselseitige InformationLie-GruppeStabWorkstation <Musikinstrument>MultiplikationsoperatorInzidenzalgebraWort <Informatik>ForcingSystemaufrufSystemprogrammStabMittelwertDemoszene <Programmierung>Workstation <Musikinstrument>InformationMAPDienst <Informatik>Ordnung <Mathematik>Response-ZeitNichtlinearer OperatorZahlenbereichDatenverarbeitungssystemMetrisches SystemWechselseitige InformationPhysikalisches SystemCADRechenschieberSchlüsselverwaltungProzess <Informatik>CASE <Informatik>CodierungSoundverarbeitungRoutingCodeGebäude <Mathematik>TypentheorieDifferenteService providerAnalysisHilfesystemGruppenoperationGeradeWeg <Topologie>Coxeter-GruppeGRASS <Programm>Exogene VariableLokales MinimumFrequenzDatenstrukturSchnelltasteNotepad-ComputerDialektComputeranimation
15:17
Exogene VariableKraftRechenwerkGammafunktionSignalprozessorHill-DifferentialgleichungDreizehnKonvexe HülleStatistikSoundverarbeitungWorkstation <Musikinstrument>ForcingMultiplikationsoperatorRechenwerkGesetz <Physik>InformationDemoszene <Programmierung>Treiber <Programm>ZeitstempelBitPhysikalisches SystemCASE <Informatik>TypentheorieRegulator <Mathematik>CADCodeDivergente ReiheCodierungPunktVollkommene InformationInzidenzalgebraARM <Computerarchitektur>GruppenoperationSystemaufrufZweiMereologieProgrammierumgebungDifferenteStatistikDienst <Informatik>Rechter WinkelVorzeichen <Mathematik>Quick-SortExogene VariableNichtlinearer OperatorTransportproblemProzess <Informatik>DatenbankPartikelsystemGrenzschichtablösungGoogolGeradeBildgebendes VerfahrenSelbst organisierendes SystemWechselseitige InformationSchnelltasteHyperbelverfahrenComputeranimation
22:50
Computeranimation
Transkript: Englisch(automatisch erzeugt)
00:13
Alright, good morning. So, as my partner just described, I would like to talk
00:21
to you a little bit about analyzing fire department responses with post-GIS spatial database. So I just want to acknowledge a little bit that originally this presentation was intended to be very technical, very highly detailed in what exact SQL commands we ran in post-GIS
00:41
to analyze these results and how we used database cursors to summarize the information, but after attending so many presentations this week on extremely highly detailed information where there was JavaScript examples on the screen and big tables of numbers and
01:01
such, I decided I was really just going to take a little bit different approach and just give it a bit more of an overview to really explain what we're doing and why we're doing this. So if you do want to learn more about the mechanics, the specific details of post-GIS and how we employed it to get some of these answers, I'm more than happy to discuss any of that with you today.
01:27
You can reach out to me via email, via Twitter, and I will tell you everything absolutely that I can. Just to put a little bit of this in context, I want to tell you a couple of things. In May of 2015, just earlier this year,
01:46
incident number 205-0047384 in the San Diego North County E911 dispatch system, there was a vegetation fire. It started out as a truck that caught on fire
02:01
and over the course of a day evolved into 100 acres of fire that were responded to by 17 different fire engines, 3 different fire departments, 13 support vehicles, and in the end caused over 18 million dollars worth of damage. In March of 2003, there was a medical emergency, 3 ambulances responded, there were 4 fatalities,
02:27
so a 3 ambulance medical emergency is a pretty significant medical emergency. So I tell you this, just again to put this in context to remind you that this isn't about data, this isn't about databases, it isn't even about technology. It's really about people's lives. It's about people's property,
02:50
it's about people's livelihood, and it's about a government's ability to protect its citizens. And of course, the technology is the means to an end to do this, but we should always keep in mind especially at events like this where it's a lot of technical stuff that we're not here to service
03:08
each other. We're here to provide this technology to those who need it to answer questions. So our clients are municipal fire departments,
03:21
largely in California but also in the eastern coast of the United States. It may become apparent to you that you do have to have a mustache in order to be a fire chief in the United States, so if that's a line of work that interests you, start now. A few key concepts that we just want to go over,
03:44
I'm sure some of these are very familiar to you in general, but I'd just like to touch on them. In the United States, the phone number we call to get emergency services, whether that be police, medical assistance, or fire, is 911 on the phone. And ultimately all those calls end up back at a
04:02
computer-aided dispatch system manned by someone like this who takes those calls, takes down the information in an incredibly rapid manner. It's probably one of the most cool-headed, collected people you could ever meet. And her job is to make sure the service that you need to get out of this
04:22
emergency comes as quickly as possible. Now these people deal with a variety of questions. People call in, their first response is,
04:43
she doesn't know how to respond. And she asks him, she says, is this your first son? Is this your firstborn? He says, no, I'm her husband. So this is maybe a little humorous, but again, the calls they get range
05:01
from this to the most extreme related to that example we gave at the beginning. So if you just take a minute, if you ever have a chance to come across an E-91 operator, give them a hug or at least give them a thumbs up. This guy, that's probably how his day ended. So computer-aided dispatch systems are pretty complex. They involve working with the power
05:28
company to make sure these systems are uninterrupted. It involves working with the phone companies to make sure these calls can get through, landlines, cell phone lines. Increasingly it involves, of course, GPS, auto location so they can find out where you are calling from.
05:45
And it involves getting this information in, connecting to the fire, police and medical emergency services, collating this information, sorting it out, arranging it in such a way that it can be used later by people. But to most of us, this is what exactly that sort of system looks like.
06:06
It's chaotic, it's incredibly valuable and immeasurably useful, but it's completely insane. And there really are only a handful of vendors, at least in the U.S., that provide computer-aided dispatch systems, particularly for E-911. So our job as Flat Rock Geographics is to
06:28
take that type of information and present it and produce things like this so that the fire chiefs, for example, can see in these three surrounding communities where are the hot spots, where do they receive most of the calls for most of the types of incidents most of the
06:44
time at different times of the year. Or producing travel time information. Stations one and three, the information kind of trying to be displayed there is the darker the lines, the longer it takes them to respond to calls in that area.
07:03
Another key concept is the notion of mutual aid. So mutual aid is an agreement among emergency responders to lend assistance across jurisdictional boundaries. So you help me, I'll help you. At any given time, a city's fire department resources may be stretched beyond their ability to provide new services. If another call comes in, they would not be able to respond in the time that they need to.
07:28
So they establish mutual relationships with nearby cities. Again, in this case, a lot of the work we do is in and around the San Diego area. And these communities, through an organization called North County Fire Joint Powers Agreement, they agree to provide assistance to
07:48
one another. So when Carlsbad has resources available and VISTA fire department needs some help, they'll provide them. And VISTA to Oceanside, etc. So they form this relationship to really be able to provide services regionally. All of this action occurs over a
08:09
particular timeline, from when you pick up that phone to when that fire truck leaves the station. That's what this CAD system, in large part, is keeping track of, is when that call comes in, which fire department that should get dispatched to, and how they're
08:25
going to respond. So in some of the more complex, very detailed CAD systems, we even have information available from when the phone was picked up, when the 911 operator first touched a key on their keyboard, when that call entered the queuing system, in
08:45
other words, to be assigned to an available responder, when the operator hung up, and when that call was dispatched. In other words, when that call rang the alarm at the fire station. Most of the time, we don't have this level of detail, but in some
09:03
cases, we do. And that's actually a whole other process of us analyzing the effectiveness of the dispatch service themselves. Typically, this is the information that the fire service itself is concerned with. Once they get the call, what happens? How
09:20
do they respond? They get dispatched, so in other words, they receive the call, they are in route, so in other words, they leave the station and go to the incident, they arrive on scene, and after the incident has finished, or at least after their role in that incident has finished, they again become available. So duration turnout, that time it took for them to get that truck
09:45
out the door. The duration travel, how long did it take them to get there? Duration on scene, how long were they responding before they became available again to respond to other incidents? And out of that, really two high-level key metrics come up. Duration response, so in other words, from when we got the call to when we got there, how long did it
10:06
take? And duration committed, from when we got the call until that truck became available again, what's the duration committed? That rolls into higher-level metrics like resource drawdown, which gives you an idea of, as more and more of our
10:22
resources are committed, our ability to respond to new incidents diminishes, and therefore we may need to rely on our mutual aid agreements. One of the higher-level metrics that kind of bubbles up from all of this information is something called the effective response force. And so our effective response force is the minimum complement of resources needed to
10:49
effectively respond to a particular type of incident. So for example, a large structure fire. It could be that in order
11:09
to respond to a large structure fire where the building is larger than a certain size, we're going to need two fire engines, one ambulance, and one fire chief. At a minimum, that's what we need in order to effectively handle that incident. And so
11:23
this is really where the higher-level analysis with something like Postgres and PostGIS comes into play is taking that individual data and summarizing and sorting through it in such a way that we can determine this information. The simple metrics are exactly that. They're easy to compute. The average amount of time it takes to respond to an incident this past
11:48
month or average utilization of a specific ambulance. Those things are easy. This higher-level information becomes a little easier to consider. Things like fire trucks move around from station to station. So there might be a fire engine. And this
12:07
is a vehicle that costs upward of a million dollars. So a fire department that has three stations isn't going to buy three of these trucks. But they're going to buy one and position it at different places throughout the day to best serve what they expect might happen. So they want to be able to answer questions. A question that just came up
12:29
recently in Carlsbad was station number six has been running overtime staff for two and a half years. So in other words, the staff that they've got there have been working more than full time in order to satisfy the number of calls that they
12:43
get in. And so what they want to know is what percent of the time was their effective response force on scene within eight minutes or less. Eight minutes is a very common metric for the maximum amount of time that they want it to take to respond to any given incident. And so what percent of the time have they effectively been able to deal with these calls?
13:07
And so that involves over some period of time looking at the incidents that they've responded to, the type of incidents those are, what the effective response force is for each of those different types of incidents, fiddling with that data in
13:24
a tool like Postgres to come up with that information. And ultimately they want to know how might adding three new staff members help improve our response times. So if they decide or determine that 12 percent of the time it takes them more than eight minutes, how theoretically is adding three new firefighters going to help them reduce that time that it takes?
13:55
As you might expect, and there's been a lot of presentations that touched on this this week, it all comes down to the data
14:01
and the data coming in from this CAD system. And a lot of times that data is far from perfect. In fact, a lot of times that data is complete rubbish and you can't use it. You shouldn't use it. You have to go back and tell them for whatever reason the information we got last night is not usable. And so I know you want to know what the average response time is, but I as a
14:24
professional can't give you that answer because the data is not reliable. They don't want to hear that and they call you and they yell at you, but that's the way it is. That's our job. And so the last couple of slides I just wanted to show here kind of illustrate exactly that challenge that we have again
14:45
when it comes to the data. As I was saying before, the CAD systems tend to be complex, probably often overly complex, too complex. What we've got showing here is these CAD codes, so in other words these codes that get generated by the CAD
15:03
computer system as the operator is entering in this information. So we've got these codes called ASST and DSP and DE. I have no earthly idea what these codes mean and exactly what they relate to, but what I know is anytime I see an
15:21
incident or an entry in the CAD system with the code ASST, really that's a time stamp for when a unit was dispatched to the call. Likewise, these six or so different codes in the system ultimately all indicate when did that unit
15:42
again become available. On scene, en route, call received. So these go back to the timeline that I was describing earlier. A couple of things in there that we didn't really touch on were also transport depart and transport arrive. So transport is ambulance service. So what time did the ambulance leave the scene and what time did that ambulance
16:08
get to the hospital? Some of this is further complicated by the fact that very typically in the United States the ambulance service is run out of the fire department and so rather than out of a particular hospital or rather than as a separate
16:26
service, it's run and managed by the fire department. Other communities though use a private ambulance service and they have their own systems. They have their own CAD system that may or may not interoperate well with the county-wide
16:43
or the mutual aid-wide CAD system. And even though the regulations and laws stipulate that these private ambulance services need to provide us the information that we want, it doesn't say that they have to give it to us the next day
17:00
or the next week or the next month. And so we're often operating with incomplete information. Again, when it comes back to saying what's the effective response for us if that is to include an ambulance but we don't have information from that ambulance, again we have to tell our customer we can't really reliably give you that information and he calls us
17:23
and yells at us and we tell him go yell at your ambulance service. So just a couple of examples here that kind of illustrates some of this data. Unit 1398, which I happen to know is an ambulance in the Carlsbad or in this mutual
17:44
aid group that we've been kind of using for examples. So here's a series of timestamps. You can see we've got our series of timestamps, 113, 15, etc. So that all seems very nice. We've got that series of codes that came from the
18:03
original CAD system and then we've got that collapsed code that really relates that to a specific point in the timeline. We've got our nice sequentially ordered series of times, these different dispatch and route on scene. But the problem we have here is we've got two timestamps for on scene. So if en route, it's kind of hard to see here,
18:32
but if this ambulance left the station at 115 and it got on scene at 119 or did it get on scene at 138.
18:44
What is that? That's 19 minutes of difference. Now based on our experience, I know it did not take from 113 to 138 for that ambulance to get on scene. What we suspect happened in this case is that this item was incorrectly
19:06
entered as on scene when it should have been listed as transport arrive. So it is on scene in a sense, but it's really when the ambulance got to the hospital, right? And so from the effective response force metric, this would be an item
19:23
that we would discard. But again, in this case, we only know that because we're familiar with the environment and the resources. Here's another fun example. 19 different timestamps for on scene arrival, about four seconds
19:44
apart, one second apart, 10 seconds apart. I don't know, maybe gum got stuck in the some underneath some keyboard by some operator. And so we look at this and we say, all right, well, it left the station at 1747.
20:03
It became available again approximately a half an hour later. We don't really know when did this thing actually arrive on scene. The fire chief calls us and he yells at us and we say we're sorry, but I'd rather give you no
20:21
answer and get yelled at than give you something wrong. So hopefully that gives you just a good idea. Again, I avoided making this extremely highly technical. I thought it would be more interesting, more useful just to describe what kind of what this process is. So just a little bit of thanks. FireStats and Paul Rotenberg is a statistical
20:44
analysis company that we work with. They operate specifically with the fire service. Carlsbad, California Fire Department and the North County Dispatch, which was this mutual aid organization that I mentioned. A lot of these images
21:00
I frankly just took off of Google, which I suspect happens a lot this week. All those images are copyrighted accordingly to where I acquired them. So that's what I've got to say if there are any questions at all.
21:28
So how does the process of that entry get into the database? It's a manual process. Is it on the fire truck side or is it at the dispatch side? At the operator side, like on scene? So it depends on the equipment
21:46
available. In a sort of more modern outfitted equipment where you've got trucks that have say GPS that are baked in and you know where they are at all times. There's a little bit more automation to that. A lot of times
22:02
from the point of dispatch to the point of available, there's literally like a big red button in the fire truck where the driver gets in the truck at the station and he hits the button, which basically sends a time stamp back to the CAD system saying I have left the station. He gets on scene, he hits a button which says
22:23
I have arrived on scene. Their role in that response is completed, he hits a button and says I am now available. So those three manual steps right there, you can see how that might relate to this type of activity.
22:45
Alright, well thank you very much.