TrafficElement::trafficConstrictionType is redundant and allows inconsistency[Bug]:

[iancornwell1]

What happened?

Raising on behalf of IT, who said in a commentary on Situation: "Traffic Element: it contains an attribute "trafficConstrictionType". the related information we use to manage according to the Abnormal Traffic Situation record we manage in a situation for all possible other type of situation, this leads to possible inconsistencies among Abnormal Traffic Situation record which should be managed in cas of abnormal Traffic and other elements in the situation.. drop this attribute and rely on Abnormal Traffic element."

Version

3

Code of Conduct

• [X] I agree to follow this project's Code of Conduct

[iancornwell1]

I agree this allows inconsistency, but there is also some unique information. The literals allow you to say that the road, carriageway, or lanes are blocked or partially obstructed (3x2=6 literals). Impact allows expression of similar information, but not exactly. You can say in Impact that lanes are restricted, which may mean partially or totally, but you cannot say which of those two possibilities; instead you can specify % capacity which is even finer-grained. It seems consistent to put all impact information into Impact, and not have it specific to TrafficElement. Are we content with the current Impact or do the trafficConstriction literals suggest to anyone that we need to expand Impact?

[ingeniumfaber]

when the carriageway is blocked we assume that there is a further situation record which states "traffic/road/lanes Blocked" or "lanes blocked", so the trafficConstrictionType for all Traffic Element lead to some implicit "traffic/road/lanes blocked" information which is normally managed by another SR. when a Traffic Blocked information is issued is always explicit and not implicitely associated to the originating/cause situation record. I guess this is an operational point of view for management of such information by road operators, sure the information can also be derived by having an incident which occupy all the lanes / carriageway but as journalistic information management the Traffic Blocked information is always added besides the incident information itself

[iancornwell1]

Discussed in a Situation v4 call with Fabzrizio, Bard, Ian, Josef, Jan, Martin, and Luca. We could not fully agree because of different ways of using the SituationPublication. It was noted that trafficConstrictionType contains extra information that is not in AbnormalTraffic, so Fabrizio suggested it be moved to AbnormalTraffic rather than deleted, however that does not meet the requirement of the Netherlands and possibly others, where any kind of unplanned event may have this associated information and there may not be abnormal traffic (because there may not even be any traffic e.g. rural road at night). So the idea to move to AbnormalTraffic seemed clearly ruled out. The question remained could the information be moved to Impact. Fabrizio and Ian at first agreed that this seemed logical, but Bard made a counter-argument. This kind of information - (road/carriageway/lanes are partially/totally obstructed) is less precise than should be available for an operator action. So we want to specify a simple 1-of-6 choice only for an unplanned event, while for OperatorAction we want to specify a more detailed Impact. That has some logic, and the simplest thing to respect that logic is to leave the model as it is. However, using the same argument about planned vs unplanned, one might say that Impact should be moved to OperatorAction - but nobody is suggesting that. As it stands no change has been agreed.