Flood Map Desktop™

1. Flood Map Desktop™ Case Studies

2. Background • FEMA’s DFIRM Tools will be decommissioned July 31, 2010. • Several FEMA Lunch & Learn sessions hosted to guide users. • Alternatives to DFIRM Tools are needed to produce flood hazard mapping for FEMA. • FMD is a tool available as a DFIRM Tools replacement.

3. Premise • Many AWRA members engaged in FEMA flood mapping projects • To date, many users have transferred FEMA projects from DFIRM Tools to FMD • Review a few use cases highlighting user experiences transferring between the systems and creating new products for FEMA

4. Case Study #1 – Sherburne, MN transfer data from DFIRM Tools to FMD

5. Case Study #1 - Sherburne, MN • 42 Printed FEMA Maps • 312 Cross Sections • 3 detailed streams • 7,375 Transportation Features • Provided with an ESRI personal geodatabase containing all spatial layers, non-spatial tables, annotation feature classes

6. Case Study #1 - Sherburne, MN

7. Case Study #1 - Sherburne, MN • Font Transfer • Issue: FMD contains FEMA symbology, but DFIRM Tools system dependent on custom MapText fonts for features such as cross sections and road shields • Solution: Download MapText fonts from FEMA’s MIP website and load into local PC c:\windows\fonts. Resolves all symbol and font transfer issues from DFIRM Tools.

8. Case Study #1 - Sherburne, MN • Example of with and without MapText font results

9. Case Study #1 - Sherburne, MN • Example of with and without MapText font results

10. Case Study #1 - Sherburne, MN • Import DFIRM Tools data to multi-user format • Issue: After data import, user wants to retain multi-user cartographic production in a personal geodatabase • Solution: DFIRM Tools annotation layers imported to a FMD ELM annotation database type.

11. Case Study #1 - Sherburne, MN ELM Disconnected multi-user cartography Connected multi-user cartography

12. Case Study #1 - Sherburne, MN

13. Case Study #1 - Sherburne, MN • Import DFIRM Tools data to FMD • Issue: Data transfer is large – “out of memory” errors generated for many computers. • Solution: Data imported to personal geodatabase in two stages: • Spatial and Non-Spatial FEMA layers • Annotation Feature Classes. • Solution: Compact final database.

14. Case Study #1 - Sherburne, MN

15. Case Study #1 - Sherburne, MN • Data transfer quality control • Issue: Transferring data from one system to another can introduce error from: tolerances, topology rules, user errors, and other database settings. • Solution: Discover and solve errors with database queries, topology rules, and error reports.

16. Case Study #1 - Sherburne, MN

17. Case Study #1 - Sherburne, MN • Error discovery results: • 6 layers containing significant topology errors • Violating 21 topology rules • 49,720 total topology errors discovered • 54,542 total database errors discovered

18. Case Study #1 - Sherburne, MN • Final Steps: Review Cartography & MIP Upload • Some minor issues discovered in cartographic placement as result of system transfer. Manually review time approximately 5 minutes per FEMA map, total of 3.5 hours for this case. • MIP upload produced no errors.

19. Case Study #1 - Sherburne, MN

20. Case Study #1 - Sherburne, MN

21. Case Study #1 - Sherburne, MN

22. Case Study #2 – Marion, IN distributed processing using non-enterprise tools

23. Case Study #2 – Marion, IN • Highly urbanized area - contains the City of Indianapolis • 97 Printed panels • 914 Lettered Cross Sections • 47 detailed streams • 26,000 transportation features • 26 LOMRs to be incorporated • Less than 1 month from start of panel production to QR3 submission

24. Case Study #2 – Marion, IN Data Edits Cartography w/ ELM file type Reconcile GRF into ELM Final Export and FEMA MIP Delivery QA Loc #1 Data Copy Cartography w/ GRF file type Loc #2

25. Case Study #2 – Marion, IN • Custom Workflow Explained • Non-enterprise system desired • Very fast client deadline • Multi-location, multi-user functions desired • Internet/WAN connection speeds inadequate

26. Case Study #2 – Marion, IN • ELM & GRF file types • ELM: Element database. MS Access based w/out MS locks, multi-user ability for cartographic elements, data stored as blob type. • GRF: Exported Graphics File. Integrated with ELM data type. Exported from project, imported to ELM. The files work in concert to facilitate a cartographic workflow.

27. Case Study #2 – Marion, IN • MS Access personal geodatabase is locked to multi-user editing. • ELM element database for cartographics is not locked .

28. Case Study #2 – Marion, IN

29. Case Study #2 – Marion, IN

30. Case Study #2 – Marion, IN • Conclusions • Low IT investment v. enterprise system • effective method for multi-user multi-location processing • Custom workflow must be created per-project, documented, and distributed to project team • Processing speed is very fast to meet tight client deadlines • Assign data manager (and a back-up) – similar to DBA • Consider multi-location access to data instead of copies if technologically/financially feasible • Can be some cartographic overlaps – QA process resolves.

31. Case Study #3 – Recreation of ArcSDE environment distributed processing using enterprise tools Case study slides provided by CDM Contact Mike Schultz or Gaston Cabanilla for further info

32. Case Study #3 – Recreation of ArcSDE environment • User desired to re-create ArcSDE experience w/out DFIRM Tools • Multi-user data editing • Single datastore w/ multiple users and locations • Higher degree of workflow standardization • Centralized quality control Case study slides provided by CDM Contact Mike Schultz or Gaston Cabanilla for further info

33. Case Study #3 – Recreation of ArcSDE environment • Issue: labor intensive creation of schema to extensive FEMA database specifications. • Solution: FMD schema imported with ArcCatalog Case study slides provided by CDM Contact Mike Schultz or Gaston Cabanilla for further info

34. Case Study #3 – Recreation of ArcSDE environment • Issue: Custom workflow used for production • Solution: Self-customization of the imported schema. • Alteration of schema does not interfere with FMD functions. • In this example, we added the “Supplemental” feature dataset to meet custom data management procedures. Case study slides provided by CDM Contact Mike Schultz or Gaston Cabanilla for further info

35. Case Study #3 – Recreation of ArcSDE environment • Disconnected databases offer an excellent solution. Data may be shared between offices without losing SDE identity. This allows data to be “checked in” and conflicts will be detected. • Issue: Efficiency and slow data editing speeds • Solution: WAN connections too slow for production but LAN connections had minimal speed loss Case study slides provided by CDM Contact Mike Schultz or Gaston Cabanilla for further info

36. Case Study #3 – Recreation of ArcSDE environment • Conclusions • Centrally stored database • Tightly managed workflow • Increased QC efficiency as all edits are posted to a single database • Customized to our process, not someone else’s process to maximize our production efficiency • Disconnected editing, while an effective solution, requires additional coordination efforts Case study slides provided by CDM Contact Mike Schultz or Gaston Cabanilla for further info

37. Case Study #4 – Extend FMD Tools extend FMD tools to include user-specific needs Case study slides provided by CDM Contact Mike Schultz or Gaston Cabanilla for further info

38. Case Study #4 – Custom Tools • Issue: High-volume producer for FEMA needs rapid software change and custom tools • FEMA replaces old QA/QC Pro database validation tool with the DVT. • The DVT introduces new requirements, some of which are not contained in the existing FMD export tool. • FEMA is not allowing exceptions for legacy data and is resistant to extending deadlines • Mapping partners need to get creative Case study slides provided by CDM Contact Mike Schultz or Gaston Cabanilla for further info

39. Case Study #4 – Custom Tools • Solution • Our developers design a stand alone ArcGIS Toolbar which pulls data from the FMD ArcSDE database, automatically reformats and exports to the required submittal formats • Process is kept simple and effective Connect to database Render (optional) Add layers Export Case study slides provided by CDM Contact Mike Schultz or Gaston Cabanilla for further info

40. Case Study #4 – Custom Tools • Solution • Export selected files – no need to re-export entire database for a correction in one file • Export to Basemap, Floodplain and Final DFIRM deliverables • Export shapefiles only for DVT test run Case study slides provided by CDM Contact Mike Schultz or Gaston Cabanilla for further info

41. Case Study #4 – Custom Tools • Conclusions • Simple interface written in VBA using existing ArcGIS capabilities • Highly effective – first round DVT pass rate is nearly100% • Does not interfere with FMD functions • Development costs have been recovered many times over. Case study slides provided by CDM Contact Mike Schultz or Gaston Cabanilla for further info

42. CDM Contact Info • Mike Schultz, GISP, CFM – schultzmd@cdm.com • Gaston Cabanilla, PE, CFM – cabanillaga@cdm.com

43. Conclusions

44. Conclusions • Importing data from DFIRM Tools is a simple process, but requires quality control measures for minor adjustments post-import. • Multi-user multi-location project processing is possible, fast, and inexpensive, but custom workflows and a cohesive team are required. • ArcSDE schema and custom tool development for organizational change improves unique processes and no FMD interference.

45. Contact • floodmapdesktop@pbsj.com • www.floodmapdesktop.com • Free downloads, forum, product information • Twitter: @floodmapdesktop • Facebook: Flood Map Desktop • Joshua Price, PBS&J • 303.221.7275, jpprice@pbsj.com

46. Questions. www.floodmapdesktop.com