Regional Boat Traffic Model

Phase I

Dr. Louis Gross, Eric Carr, Jane Comiskey The Institute for Environmental Modeling (TIEM) University of Tennessee

Dr. Richard Flamm Fish and Wildlife Research InstituteFlorida Fish and Wildlife Conservation Commission

Long-range Model Goals

• Simulate boating traffic from facilities to destinations on a regional scale.• Develop a generic model that can be initialized with data from specific locations.• Provide the capability to evaluate outcomes of management scenarios.• Incorporate spatial information from biological models.

• Define model framework• Develop and test on generic landscape• Generate boating paths on landscape• Store and display paths

Phase 1 Goals

Model Description

Phase 1 Implementation

• Object-oriented model (C++)• Spatial resolution: flexible (30-m)• Spatial extent: regional (4500 sq km)• Time step: daily• Simulation time period: 1 year• Input/output: Shapefiles, Database• Visualization: ESRI ArcGIS shapefiles

Logical Model Components

• Master Mesh generation• Facility definition• Boat type definition• Destination selection• Path Generation• Database interface

Boating Facility Component

• Data:• Geo-referenced location on landscape• Set of boat types• Activity attributes

• Methods: Launch scheduler

Facility Locations (randomly selected)

Boat Type Component

• Model simulates and tracks representative trips by boat type rather than simulating individual boats.• Contains data specific to each boat type (draft, speed limitation, activities).• Each boat type holds a landscape map “trimmed” for draft and speed limitations.• Controls destination selection.

Boating Destinations

• Destinations randomly generated.

• Single destination per trip.

Landscape Components

• Shoreline• Trip origins/destinations• Bathymetry• Speed zones• Obstacles

Model Mesh Implementation

• Model stores and manages landscape information as a vertex-based mesh. • Generates a geo-referenced Master Mesh of designated size and resolution.• Initializes Master Mesh by a multi-step process utilizing ESRI ArcGIS tools to incorporate landscape data layers.

Model Mesh Functionality

• Holds vertex IDs and locations.• Defines vertex connectivity via edges.• Allows assignment of weights to vertices• Allows computation of distances between vertices along edges.• Edge weights are determined from vertex weights and distance between vertices.

Automatic Mesh Generation

• Non-trivial task due to :• Shoreline constraints• Application of data to nodes• Internal clusters• Scaling and connectivity issues

• Mesh utilizes a regular network of vertices• Horizontal, vertical and diagonal connectivity• Model designed to use any vertex /edge network

Automatic Grid-based Mesh

Zoomed View of Uniform Mesh of Vertices

Why a uniform mesh?

• Ease of implementation, given the scale (30m) and number of vertices (4.95 M). • Input parameters can be assigned across all vertices using shapefiles, leveraging ESRI ArcGIS capabilities. • Allows uniform definition of connectivity across all vertices.

Current Model Input/Output

• Open format• ESRI ArcGIS compatible• Designed to store points, lines, and multi-lines.• Shapelib info: http://shapelib.maptools.org/

Shapefiles

Trip Path Determination

• Objective: to generate a path that follows a reasonable route between a Facility and Destination.

• Path generation should consider obstacles and regulations (speed limits) in decision rules.

• Applicable to regional scale simulation.

• Executable on a desktop-based computing platform.

Dijkstra’s Shortest Path Algorithm

• The Dijkstra algorithm is a common method for determination of shortest paths within a graph or network.

• This method utilizes connectivity and weights of edges to determine a minimum cost path. Spatial location or spacing between vertices is irrelevant, allowing the use of any meshing configuration.

Mesh Viewed as a Graph

The generated mesh is viewed by the Dijkstra algorithm as a network or graph that has no spatial component.

Least Cost Trip Path

Implementation

• The C++ Boost Graph Library (www.boost.org) was used to implement the Dijkstra algorithm for trip path determination.

• Available memory limited the size of the graph processed to ~8.5 million edges.

• Computation time was approximately 30 seconds per map (8.5 million edges).

Results

• The Dijkstra algorithm computes paths from a given point of origin, such that the route to any other location from that point is determined.

• A single path is saved from origin to destination: the least cost path. Alternate routes of the same weighting are not stored.

• Routes are grown out from the origin, resulting in re-use of optimized route segments.

• These limitations allow a large graph to be processed in a reasonable execution time.

Trip Map

In this example simulation, the model generates ~ 3300 trips per year per facility. The map at right shows trip routes generated for a single facility over a 365 day simulation.

Model Database Objectives

• Provide search capabilities across the generated trip paths by facility, destination, time, and spatial location.

• Allow direct C++ database access for input and output.

• Future direct database access by ESRI ArcGIS products to create model inputs and analyze model outputs (replacing use of shapefiles).

Database Implementation

• Initially implemented as storage for individual boat model design.

• Design and performance would be similar within the current facility-based model.

• MYSQL database.

• MYSQL++ is used as the C++ interface within the model. http://tangentsoft.net/mysql++/

Database Tables

• Facility Table: contains IDs and related facility information.

• Boat Type Table : contains information defining the various boat types.

• Trip Table : indexed to both the Facility and Boat Type tables, the Trip Table contains the time, duration, distance, and path of a trip.

Trip Storage

• Trips were stored by saving each individual trip segment, so that a spatial and temporal search could be performed on stored paths.

• Segment storage results in a huge database at the current map resolution of 30 m.

• Implementation was successful but problems may arise as the number of trips increases.

Next Steps: Database

• Store input information from ESRI ArcGIS in database.

• Initialize model from database.

• Store trip paths in database.

• Implement ArcGIS access and search of model output stored in database.

ESRI ArcGis:Input to Database

• Current use of shapefiles for mesh implementation could be bypassed with direct storage of the mesh within the database.

• The goal is a complete definition of the model within the database prior to simulation, including parameter values for Facility and Boat Type.

OpenGIS® Simple Features Specifications For SQL

• The OGC SQL implementation allows for the storage of multi-lines within an SQL field.

• This may resolve the excessive number of entries associated with storage of segments.

• Spatial intersection tools exist for searches on SQL fields.

Trip Storage in Database

ESRI ArcGIS: Output Access

• Direct access by ESRI ArcGIS tools to trip paths stored in database will facilitate data exploration.

• Performance will be enhanced, as shapefiles were not designed to hold the volume of data the model is currently storing.

Next Steps: Model

• Adapt to specific regional landscapes• Calibrate with observation data• Explore visualization options• Develop alternate path-generation modules• Explore variable mesh spatial grids• Incorporate information from other models• Provide input for other models• Evaluate management scenarios

Next Steps: Mesh

• Variable mesh – allows variation in underlying mesh size to reflect changes in complexity of map layers, e.g. a nested change in resolution from 30 to 60 to 120 meter spacing.• Examine alternate mesh shapes. Triangles offer interesting capabilities for nesting and edge representation.

Boat Traffic Model

Example Simulation

Introduction

• Implementation of the Boat Traffic model is a multi-step process. This example demonstrates some of the steps in the mesh generation, configuration and implementation of the model.

Master Mesh• Generating and geo-referencing the master

grid is the first step in the mesh generation process.

• The bottom left corner of the map is georeferenced in space using the Albers Projection.

• The number of rows and columns as well as cell size is chosen.

• The vertex mesh is grown from the bottom left corner, implementing the appropriate number of rows and columns and calculating the geo-referenced offset positions for each vertex.

Location

General Parameters

• Bottom Left Corner: (510000,380000) (FDEP Albers HARN)

• Rows : 3000• Cols : 1650• Cell size : 30 meters• Vertices : 4,950,000• Total coverage area:

160,032,074 m2

• Shapefile size: 220 meg

Zoomed View of Master Mesh

Input Generation

• Mesh vertex points can be associated with e.g. bathymetry, regulatory areas, speed zones, facility locations, or destination locations as possible model inputs.

• An ESRI ArcGIS shapefile is generated for each map layer as an input to the model.

• The Master Mesh extracts data from these shapefiles for model implementation.

• Two input maps are currently designed for implementation: water mask and speed zones.

Water/Land Mask

• A bathymetry shapefile was converted to a 90 meter raster layer. 90 m was used to facilitate connectivity of vertices spaced at 30 m intervals.

• A cluster analysis was performed to identify and exclude all inland bodies of water.

• The primary sea-cluster was used as the simulation area.

• ~2 million of the 4.95 million mesh vertices are in water.

Water/Land Mask

The raster water mask, in combination with the Master Mesh, identifies the water vertices used in the model. Green vertices, representing land, will be trimmed away by the model during run time.

Speed Zones

• The model uses weights associated with the edges to determine optimal trip routes. Use of speed limits averaged between vertices and combined with the length of the edge provides a “time to traverse” that is used as an edge weight.

• Bathymetry values are used to represent speed zones for this test application. Values were capped at 30 mph outside of channels, which were assigned 35 mph.

Facilities

• Facilities are designated using ESRI ArcGIS tools for implementation by the model.

• The test example bypasses Arc assignment and uses a random placement of facilities.

• Ten facilities were generated for the run.

Destinations

• Destinations are also designed to be identified using ESRI ArcGIS tools.

• The test run randomly selects 2000 of the ~2 million active vertices as destinations.

• The destination for each trip is selected after launch.

• Outbound and inbound routes are identical.

Boat Types

• Two boat types are implemented in the model.

• No distinctions between boat types are currently modeled.

• Each boat type has its own launch queue and generates it own shortest path (Dijkstra) map.

Model Run

• The model runs over 10 boating facilities with 2 boat types at each facility, generating 20 shortest path maps over 8,193,464 edges.

• Complete run time: 10 min 20 secs or 30 sec per map generation.

• Memory usage: ~2 gigabytes

Trip Map

The model generates ~ 3300 trips per year per facility. The map at right shows trip routes generated for a single facility over a 365 day simulation.

Trip Density

A calculation of trip line density within ESRI ArcGIS for the previous trip map shows corridors of high use in the simulation.