We're sorry but this page doesn't work properly without JavaScript enabled. Please enable it to continue.
Feedback

Analyzing Fire Department Response with PostGIS

00:00

Formale Metadaten

Titel
Analyzing Fire Department Response with PostGIS
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
Herausgeber
Erscheinungsjahr
Sprache
Produzent
Produktionsjahr2015
ProduktionsortSeoul, South Korea

Inhaltliche Metadaten

Fachgebiet
Genre
Abstract
Local government fire departments always face scrutiny of their performance and efficiency. They are continuously asked to do a better job with fewer resources. In this highly technical session we will show how PostGIS is being used to analyze and measure performance throughout the city and plan for future resource requirements. Every city we work with is unique in some way. Some fire departments act as the local ambulance service while other cities contract with private ambulance companies. Emergency “911” response centers are often managed by police/law enforcement departments but not always! Many cities also have “mutual aid” agreements with neighboring cities to assist them when needed. For our customers PostGIS stores and manages the geo-located events (fires, hazardous spills, etc.) and provides details about the departments and individual emergency vehicle performance. It is most interestingly used to create statistical reports about things such as “Effecive Response Force” and “Resource Drawdown”, which are used to measure the efficiency and effectiveness of the department. Please come to learn how PostGIS is used to analyze things such as primary response areas and fire hazard severity zones, allowing our customers to ask more advanced, geographically based questions.
126
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
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
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
Computeranimation
Transkript: Englisch(automatisch erzeugt)
Alright, good morning. So, as my partner just described, I would like to talk
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
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
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.
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,
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
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,
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,
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
each other. We're here to provide this technology to those who need it to answer questions. So our clients are municipal fire departments,
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,
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
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
emergency comes as quickly as possible. Now these people deal with a variety of questions. People call in, their first response is,
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
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
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.
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.
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
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
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.
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.
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
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
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
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
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
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
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
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
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
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
effectively respond to a particular type of incident. So for example, a large structure fire. It could be that in order
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
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
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
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
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
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?
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
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?
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
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
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
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
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
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
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
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
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
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
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
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
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
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,
but if this ambulance left the station at 115 and it got on scene at 119 or did it get on scene at 138.
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
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
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
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.
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
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
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
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.
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
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
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
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.
Alright, well thank you very much.