Table of Contents
Defines the behavioral demands regarding the driving speed within the behavior space.
| Name | Type | Value | Opt. | Description |
|---|---|---|---|---|
| max | double | [0, ∞[ | - | Maximum allowed speed |
| timeMax | double | [0, ∞[ | x | Maximum allowed speed for a specific time interval |
| timeInterval | string | e.g. Mo-Fr 6-22h | x | Specific time interval |
| wetMax | double | [0, ∞[ | x | Maximum allowed speed for a wet road |
Defines the behavioral demands for entering and leaving the behavior space.
Defines the behavioral demands for the longitudinal entry in the behavior space.
| Name | Type | Value | Opt. | Description |
|---|---|---|---|---|
| crossing | string | allowed; conditional; prohibited; not_possible | - | Behavioral demand regarding the crossing of the boundary seen from outside the behavior space. allowed: This property of the boundary attribute does not restrict the driving behavior of a vehicle. conditional: This property of the boundary attribute restricts the driving behavior of a vehicle according to the specified condition(s) such as “trafficLightActive” “redLightCondition” “stop” “noStagnantTraffic” “noRedLight” “residentsOnly” or “timeInterval” (see the following rows of this table). prohibited: This behavioral demand states a clear prohibition on entering associated behavior spaces. From the point of view of traffic rules crossing the boundary is prohibited but there are special cases that justify crossing. For example a lane change would be legitimate despite boundary attribute with the value prohibited if a breakdown vehicle is passed as a result. not_possible: For some boundaries not only is crossing prohibited but crossing is also physically impossible (e.g. a guard rail or a wall). |
| trafficLightActive | string | yes; no | x | Needs to be specified if the longitudinal entry is controlled by a traffic light. Defines whether the crossing of the boundary applies for an active or inactive traffic light. Note: If used always both cases have to be defined separately (“trafficLightActive” = “yes” / “no”). Therefore the longitudinal boundary is defined twice. |
| redLightCondition | string | yes; no | x | Needs to be specified if reservation is controlled by a traffic light and turn on red is allowed. Note: In this case the behavioral demand “noRedLight” for the longitudinal boundary crossing condition is removed and an additional “stop” is added (German rules)! |
| stop | string | yes; no | x | Needs to be specified if “crossing” = “conditional”. Boundaries with this behavioral demand shall not be crossed without further action. This attribute requires that the vehicle comes to a standstill at the boundary. It may only continue driving after it has come to a standstill. |
| noStagnantTraffic | string | yes; no | x | Needs to be specified if “crossing” = “conditional”. A vehicle may only enter areas with this behavioral demand if it is possible to drive completely through the area. The vehicle still has the option of stopping for a short time if the situation requires it. Nevertheless it must be foreseeable that no longer stops will occur as otherwise the flowing traffic of other road users will potentially be impeded. An example of this is turning left at intersections with oncoming traffic. If it is foreseeable that only a short stop is required when crossing the intersection to allow oncoming traffic to pass this is still permissible. However if it is clear that the traffic after the targeted area is stuck or the traffic is even already jammed in this area then it is necessary to wait in front of the area at the boundary. |
| noRedLight | string | yes; no | x | Needs to be specified if “crossing” = “conditional”. Behavior spaces that are controlled by traffic signals must not be passed through when the light is red. Specifically passing through the associated boundary is not permitted during a red phase. |
| residentsOnly | string | yes; no | x | Needs to be specified if “crossing” = “conditional”. Some areas may only be entered by residents of this specific area. In this case behavior spaces shall only be crossed by residents. |
| timeInterval | string | e.g. Mo-Fr 6-22h | x | Needs to be specified if “crossing” = “conditional”. Some areas may only be entered within a specific time interval. |
Defines the behavioral demands for the lateral exit from the behavior space.
Defines the behavioral demands for the left lateral exit from the behavior space.
| Name | Type | Value | Opt. | Description |
|---|---|---|---|---|
| crossing | string | allowed; conditional; prohibited; not_possible | - | Behavioral demand regarding the crossing of the boundary seen from inside the behavior space. allowed: This property of the boundary attribute does not restrict the driving behavior of a vehicle. conditional: This property of the boundary attribute restricts the driving behavior of a vehicle according to the specified condition(s) such as “parkingOnly” (see the following row of this table). prohibited: This behavioral demand states a clear prohibition on entering associated behavior spaces. From the point of view of traffic rules crossing the boundary is prohibited but there are special cases that justify crossing. For example a lane change would be legitimate despite boundary attribute with the value prohibited if a breakdown vehicle is passed as a result. not_possible: For some boundaries not only is crossing prohibited but crossing is also physically impossible (e.g. a guard rail or a wall). |
| parkingOnly | string | yes; no | x | Needs to be specified if “crossing” = “conditional”. There are behavior spaces that may only be entered for the purpose of parking. For this purpose the intention to park must be present and parking must actually be performed in this area. |
Defines the behavioral demands for the right lateral exit from the behavior space.
| Name | Type | Value | Opt. | Description |
|---|---|---|---|---|
| crossing | string | allowed; conditional; prohibited; not_possible | - | Behavioral demand regarding the crossing of the boundary seen from inside the behavior space. allowed: This property of the boundary attribute does not restrict the driving behavior of a vehicle. conditional: This property of the boundary attribute restricts the driving behavior of a vehicle according to the specified condition(s) such as “parkingOnly” (see the following row of this table). prohibited: This behavioral demand states a clear prohibition on entering associated behavior spaces. From the point of view of traffic rules crossing the boundary is prohibited but there are special cases that justify crossing. For example a lane change would be legitimate despite boundary attribute with the value prohibited if a breakdown vehicle is passed as a result. not_possible: For some boundaries not only is crossing prohibited but crossing is also physically impossible (e.g. a guard rail or a wall). |
| parkingOnly | string | yes; no | x | Needs to be specified if “crossing” = “conditional”. There are behavior spaces that may only be entered for the purpose of parking. For this purpose the intention to park must be present and parking must actually be performed in this area. |
Defines the behavioral demands regarding the reservation of the behavior space. Specifies the conditions that need to be fulfilled to enter and/ or remain in this area. These conditions depend on type and link of the reservation. The reservation type defines with respect to the driving direction if the behavior space is reserved for specific road users. Possible road user classes are motor vehicles bicycles pedestrians and railed vehicles. A reservation may be own-reserved externally-reserved or equally-reserved. If the behavior space is not own-reserved for the vehicle there is a link to other lanes/ areas from which the reservation-entitled road users may come from.
| Name | Type | Value | Opt. | Description |
|---|---|---|---|---|
| reservation | string | own; externally; equally | - | Defines the type of the reservation. own: In behavior spaces declared as own-reserved a vehicle has priority. This means that no constraints are imposed on the vehicle with respect to priority. externally: In externally-reserved behavior spaces the vehicle does not have priority. Priority must be given to other road users. Specifically this means that road users who have the right of way must not be impeded in their travel. An externally-reserved space is always assigned information about type of reservation-entitled road users and direction of origin. equally: The expression equally-reserved also depends on the type of road user and the direction of origin. In equally-reserved behavior spaces road users must communicate with each other. This means that priority is coordinated among the road users involved. In general this behavioral demand can be seen as a request for cooperation. |
| motorVehicle | string | yes; no | x | Needs to be specified if “reservation” = “externally” OR “equally”. In this case at least motor vehicles are reservation-entitled road users. More road users may be added if necessary. |
| bicycle | string | yes; no | x | Needs to be specified if “reservation” = “externally” OR “equally”. In this case at least bicycles are reservation-entitled road users. More road users may be added if necessary. |
| pedestrian | string | yes; no | x | Needs to be specified if “reservation” = “externally” OR “equally”. In this case at least pedestrians are reservation-entitled road users. More road users may be added if necessary. |
| railedVehicle | string | yes; no | x | Needs to be specified if “reservation” = “externally” OR “equally”. In this case at least railed vehicles are reservation-entitled road users. More road users may be added if necessary. |
| linkedLane | Depends on specific map format | Depends on specific map format | x | Needs to be specified if “reservation” = “externally” OR “equally”. Linked lane (regular motion space e.g. traffic lane crosswalk parking area …) from which the reservation-entitled road users may come from. |
| linkedArea | Depends on specific map format | Depends on specific map format | x | Needs to be specified if “reservation” = “externally” OR “equally”. Linked area (non-regular motion space e.g. sidewalk traffic island …) from which the reservation-entitled road users may come from. |
| redLightCondition | string | yes; no | x | Needs to be specified if reservation is controlled by a traffic light and turn on red is allowed. Note: In this case the value “noRedLight” for the longitudinal boundary crossing condition is removed and an additional “stop” is added (German rules)! |
| turnArrowActive | string | yes; no | x | Needs to be specified if reservation is controlled by a traffic light and a separate turn arrow light is present. Example: Left turn without active turn arrow light 🡪 Yield in front of oncoming traffic and crossing pedestrians. Left turn with active turn arrow (can be activated additionally to the usual green light) 🡪 right of way. |
Defines the permission to overtake other road users.
| Name | Type | Value | Opt. | Description |
|---|---|---|---|---|
| overtake | string | yes; no | - | Permission to overtake |
Continue with the next chapter Application Example or go back to the overview page.