Download Document

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 Institute
Florida 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.
Phase 1 Goals
• Define model framework
• Develop and test on generic landscape
• Generate boating paths on landscape
• Store and display paths
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
Shapefiles
• Open format
• ESRI ArcGIS compatible
• Designed to store points, lines, and multilines.
• Shapelib info: http://shapelib.maptools.org/
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.
Trip Storage in Database
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.
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 georeferenced 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.