Title of Paper: Computational grid generation modeling transport of pathogens in Lake Michigan

Title of Paper: Computational grid generation modeling transport of pathogens in Lake Michigan Authors Names: Peter N. Shedivy, Hector Bravo PhD Abstract: An estimated 1.2 million people, mostly young and elderly, die annually from waterborne disease worldwide (Hunter 1997). Research at the University of Wisconsin- Milwaukee is underway to develop a coupled biological and physical model to improve predictions of pathogen transport and fate in the Great Lakes coastal environment. Reliability of model predictions depends on accurate representation of the modeling domain, meteorological forcing fields, initial conditions, and boundary conditions. This paper describes the generation of the modeling domain using ArcGIS 3D Analyst and Spatial Analyst extensions. Irregular spaced data including bathymetry, coastlines, and harbor structures formed a triangulated irregular network (TIN) which was converted to a raster. A constant raster converted to a point feature class orientated parallel to the coast was assigned depth values from the converted TIN. A grid tool was created in AcrGIS Model Builder allowing future implementation. The Lake Michigan model currently runs on this grid. Paper Body 1. Introduction ArcGIS ArcInfo 9 contains many toolboxes, two of which are Spatial Analyst and 3D Analyst. Both tools are applied in developing the modeling domain for a coupled biological and physical model to improve predictions of pathogen transport and fate in the Great Lakes coastal environment. The task of creating this modeling domain is the result of current research being conducted at the University of Wisconsin-Milwaukee, Department of Civil Engineering and Mechanics. The project is entitled Predicting Pathogen Fate in Great Lakes Coastal Environment and is funded by NOAA Human Health Initiative. Currents in Lake Michigan and all coastal bodies of water are driven by the wind, bathymetry, temperatures, and the earth s rotation. Therefore, accurate representation of the bathymetry is one crucial task to develop reliable lake current predictions. Inaccurate bathymetry would create poor predictions of lake currents and hence the transport of pathogens. The capabilities of ArcGIS 3D Analyst and Spatial Analyst will readily solve the need for a highly resolved and reliable bathymetry. The Lake Michigan bathymetry makes up the modeling domain along the shores of Milwaukee County, Wisconsin, USA (Figure 1). According to the predefined model conditions, the domain encompasses north-south extent of 45,500 meters by 12,000 meters east-west along the shores of Milwaukee and its coastal neighbors. This domain contains 100 by 100 square meter cells, resulting in a 455 row by 120 column grid. Each grid square has to be assigned only one depth value representative of the entire cell area. A total of 54,600 cells will then need a depth assigned to them to provide an accurate 1

bathymetry. Since the Milwaukee coast is parallel to lines of longitude, the modeling domain must also be aligned parallel to the coast to maximize the number of cells that are not on land. In general, the modeling domain is quite complex, containing a marina, breakwaters, and ship docks. Fortunately, these features are easily represented by vector data type and the National Oceanic Atmospheric Administration (NOAA) is the source of all lake depths, shorelines, breakwaters, and pier structures in the Great Lakes(1). Figure 1a: Map of the study area for the transport model. Since depths or the bathymetry of Lake Michigan is a continuous surface, developing a continuous depth map in three dimensions is appropriate and ArcGIS Spatial Analysis and 3D Analyst are toolboxes that model surfaces well with either raster or vector data approaches. The analysis created the bathymetry surface using both, NOAA s vector data formed a TIN which was converted to a raster. The raster attributes of depth were then converted back to vector data, or a point feature class containing a 455 by 120 uniform grid which is oriented parallel to the Milwaukee coast. In this interpolation by creating the TIN first it will preserve the original data. The raster will then be a good approximation of the TIN based on raster cell size of 100 meters and some filtering. Since the raster will not be oriented parallel to the coast, a point feature class that is parallel to the coast will be assigned the depths values of the raster. For further reference to the ArcGIS Spatial Analyst and 3D Analyst tools, the reader is referred to the ESRI texts on the subjects (2, 3). 2

2. Data Source and Preparation 2.1 Source Data The sources of the data needed for the modeling domain is the National Oceanic Atmospheric Administration (NOAA) website (1). This website contains vector data (shapefiles) for download. Of interest are the soundings or depth values, the shoreline and breakwaters polylines, and a shoreline polygon. The data has a geographic spatial reference to the World Geodetic System of 1984 (NAD 83). This is an important part of the analysis, since the z-values of the downloaded data are in meters and their x and y values are in degrees. This vector data is the format used for creating a three dimensional surface called a TIN in the 3D Analyst toolbox of ArcGIS (4). Preparing the extracted data from the NOAA website was easily performed using common ArcGIS tools. The shapefiles of interest were only extractable at a large viewable scale. Again, the boundary of the model is approximately 12,000 meters north to south and 45,500 meters east to west, while the extractable viewable area of the soundings shapefiles from the web was approximately one-tenth of the 120 by 455 cell domain. Therefore around 10 different screens in all were downloaded for each feature of interest. 2.2 Preparing Downloaded Shapefiles The source data types were appended together and topology errors were corrected. All the downloaded shapefiles were added to ArcMap. The soundings shapefiles were all appended together using the Data Management Tool Append. This simply consolidated the 10 soundings, 10 coastline, and 2 break wall shapefiles into one sounding, one coastline, and one breakwater layer, respectively. The shoreline polygon was extracted at a small scale and consisted of only one shapefile. A view of this data is displayed in Figure 2 taken from ArcMap. The spatial reference of this data is the same as the format that it was downloaded in, namely the WGS 1984(NAD1983) coordinates. Next the Data Management Tools in ArcMap, Add XY Coordinates Tool was applied on the soundings shapefile. The attribute table of the soundings shapefile now contained latitude and longitude coordinates, and its original depth value. 3

Figure 2: Source data downloaded from the NOAA website which includes the soundings, breakwaters, shoreline, and shoreline polygon. Topology errors existed in the source data. The shoreline had breaks in it that needed to be connected in random segments. Any breaks in the shoreline will result in an incomplete TIN. To correct these errors, an ortho-rectified aerial photo(5) with a raster resolution of 30 meters was added to ArcMap and the features were overlaid. By using the Editor Toolbar, topology errors in the shoreline were corrected manually. Automated methods of correcting topology errors using ArcGIS tools can be found in Huxhold et al(6). 2.3 Creating a Custom Map Projection The spatial reference of the source data, WGS 1984, is one of the many geographic spatial references available in ArcGIS. Therefore projecting the source data can be done easily. A map projection is now needed in order to view the data in threedimensions using ArcScene, to create the final raster cell size of 100 meters, and for use 4

of the 3D Analyst Tools. The projection chosen is a custom Lambert Conformal Conic projection. This projection uses a flattened cone and projects the latitude and longitude (3D coordinates) values of degrees to meters (2D coordinates). The resulting coordinates of all the projected shapefiles will have X, Y, and Z values in units of meters. The input parameters for defining the projection in ArcCatalog are based on the location of modeling domain and follow conventional rules of creating projections for maintaining accuracy, which can be found in ESRI s text on map projections(7). These parameters include: Central Meridian: -87.84 degrees Standard Parallel 1: 42.911 Standard Parallel 2: 43.056 Latitude of Origin: 42.77 Linear Unit: Meters Geographic Coordinate System: WGS 1984 The custom map projection has been named mke.prj. The shapefiles were then added to ArcMap and the display was changed to the map projection mke.prj. As the data is now displayed in ArcMap in units of meters, each shapefile was exported and assigned the same coordinate system as the data frame. This step is necessary because the Add XY Coordinates Tool (discussed below) would otherwise assign the WGS 1984 coordinates to the attribute tables, and not the mke.prj in units of meters. The original 4 shapefiles were preserved and from then on the 4 newly exported shapefiles were used. These shapefiles obviously only differ by their spatial reference, the old one having a geographic reference and the updated shapefiles have a projected reference. The attribute table of the soundings shapefile now has five attributes, the new X and Y projected coordinates, the old latitude and longitude geographic coordinates, and the original depth value in meters. Figure 3 shows the shapefiles displayed with all three dimensions using ArcScene. Figure 3. A view from ArcScene. The TIN boundary for the TIN is made transparent and the soundings base heights have a z unit conversion of -10. 5

2.4 Creating the boundary for TIN input Additionally, a boundary polygon used as TIN input needs to be created in ArcMap using the ArcEditor tools. The exact purpose of this is discussed below, but a polygon that encloses the soundings data and exactly matches the shoreline will serve as a boundary in the TIN creation. The four exported shapefiles (which now display in the mke.prj) are added to a new ArcMap session. Using the Arc Toolbox under the Data Management Tools, a new polygon type feature class was created. The spatial reference of the new shapefile is set to same as display under the Environments tab to assure that the newly created feature class will have the mke.prj as a spatial reference. The boundaries on the north, south, and west end do not coincide with the modeling domain and extend beyond the grid. Next, the Editor Toolbar in ArcMap was initialized to draw the boundary polygon. The boundary polygon was drawn to coincide with the west shoreline and border the north, west and south sounding points. However, the west boundary or shoreline needs to be traced exactly. The depths of zero and shallow water especially around beaches are critical for the transport model. This boundary will serve as a mask in the raster creation. Additionally, a second TIN boundary that does not trace the west shoreline carefully but extends inland was created and later will be used as TIN input. The newly created TIN boundary polygon is displayed in ArcMap shown in Figure 3. 2.5 The Geodatabase Other than the aforementioned data preparation procedures, the only other data preparation for the vector data was to convert the downloaded shapefiles to the higher form of spatial data in ArcGIS, a feature class in a personal geodatabase. This is not needed for use of the remaining tools but is simply the higher and preferred form of spatial data currently. More on geodatabase design can be found in Zeiler (4). This geodatabase contains all the information involved in creating the 3D model. The data is ready for analysis using ArcGIS 3D and Spatial Analyst Tools. 3. 3D Analyst 3.1 Tin Creation A triangulated irregular network or TIN is a continuous surface made up from a set of points with elevation. Triangulated refers to the forming of an optimized set of triangles from a set of points, irregular refers to the surface can be modeled with a variable density of points, and network refers to the topological structure in the TIN necessary for spatial analysis (4). A TIN is created by multiple feature classes containing point, line, and polygon geometry types (4). ArcGIS uses the Delaunay triangulation algorithm to optimize how the triangle faces model the surface. This algorithm is commonly used when modeling surfaces, for example Matlab and IDL software s have this function built in to create surfaces from points. A TIN models a surface well and is more accurate than a raster surface model because the resolution of the surface in a raster is limited to the cell size (4). Sharp 6

discontinuities in the surface like the breakwaters and shorelines are hard to resolve in a raster. A TIN can easily distinguish hard break line features such as the breakwaters and shoreline. TIN creation started by the launching of ArcScene, displaying the 3D Analyst toolbar, and verifying the Scene Properties are set to the spatial reference of the mke.prj. The 4 feature classes were then added to ArcScene; soundings, shoreline, breakwater, and TIN boundary. Additionally, the shoreline polygon was added to include the rivers in the TIN and for visualization purposes. Under the 3D Analyst toolbar the Create TIN from Features Tool was then utilized. The soundings were triangulated as mass points with their height source set to their z attribute field, the shoreline and breakwater polylines were triangulated as hard break lines with their height source field set to zero, and the TIN boundary was used in the triangulation as a hard clip eliminating absent data outside the soundings area for interpolation into the TIN. The shoreline polygon was used as a hard fill in the TIN creation with a height source of zero. This assigned a constant z value of 0 on the face of the shoreline polygon. This boundary did coincide on its east side with the shoreline polyline. Worth mentioning, is that if any feature classes used here had no attribute field with z values of zero, then they were created. A summary of the TIN input is given in Table 1. The resulting TIN is displayed in Figure 4 with its symbology set to face elevation with a graduated color ramp, and its base heights modified with a z unit under conversion of negative ten to account for bathymetry and a multiple of ten due to the small vertical to horizontal extent displayed. After all, the maximum depth is 120 meters which is a fraction of the horizontal extent. Layer Height Source Triangulate As Soundings Z Mass points Shoreline Z = 0 Hard breakline Breakwater Z = 0 Hard breakline Dredged Depths Z Hard fill TIN Boundary NO VALUE Hard clip Shore Land Z Hard fill Table 1. Input feature classes used in the TIN creation. An additional input feature for the TIN can be added simply by accessing the Modify TIN tool under the 3D Analyst Toolbar. This tool was used between the shore land and breakwaters near the confluence of the Milwaukee River and Lake Michigan, where the bottom surface is dredged for the port of Milwaukee. The dredged depth polygon was extracted from the NOAA website and was triangulated as a hard fill with its height source set to its respective z field (Table 1). The resulting TIN is shown in Figure 4 below. 7

Figure 4. A small scale view (left) and a large scale view (right) of the created TIN. The breakwater and shoreline (right) are accurately represented in this surface model. 3.2 TIN to Raster Since the conversion of the breakwaters to a raster will produce poor results at a 100 meter resolution, another TIN is created without using the breakwater. Additionally, since the modeling domain will not contain the rivers, the boundary created previously does close the gap caused by the river confluence. This boundary was used as a mask in the TIN to raster conversion. In ArcScene, the 3D Analyst Toolbox was used to convert the TIN to a raster. The output raster data was set to a 100 meter cell size, used the nearest neighbor method of conversion, and was masked with the newly edited boundary. The raster is displayed in Figure 5. Figure 5. The raster resulting from the TIN. The boundary used for the mask is displayed at 70% transparent allowing the water surface to be visualized. 4. Spatial Analyst 8

4.1 Introduction Thus far, the modeling domain of 54,600 cells encompassed a rectangle that is not parallel to the coast and a coordinate transformation of the raster to align it with the coast would contain incorrect depth values. However, a uniform point feature class centered at each raster with only X and Y values as attributes was created to perform a coordinate transformation on. Using the Spatial Analyst Toolbox under Extraction, the Extract Values to Points tool was then used to assign the raster depth values to the transformed point feature class. The attributes of the final point feature class then contained the original X and Y coordinates in the mke.prj, but also the depths referenced to the transformed coordinates. The table of attributes was then exported and used as the modeling domain in the transport model. 4.2 100 meter by 100 meter Grid Generation Using the Spatial Analysis Toolbox, the Raster Creation tool was used to create a constant raster matching the extent of the modeling domain. The output cell size was 100 meters and the spatial extent follows; 45500 north, 0 south, 12000 east, and 0 West. In the Conversion Toolbox, the Raster to Point tool was used to convert the raster to a point feature class with points centered at the raster center. The lower southwest corner cell coordinates were identified as (X, Y) ~ (50m, 50m), although the attribute table did not contain these coordinates. Therefore the add XY Coordinates tool was used to add these coordinates as attributes to the feature class. This geoprocessing took 15 minutes to complete, depending on computer processor speed and memory. Both the raster and point feature class are shown below in Figure 6. Figure 6. The constant raster created (far left) set at 50% transparent, the converted point feature class (inner left), the coordinate transformation performed on the point feature class aligning the grid with coast (inner right), and finally the transformed grid assigned depth values from the underlying raster (far right). The transparency of the far right grid is at 50%, allowing the depths assigned from the bathymetry raster to be visible. 9

4.3 Rotated and Translated Grid Two new attribute fields in the grid file needed to be added to store the new X and Y transformed coordinates. These coordinates would then be used to create another grid rotated and translated to match the modeling domain. Predefined model conditions for the domain in addition to the spacing and number of points, is a rotation of 12.5 degrees counter clockwise and a translation of 1225.65 meters east for each point. The new fields were named X_rot_tran and Y_rot, since the translation was only in the horizontal direction. An editing session was then initialized and the two new fields were calculated using the following transformation equations: 12.5π 12.5π X _ rot _ tran = 1225.65 + X cos + Y sin () 1 180 180 12.5π 12.5π Y _ rot = X sin + Y cos ( 2) 180 180 After saving the edits, the attribute table was exported to a database file (dbf) and given a new name. The new table contained X and Y values, but did not contain any features displayable on a map since it was just a dbf file. In ArcCatalog, the exported table was used to create a feature class from its XY table. The new feature class X field was assigned the X_rot_tran field, the Y field was assigned the Y_rot field, and the spatial reference was set to the mke.prj. The feature class was previewed in ArcCatalog and then displayed in ArcMap to assure no errors were made. The rotated and translated uniform grid is shown in Figure 6. 4.4 Assign Raster Depths to Grid In ArcMap, the raster created from the TIN and the transformed grid were displayed. In the Spatial Analysis Toolbox, the Extraction toolbox was used and the Extract Values to Points tool opened. This tool extracts the bathymetry from the raster cells to the rotated and translated grid points. Since the point file will no longer coincide with the center of the raster cells, depths will be interpolated from surrounding cells and this interpolated value assigned to the grid point. All the attributes of the input raster and the input point shapefile were included in the output point feature class. The new point feature class attribute table was then exported and became the model domain for input to the transport model. It contains 54,600 rows ordered from west to east and north to south relative to its location in ArcMap. 5. Analysis Results 5.1 Smoothing Raster Surface Although the raster in Figure 6 does represent the bathymetry well, some slopes are too great which caused instabilities in the transport model. This problem was resolved by using the Filter tool in the Spatial Analyst Toolbox. The filter was set to low which then averaged each cell with its surrounding eight cells, resulting in a smoother surface 10

shown on the right in Figure 7. The filter tool was performed twice to achieve model stability. Figure 7. The roughness in the bathymetry along the coast south of the harbor caused the transport model to become unstable. The unfiltered bathymetry (left) and the filtered bathymetry (right); although there is not much difference, this filtering created model stability. The filtered raster was used to assign depths to the final grid. 5.2 Transport Model Predictions The transport of pathogens depends on the currents in the lake. Using the modeling domain created in this analysis, the transport model was run for a three week period during which velocity measurements existed. The model predictions compare well with the measurements as shown in Figure 8. 5.3 Future Implementation During the ArcGIS analysis, many toolboxes were utilized and rather than complete the entire procedures over for a different location or to add new data as it becomes available, a grid generation tool was created using ArcGIS Model Builder. From the source data to the generated raster, Figure 9 shows a flow chart of the steps taken for this analysis. This grid tool allows future implementations of the method used herein. 11

Figure 8. Comparison of model predictions and measurements is routine in calibrating any physical model. A measured three week period of velocity at a monitoring location at a depth of 19 meters compared well with the model predictions. From top to bottom are the east-west currents, the northsouth currents, and the magnitude of the currents. Measurements are designated by tick marks. 12

Figure 8. A grid generation tool flow chart. This tool can be simplified to converting the source data to the end product of the raster. This tool is useful for future implementation of grid generation. 13

6. Conclusions Successful modeling of circulation and transport in a lake requires accurate and appropriate representation of the modeling domain and the driving mechanisms. In the case study presented here the driving mechanisms are atmospheric forcing (wind, cloudiness, air temperature, and dew point), flow from tributaries, effect of the Earth s rotation, and the flow and thermal conditions at open boundaries. Appropriate representation of the modeling domain requires a balance between detail and scale. Bathymetry, shoreline, and existing structures have to be represented in enough detail. On the other hand, lake circulation models are designed to solve problems at a certain scale, and too much detail can lead to problems such as numerical instability. Modeling is a combination of science and art, and ArcGIS provided in this case an excellent and efficient tool to strike a balance between detail and scale. Acknowledgements This research has been supported by the National Oceanic Atmospheric Administration. The following faculty and staff at the University of Wisconsin-Milwaukee contributed to the authors academic advancement in the area of ArcGIS; Professor William Huxhold and Eric Fowler of the School of Architecture and Urban Planning, along with student help from Joyce Witebsky. Additional thanks to ESRI. Appendixes None End Notes None References 1. US Department of Commerce: National Oceanic Atmospheric Administration; Available: http://ocs-spatial.ncd.noaa.gov/encdirect/viewer.htm.accessed: June 18 2006. 2. ESRI, ArcGIS 9 Using ArcGIS Spatial Analyst, Environmental Systems Research Institute, Inc. 2004. 3. ESRI, ArcGIS 9 Using ArcGIS 3D Analyst, Environmental Systems Research Institute, Inc. 2004. 4. Zeiler, Michael, Modeling Our World: The ESRI Guide to Geodatabase Design, Environmental Systems Research Institute, Inc. 1999. 14

5. Environmental Remote Sensing Center, Space Science & Engineering Center, University of Wisconsin-Madison. Available: http://www.wisconsinview.org/. Accessed: June 20, 2006. 6. Huxhold, William, Fowler, Eric M., Parr, Brain, ArcGIS and the Digital City: A hands on approach for local government, Environmental Systems Research Institute, Inc. 2004. 7. ESRI, ArcGIS 9 Understanding Map Projections, Environmental Systems Research Institute, Inc. 2004 Author Information: Primary Author Peter N. Shedivy Research Assistant University of Wisconsin-Milwaukee Department of Civil Engineering and Mechanics 3200 N. Cramer Street Milwaukee, WI 53211 US 4145304644 shedivy@uwm.edu Co-Author Dr. Hector Bravo, Ph.D. Associate Professor University of Wisconsin-Milwaukee Department of Civil Engineering and Mechanics 3200 N. Cramer Street Milwaukee, WI 53211 US 4142296229 hrbravo@uwm.edu 15