"Geospatial data exchange is needed now to improve efficiencies, save lives" – Urgent Communications
mcpmanager September 22nd, 2016
Posted In: Industry Insights
Originally published in Urgent Communications, View From the Top, September 8, 2016
Geospatial data exchange is needed now
It would allow critical information to be shared, even across county lines, at a moment’s notice
By Robert Horne
For decades, even centuries, whenever traditional cartographers created pen-to-paper maps, accuracy often was an elusive concept, in large measure because of the tools of the trade. It was difficult to ensure that the end of one line was matched exactly to the beginning of the next line, because the ink would bleed on the paper. And it really didn’t matter because one only could magnify the map so much. So, close enough was good enough.
Today’s computerized mapping environment has changed this paradigm dramatically. When creating maps today, it is vitally important that the end of one line connects precisely to the beginning point of the next line, and that the street centerlines are drawn in the correct direction. Let’s say that you’re creating a map that contains a one-way street, and that you inadvertently draw one segment of the road so that it is going in the wrong direction—you’ve just changed the flow of traffic.
And it doesn’t matter if the map is labeled to correctly indicate that this is a one-way street from beginning to end; if that street centerline is drawn in the wrong direction, when the computer-aided dispatch (CAD) system runs the algorithm that determines how to get from point A to point B along that road, it will reroute the first responders at the point where it believes the road changed direction, which will delay their arrival at the emergency scene.
Just as vital is ensuring that lines connect properly because when they don’t, the CAD system might believe that two roads don’t intersect when they actually do, which also would result in a rerouting situation. This is a big problem when seconds matter and lives are on the line. Fortunately, modern mapping applications have a “snapping” tool that ensures that road segments properly connect to each other.
All of this collectively is called topology, which simply is the act of maintaining flow from one feature to the next. If topology isn’t maintained properly, it will create a lot of headaches for PSAPs and the first responders that they serve.
Accuracy also is an important consideration when creating polygons, response areas, and jurisdictional boundaries, because without it overlapping or orphan areas can result. The former is problematic because when these elements overlap, the area belongs to multiple jurisdictions; ergo, when an emergency occurs, first responders from multiple jurisdictions are dispatched, which unnecessarily depletes available resources and places first responders at risk.
Orphaned areas—which typically occur when polygons or jurisdictional boundaries do not properly snap to each other—arguably are even worse, because they don’t belong to any jurisdiction, at least in the eyes of the CAD system. As a result, dispatchers often become confused when an emergency occurs in one of them, because they’re not sure what agency to send in response. In turn, valuable time is wasted, which again is a big problem when lives are on the line.
A critical step in making all of this work is called edge-matching, a tactic that GIS mapping applications employ in which an algorithm corrects all of the existing overlaps, orphan areas and other inconsistencies, and then the snapping tool snaps everything into place.
Geospatial Data Exchange
There is a big difference between live data and canned data. Traditionally, public safety answering points (PSAPs) download GIS data into their CAD systems on a periodic basis, usually once a quarter, but often only once or twice a year. Unfortunately, thousands of updates are made to that data—for example, new street centerlines are added and addresses are modified—before the next download is executed. The result is that old data is being leveraged to make emergency dispatch decisions, which in turn creates dangerous scenarios both for the first responders and the citizens they are trying to protect and serve.
Let’s say that Jurisdiction A dispatches an ambulance company to a rural location in Jurisdiction B. The ambulance company can take one of two routes to the emergency scene. What it doesn’t know as it embarks, however, is that one of the routes has been closed by emergency management authorities in Jurisdiction B because a major weather event the day before caused flash flooding and parts of the road are under several feet of water. Unfortunately, the ambulance company is instructed by Jurisdiction A dispatchers to take this route because it is the shorter of the two.
There are a couple of reasons why Jurisdiction A is unaware of the road closure in Jurisdiction B. One is that one or both of the PSAPs are not yet Next Generation 911 (NG911) capable, so there are no automated systems to share GIS data. Another is that Jurisdiction B failed to update its data in a timely fashion, so Jurisdiction A was left in the dark. Either way, this is a terrible outcome for the citizen needing emergency assistance, because the ambulance was forced to backtrack and find alternate routing to the emergency scene, which turned a 10 minute trip into a 30-minute adventure.
There are significant implications when a disconnect occurs between jurisdictions concerning the data that is used to provide emergency response. Consider the plight of Shannell Anderson, a newspaper delivery supervisor in the Atlanta metropolitan area. One morning in late December 2014, at about 4:00 a.m., Anderson was driving an unfamiliar route, as she was covering for the normal delivery person, who had called in sick. Anderson took a wrong turn and inadvertently drove her car into a pond.
As the car sank, water pressure prevented Anderson from opening her car doors and swimming to safety. Keeping her wits, Anderson called 911, explained her dilemma and provided her exact location. Unfortunately, the location didn’t come up on the 911 telecommunicator’s screen. There were two reasons for this. As reported by several media outlets, the first was that Anderson’s call had hit a tower in Fulton County, so it was fielded by a PSAP in Alpharetta, Ga.; unfortunately, Anderson’s emergency was playing out just a few yards into adjacent Cherokee County. The second bit of bad luck for Anderson was that the Alpharetta CAD system had no record of the intersection provided by Anderson, even though it was within walking distance of the county line—such is the limitation of siloed data.
It took roughly 20 minutes to unravel the mystery and transfer the call to a Cherokee County PSAP, but by then it was too late for Anderson. Though she was still alive when firefighters pulled her unresponsive body out of the pond, she died a few days later in a local hospital.
A Better Way
All of this might have been avoided if the two PSAPs involved in this event had the ability to not only share data, but also to access up-to-date live data feeds provided by data stewards. Traditionally, PSAPs have relied on street centerline and address point information generated by state and local departments of transportation in order to dispatch law enforcement, fire and emergency medical service (EMS) responders. Unfortunately, this information is dated the moment that it is downloaded into the agency’s computer-aided dispatch (CAD) system; the longer the amount of time between downloads the more dated and less useful the information becomes.
A better approach would be to establish a live data feed between the department of transportation and the PSAP. An appliance would be installed at every PSAP that captures the feed every minute, every quarter hour, every hour—whatever makes sense for that agency—and immediately updates the PSAP’s GIS dataset, so that the most-current information always is available to 911 telecommunicators. In order for such an approach to work, the DOT must publish its data each time it is updated and then automatically push the update to each PSAP that is interconnected to the DOT’s servers. Once the updated dataset is cached in the PSAP’s CAD system, it will have the most current data. Even if the data connection between the PSAP and DOT is lost for a period of time, the data will be only hours or days old, rather than weeks or months, as was the case with the traditional approach to data maintenance.
Because access to view this data is available to the general public—for instance, all of it is available in Google Maps—security measures do not dictate that it be transported over the agency’s secure Emergency Services IP Network (ESInet). Rather, the DOT’s data feed could be transported over the commercial Internet. This is advantageous because street centerline and address points data would unnecessarily consume ESInet bandwidth that otherwise could be reserved for the agency’s life-safety mission. More importantly, the Internet reaches data providers, PSAPs and backup facilities currently not on an ESInet; also, for those PSAPs that are connected to the ESInet, the Internet could serve as a backup pathway to this data should access to the public safety network be impaired.
In a geospatial data exchange environment, each PSAP that is capable of receiving live data feeds can catalog all of the up-to-date information that is available regionally for later retrieval, without having to check for updates or contact a specific data steward. That means critical information needed concerning a location, even if it is across county and even state boundaries, would be accessible at a moment’s notice.
However it occurs, it is imperative that 911 telecommunicators are able to access accurate addressing data about a neighboring jurisdiction at any time, because they often find themselves fielding calls from such jurisdictions that are sent to them in error, as was the case with Shannell Anderson.
The street centerline and address point data maintained by the DOT is only one critical dataset that needs to be updated and automatically disseminated to PSAPs in real time. For instance, public works, working with the fire department, maintains the fire hydrants data layer, which includes water pressure and flow information. Such data would be critical for incident commanders to have when rolling up to a skyscraper fire, as knowing which hydrant has enough water pressure to reach the top of a 30-story building would be a crucial bit of information.
In addition, the planning or building department, as well as the tax assessor’s office, would maintain address and property boundary data. Meanwhile, law enforcement would be responsible for data related to emergency service zones (ESZs), which establish response boundaries based both on geography and response type.
A mind-boggling amount of data is updated every day. For instance, the DOT might launch a road-paving project that will close a road for 30 days, or public works might have to close a lane on another road in order to perform a water-main repair. At best, these scenarios would create traffic-congestion nightmares, but at worst they might delay the arrival of an ambulance that’s carrying a critically ill or injured patient to an emergency room. Live data feeds would keep PSAPs abreast of such developments, which would have a profound effect on emergency response.
The data stewards who work for the DOT, public works, et al, need to understand that the data they create and maintain is critical to the life-safety mission. This is a counter-intuitive way for them to think, so an educational effort needs to be implemented that will help them to understand their incredibly important role in emergency response, i.e., because that mission matters so much, so does theirs.
This educational effort would be accomplished best by the PSAPs, but they too often fall victim to old, silo-oriented ways of thinking that prevent them from thinking of the data stewards as being part of the solution, and then building a relationship with the data stewards that will result in more-accurate data being provided in a more timely manner.
Meanwhile, the data stewards need to be made to understand that the street centerlines they create ultimately will be used to dispatch police, fire and EMS to any number of live-and-death situations—and if certain data standards aren’t met, people most certainly will die.
People like Shannell Anderson.
Robert Horne is a communications consultant for Mission Critical Partners, Inc. (www.missioncritical.3twenty9.net), a public safety communications consulting firm headquartered in Port Matilda, Pennsylvania. He can be emailed at firstname.lastname@example.org.