North Carolina Emergency Operations Centers

Metadata also available as - [Outline] - [Parseable text] - [XML]

Frequently-anticipated questions:

What does this data set describe?

Title: North Carolina Emergency Operations Centers
Abstract:
Emergency Operations Centers (EOC) in North Carolina
"The physical location at which the coordination of information and resources to support domestic incident management activities normally takes place. An EOC may be a temporary facility or may be located in a more central or permanently established facility, perhaps at a higher level of organization within a jurisdiction. EOCs may be organized by major functional disciplines (e.g., fire, law enforcement, and medical services), by jurisdiction (e.g., Federal, State, regional, county, city, tribal), or some combination thereof."
(Excerpted from the National Incident Management System)
In instances where TGS could not verify the location of an Emergency Operations Center due to non-cooperation of the entity and to the exhaustion of all possible alternative resources, its location was depicted at the center of the service area.
In cases where an Emergency Operations Center has a mobile unit, TGS captured the location of the mobile unit as a separate record. This record represents where the mobile unit is stored.
Text fields in this dataset have been set to all upper case to facilitate consistent database engine search results.
All diacritics (e.g., the German umlaut or the Spanish tilde) have been replaced with their closest equivalent English character to facilitate use with database systems that may not support diacritics.
The currentness of this dataset is indicated by the [CONTDATE] attribute. Based upon this attribute, the oldest record dates from 03/28/2007 and the newest record dates from 05/04/2007.
  1. How should this data set be cited?

    Techni Graphic Systems, Inc., North Carolina Geographic Information System (NCGIS), and Homeland Infrastructure Foundation-Level Data (HIFLD) Working Group, 20070621, North Carolina Emergency Operations Centers.

  2. What geographic area does the data set cover?

    West_Bounding_Coordinate: -84.031338
    East_Bounding_Coordinate: -75.686639
    North_Bounding_Coordinate: 36.508273
    South_Bounding_Coordinate: 34.057582

  3. What does it look like?

  4. Does the data set describe conditions during a particular time period?

    Beginning_Date: 28-Mar-2007
    Ending_Date: 04-May-2007
    Currentness_Reference: ground condition

  5. What is the general form of this data set?

    Geospatial_Data_Presentation_Form: vector digital data

  6. How does the data set represent geographic features?

    1. How are geographic features stored in the data set?

      This is a Vector data set. It contains the following vector data types (SDTS terminology):

      • Entity point (107)

    2. What coordinate system is used to represent geographic features?

      Horizontal positions are specified in geographic coordinates, that is, latitude and longitude. Latitudes are given to the nearest 0.000001. Longitudes are given to the nearest 0.000001. Latitude and longitude values are specified in Decimal degrees.

      The horizontal datum used is D_WGS_1984.
      The ellipsoid used is WGS_1984.
      The semi-major axis of the ellipsoid used is 6378137.000000.
      The flattening of the ellipsoid used is 1/298.257224.

  7. How does the data set describe geographic features?

    Emergency Operations Centers (EOC) in North Carolina
    "The physical location at which the coordination of information and resources to support domestic incident management activities normally takes place. An EOC may be a temporary facility or may be located in a more central or permanently established facility, perhaps at a higher level of organization within a jurisdiction. EOCs may be organized by major functional disciplines (e.g., fire, law enforcement, and medical services), by jurisdiction (e.g., Federal, State, regional, county, city, tribal), or some combination thereof".
    (Excerpted from the National Incident Management System) (Source: National Incident Management System)

    FID
    Internal feature number. (Source: ESRI)

    Sequential unique whole numbers that are automatically generated.

    SHAPE
    Feature geometry. (Source: ESRI)

    Coordinates defining the features.

    ID
    Unique identifier for feature. (Source: TGS)

    Text

    METLNKID
    Link to Metadata - Currently this attribute is not used and is not populated. (Source: TGS)

    Text

    FEATTYPE
    Geometry type of feature. (Source: TGS)

    ValueDefinition
    POINTFeature is represented by point.

    SECCLASS
    Security classification of feature. (Source: TGS)

    ValueDefinition
    UNCLASSIFIEDEntity is unclassified.

    NAME
    Name of entity. (Source: TGS)

    Text

    AREA
    Three (3) digit telephone area code for entity. (Source: TGS)

    Valid area codes without punctuation. Only numeric digits are used. A list of valid area codes can be found at <http://www.nanpa.com>.

    PHONE
    Seven (7) digit telephone number for entity formatted as nnn-nnnn. All alphabetic characters have been translated to the corresponding numeric digit. (Source: TGS)

    Phone numbers formatted as nnn-nnnn. Only numeric digits are used. The first three (3) digits (the exchange) must form a valid combination with the area code. A list of valid area code and exchange combinations can be obtained from <http://www.nanpa.com>.

    ADDRESS
    Physical street address for entity. "PO Box", "General Delivery", "Rural Route", and "Highway Contract" addresses are not considered physical addresses and should not appear in this attribute. Some areas do not have regular city style addressing, so entities may not have a street number. In such cases, the name of the road they are located on is listed in this attribute. Some rural areas may not have named roads. In these rare cases, this attribute will be blank. (Source: TGS)

    Text

    ADDRESS2
    Location within physical address, e.g., floor, suite, building. (Source: TGS)

    Text

    CITY
    The name of the city associated with the entity's physical address. For physical addresses that the U.S. Postal Service (USPS) delivers to, this should be a "city" acceptable to the USPS as defined in their Address Information System (AIS). Sometimes the USPS does not deliver mail to a physical address but recognizes the location (i.e., they list the location as "undeliverable"). The cities associated with these locations are acceptable. In some cases, the USPS does not recognize individual physical addresses in a city; rather, they list the city as having "General Delivery". In these cases, the city and associated zip code are acceptable (the entity's [ADDRESS] attribute will contain a street address, not "general delivery"). The entity may not actually be located within the city limits of the "city" specified in its city field. Instead, it may actually be located within the city limits of another city. In some cases, the "city" that appears in this attribute may not even be a city in an administrative sense, but it is still an acceptable "city" to the USPS. An example of this is "Notre Dame, IN". There is no city in Indiana called "Notre Dame", but this is considered an acceptable city by the USPS for any delivery going to the University of Notre Dame which is actually located in the city of South Bend. "Notre Dame", like most USPS cities, is an easily recognized place, and it gives the user of the data a good general idea of where the entity is located (if the entity is located in a small municipality, the USPS "city" may be more recognizable than the name of the municipality), and it would be part of the address one would use to send a shipment to the entity's location. Using the USPS acceptable "city" also allows someone to do a logical consistency check between the zip code and the city by using the USPS AIS.
    Sometimes an entity may report a city that is not accepted by the USPS, and although TGS has tried to replace those cities with an acceptable alternative, some of them may remain in this dataset. (Source: TGS)

    Text

    STATE
    Two (2) character abbreviation for state associated with the entity's physical address. In almost all cases, this is the same as the state where the entity has been depicted geospatially. However, there are cases, particularly where an entity is part of a larger facility that cuts across state lines, where the entity's location may be depicted in a state other than the one indicated in this attribute. Also, the state in which an entity appears to be located may change depending on the scale of the state boundary theme being used. (Source: TGS)

    Formal codeset
    Codeset Name:Official USPS Abbreviations - State Abbreviations
    Codeset Source:United States Postal Service <http://www.usps.com/ncsc/lookups/usps_abbreviations.html>

    ZIP
    Five (5) digit USPS zip code for entity's physical location. (Source: TGS)

    Formal codeset
    Codeset Name:USPS Address Information System - Domain is further restricted by only allowing physical (non PO Box) zip codes.
    Codeset Source:United States Postal Service

    ZIPP4
    Four (4) digit USPS zip code extension. This attribute was automatically assigned using the entity's physical address and USPS address information system (AIS) data. (Source: TGS)

    Formal codeset
    Codeset Name:USPS Address Information System (AIS) - ZIP9
    Codeset Source:United States Postal Service

    COUNTY
    County name where entity is located. (Source: TGS)

    Formal codeset
    Codeset Name:Geographic Names Information System (GNIS)
    Codeset Source:US Department of the Interior - US Geologic Survey

    FIPS
    Five (5) digit FIPS (Federal Information Processing Standards) Code for the County where entity is located. The first two (2) digits represent the state and the last three (3) digits identify the county within the state. (Source: TGS)

    Formal codeset
    Codeset Name:Federal Information Processing Standards Publications - Counties and Equivalent Entities of the U.S., Its Possessions, and Associated Areas
    Codeset Source:National Institute of Standards and Technology (NIST) <http://www.itl.nist.gov/fipspubs/co-codes/states.txt>

    DIRECTIONS
    Directions to entity location, or description of the entity's location. (Source: TGS)

    Text

    EMERGTITLE
    Title of person or name of office for emergency point of contact. (Source: TGS)

    Text

    EMERGPHONE
    Ten (10) digit telephone number of emergency point of contact formatted as nnn-nnn-nnnn. All alphabetic characters have been translated to the corresponding numeric digit. (Source: TGS)

    Phone numbers, including area code, formatted as nnn-nnn-nnnn. A list of valid area code and exchange combinations can be found at <http://www.nanpa.com>.

    EMERGEXT
    Telephone extension for emergency point of contact. (Source: TGS)

    Text

    CONTDATE
    Date entity was contacted by TGS. (Source: TGS)

    Date

    CONTHOW
    Method by which entity was contacted. (Source: TGS)

    ValueDefinition
    PHONEEntity was contacted by phone.
    FAXEntity was contacted by fax.
    MAILEntity was contacted by mail.
    EMAILEntity was contacted by email.
    WEBEntity information was gathered and/or verified by official entity website as a last resort.
    ALT REFGeospatial reference information obtained from local authorities, e.g., downloadable parcel maps, 911 streets.

    GEODATE
    Date entity was geocoded by TGS. (Source: TGS)

    Date

    GEOHOW
    Method by which entity was geocoded. (Source: TGS)

    ValueDefinition
    AUTOEntity was automatically geocoded.
    MANUALEntity was manually geocoded.
    ADJUSTEDEntity was shifted by TGS to an updated set of NAVTEQ streets. This only applies if the entity was manually geocoded by TGS to a previous version of NAVTEQ streets.
    PROVIDEDEntity was geocoded using coordinates provided by the state.

    NAICSCODE
    NAICS (North American Industry Classification System) Code for entity. NAICS Codes (and NAICS Descriptions) have been assigned based upon the entity's primary function, regardless of if that is the function that qualified it to be included in this dataset. (Source: TGS)

    Formal codeset
    Codeset Name:North American Industry Classification System (NAICS 2002)
    Codeset Source:US Census Bureau - <http://www.census.gov/epcd/www/naics.html>

    NAICSDESCR
    NAICS (North American Industry Classification System) Description for entity. The "Index Entries" that appear on the NAICS webpage (<http://www.census.gov/epcd/www/naics.html>) are being used to populate this attribute as opposed to the "NAICS Title". While there is a one to one correspondence between NAICS Codes and "NAICS Titles", there is a one to many relationship between NAICS Codes and the "Index Entries". By using the "Index Entries", we have placed the entities that make up this layer into more specific categories; however, the user of this data should be aware that this was not the intended purpose of these "Index Entries". The "Index Entries" were intended as a way to search the NAICS database and as a way of enumerating ways in which establishments falling under the given NAICS Code may be named. Thus, there are often two or more "Index Entries" that are synonyms, for example: "Prisons" and "Penitentiaries". In cases like this, we have standardized on one "Index Entry".
    NAICS Descriptions (and NAICS Codes) have been assigned based upon the entity's primary function, regardless of the function that qualified it to be included in this dataset. (Source: TGS)

    ValueDefinition
    EMERGENCY PLANNING AND MANAGEMENT OFFICES, GOVERNMENTEMERGENCY PLANNING AND MANAGEMENT OFFICES, GOVERNMENT - [NAICS Code 922190]: Entities primarily engaged in public order and safety (except courts, police protection, legal counsel and prosecution, correctional institutions, parole offices, probation offices, pardon boards, and fire protection) are classified under this description. These establishments include the general administration of public order and safety programs.

    GEOLINKID
    Link ID for the street segment to which entity was geocoded. Refer to the [ST_VENDOR] and [ST_VERSION] attributes for the street vendor and version that was used to geocode the entity. (Source: TGS)

    Text

    SOURCE
    Original source of entity record. (Source: TGS)

    ValueDefinition
    TGSEntity information was provided by TGS.
    DHS/FPSEntity information was provided by the Department of Homeland Security/Federal Protective Service through the Homeland Infrastructure Foundation-Level Data (HIFLD) Working Group.
    FEMAEntity information was provided by the Federal Emergency Management Agency through the Homeland Infrastructure Foundation-Level Data (HIFLD) Working Group
    NCGISEntity information was provided by the North Carolina Geographic Information System.

    X
    Longitude in WGS 84 Decimal Degrees. (Source: TGS)

    Range of values
    Minimum:-180
    Maximum:180
    Units:WGS 84 Decimal Degrees

    Y
    Latitude in WGS 84 Decimal Degrees. (Source: TGS)

    Range of values
    Minimum:-90
    Maximum:90
    Units:WGS 84 Decimal Degrees

    ST_VENDOR
    Indicates name of vendor providing original street data used for geocoding. (Source: TGS)

    ValueDefinition
    NAVTEQNAVTEQ streets were used for geocoding.
    TGSTGS drew in a new street segment that does not exist in the file supplied by NAVTEQ
    <BLANK>Entity was geocoded using coordinates provided by the state, therefore the street vendor is unknown.

    ST_VERSION
    Indicates the year and quarter of streets used for geocoding. (Source: TGS)

    ValueDefinition
    2006Q44th Quarter 2006 NAVTEQ street data was used for geocoding.
    <BLANK>Entity was geocoded using coordinates provided by the state, therefore the street version is unknown.

    GEOPREC
    Geospatial precision. (Source: TGS)

    ValueDefinition
    BLOCKFACEEntity is geocoded to correct block and correct side of street per street data indicated by [ST_VENDOR] and [ST_VERSION].
    ONENTITYEntity is geocoded on entity rooftop per aerial imagery (in most cases USGS DOQQs).

    PHONELOC
    Indicates whether the phone number in the phone field rings to the actual location of the entity. (Source: TGS)

    ValueDefinition
    YESPhone number rings to the actual entity location.
    NOPhone number does not ring to the actual entity location. It may ring to an administrative office or central location.
    <BLANK>Unknown - It is not known if the entity's phone number rings to the entity's location.

    QC_QA
    Organization that performed Quality Control/Quality Assurance on the record. (Source: TGS)

    ValueDefinition
    TGSTGS has performed Quality Control/Quality Assurance on the entity record.
    <BLANK>The record has not had Quality Control/Quality Assurance performed by TGS.

    EOC_ID
    Unique identifier for feature provided by North Carolina. (Source: TGS)

    Text

Who produced the data set?

  1. Who are the originators of the data set? (may include formal authors, digital compilers, and editors)

  2. Who also contributed to the data set?

  3. To whom should users address questions about the data?

    Mike Thompson
    Techni Graphic Systems, Inc.
    Director of Geospatial Datasets
    2000 Noble Drive
    Wooster, Ohio 44691
    USA

    330-263-6222 (voice)
    330-263-6294 (FAX)
    mthompson@tgstech.com

    Hours_of_Service: 8am - 5pm, Monday - Friday, Eastern Time

Why was the data set created?

Homeland Security
Use Cases: Use cases describe how the data may be used and help to define and clarify requirements.
1. A resource for preparing, mitigating, responding to and recovering from an emergency.
2. A list of resources to draw upon by surrounding areas when local resources have temporarily been overwhelmed by a disaster.
3. A resource for Emergency Management planning purposes.
4. A resource for catastrophe response to aid in the retrieval of equipment by outside responders in order to deal with the disaster.
5. A resource for situational awareness planning and response for Federal Government events.

How was the data set created?

  1. From what previous works were the data drawn?

    FEMA_STATE_EOC (source 1 of 4)
    Federal Emergency Management Agency (FEMA), 200702, "state_eoc".

    Type_of_Source_Media: Electronic Mail System
    Source_Contribution:
    This was provided by the Homeland Infrastructure Foundation-Level Data (HIFLD) Working Group and was used as a source for Emergency Operations Centers in the United States.

    DHS/FPS_CITY_EOC (source 2 of 4)
    Department of Homeland Security/Federal Protective Service (DHS/FPS), 20070213, "HIFLD-CITY-EOC".

    Type_of_Source_Media: Electronic Mail System
    Source_Contribution:
    This was provided by the Homeland Infrastructure Foundation-Level Data (HIFLD) Working Group and was used as a source for Emergency Operations Centers in the United States.

    NC_EOC (source 3 of 4)
    North Carolina Geographic Information System (NCGIS), 20070107, "eoc".

    Online Links:

    Type_of_Source_Media: Online
    Source_Contribution:
    This was used as a source for Emergency Operations Centers in North Carolina.

    NAVTEQ_Streets_2006_Q4 (source 4 of 4)
    NAVTEQ, 2006, NAVSTREETS.

    Type_of_Source_Media: CD-ROM
    Source_Contribution:
    NAVTEQ streets were used as a reference in the automatic geocoding and manual geolocating of entities.

  2. How were the data generated, processed, and modified?

    Date: 21-Jun-2007 (process 1 of 1)
    TGS Emergency Operations Centers Processing
    1) Verified name, physical address, and phone number by contacting the entity or an authority responsible for the entity.
    2) Determined or verified the geospatial location for the entity through contact with entity or authority responsible for entity. Entities were asked to describe their geospatial location relative to landmarks visible in ortho imagery.
    3) In cases where an Emergency Operations Center has a mobile unit, TGS captured the location of the mobile unit as a separate record. This record represents where the mobile unit is stored.
    4) All of the entities that were "completely verified" were reviewed by a TGS QC Technician. QC Technicians are trained to look for inconsistencies within the data and between the data and reference sources, such as imagery. Where inconsistencies exist, the TGS QC Technician re-verified the information by contacting the entity.
    5) All of the entities that were "completely verified" were examined as an aggregate (e.g., not every record was examined individually) by a TGS QC2 Technician. The automated checks described above and in the Attribute_Accuracy_Report were used to find any inconsistencies that remained in the data. If necessary, information was re-verified.
    6) NAICS Codes and NAICS Descriptions were assigned based on the entity name and on web research since this is information that can't be gathered over the phone.
    7) Four digit United States Postal Service (USPS) zip code extensions were assigned based upon USPS Address Information System (AIS).
    8) County names and county FIPS codes were assigned through a spatial join.
    9) All text fields were set to all upper case.
    10) Leading and trailing spaces were trimmed from all text fields.
    11) Non printable and diacritic characters were removed from all text fields.

    Person who carried out this activity:

    Nicole Hackworth
    Techni Graphic Systems, Inc.
    Project Manager
    2000 Noble Drive
    Wooster, Ohio 44691
    USA

    330-263-6222 (voice)
    nhackworth@tgstech.com

    Hours_of_Service: 8am - 5pm, Monday - Friday, Eastern Time
    Data sources used in this process:
    • FEMA_STATE_EOC
    • DHS/FPS_CITY_EOC
    • NC_EOC
    • NAVTEQ_Streets_2006Q4

    Data sources produced in this process:

    • EOC

  3. What similar or related data should the user be aware of?

How reliable are the data; what problems remain in the data set?

  1. How well have the observations been checked?

    For entities that were contacted, the name, address, city, state, and five (5) digit zip code was verified to be correct as of the date indicated by the [CONTDATE] attribute. The existence of the entity was also verified, as well as whether or not it met the criteria for inclusion in this dataset. Four (4) digit zip code extensions were derived from USPS (United States Postal Service) data and were not verified.
    ID Check: The [ID] attribute is not blank and all IDs are unique.
    Coordinate Check: Coordinates are not null or zero and the x and y fields match the shape.
    Basic Address Check: Physical addresses were verified to be non blank and to not be a "PO Box", "General Delivery", "Highway Contract", or "Rural Route" address.
    Basic Name Check: Entity name is not blank, and it has a minimum of 2 characters. Name does not contain punctuation characters that can interfere with database operations, such as " (quote) and * (asterisk).
    Basic Phone Check: All phone numbers (including the area code) are ten (10) numeric digits. Alphabetic characters have been converted to the corresponding numeric digit.
    County FIPS to State Compare Check: The county represented by the tabular FIPS Code attribute is actually in the state specified by the state attribute.
    County Name to State Compare Check: The county represented by the tabular county name attribute is actually in the state specified by the state attribute.
    Phone Number Format Check: Phone numbers (including area code) were verified to be formatted as nnn-nnn-nnnn.
    NPA_NXX Check: Area codes (sometimes called "Number Planning Areas", or NPA's) and central office codes (sometimes known as exchanges, or NXX's) were validated against data from the North American Number Planning Administration (NANPA). In some cases, NPA-NXX combinations did not show up in the NANPA data but were verified to work.
    Zip Code Check: The zip code is five (5) or nine (9) numeric digits, and is listed in the postal database, is in the same state as indicated by the entity's [STATE] attribute.
    Zip City Check: The entity's zip code and its city were verified to match according to the USPS Address Information System (AIS).
    Collocation Check: Entities with different addresses must not share the exact same geospatial location.
    Geographic Spell Check: Words that appear in the entity name were checked against a standard English word list (and Spanish word list for entities in Puerto Rico). Words not appearing in these standard word lists were then checked against names appearing in the Geographic Names Information System (GNIS) of geographic features that are located within 25 miles of the entity. Proper names were manually reviewed for correct spelling.

  2. How accurate are the geographic locations?

    The geographic location of contacted entities was verified to be correct relative to the street data vendor and version as indicated by the [ST_VENDOR] and [ST_VERSION] attributes. The horizontal accuracy is indicated by the [GEOPREC] attribute. A value of "BLOCKFACE" indicates that the entity was geocoded on the correct block and correct side of the street. A value of "ONENTITY" indicates that the location is on the entity's facility as determined by USGS DOQQ imagery and that it is on the correct block and correct side of the street.

  3. How accurate are the heights or depths?

  4. Where are the gaps in the data? What is missing?

    This dataset is based on information provided by the North Carolina Geographic Information System (NCGIS) and the Homeland Infrastructure Foundation-Level Data (HIFLD) Working Group.
    Administrative Locations: Locations that serve only an administrative purpose (e.g., purchasing, billing, budgeting) are intended to be excluded from this dataset, but a few may be included.

  5. How consistent are the relationships among the observations, including topology?

    See "Attribute_Accuracy_Report". Many of the checks described in that section check for both attribute accuracy and logical consistency.

How can someone get a copy of the data set?

Are there legal restrictions on access or use of the data?

Access_Constraints: There are no access constraints.
Use_Constraints: There are no use constraints.

Who wrote the metadata?

Dates:
Last modified: 21-Jun-2007
Metadata author:
Mike Thompson
Techni Graphic Systems, Inc.
Director of Geospatial Datasets
2000 Noble Drive
Wooster, OH 44691
USA

330-263-6222 (voice)
330-263-6294 (FAX)
mthompson@tgstech.com

Hours_of_Service: 8am - 5pm, Monday - Friday, Eastern Time
Metadata standard:
FGDC Content Standards for Digital Geospatial Metadata (FGDC-STD-001-1998)

Generated by mp version 2.9.5 on Wed Aug 27 10:29:57 2008