Multiple traffic signal plans per intersection

dabreegster commented 3 years ago

In reality, a single intersection often has multiple configurations for signal timing. Weekday morning rush hour is very different than weekend middle of the night. If I'm not mistaken, these are called "plans." We only support one today, but given the upcoming integration to import timing from https://github.com/xzhou99/Signal2timing, now's a good time to support multiple.

[ ] Update the JSON schema to support this. Most likely, adding a new "plans" dictionary to contain "stages" and "offset". Each plan likely has a name/description and some way of specifying when it's active -- a time range, maybe also some way of encoding days of the week. Not sure yet about specifying a default plan if some time range isn't covered, or whether to try to repair overlapping ranges or just reject bad input.
[ ] Automatically upgrade old JSON files into the new schema
[ ] Support plans at the map_model layer
[ ] Support plans at the sim layer
[ ] Add basic editing in the UI. I can imagine something fancy to browse through different times-of-day, but likely going to start with something simple, and de-emphasize the advanced controls by default.

dabreegster commented 3 years ago

Here's an example of what the JSON might look like:

{
  "intersection_osm_node_id": 29449863,
  "plans": [
      {
          "start_time": "00:00:00",
          "end_time": "07:00:00",
          "days": [
              "Monday",
              "Tuesday",
              "Wednesday",
              "Thursday",
              "Friday"
          ],
          "stages": ...,
          "offset_seconds": 0
      },
      {
          "start_time": "07:00:00",
          "end_time": "20:00:00",
          "days": [
              "Monday",
              "Tuesday",
              "Wednesday",
              "Thursday",
              "Friday"
          ],
          "stages": ...
      },
      ...
  ]
}

Questions: 1) Is "plan" the correct term for this? 2) Do plans have descriptions or symbolic names, or are they just identified by the time they run? 3) Is the 24-hour HH:MM:SS format reasonable for times? An alternate is seconds since midnight -- more machine-readable, less human-readable. Since this file isn't really meant to be read directly by people, I would lean towards the latter. 4) Are the time ranges guaranteed to partition the 24 hours perfectly with no gaps and overlaps? I'll likely add validation for this and reject anything that doesn't fit. 5) Do plans often change for different weekdays, or should we just have a weekday/weekend distinction? I know there are sometimes special plans for particular days of the year (like a big football game), but I don't think we need that level of detail yet. A/B Street scenarios usually cover a single day right now; we could use some configuration to specify what day-of-the-week should be used for signal plans.

@xzhou99, @jiawei92 any feedback on the JSON format?

dabreegster commented 3 years ago

I've implemented a simpler version of the JSON change, example https://github.com/dabreegster/abstreet/blob/master/traffic_signal_data/data/1199586616.json

Can keep iterating on it if this doesn't work, but I think creating a separate map edits file to represent weekdays, weekends, special days of the year, etc is a more clear way to select between different plans. And within a single day, having start and end time is redundant; the plans should just be listed in order, specifying only start time.

asu-trans-ai-lab commented 3 years ago

Quick inline comments.

Is "plan" the correct term for this?

correct.
Do plans have descriptions or symbolic names, or are they just identified by the time they run?

they should have a name such as weekend vs. weekday, but we can handle this complexity later. Is the 24-hour HH:MM:SS format reasonable for times? An alternate is seconds since midnight -- more machine-readable, less human-readable. Since this file isn't really meant to be read directly by people, I would lean towards the latter.

Are the time ranges guaranteed to partition the 24 hours perfectly with no gaps and overlaps? I'll likely add validation for this and reject anything that doesn't fit.

Do plans often change for different weekdays, or should we just have a weekday/weekend distinction? I know there are sometimes special plans for particular days of the year (like a big football game), but I don't think we need that level of detail yet. A/B Street scenarios usually cover a single day right now; we could use some configuration to specify what day-of-the-week should be used for signal plans.

if possible, please use HHMM:SS for the consistency of GMNS. https://github.com/zephyr-data-specs/GMNS/blob/master/Small_Network_Examples/TOD_Examples/CT_Ave.md, you can also check the field of "time_day" https://github.com/zephyr-data-specs/GMNS/blob/master/Specification/link_tod.schema.json XXXXXXXX_HHMM_HHMM, where XXXXXXXX is a bitmap of days of the week, Sunday-Saturday, Holiday. The HHMM are the start and end times."

a-b-street / abstreet

Multiple traffic signal plans per intersection #447