1. 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

2. Data Systems General Architecture (Past) TRAVEL DEMAND MODEL TIP DB EXISTING TIP APPLICATION MTP DB EXISTING MTP APPLICATION GIS: Coverages & Shapefiles Question: What would be different about future regional transportation system performance with or without certain projects? LAND USE MODEL

3. 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)

4. Vision

5. RDBMS MAINTENANCE APPLICATION TRAVEL MODEL I/O APPLICATION GENERAL USE APPLICATION TIP DB MTP DB TRAVEL DEMAND MODEL EXISTING TIP APPLICATION EXISTING MTP APPLICATION System Architecture Transportation Components (After) GIS: Coverages & Shapefiles LAND USE MODEL ? GEO DATA BASE ANY LEGITIMATE CLIENT…

6. 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

7. Transportation Reference Network: Users’ view

8. Transportation: a Project-based Approach “Project” defined (for the data system): Future event with completion date Geographic location Alters transportation system Can be modeled

9. Key feature: future year networks derived from operation on reference and project layers BASE YEAR NETWORK FUTURE NETWORK FUTURE PROJECTS + =

10. 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

11. 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)

12. Overview of Applications MAINTENANCE APPLICATION MODEL I/O APPLICATION GENERAL USE APPLICATION GEO DATA BASE TIP DB MTP DB TRAVEL DEMAND MODEL EXISTING TIP APPLICATION EXISTING MTP APPLICATION RDBMS For power GIS and database managers: to manage the geometric network and project data, including editing and maintenance functions 1 For transportation modelers: To convert the geometric network and projects data to EMME/2 format and vice versa 2 For general users with little or no GIS experience: A user friendly mapping interface to query and display projects and other business data 3

13. Additional Option: Scan project DB’s for all projects that need to be mapped Maintenance Application: User View

14. Maintenance Application: Mapping a project

15. General Use Application: Data Loading and Metadata

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

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

18. Model I/O Application: Display Model Output to Geodatabase

19. Status Transportation: in beta test cycle Demographic & LU data plus any supporting application(s): about to restart design External data import/export: future

20. 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?

21. Questions?

22. 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…

23. 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

24. 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

25. GIS Contacts at PSRC Jeff Frkonja Senior Planner Puget Sound Regional Council 206-464-6180 jfrkonja@psrc.org Andy Norton Senior GIS Analyst Puget Sound Regional Council 206-464-7527 anorton@psrc.org

26. Transportation Layer: TransNexus

27. Project Event Editing

28. General Use Application: Display Projects or Model Results

29. Geodatabase New Enterprise Data Model (Transportation) Project Route Feature Class Transportation Reference Network: Junction and Edge Feature Classes MTP Projects: ProjectID Title Description Cost Sponsor Etc… TIP Projects: ProjectID Title Description Cost Sponsor $ Programming Etc… Transit Routes Trans Nexuses Other…

30. PSRC Edge ID Direction (From/To Node) Modes Design Characteristics Speed limit In/out service dates Date last modified Transportation Reference Network: Edges Freeway 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

31. Transportation Reference Network: Junctions Generic Centroid Station: monorail Station: lightrail Station: ferry Station: bus Station: commuterrail Park and Ride FACILITY TYPES

32. 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

33. Transportation Projects: User’s View

34. Maintenance Application: Project/ref coincidence

35. Maintenance Application: New ref features

36. 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