1. L04 Source Code Review & Modification Options to Connect to AMS Data Hub (Xuesong Zhou) 1

2. 1. Network data 2

3. Network loaded from shape file 3

4. 2. Incident data (in database dbf, or CSV format) 4

5. Shaped file loaded. 5

6. 3. Weather data loaded 6

7. Q1: PostgreSQL not really needed… Can we use CSV format for simplicity? 7

8. Q2: Do we use in-house databases in MAG or Metro? 1. Database for historical incident and weather data (in house database in MAG or Metro) 2. (NW) Scenario building for given # of scenarios and simulation time 3. Generated native DYNAMART-P incident, weather and demand files 4. NEXTA AMS data hub 5a. Dynus-T program 5b. DynaStudio program 6. Trajectory data 8

9. Q3: Do we need to change or enhance the algorithm for scenario generation? 1. Database for historical incident and weather data (in house database in MAG or Metro) 2. (NW) Scenario building for given # of scenarios and simulation time 9

10. Q4: Should we combine different scenario files into one central database/csv file? E.g. scenario no, incident no., long, lat, or geo area, time duration, matched link ID, impacted parameters 10

11. Q5: Key is to visualize generated weather and incident scenarios in GIS environment, rather than just showing raw data in GIS. 11

12. Final Comments/Suggestions: 1. Try to use in-house database format and engines (e.g. MySQL) in MAG and Metro to store, visualize the historical and “predicted” weather and incident data 2. Need to review the scenario generation methods (spatial and temporal distributions) with MAG and Metro, and ensure MPO users can change generated scenarios to fit the local needs 3. To enable Dynus-T simulation run, needs format specifications from Robert Tung about the incident, weather and demand variation data, so we can convert incident.dat from DYNASMART-P to Dynus-T in first model coupling trial 12