Turnpike Enterprise Use of Tele Atlas GIS Data

Turnpike Enterprise Use of Tele. Atlas GIS Data for Transportation Modeling presented to GIS Committee presented by Eric Songer, URS Corporation 11/20/2008

Agenda Context What we did What we are doing Where we believe we should go Discussion 1

Context “Data Driven” Approach • GIS database is key • Start with best available data • Refine and constantly correct data Modelers and GIS Analysts work closely • Hand off point is fluid • Modelers use Arc. GIS to edit database 2

Tele. Atlas Data for Transportation Modeling What We Did Turnpike State Model Tele. Atlas “features” Spatial/Geometry Issues Attribute Issues 3

Turnpike State Model Statewide County Building Blocks Used shapefiles from Tele. Atlas Duplicate arcs removed Chaining of arcs done in Fennessy’s software 4

Tele. Atlas “Features” Duplicate arcs to represent multiple names County basis has duplicate arcs between counties Attribute fields not needed for modeling Attributes needed for modeling Unique ID field Dynamap_ID 5

6

Spatial Geometry Issues Duplicate arcs cause headaches Geometry links up in 3 dimensions Does not contain every road Does not contain future roads 7

Attribute Issues Occasional errors (don’t assume they’re correct) FZLEV or TZLEV = -9 are duplicate arcs Does not have capacity, counts, and network identification Has address and labeling information 8

Lessons Learned Separate county files are logistic problem Never missed duplicate arcs or discarded fields Need to have capability to “Check in” numerous editors versions Maintenance, Maintenance… Can’t rely on anybody’s data “as is” or you will be wrong Modelers can edit in Arc. GIS with little training 9

Tele. Atlas Data for Transportation Modeling What We Are Currently Doing Context Versioned ESRI geodatabase Model runs are snapshots of database 10

Context Regional Models (Lee-Collier, Central Florida) Continual refinement of all processes Lee-Collier complete Central Florida being built 11

Versioned ESRI Geodatabase Personal Arc. SDE (SQL Server Express) Editors get Personal GDB (Access based) Checked in by data administrator No longer separate county files 12

Model Run Snapshots Shapefile is exported for input to model Separate shapefiles for Existing and Future conditions Shapefile and associated model files can be archived 13

Lessons Learned Tradeoff between speed and duplication The Devil is in the details You are never done It can always be better 14

Tele. Atlas Data for Transportation Modeling Where we are going Routine Maintenance of Data • Regular Updates of Tele. Atlas • Transaction File • Many small updates True Geodatabase or Route System Basis Finished Models are Archived as Snapshots/Versions 15

Regular Maintenance Get quarterly updates as Transaction Files Automate update where appropriate Expect we will always need to manually fix some areas 16

True Geodatabase Believe a cascading update structure can be built Better way to store data Spatial views Versioning 17

Archiving Multiple dimensions to problem of archiving Not only documentation Need to be able to resurrect that model for future work 18

Food for Thought Arcs must be “Chained” Doesn’t need to be done in model software Data Driven and Model Centric approaches both have tradeoffs Data side is constantly being updated by third party 19

Questions ? Eric Songer 850 -402 -6327 eric_songer@urscorp. com 20