Cycling: design and implementation

1. Basic settings

1.1. Unscheduled Vehicle Group

In Omsi, bicycle traffic is guided on car paths, i.e. car paths must be laid in the intersection editor as well as in the map editor. In order for these to be used (exclusively) by bicycle traffic, the file unsched_vehgroups.txt must be edited. This is located in the folder of the respective map and contains 4 categories by default: "Normal Cars", "Trucks", "Commercials" and "Ambulance". No category should be removed, otherwise errors will occur.

A new group is now defined below these groups. This should receive the value 0 for the "default density" by default. This value means that basically every path is blocked for this group unless it is explicitly released.

It should look something like this (the naming of the group is of course arbitrary):

[group]
Byicycles
0

1.2. Control in the editor

In the map editor, there should now be another group under the "Traffic Rules" tab. In addition, you can see that each path is black when selecting the trip frequency for the group "Bicycles", i.e. no traffic of the corresponding group can occur there. This ensures that after this step no cyclist is present or uses paths of motor vehicle traffic. However, the paths on the cycle track are still used by motor vehicle traffic in this phase.

View Vehicle Groups under "Traffic Rules"	Motor vehicle traffic paths	Cycling paths

1.3. Editing the AI list

The bicycles must then be added to the AI list. The name of the group must be identical to the entry in the file unsched_vehgroups.txt. The only bicycles available in OMSI so far are those of the HafenCity add-on, which are inserted as follows:

[aigroup_2]
bicycles

Vehicles\HC_Fahrrad\fahrrad_1.bus    1
Vehicles\HC_Fahrrad\fahrrad_2.bus    1
[end]

2. Create cycle paths

2.1. Necessary steps

The use of invis splines for cyclists is not recommended for two reasons:

1. With invis-splines, collision detection does not work without errors.
2. The paths of cycling traffic should have a different width (clearance) to allow passing.

Therefore, the creation of intersection objects is briefly discussed below:

The creation of paths for cycling traffic does not differ from the creation of motor vehicle paths. The only difference is that the width should be reduced to 1.5m or less, depending on your taste.

A width of 0.5m has proven to be effective, so that cyclists can also be overtaken or overtake. For a rule-compliant overtaking distance, a higher value would be required, which in Omsi, however, would increasingly lead to problems such as cyclists blocking each other.

The setting "true width of paths" under "View" in the SDK tool makes the lane width clearly visible:

An assignment to the respective traffic group cannot be made here. Paths should still be marked with the parameters "Type: Street" and "Direction: Forward".

The creation of traffic light phases does not differ from the creation of intersections without bicycle traffic. It may only be advisable to increase the clearance time by shortening the green phase. This will ensure that the intersection is free of cycling traffic at the next green phase.

Example:

The lower two phases are intended for bicycle traffic. They have a shorter green phase.

Helferlein's traffic light objects are recommended for the installation of the traffic lights, as they also contain small signal heads for bicycle traffic.

Finally, the correct categories are assigned to the created paths:

• For all cycling paths: An appropriate frequency must be assigned, and they must also be closed to vehicle traffic ("No Unscheduled Traffic" must be selected for the "Normal Cars" group).
• For all car paths: A corresponding frequency must be assigned. The paths are already blocked for bicycle traffic by default, see chapter Unscheduled Vehicle Group

Bicycle traffic	Car traffic

Finally, cycle traffic should now appear in the game!

2.2. Visual design

The following can be fundamentally assumed for the construction of cycle paths that approximately correspond to reality or the applicable regulations: The aim according to the Recommendations for Cycle Facilities (ERA) of the Road and Traffic Research Association (FGSV) is a continuous and objectively as well as subjectively safe cycling network. The following minimum dimensions can be read in the ERA:

2.2.1. Examples of implementation, real and in Omsi:

One-way bi-directional cycle path	Protecting strip	One-way cycle path
Full cycle lane in two directions, separated from the road	Bicycle lane on the road	Fully-fledged cycle path in one direction, separated from the road

Cycle path splines without paths are included in the following packages, among others:

The construction of separate infrastructure in the area of intersections is desirable:

• Berlin solution: Cycling traffic is guided on the carriageway in the intersection area
• WCL: Widened cycle lane: Cyclists have a clearly advanced stop line so that they can position themselves in front of motor vehicle traffic when the light turns red, e.g. for a direct left turn.
• Advanced stop lines next to the motor vehicle lane for improved visibility

3. Script-side adaptations

It can happen with the normal settings that the bicycle traffic both drives very slowly and disregards red traffic lights. To solve this, the following file can be modified in the HC_Bicycle_constfile folder: bicycle_constfile.txt

• Brake force: Increase the value AI_brake. Good results were found with the value 2000.
• Higher speed
  • Increase the value of the minimum maximum speed vmax_min to e.g. 20 km/h.
  • Increase the possible added speed vmax_add to e.g. 10 km/h.
  • This makes speeds of 20-30 km/h possible.