Description of Six Automated QC Checks Version: 1.0 April 2008 Table of Contents 1. Introduction 2. What Is Being Automated. 2.1. Verify Correct Line Type Bounding SFHA Polygons. 2.2. Verify That BFE Lines Extend Across the Entire SFHA 2.3. Verify That BFE Lines Do Not Cross 2.4. Verify That the Vertical Datum for Cross Sections Match the STUDY_INFO table 2.5. Verify That the Vertical Datum for BFE Lines Match the STUDY_INFO table 2.6. Verify that the panel-not-printed reason is populated for non-printed panels 1. Introduction The Department of Homeland Security’s (DHS’s) Federal Emergency Management Agency (FEMA) will be automating six out of 21 visual DFIRM panel review checks. These checks are currently conducted visually as part of the quality control reviews performed on final DFIRMs submitted by Mapping Partners. When a Mapping Partner submits a final DFIRM database and georeferenced map panels to FEMA via the MIP Study Workflow, first the automated verification of the DFIRM database is performed. When the DFIRM database passes the auto-verification check, the visual agreement check is initiated which validates agreement between features shown on map panels and the DFIRM database. Visual agreement check includes verification of the 35 (14 index checks, and 21 panel checks) checks which are described in FEMA’s DFIRM Verification Check Standard. Furthermore, error descriptions and validation messages are citations to FEMA’s Guidelines and Specifications Appendix L: Guidance for Preparing Draft Digital Data and DFIRM Databases, and the database domain table where applicable. The six new automated checks described in this document represent the most commonly encountered errors on final DFIRMs submitted by Mapping Partners. In addition, these six checks are the most time consuming ones during the visual agreement check process. The automation of these six checks will allow for faster turn around times of both initial DFIRM submissions and re- worked submissions. The following table summarizes the validation messages associated with each of the six automated checks: Check Type: Verify Correct Line Type Bounding SFHA Polygons Validation Message: Error 1301: The following S_FLD_HAZ_AR polygon(s) are attributed as a Special Flood Hazard Area but are bound by an invalid S_FLD_HAZ_LN LN_TYP: Check Type: Verify That BFE Lines Extend Across the Entire SFHA Validation Message: Error 1302: The following S_BFE line(s) undershoot or overshoot the SFHA boundary by more than 25 feet: Check Type: Verify that BFE lines do not cross Validation Message: Error 1303: The following S_BFE line(s) overlap or touch another S_BFE line: Check Type: Verify that the vertical datum for cross sections match the STUDY_INFO table Validation Message: Error 1304: The V_DATUM for the following S_XS line(s) do not match the V_DATUM in the STUDY_INFO table: Check Type: Verify that the vertical datum for BFE lines match the STUDY_INFO table Validation Message: Error 1305: The V_DATUM for the following S_BFE line(s) do not match the V_DATUM in the STUDY_INFO table: Check Type: Verify that the panel-not-printed reason is populated for non-printed panels Validation Message: Warning 1306: The following S_FIRM_PAN polygon(s) have a potentially incorrect combination of attributes for PANEL_TYP and PNP_REASON: 2. What Is Being Automated The following sections provide a description of the logic for each of the six new automated checks which will replace part of the current manual review processes associated with post-preliminary DFIRM reviews. Additionally, a description of tolerances allowed for each check and examples of how these tolerances will be applied are also provided where needed. 2.1. Verify Correct Line Type Bounding SFHA Polygons Check Description: For a polygon to be evaluated in this check SFHA_TF must equal “T” and FLD_ZONE must equal one of the following: “A”, “AE”, “AH”, “AO”, “AR”, “V”, “VE”, “A99”, ”, or “1 PCT ANNUAL CHANCE FLOOD HAZARD CONTAINED IN CHANNEL”. The code then finds the S_FLD_HAZ_LN lines that share a line segment with these polygons. If the LN_TYP of the line is not one of the accepted values, Error 1301 is called. A 25-foot tolerance was added to this check to prevent Error 1301 from being called due to small topology errors. In testing it was discovered that nearly all DFIRM data sets had at least some flood hazard lines that extended past the boundary of one polygon and touched the boundary of the adjacent polygon. If the length of the shared line segment is less than 25 feet, it will be allowed to pass. If less than 20 records are affected, the FLD_AR_ID for each record is given. If more than 20 records are affected, the error report will simply state the number of affected records. This is the same reporting format used by the existing Auto report. Logic: If: S_FLD_HAZ_AR SFHA_TF attribute is coded to “T” and the bounding S_FLD_HAZ_LN LN_TYP is coded as: “Floodway, Limit of Floodway, Limit of Detailed Study, Limit of Study, 1 PCT Annual Chance Flood Hazard, End of Spatial Extent or Zone Break, Apparent Limit, or Source Boundary” Then: Correct – Please move to next check Else: An error will be returned as: “Error 1301: The S_FLD_HAZ_AR polygon attributed as a Special Flood hazard Area is bound by an invalid S_FLD_HAZ_LN LN_TYP” Error Description: The following S_FLD_HAZ_AR polygon(s) are attributed as a Special Flood Hazard Area but are bound by an invalid S_FLD_HAZ_LN LN_TYP. Reference: The field description for SFHA_TF in S_Fld_Haz_Ar (Appendix L: pg L-291) describes what constitutes the SFHA. The check is making sure that the areas that are considered to be a SFHA have a valid corresponding line (e.g., all of the values in D_Ln_Typ [Appendix L: pg L-426] that relate to the SFHA and end of study). Appendix L: Pg. L-425 D_Ln_Typ defines the precedence of the line attribution. Example: This example below shows a very small line segment with an incorrect line type. This check will allow this type of error to pass, as long as the line segment is less than 25 feet. That is, when a S_FLD_HAZ_LN with an incorrect LN_TYP bounds an SFHA polygon, and the length of the shared segment is less than 25 feet, the polygon will be allowed to pass. 2.2. Verify That BFE Lines Extend Across the Entire SFHA Check Description: Since BFE lines are only allowed in AE polygons with no static BFE, this check makes sure the end points of the BFE line are within 25 feet of the boundary of one of these polygons. The BFE line is determined to be at the polygon boundary if a 25-foot buffer around the two BFE end points each intersect at least one polygon meeting condition 1 AND at least one polygon meeting condition 2 below: Condition 1: FLD_ZONE = (“AE” OR “AH”) AND (STATIC_BFE = null OR STATIC_BFE = -9999) Condition 2: FLD_ZONE >< (“AE” OR “AH”) OR (FLD_ZONE = (“AE” OR “AH”) AND STATIC_BFE >< null AND STATIC_BFE >< -9999) The code also handles the following special cases: 1. If the BFE line is at the end of spatial extent, the BFE will pass as long as the end point is within 25 feet of a S_FLD_HAZ_LN with a LN_TYP = “END OF SPATIAL EXTENT” 2. If the BFE line ends at a levee, dam, or other general structure, it is allowed to pass as long as the end point is within 25 feet of a S_GEN_STRUCT feature. 3. BFE lines in AH zones with no static BFEs are allowed to pass. If more than 20 records are affected, the count of affected records will be given. This is the same reporting format used by the existing Auto report. Logic: If: S_BFE line is within +/- 25 feet of the SFHA boundary Then: Correct – Please move to next check Else: An error will be returned as: “Error 1302: The following S_BFE line(s) undershoot or overshoot the SFHA boundary by more than 25 feet” Error Description: The following S_BFE line(s) undershoot or overshoot the SFHA boundary by more than 25 feet. Reference: Page L-272 in Appendix L states: The spatial elements representing BFE features are lines extending from Special Flood Hazard Area (SFHA) boundary to SFHA boundary. The BFE lines will have no visible gaps or overshoots between the SFHA boundary and the end of the BFE line at the publication scale of the DFIRM. Example: The example below shows how the end point of the BFE stops at the boundary between the AE zone and the AO zone. The BFE placement is actually correct, since AO zones are not supposed to have BFE lines. In fact, only AE zones without a static BFE should have BFE lines. (VE zones have transects, not BFE lines. Transect lines are part of a separate layer and are outside the scope of this check). Another example of where the BFE line does not extend across the entire SFHA, but the placement is actually correct is presented below. In this case, BFE lines end at a levee. Since the BFE value is different on either side of the levee, these lines will be allowed to pass as long as the end points are within 25 feet of a S_GEN_STRUCT feature: 2.3. Verify That BFE Lines Do Not Cross Check Description: This check verifies that no BFE line intersects with any other BFE line. If they do, the error will be called for the affected records. If up to 20 BFE records are affected, the ID numbers for each record will be given. If more than 20 records are affected, the count of the number of affected records will be given. This is the same reporting format used by the existing Auto report. Logic: If: S_BFE line does not overlap or touch another S_BFE line Then: Correct – Please move to next check Else: An error will be returned as: “Error 1303: The S_BFE line overlaps or touches another S_BFE line” Error Description: The following S_BFE line(s) overlap or touch another S_BFE line. Reference: Page L-272 in Appendix L states: Each BFE is represented by a single line. 2.4. Verify That the Vertical Datum for Cross Sections Match the STUDY_INFO table Check Description: This check verifies that the vertical datum listed for each cross section line is equal to the vertical datum cited in the study info table. The text values must match exactly. If they do not match, the error will be called for the affected records. If up to 20 records are affected, the ID numbers for each affected record will be given. If more than 20 records are affected, the count of the number of affected records will be given. This is the same reporting format used by the existing Auto report. Logic: If: S_XS V_Datum field is equal to the V_Datum field in the STUDY_INFO table Then: Correct – Please move to next check Else: An error will be returned as: “Error 1304: The S_XS line V_Datum attribute does not match the V_Datum attribute in the STUDY_INFO table” Error Description: The V_DATUM for the following S_XS line(s) do not match the V_DATUM in the STUDY_INFO table. Reference: The Study_Info table record is essentially a summary of the study information and is also used to print out the FIRM’s Legend and Notes To Users sections. Since the digital data is used to create the map, the datum between the digital XSs (Appendix L: pg L-351) and Study_Info (Appendix L: pg L-356) should be the same. 2.5. Verify That the Vertical Datum for BFE Lines Match the STUDY_INFO table Check Description: This check verifies that the vertical datum listed for each BFE line is equal to the vertical datum cited in the study info table. The text values must match exactly. If they do not, the error will be called for the affected records. If up to 20 records are affected, the ID numbers for each affected record will be given. If more than 20 records are affected, the count of the affected records will be given. This is the same reporting format used by the existing Auto report. Logic: If: S_BFE V_Datum field is equal to the V_Datum field in the STUDY_INFO table Then: Correct – Please move to next check Else: An error will be returned as: “Error 1305: The S_BFE line V_Datum attribute does not match the V_Datum attribute in the STUDY_INFO table” Error Description: The V_DATUM for the following S_BFE line(s) do not match the V_DATUM in the STUDY_INFO table. Reference: The Study_Info table record is essentially a summary of the study information and is also used to print out the FIRM’s Legend and Notes To Users sections. Since the digital data is used to create the map, the datum between the digital BFEs (Appendix L: pg L-272) and Study_Info (Appendix L: pg L-356) should be the same. 2.6. Verify that the panel-not-printed reason is populated for non-printed panels Check Description: If PANEL_TYP is populated with “Countywide, Not Printed” or “Community Based, Not Printed”, the code then checks whether PNP_REASON is populated. The field is determined to be populated if it contains at least one character between “A” and “Z”. Otherwise, this warning will be called. If up to 20 records are affected, the ID numbers for each affected record will be given. If more than 20 records are affected, the count of the affected records will be given. This is the same reporting format used by the existing Auto report. Logic: If: S_FIRM_PAN PANEL_TYP field is populated as Countywide, Not Printed or Community Based, Not Printed and the PNP_REASON is field populated with a string Then: Correct – Please move to next check Else: A warning will be returned as: “Warning 1306: The following S_FIRM_PAN polygon(s) have a potentially incorrect combination of attributes for PANEL_TYP and PNP_REASON: Warning Description: The following S_FIRM_PAN polygon(s) have a potentially incorrect combination of attributes for PANEL_TYP and PNP_REASON. Reference: The connection is inferred by the field descriptions of S_FIRM_Pan’s PANEL_TYP (Appendix L: pg L-286) and PNP_REASON (pg L-287). When the PANEL_TYP value includes “Not Printed”, the user must fill out the PNP_REASON field.