poggenhans
commented
4 years ago You are absolutely correct in your observation that conceptually regulatory elements should be preferred in order to express regulations that affect a lanelet (or an area). This is because it is better to reason about where a rule (e.g. a traffic sign) if it is represented this way.
A difference to that is the subtype of a lanelet. Whether something is a road or a sidewalk is not a rule, it is a fact. This means that e.g. if something is a sidewalk simply because its appearance indicates it is a sidewalk, you would use ths subtype attribute, while when it was labelled by a traffic sign, you would instead use an appropriate TrafficSign regulatory element. In my opinion, this concept is quite clear.
You are also right that in some points we do not strictly follow this concept (e.g. for the location or speed_limit tags). This is for reasons of simplicity and to reduce the effort to create maps. The tooling to create maps that we have currently is quite limited. Also the implementation of lanelet2_traffic_rules still lacks a lot of details. Your example of restricted overtaking on highways would be better solved with a regulatory element that references the respective traffic signs, but currently there is noting in lanelet2_traffic_rules that checks for that. We are always happy about contributions that help extending it :wink: .
msmcconnell
In my usage of lanelet2 I have found a certain amount of overlap between the role played by regulatory elements and primitive attributes. When I first read the lanelet2 paper, I was under the impression that all regulations would be handled by regulatory elements. For example, the speed limit, the access to a specific participant (vehicle, bike, etc.), the ability to lane change. In using the library, I have instead found there are two sources of truth for rules of the road. The first is the attribute set of the lanelet. The subtype and location attributes are used to infer traffic rules (like speed limit), while the participant attribute is used to set access rules directly. In addition regulations about when lane changing is possible are determined entirely by attributes on the line strings. This could cause issues in some highways with dynamically managed lanes where the marking on a line does not directly relate to the ability for a vehicle to change lanes.
Meanwhile regulatory elements also contain speed limits and are used for most other regulations. I would be interested in hearing why the library is designed in this way. After using the library for a while now, I feel using regulatory elements for all aspects of traffic rules would be more inline with the layered approach lanelet2 proposes.