# Mitigating Urban Congestion: A Cooperative Reservation Framework for Automated Vehicles
## 3 Infrastructure Map Recognition
### Cluster Compatibility Logic  
After finding the relevant lanes, the _control area_ is built based on an arbitrary longitudinal distance of coverage that can be adjusted as needed. Then, cluster compatibility is calculated by evaluating the intersection of the monitored lanes comprising each cluster. When a lane intersects with another lane, the corresponding cluster is marked as non-compatible; if there is no intersection, it is marked as compatible. The result is a list of clusters with compatible and incompatible clusters defined. This process is fully automatic for both types of environment, e.g., intersections and roundabouts, with slight differences between them that will be explained in more depth in the next sections. In Figure 4, the result of the procedure applied to generate the set of _Survey Clusters_ explained in previous sections can be seen depicted with each _Survey Cluster_ composed of its _Entry area_ (pink polygons), its _survey area_ (green polygons), and its _Exit area_ (blue polygons). Note that each _Survey Cluster_ is identified with Entry, Exit, and Survey area; thus, several clusters can share the same Entry or the same Exit, which declares a possible incompatibility, but never both. At the same time, each relevant area within the generated _Survey Cluster_ can contain one or more roads, which are automatically assigned by reading the High-Definition Map and processing the logical contacts and geometrical information stored in the network topology. These lanes will be useful for tracking and positioning procedures. Furthermore, since multiple Entry/Exit areas can be shared among clusters, they are implemented with shared memory for the sake of efficiency. In addition, Entry and Exit points are placed as colorized squares in relevant Exit and Entry areas, which mark the local Cartesian coordinates as waypoints for the ABP suggestions when a new incoming vehicle mission is shared. On the other hand, High-Definition Map information, such as roads and lanes (red arrow lines), and lane IDs (black numbers), which are crucial for the planning system, are shown. These lanes contain important geometric and semantic information, with Cartesian and Frenet waypoints parameterized with a 0.5 m distance between each point. This information is not only useful for the vehicle but also for the tracking process implemented on the infrastructure side. Moreover, although the conflict areas are not shown in this Figure, they are managed internally by the arbitration engine in real-time, since the compatibility of conflict zones depends on the resources currently using the emplacement arbitrated. Finally, note that the visualization provided comes from the framework in which the arbitration system was implemented and tested, i.e., Rviz, from ROS2. Figure 3(a) shows the process applied to a four-way intersection; conversely, in Figure 3(b), the result of the same process applied in a roundabout can be seen with the same  
Figure 4: Surveillance areas for each respective traffic emplacement. information extracted from the HD Map, and _Survey Clusters_ found in _Entry_ and _Exit_ lanes. As can be seen, the only difference between both paradigms can be found at the arbitration level since the _Survey_ lanes of the intersection are actual intersected lanes that generate conflict areas, while in the roundabout, these are survey lanes near the entrance where the detected vehicles are checked to ensure a free area for any vehicle entrance. These survey lanes are used in a different manner by the roundabout arbitration system since the conflicting area is found within the cluster itself; i.e., each cluster is compatible with itself, depending on the vehicles using its resources. Given the logical roundabout structure, this makes more sense than defining the compatibility between each other. To clarify how this compatibility is constructed, in Figure 5, the relationship between _Survey Clusters_ is depicted considering an intersection topology. The figure represents four intersection _Clusters_ with several conflict zones.