Recurrent Events

[sknick-iastate]

Within Iowa we had a few discussions on how to handle recurrent events. Below are some of our notes on how we handled these events.

-Since each lane closure is handled individually then recurrent closures must be separate events in the specification. Since we can have recurrent work zones that last for multiple months, we decided to show only the events for the next 14 days. This helped reduce the total number of events.

-We would only show future or current lane closure events and disregard any completed events (most common in the recurrent event types)

[Joseph-Kuenzi]

We at Oregon DOT have hit upon this same question/resolution regarding recurrent events. It seems that there is no guidelines, as of yet, regarding how to report a work zone event that occurs for an extended period of time and has specific hours of work zone operation.

Setting a specific timeframe in the future that the WZ feed will reflect WZ future/active projects/activities was our conclusion as well.

To best represent the current status of the work zone activities' impact to the roadway, ODOT's feed will contain a record for every daily schedule available to best denote when the WZ is truly active. This can be accomplished by utilizing the identifier/subidentifier to link the whole work zone project to multiple work zone activities.

[lynnerandolph]

TxDOT's feed is created similar to what Iowa did. We update it each day so that if we have a recurring event that goes on for 6 months, the feed will show the next 14 days of recurrences. I'm not sure this is the "best" way to handle recurring events unless there is somewhere explicit that says events in the future don't exist yet. Otherwise, what's published is a slightly misleading list of events. Especially if you have non-recurring events that are in the feed but are more than 14 days out.

[daylesworth]

I suggest considering JSCalendar to specify recurring events. It's currently a standard-track Internet draft and the latest version can be found at https://tools.ietf.org/html/draft-ietf-calext-jscalendar. We're using it to specify recurring events in another GeoJSON data feed and it's working really well. Specifically, it defines recurrenceRules and recurrenceOverrides object properties that describe repeating events (daily, weekly, etc.) along with exceptions (weekends, holidays, etc.). A subset of JSCalendar properties could be added to WZDx without modification, or they could be integrated to resolve some redundant properties (like start versus start_date).

[lynnerandolph]

@daylesworth do you know how compatible JSCalendar is with iCal? Just curious as we're currently keeping our scheduled events in iCal format.

[daylesworth]

iCalendar does not use JSON, but there is a JSON mapping called jCal. JSCalendar is designed to address several issues with iCal/jCal, which are described in the draft: https://tools.ietf.org/html/draft-ietf-calext-jscalendar-26#section-1.1. Since WZDx is a new spec and has no requirement for iCal interop, I would suggest going with the most forward-looking standard.

[Polly-Okunieff]

Lessons learned from GTFS where they included two tables for calendar (similar to recurrent events) and calendar dates (for exceptions or detailed daily schedules). Data providers implemented these so that their intent was a mis-mash of confusion and incompatibility. Some thoughts on using the recurrence: (1) a "recurrence override" will need to be sent out when the work is cancelled What are the business rules associated with this? (2) this will not accommodate the actual (verified) time when the WZ starts or when workers are present.

[lynnerandolph]

iCalendar does not use JSON, but there is a JSON mapping called jCal. JSCalendar is designed to address several issues with iCal/jCal, which are described in the draft: https://tools.ietf.org/html/draft-ietf-calext-jscalendar-26#section-1.1. Since WZDx is a new spec and has no requirement for iCal interop, I would suggest going with the most forward-looking standard.

I was really more asking for translating, not suggesting iCal for this purpose.

[CraigMoore-Sea]

JSCalendar provides a framework that if we stick to could make the work of data producers and consumers easier.

Getting support of the feed working group will be very helpful in rolling this out. Also getting a consumer to participate will help define best practices for consuming and displaying data from recurrent closures.

[Mahsa-Ettefagh]

Comments received during the V3 Specification Update Subgroup meeting on 4/29/2020:

• Lynne Randolph: we should use a calendar, for sure. right now, the information is misleading since we're splitting and outputting 14 days of a recurring event at a time.
• Neil Boudreau, MassDOT: I think that a calendar approach is the way to go and would follow along with updates that we hope to make to our lane closure notification process in MA
• Ross Sheckler: I am not familiar with JSCalendar but we have concerns with the hierarchy of projects, events, and activities within an event. We are trying to establish a metric around activity within a project that is within traffic
• Jim Williams (INRIX): Calendar - UTC? - yes
• Sabrina Mosher: Dealing with the recurring event was the one of the most difficult part of producing a feed so a calendar would be good. It would also make it more clear that an event was recurring rather than having to see that the event occurred multiple times by looking at multiple events
• Qassim Abdullah: Are we planning broadcasting such events for future AV/CV
• Ross Sheckler: If an activity is continuous in time it is a single event. If an activity such as a lane closure is terminated and started at a later time it is two separate events.
• Derald W Dudley: https://tools.ietf.org/html/draft-ietf-calext-jscalendar-26
• Carole Delion (MDOT SHA): Having a means to track/measure post event may be needed on top of users on the road ingesting the information

[jewel1965]

In the Open 511 event spec, we created a schedule object to define recurring and interval events. This may be considered for ideas.

[Dunge]

I agree JSCalendar provides the best end result as a complete json schema.

My only inquietude is that it isn't well established yet. As a data producer and a C#/.NET developer, I can find lots of open source libraries to interface with for example the iCal object model, but nothing about JSCalendar. So in order to provide this, we would need to develop everything from scratch, from the object model, database layer, user control interface up to the json serialization.

But don't let that comment influence the choice, as I said, I agree JSCalendar provides a better result.

[CraigMoore-Sea]

Another viable option to consider is JCal, which is a direct JSON implementation of iCalendar.
[https://tools.ietf.org/html/rfc7265]

I'd like to here some discussion on the pros and cons of each as applied to WZDx.

[sknick-iastate]

I took a look at how JSCalendar could be implemented within the current specification along with @j-d-b and @CraigMoore-Sea. There are a few challenges that we may face since JSCalendar is also object oriented that would require some restructuring of the WZDx. This would be achievable but would take some time to implement.

The bigger issue that we see is that with the WZDx we are trying to show both real-time and planned work zones in the same feed (as can be seen with the <event_status>). Additionally, when a work zone is active we have accuracy fields of both the time and location (<start_date_accuracy>, <end_date_accuracy>, <beginning_accuracy>, <ending_accuracy>) which means that the <start_date> can vary once a work zone is verified. So we would be trying to show both the active work zone which may have verified time/location information as well as planned work zones that should still be based on the estimated time/location in the same object. The recurring rules within JSCalendar are all based on the <start> (in JSCalendar) field which in our implementation could change when the start time is verified (or adjusted for a specific day).

Another potential challenge is that JSCalendar uses a duration instead of an end date. This works well for meeting calendars but in our implementation would likely require the duration to be recalculated when a start time is verified. If the work zone starts early or later than expected, I believe we still expect the work zone to be completed by the end date not on a specified duration.

I’d still like to hear input from others but our recommendations at this point is to follow similar approaches that are being done in Iowa and Texas with showing planned recurring events out X amount of days. We feel this will make it easier for consumers since they can parse out only active events and discard the planned events. We suggest working with the technical assistance committee on developing some business rules or best practices for handling recurring events as well as identifying tools that could be used that convert the data that is being collected to the WZDx format.

[vchandranNTAM]

I am just joining the discussion so please pardon any repetition in question themes from me. Calendar definitely is the tool that can be harnessed to help here.

The biggest concern for me would be to first universally define what it means to be a "recurring" road event. I have not seen that anywhere in the discussion. All it takes is one DOT to follow a slightly different path and it will throw the models discussed here for a loop.

If this has already been discussed, can someone point me to what it means when folks are referring to a recurring event (in real project terms). A workzone like the I-25 GAP project that occurs over time and is broken up into subsequent closures may be thought of as series of recurring events (to some). To others, it may be a WorkZone (WZ) project with a start and end date and multiple subsequent closures (with their own start and end dates) over the time WZ period.

Hypothetically, would planned yearly maintenance of an asset be considered an infinite recurring event? Do they even need to be planned? etc.,

[j-d-b]

Based on several rounds of discussion culminating in a focused meeting on recurrent events in late July 2021, the group came to the conclusion that:

A "recurrent event", that is, a work zone that occurs in a similar fashion multiple days or on a fixed schedule, should be represented with a unique WZDx road event for each occurrence of work.

Some additional Notes:

• The start and end date time of each road event should reflect the start/end of that occurrence of work.
• Each occurrence of work can be "linked" to a parent "work zone" using the Relationship (also see Refactor the Relationship object: explicitly define and identify entities related to a road event  #197 for a more clear implementation).
• See here for an example feed including a recurrent work zone implemented following the above premise.
• Many DOTs have a schedule associated with a recurrent work zone. This schedule can be processed when generating a WZDx feed to create a WZDx road event for each occurrence of work.

[j-d-b]

Closed as this was resolved by clarifying that each occurrence of work should be represented by it's own road event and providing examples demonstrating this.