Define time sets in separate table

[e-lo]

timeday_set as defined in the wiki make a lot of sense, but requires parsing in order to be legible or useful.

e.g. Monday-Friday 0700-0900 would be 01111100_0700_0900

Suggest an optional time_set_definitions file that would allow using legible names for timeday_set and have each of the information in the variable set name split out into a variable, i.e.

• name (str): legible, i.e. AM Peak
• abbr (str):
• set_id (str): the original timeday_set definition
• holiday
• start_time
• end_time
  etc.

This will also make it easier to translate from GMNS to a static network variable that might vary over time, such as LANES_AM which could be a concatenation of the variable and the time period abbreviation.

[ssmith55]

Optional time_set_definitions file could be modeled on what GTFS does. Appropriate adjustments would then be made to the other files that use time-of-day information.

Field Name	Type
timeday_id	ID	Primary key, similar to service_id in GTFS
monday	enum	0 or 1
tuesday	enum	0 or 1
wednesday	enum	0 or 1
thursday	enum	0 or 1
friday	enum	0 or 1
saturday	enum	0 or 1
sunday	enum	0 or 1
holiday	enum	0 or 1
start_time	timeofday	HHMM  (24hr format)
end_time	timeofday	HHMM  (24hr format)

[e-lo]

Suggest following modifications to your great suggestion, @ssmith55

1. timeday_id Description: Primary Key. Unique name of the time of day. Preferable legible rather than a number.

2. Types for days of week, holiday, etc are type: Boolean

3. add snow and unknown (or some other default)

4. format for times (start_time, end_time) is HH:MM which is both more legible (and just as easy to process)