The Emergency Management Templates provide a sample Geodatabase in each of the application downloads (COP, Mobile, Standard Maps). There is a fourth template for those of you looking to build your own GIS Server and Geodatabase for Emergency Management. This blog entry provides details about the structure of those Template Data Models and how you can use them in your project.
If you are new to GIS you will probably be surprised at the level of enthusiasm and interest in data models in the GIS user community. There are a few key reasons for this interest:
- Data is the biggest investment in GIS for most organizations. The data model directly affects the cost and duration of their projects.
- GIS databases always have to support many applications and many types of maps and reports. It is hard to anticipate all of the data requirements from a typical set of application requirements, so most organizations are driven to look for best practices for database design to make sure their system provides a foundation for future applications.
- Designing and building GIS databases is a relatively new profession and the tools, methods, and design patterns are still emerging.
The purpose of the Emergency Management Template data model is to provide a good design for a Local Emergency Operations Center (EOC) in Louisville, KY. Yes, it can be used in other jurisdictions and for other purposes, but the style of data model and the similarity to the existing data provided by LOJIC, the Local Government GIS organization in Louisville, but there are a number of design decisions made specific to Louisville and the scope of the model is to support some specific applications for an EOC.
So on the one hand, the EMTemplate.mdb can be used as a ready-to-use Geodatabase design, but like we did in building the Louisville example, you will need to go through a process of selecting the right content for your applications and available local data to build your system. Some people think that it would be better for ESRI to provide a universal data model that can handle every situation and produce any kind of map, but we didn’t take that approach because solutions with a scope like that rarely work at a practical level. We want to help you to get to the point of deciding which attributes you need on the FireStation feature class, how your maps should look at 1:10,000 scale, and how you are going to manage a street centerline dataset that works for mapping and for dispatch. We won’t solve all of those problems with EMTemplate.mdb, but at an implementation level this example should help you to get there.
For an introduction to the content of the Template, watch the video.
From the video you should have an initial understanding of the content of the data model templates and you might have some ideas about how to use data you already have. Again, there are 3 main parts to the template geodatabase:
- Basemap – Local Government GIS data and other feature classes to support a Public Safety Basemap.
- Public Safety – Data that can be managed by local government and/or Public Safety groups. These datasets include emergency locations such as shelters, events, resources, along with more detailed information for facilities such as police stations and fire stations.
- Emergency Operations – Data for incidents and related dynamic information.
Note there is a 4th category called LiveFeeds that has its own template to collect information from various sources and formats to create simple feature classes.
Some people may wonder why we are organizing the data into these “logical” groups. The reason is that we envision different workgroups/organizations will manage this information at different times and that the permissions on each of the datasets in those feature datasets will be the same. In general, it is a recommended practice for Geodatabases to put data with the same permissions into feature datasets and grant privileges for all data at the feature dataset level.
You will also notice the DOT_ tables and the Hillshade raster dataset in the screenshot here. The DOT Hazmat tables are part of Emergency Operations, and the Hillshade is used in the Basemap. The reason they are not in the feature datasets is that you cannot put tables and raster datasets into feature datasets in a Geodatabase.
We would like to once again thank the Local Government GIS organization in Louisville, KY for allowing us to include a sample of their data in the templates. You should be aware that we took a copy of the data at a point in time (1999) and built additional content on top of those datasets. As a result, the data in the templates has been significantly altered from the original database and also does not reflect real conditions. That will be obvious, but we want to clarify that for people who are just getting started.
The Basemap feature dataset contains a number of feature classes like Airports, Parcels, County Boundaries, Streets, and other datasets that are typically managed by local government GIS groups and their partners. The style of data model in the template is basically a copy of the LOJIC data model with some changes in field names, descriptions, and other content.
You can also see the key information (mentioned in the video) for FacilitySite and FacilitySitePoint. In general, you would expect that each site polygon (i.e., the Louisville Airport) would have one or more SitePoints that represent the front door and other key locations and businesses at the Site. In the Louisville example we only have a small set of the polygons and many more SitePoints.
The FacilitySite polygons include data from the LOJIC Areas of Interest feature class. If we had more time we would have added more of these polygons to the database – there are many more Sites in the real world than we have as polygons in the database. We did not add MetroParks into the polygon database but would do that if we were starting over.
We also added HazMat locations into the FacilitySitePoint feature class along with a number of other point locations. In hindsight we might have been better off making a separate HazMat feature class to house that information and include HazMat type and quantity information, although just having the location plus point of contact information is probably about right for a basemap. You will notice that a number of the SitePoints were geocoded/located using address information and should be placed more accurately on the Sites. You will also notice places with many points stacked on top of each other because they have the same address. We just didn’t have time to fix this in the data.
Beyond some of those details, this approach – having these 2 simple feature classes for these types of features – is a big shift in thinking for many local government GIS shops. We are really interested in your feedback and ideas on this topic. We see many opportunities with this approach – maps, searches, performance, symbology all work better than having the information scattered across many feature classes.
The Public Safety feature dataset contains a number of feature classes that are of interest to Public Safety organizations. In many cases the Fire and/or Police departments maintain some or all of this data, but in other cases the local government GIS organization manages this information. There is no strong recommendation either way; it really depends on the GIS capability and priorities in these organizations.
This data is relatively static and is not large in size compared to the Basemap datasets. One key part of this data spans both planning and operations activities – the EmergencyFacility feature class.
The EmergencyFacility domain provides a better look at the kinds of features in this dataset:
This feature dataset contains data that is specific to incidents and emergency management activities. The information is dynamic and evolves quickly. Most of the content here should be easy to understand – especially after you try the COP template and/or watch the video.
One part that is not described anywhere else is the inclusion of DOT HazMat reporting content:
These tables are based on DOT reporting requirements and provide a place to store information on PHMSA incident reporting forms 171.15 and 171.16 as described at: http://www.phmsa.dot.gov/hazmat/incident-report. While you may not be required to report using these forms, it should at least provide you an example of how to build geodatabase content to support these kinds of requirements.
We are interested in your feedback on this topic – especially comments on what we can do to make it easier for you to build your own system. Contact us anytime at ArcGISTeamPublicSafety@esri.com.