Data Storage and Dissemination Outline

Past/Existing data management overview

Future data management:

• Goals

• Broad description of proposed solution

• Key details of proposed solutions

Challenges and lessons

Next steps

Data Systems General Architecture(Past)

TRAVELDEMANDMODEL

TIP DB

EXISTINGTIP

APPLICATION

MTP DB

EXISTINGMTP

APPLICATION

GIS:Coverages

& Shapefiles

Question: What would be different about future regional transportation system performance with or without certain projects?

LANDUSEMODEL

Goals of proposed “Enterprise” Solution:

Support model suite enhancements and future possibilities

• Process automation

• Quicker model run and analysis turnaround

Support planning policy framework (Plan<->TIP<->PSRC project Approval)

General efficiency and increased capability:

• simultaneous multi-user access

• automated data validation

• In-your-face metadata

Solid foundation for region-wide data sharing and publication (WWW)

(note WA-TRANS FGDC Transportation Framework pilot, Summer 2005)

VisionI am a Park & Ride...

...with 200 stalls

...with 20 bike slots

I am an airport......generating 20,000 person-trips am peak...with 689 based passenger aircraft

I am a freight depot......generating 500 truck trips in am peak...attracting 400 truck trips in am peak...attracting 25 air freight landings ampeak

I am a bus station......receiving 20 buses in am peak...sending out 19 buses in ampeak...handling these routes... ...Metro 242 ...ST 101

I will be a train station in 2015......receiving 10 trains in am peak...sending 10 trains in am peak

I am a multi-modal link.....on HSS...named SR-99...with 2 GP lanes north and south...with a class three bicycle lane NB...related to trans. model link #224

I monitor SR-99......on MM/DD/YYYY in am peak hour... ...4,500 cars northbound ...4,900 cars southbound ...38 bicycles southbound

I am a link improvement......in the MTP...modeled in package X5...on SR-99...to be complete in 2020...resulting in...

I am an analysis zone......of type "Urban Center"...named "Seatac"...within county "King"...with 19,345 residents in 2000

Browsing Application Concept7-15-02

RDBMS

MAINTENANCE

APPLICATION

TRAVEL MODEL I/O

APPLICATION

GENERAL USE

APPLICATION

TIP DB

MTP DB

TRAVELDEMANDMODEL

EXISTINGTIP

APPLICATION

EXISTINGMTP

APPLICATION

System Architecture Transportation Components (After)

GIS:Coverages

& Shapefiles

LANDUSEMODEL

?

GEODATABASE

ANY LEGITIMATE CLIENT…

Key Feature: Integrated Data Model

Transportation Network (in progress)

• Multimodal: One edge layer plus one junction layer for ALL modes (the “reference network”)

• Granular: Ref net spatial layers plus related attribute tables encapsulate attributes for both directions and all times of day for present AND future possibilities

• Dynamic: Possible future state(s) of the network determined by queries at runtime NOT in data

Land use and demographic data (future)

• Controlled: Results of data processes are “published” (along with metadata) once

All data is transparent: accessible to all

Data is secure: editable to few

Transportation Reference Network: Users’ view

Transportation: a Project-based Approach

“Project” defined (for the data system):

Future event with completion date

Geographic location

Alters transportation system

Can be modeled

Key feature: future year networks derived from operation on reference and project layers

BASE YEAR NETWORK FUTURE NETWORKFUTURE PROJECTS

+ =

Key feature: model automation

Automated, query-based scenario creation

• In/out service years

• Other selection criteria (optional)

• Other rule-based network thinning (optional)

Automated travel model (in progress) and LU model (future) inputs generation

Automated travel model (in progress) and LU model (future) forecast retrieval into Geodatabase

Key feature: data maintenance support

Software “helper” application together with server features…

• Ensures validity across all dependant layers

• Maintains relationships between different databases

• Maintains metadata (such as datestamps)

Overview of Applications

MAINTENANCE

APPLICATION

MODEL I/O

APPLICATION

GENERAL USE

APPLICATION

GEODATABASE

TIP DB

MTP DB

TRAVELDEMANDMODEL

EXISTINGTIP

APPLICATION

EXISTINGMTP

APPLICATION

RDBMS

For power GIS and database managers:to manage the geometric network and project data, including editing and maintenance functions

11

For transportation modelers:To convert the geometric network and projects data to EMME/2 format and vice versa

22

For general users with little or no GIS experience:A user friendly mapping interface to query and display projects and other business data

33

Additional Option:

Scan project DB’s for all projects that need to be mapped

Maintenance Application:User View

Maintenance Application: Mapping a project

General Use Application:Data Loading and Metadata

Model I/O Application: Create an EMME/2 Input Scenario

Model I/O Application:Create an EMME/2 Input Scenario (Cont.)

Model I/O Application:Display Model Output to Geodatabase

Status

Transportation: in beta test cycle

Demographic & LU data plus any supporting application(s): about to restart design

External data import/export: future

Lessons Learned

Migrating legacy data to new system: more huge than you ever think

Software and data model development: proceed together in many small steps

Question: your data integration success stories or lessons?

Questions?

Key lesson: Many small cyclical steps

Each iteration of schema prompts application update…

…application test reveals data or schema issue…

…which when fixed allows a new application feature to be attempted…

…for which the feasible application solutions prompt a schema update…

Key challenge: Discovering what new capabilities and limits are present in commercial software

Geometric network (only feature available when project started) exposes insufficient spatial relationship tools

New relational database capability is significant advance…but has performance and functional issues

Stock loading and validation tools cumbersome and implement only part of underlying data provider capabilities

Key lesson: migration timing and planning

Document the migration (in detail) so that the entire process can be repeated easily

Revise migration plan with each schema/application iteration to foresee migration implications

Data migration is the bulk of the work

Assume more manual work than marketing flyers imply

GIS Contacts at PSRC

Jeff Frkonja Senior PlannerPuget Sound Regional Council206-464-6180jfrkonja@psrc.org

Andy NortonSenior GIS AnalystPuget Sound Regional Council206-464-7527anorton@psrc.org

Transportation Layer: TransNexus

Project Event Editing

General Use Application: Display Projects or Model Results

Geodatabase

New Enterprise Data Model (Transportation)

Project RouteFeature Class

Transportation Reference Network: Junction and Edge

Feature Classes

MTP Projects:ProjectIDTitleDescriptionCostSponsorEtc…

TIP Projects:ProjectIDTitleDescriptionCostSponsor$ ProgrammingEtc…

Transit Routes

Trans Nexuses

Other…

• PSRC Edge ID

• Direction (From/To Node)

• Modes

• Design Characteristics

• Speed limit

• In/out service dates

• Date last modified

Transportation Reference Network: EdgesFreeway

Expressway

HOV

Reversible

Ramp

Arterial

Local

Non-Motor

Ferry

Rail

Monorail

Busway

Light rail

Centroid Connector

CORE ATTRIBUTES

By Time of Day

Unique ID

Metadata timestamp

FACILITY TYPES

Business timestamp

Transportation Reference Network: Junctions

Generic

Centroid

Station: monorail

Station: lightrail

Station: ferry

Station: bus

Station: commuterrail

Park and Ride

FACILITY TYPES

Transportation Projects Layer: Business Rules

Projects must be represented by a linear route (or a polygon)

Project routes must coincide with one or more reference edges

Project outcomes attributes correspond to ref edge attributes• PSRC Edge ID

• Direction (From/To Node)

• Modes

• Design Characteristics

• In/out service dates

Project design characteristics replace base year characteristics for scenarios in which project participates

Transportation Projects: User’s View

Maintenance Application: Project/ref coincidence

Maintenance Application: New ref features

Key challenge: Articulate business rules for Geodatabase-to-EMME/2 data exchange

Goal clarity: separating what should be from what is

• Legacy model manipulated exogenous data to achieve calibration (i.e., a road with 2.3 northbound lanes)

Triage: which chosen design goals are best met in which system component (Geodatabase, application, or model?)

• More realistic network representation=>Geodb

Complexity: can rule-based automation work?

• “Shadow” HOV and weave links

one geodatabase edge becomes separate SOV and HOV links in model