Data Storage and Dissemination Outline

Transcription

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) EXISTING TIP APPLICATION Question: What would be different about future regional transportation system performance with or without certain projects? TIP DB GIS: Coverages & Shapefiles LAND USE MODEL MTP DB EXISTING MTP APPLICATION TRAVEL DEMAND 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 I am a Park & Ride......with 200 stalls...with 20 bike slots 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 am an airport......generating 20,000 person-trips am peak...with 689 based passenger aircraft I am an analysis zone......of type "Urban Center"...named "Seatac"...within county "King"...with 19,345 residents in 2000 I monitor SR on MM/DD/YYYY in am peak hour ,500 cars northbound...4,900 cars southbound...38 bicycles southbound I am a freight depot......generating 500 truck trips in am peak...attracting 400 truck trips in am peak...attracting 25 air freight landings am peak I am a bus station......receiving 20 buses in am peak...sending out 19 buses in am peak...handling these routes......metro ST 101 I will be a train station in receiving 10 trains in am peak...sending 10 trains in am peak I am a link improvement......in the MTP...modeled in package X5...on SR-99...to be complete in resulting in... Browsing Application Concept

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

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 PROJECTS FUTURE NETWORK

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

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

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 Andy Norton Senior GIS Analyst Puget Sound Regional Council

26 Transportation Layer: TransNexus

27 Project Event Editing

28 General Use Application: Display Projects or Model Results

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

30 Transportation Reference Network: Edges Freeway Expressway HOV Reversible Ramp Arterial Local Non-Motor Ferry Rail Monorail Busway Light rail Centroid Connector FACILITY TYPES PSRC Edge ID Direction (From/To Node) Modes Design Characteristics Speed limit In/out service dates Date last modified CORE ATTRIBUTES Unique ID By Time of Day Business timestamp Metadata timestamp

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

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