Context
Hi CommonRoad maintainers,
We are working on CommonRoad ↔ Autoware integration with an automotive autonomy partner.
As part of this workflow, we convert real-world Lanelet2 .osm maps to CommonRoad (via lanelet2cr) and then to SUMO/Autoware.
This issue breaks traffic-light handling in the converted CommonRoad scenarios.
Note: I cannot share the input map publicly due to NDA.
Observed behavior
After Lanelet2 → CommonRoad conversion, all traffic lights in the output scenario have non-finite positions:
Lanelet and traffic sign coordinates are finite; only traffic lights are affected.
In my case, 946/946 traffic lights were affected.
Expected behavior
Traffic light coordinates should be finite values in scenario coordinates.
Root cause hypothesis
In crdesigner/map_conversion/lanelet2/lanelet2cr.py (master), traffic lights use a different lat/lon argument order than other objects.
Traffic light conversion (current):
x, y = self.transformer.transform(node.lon, node.lat)
Other conversions in the same file use (lat, lon), e.g. origin and traffic signs:
self.origin_utm = self.transformer.transform(origin_lat, origin_lon)
x, y = self.transformer.transform(float(traffic_sign_node.lat), float(traffic_sign_node.lon))
Since the transformer is created via Transformer.from_proj(...) without always_xy=True, axis order can follow CRS defaults; passing (lon, lat) where (lat, lon) is expected may push latitude out of range and yield inf.
Suggested fix direction
- Make traffic light conversion consistent with the rest of the file (use (lat, lon)), or enforce a single convention via
always_xy=True and update all call sites.
Impact
This issue makes traffic lights unusable in downstream SUMO/Autoware workflows (signals cannot be placed correctly), blocking robust LL2 → CR conversion for real-world maps.
Context
Hi CommonRoad maintainers,
We are working on CommonRoad ↔ Autoware integration with an automotive autonomy partner.
As part of this workflow, we convert real-world Lanelet2
.osmmaps to CommonRoad (vialanelet2cr) and then to SUMO/Autoware.This issue breaks traffic-light handling in the converted CommonRoad scenarios.
Note: I cannot share the input map publicly due to NDA.
Observed behavior
After Lanelet2 → CommonRoad conversion, all traffic lights in the output scenario have non-finite positions:
Lanelet and traffic sign coordinates are finite; only traffic lights are affected.
In my case, 946/946 traffic lights were affected.
Expected behavior
Traffic light coordinates should be finite values in scenario coordinates.
Root cause hypothesis
In
crdesigner/map_conversion/lanelet2/lanelet2cr.py(master), traffic lights use a different lat/lon argument order than other objects.Traffic light conversion (current):
Other conversions in the same file use (lat, lon), e.g. origin and traffic signs:
Since the transformer is created via
Transformer.from_proj(...)withoutalways_xy=True, axis order can follow CRS defaults; passing (lon, lat) where (lat, lon) is expected may push latitude out of range and yieldinf.Suggested fix direction
always_xy=Trueand update all call sites.Impact
This issue makes traffic lights unusable in downstream SUMO/Autoware workflows (signals cannot be placed correctly), blocking robust LL2 → CR conversion for real-world maps.