cmap-repos / mhn_programs Goto Github PK

Verify them for both out1 and out2.

When running Update Highway Project Years, any project that combines highway and transit elements (e.g. future bus routes coded on top of new busway links) is currently flagged as being in the MHN but not in year.csv (or required.csv).

bus_future currently stores TIPID and RSP_ID in the NOTES field. For consistency with highway and rail project coding, bus_future should have separate fields for TIPID and RSP_ID

Currently, most of the MHN processing tools rely on one or more SAS scripts. In the interest of making the code useful to as many people as possible (and, frankly, to get away from the awful SAS language itself), those scripts should be converted to a language that can be interpreted by common, free software -- either R or pure Python, depending on the script.

Of course, all of the scripts still require an ArcGIS license...

Currently, the MHN stores detailed truck restriction information in hwynet_arc's TRUCKRES field, with 49 possible categorizations. However, when Emme batchin files are generated by generate_highway_files_2.sas, only the MODES field and categories 1, 2 & 3 of TRUCKRES ("no trucks", "no trucks > 5 tons", & "no trucks except B-plates", respectively) are explicitly used to determine the available modes in Emme (lines 258-69):

if modes=1 then mode='ASHThmlb';  ** all modes;
else if modes=2 then do;  ** truck restrictions;
   if trkres=1 then mode='ASH';
   else if 2<=trkres<=3 then mode='ASHb';
   else mode='ASH';  ** catch all for truck restrictions outside City not yet reviewed;
end;
else if modes=3 then mode='AThmlb';  ** truck only;
else if modes=4 then delete;  ** transit only;
else if modes=5 then mode='AH';  ** HOV only;

Instead of the catch-all expression, the other 46 TRUCKRES categories (mostly specific weight restrictions) can be used to better refine the output modes, e.g. by allowing medium, light and b-plate trucks, but not heavy trucks.

Additionally, the VCLEARANCE field could potentially be used to exclude certain modes based on typical mode-specific vehicle height, and the CHIBLVD field could be used to exclude all truck modes.

The 8 non-"AM" time-of-day transit files are only ever imported by the activity-based/CT-RAMP model, so only "AM" files actually need to be generated for the 4-step model. The Generate Transit Files tool already has a "CT-RAMP Output" checkbox, so if this is unchecked then the other 8 non-"AM" sets don't need to be created. This change should be coordinated with the Master Rail Network code.

Resume effort from a few years ago. If I recall correctly, most tools worked fine, but the ones that required edit mode (notably Incorporate Edits) were problematic.

For consideration: add additional field(s) to code truck tolls separately from auto (I-PASS) rates.

Currently, only I-PASS auto rates are coded, and other vehicle class rates are determined by multiplication factors. This works well for Illinois Tollway rates, but may not hold for privately managed tolls (e.g. Houbolt Rd).

Making this change may be overkill for a single project, but if the functionality could be applied more generally a change to the MHN could be warranted.

Currently, highway project TIPID values are stored in an integer-like text format, but they should be formatted as 00-00-0000 for better compatibility with TIP database. This change will require updates to all of the Python and SAS scripts that handle highway project coding (and maybe future bus coding, too?). Would also require a change in formatting for the 3 input CSVs (year, required, no_code).

Currently only XLS (or, in the case of processed GTFS data, CSV) is accepted.

If penultimate node has dwt=#0, no alightings will be allowed at final node.

If there is a bus with itinerary nodes 4,3,2,1, and link 2-3 is split into 2-5 & 5-3, the bus itinerary will become 4,2,5,3,1: the middle section is incorrectly reversed, and makes the route considerably longer (as well as requiring more shortest-path-finding during transit file generation).

This is a non-issue for a bus with itinerary nodes 1,2,3,4, whose itinerary would become 1,2,5,3,4, which is correct.

Currently, any bus routes that have bus priority along any portion (i.e. require TTF=2 in Emme) must have full coding in the bus_future_itin table. This is true even for existing bus-priority service (Pace's bus-on-shoulder routes, CTA's Jeffery Jump and Loop Link routes), where "future" routes are coded to replace the imported GTFS-derived routes.

Coding bus routes is extremely time consuming, error prone, and completely unresponsive to changes in existing routes that are being substituted out. It seems to me that a more elegant solution would be to assign bus priority to specific links in the network (both the base network and highway project coding), and assume that any buses using those links should have TTF=2 in Emme. Since some bus priority is time-specific (e.g. parking lanes becoming bus lanes during peak periods), it may make sense to code this using "TOD"/time-of-day strings like the future bus routes currently use to specify coding for specific model time periods (e.g. "234678" for AM and PM peak, plus shoulders).

This would make it significantly easier to code many BRT projects in the future, where existing routes become more efficient. Only new routes would need to be coded, and changes to existing service would all be handled by simple highway project coding.

The value in @busveq is used as background traffic in the volume-delay functions to determine total link volumes. Beginning with the ON TO 2050 Plan update, CMAP uses four time periods for transit assignment (NT: 6 pm – 6 am, AM: 6 am – 9 am, MD: 9 am – 4 pm, PM: 4 pm – 6 pm). The values for @busveq are added to the time-of-day highway networks by temporarily importing the transit coding from the appropriate transit time period and calculating the vehicle equivalents based on the headways of routes. However, the bus vehicle equivalents are being overestimated for every period except the PM peak because the transit assignment time periods don’t align with the traffic assignment periods except for the PM peak. An improved process would directly calculate @busveq from the bus coding in the MHN – this would ensure consistency with the traffic assignment periods (only capturing buses operating during the time period) and the value could be imported into the Emme networks as an extra link attribute.

Problem occurs while running generate_transit_files_2.sas.

Example, from TOD 1, scen 400, c13q3, which was supposed to end with nodes 11555 and 11414, but link 11414-11555-1 is deleted by project 03-96-0021 in 2025:

a  'p51002'   P   3   600   15   '223 ELK GROVE - ROSE'
  path=no
   21624   dwt=0.01   ttf=1   us1=1   us2=0
   12187   dwt=0.01   ttf=1   us1=1   us2=0
   12207   dwt=0.01   ttf=1   us1=1   us2=0
   11977   dwt=0.01   ttf=1   us1=2   us2=0
   11818   dwt=0.01   ttf=1   us1=1   us2=0
   11710   dwt=0.01   ttf=1   us1=1.2   us2=0
   11711   dwt=0.01   ttf=1   us1=0.6   us2=0
   11712   dwt=0.01   ttf=1   us1=0.4   us2=0
   21597   dwt=0.01   ttf=1   us1=0.3   us2=0
   21596   dwt=0.01   ttf=1   us1=2.4   us2=0
   .   dwt=0.01   ttf=1   us1=0.1   us2=0
   .   lay=3

Solution: Prior to calling SAS, generate a scenario-specific list of nodes that have been deleted by hwyproj since MHN base year. For each of these, list also the closest node that does exist in the current scenario. Substitute these node IDs -- if they are the first itin_a or last itin_b of an itinerary -- in the representative runs itineraries CSV (which is generated on-the-fly for each Scenario-TOD pair) before SAS even begins. May lengthen affected routes significantly.

This means that benefit of ABB ID (namely, being able to have both a baselink and a skeleton link between the same two nodes) is lost until this is changed.

Currently, generate_transit_files_2.sas only expects the REPLACE field in replace.csv (exported from bus_future with fields TRANSIT_LINE, REPLACE, TOD by generate_transit_files.py) to contain a single replacement route. SAS script should be updated to allow for the specification of multiple routes to be replaced, using a colon-delimited format for consistency with other MHN/MRN coding.

For example, if a future route B-111 is replacing current routes B-111 and B-112, the REPLACE value should be coded as B-111:B-112.

Bus coding template's REPLACE note and the MHN wiki page should be updated to make this clear.

Currently, years-old project coding for an inactive TIPID can theoretically be resurrected if the project is suddenly active in the TIP. The coding may be woefully out of date, so it would likely be prudent to warn the user to check the project coding against the description in the TIP.

Esri has added a lot of new features to ArcGIS 10.2 and 10.2.1. Some of these can potentially be incorporated into MHN/MRN processing. Of note:

• Detect Feature Changes tool
• Similarity Search tool
• Table to Excel & Excel to Table tools
• Alter Field tool (field renaming!)
• Add Geometry Attributes tool

Also: the Near and Generate Near Table tools received "dramatic" speed boosts.

In order to support bus coding on transit-only links (e.g. the McCormick Place Busway), logic must be added to generate_transit_files_2.sas to stop those links (modes=4) from being excluded during the link verification phase.

Currently, verification is based on the highway links files (the .l1 files in the highway output folder), which explicitly -- and correctly -- omit transit-only links. A separate list of transit-only links will probably need to be generated, that the SAS script can then allow during verification.

This is a low-priority issue, as the affected routes are rerouted with shortest path, and the only route currently coded on transit-only links is part of a fiscally unconstrained Major Capital Project, not included in Conformity analyses.

Rewrite parameters into a MasterHighwayNetwork object, which can then be instantiated with a path given by user through ArcGIS tool GUI.

Currently, future bus routes and park-n-ride lots are coded to specific scenario IDs with a field called SCENARIO, which would look like '34567' for something intended to exist in scenarios 300, 400, 500, 600 & 700.

Given the arbitrary nature of the scenario codes, and the fact that their meanings will change over time when the model base year is updated, these fields should be replaced with START_YEAR (and possibly also END_YEAR) fields that allow for an absolute time reference for when each bus route or park-n-ride lot should exist that would not need to be manually updated when the model base year changes.

Several scripts will need to be updated to accommodate this change, as well as the future bus coding template Excel spreadsheet, but the results will be worth it.

The MRN could benefit from a similar update.

It is currently possible to add two links to the MHN that connect the same two nodes. For this to happen, either the BASELINK values or the digitized direction (and therefore the ANODE and BNODE values) must differ. If at least one of the links represents a two-way road, the Emme batchin files may contain two links with the same inode and jnode, and only one of them will be imported. (The other will be ignored with a non-fatal warning.)

The MHN processing scripts should check for this possibility and warn the user. This could be done in one of two places:

1. When running "Incorporate Edits", check the DIRECTIONS values on any links sharing the same nodes to predict whether this issue may occur later; or,
2. When running "Generate Highway Files", check for duplicate inode-jnode pairs during the creation of the Emme batchin files.

I am not sure yet which approach would be best.

CTA routes J14, 37, 111A & 115 appear to have never been assigned an ABM vehicle type in the GTFS processing scripts, so a dummy value is coming through. This will cause problems when trying to generate non-base year ABM transit networks (which hasn't been done yet).

Update Highway Project Years tool uses NOTES to compare TIP IDs in year.csv. TIP_ID was added to the MRN. TIP IDs will no longer be stored in NOTES.

Add a new table to geodatabase containing Pace park-n-ride locations (nearest node on an arterial), cost and number of spaces. Update scripts (generate transit files, incorporate edits) to include these in future Emme output files and ensure specified nodes always exist.

When running Generate Highway Files, add report of Major Capital Projects included in the specified scenario.

Expanded vehicle classes for ABM are stored in bus_base and bus_current, but are not available for bus_future. What happens when exporting a future network with ABM output turned on?