roadrunner-convert-lanelet2-to-rrhd
The roadrunner-convert-lanelet2-to-rrhd skill converts Lanelet2 OpenStreetMap files in .osm format to RoadRunner HD Map .rrhd format for use in autonomous driving simulations. Use this skill when importing Lanelet2-formatted maps into RoadRunner via MATLAB, specifically for files containing type=lanelet relations with complete lane topology, junction definitions, barriers, traffic signs, and road markings that require conversion to the proprietary RRHD format.
git clone --depth 1 https://github.com/matlab/matlab-agentic-toolkit /tmp/roadrunner-convert-lanelet2-to-rrhd && cp -r /tmp/roadrunner-convert-lanelet2-to-rrhd/skills-catalog/automotive/roadrunner-convert-lanelet2-to-rrhd ~/.claude/skills/roadrunner-convert-lanelet2-to-rrhdSKILL.md
# Lanelet2 to RRHD Converter
Converts Lanelet2 `.osm` files to RoadRunner HD Map `.rrhd` format.
## When to Use
- Converting a Lanelet2 `.osm` file to RoadRunner HD Map `.rrhd` format
- Importing Lanelet2 maps into RoadRunner via MATLAB
- Building RRHD from `.osm` sources that contain `type=lanelet` relations
- Need full pipeline: parse, geometry, topology, semantics, junctions, barriers, signs, markings
## When NOT to Use
- Input is a standard OpenStreetMap file (highway=* ways without `type=lanelet` relations)
- Input is OpenDRIVE `.xodr` — import directly via `roadrunner-import-scene`
- Building RRHD from scratch without a source file — use `roadrunner-rrhd-authoring`
- Only need asset path lookups — use `roadrunner-asset-mapping`
## Key Rules
- **Always write to .m files.** Never put multi-line MATLAB code directly in `evaluate_matlab_code`. Write to a `.m` file, run with `run_matlab_file`, edit on error.
- **ALL pipeline steps are mandatory.** Do NOT stop after writing lanes/boundaries — junctions, curve markings, barriers, signs, and speed limits must all be built.
- **Boundary geometry is IMMUTABLE.** Never flip, resample, project, or modify boundary points.
- **One boundary object per way.** Deduplicate via `wayToBndID` map.
- **Detect alignment for EVERY lane.** Never hardcode `"Forward"` for all boundaries.
- **Center line density: 1 point per meter minimum.** Use `max(10, round(avgLen), nLeft, nRight)`.
- **Run enforcement gate before `write()`.** Alignment, spatial, extension, and completeness checks are mandatory.
- **No nested function definitions.** Code runs in script context — all logic inline or anonymous functions.
## Behavior
Generate MATLAB code that performs the conversion pipeline described below. Run it via `mcp__matlab__evaluate_matlab_code`. No pre-built scripts or `addpath` calls are needed — Claude generates all code at runtime from these instructions.
**MANDATORY: ALL steps must be executed.** Do NOT stop after writing lanes/boundaries. The pipeline is incomplete without: junctions, curve markings (stop lines + crosswalks), barriers, signs, and speed limits. Every element found in the OSM MUST appear in the output RRHD.
**MANDATORY: Steps 3b and 3c (discovery) must execute IN THE SAME code block as Step 3a.** These are not optional post-processing — they are part of parsing. The discovery loop code is inlined below in Step 3. If you skip 3b/3c, the completeness gate in Step 9 will fail with assertion errors.
**Scope:** This skill supports **Lanelet2 OSM only**. If the input is a standard OpenStreetMap file (highway=* ways without `type=lanelet` relations), do NOT attempt conversion. Instead inform the user: "This file appears to be a standard OpenStreetMap road network, not a Lanelet2 map. This skill only supports Lanelet2 OSM → RRHD conversion."
**Companion skills (invoke automatically during conversion):**
| Skill | When to invoke | Purpose |
|-------|----------------|---------|
| `roadrunner-rrhd-authoring` | Step 9 (Build RRHD Objects) | Provides `roadrunner.hdmap.*` class/property reference and construction patterns |
| `roadrunner-asset-mapping` | Step 8 (Extract Semantics) | Resolves marking subtypes, sign codes, and barrier types to RoadRunner asset paths |
These skills are loaded on demand — read their references when generating RRHD construction code or resolving asset paths. This skill provides the Lanelet2-specific parsing and bridging logic.
## Coordinate System
Lanelet2 OSM nodes may use either:
- **`local_x`/`local_y` tags** — already in local meters, use directly as geometry X/Y
- **`lat`/`lon` attributes only** — geographic coordinates that MUST be projected to local meters
### Step 1: Check for `map_projector_info.yaml`
Lanelet2 datasets typically include a `map_projector_info.yaml` file in the same directory as the `.osm` file. This file specifies the projection and map origin:
```yaml
ProjectorType: TransverseMercator
VerticalDatum: WGS84
MapOrigin:
Latitude: 42.300945
Longitude: -83.698205
Altitude: 0
```
**Always look for this file first.** Parse it to get `ProjectorType` and `MapOrigin`:
```matlab
projFile = fullfile(fileparts(osmFile), "map_projector_info.yaml");
if isfile(projFile)
txt = fileread(projFile);
latMatch = regexp(txt, 'Latitude:\s*([-\d.]+)', 'tokens');
lonMatch = regexp(txt, 'Longitude:\s*([-\d.]+)', 'tokens');
if ~isempty(latMatch) && ~isempty(lonMatch)
originLat = str2double(latMatch{1}{1});
originLon = str2double(lonMatch{1}{1});
end
end
```
If `MapOrigin` is `[0, 0]`, the origin is implicit — use the centroid of all nodes instead.
### Step 2: Determine coordinate mode
1. **Nodes have `local_x`/`local_y`** → use directly, set `geoRef` from `map_projector_info.yaml` MapOrigin (or from node lat/lon if yaml missing)
2. **Nodes have only `lat`/`lon`** → project to local ENU meters using the origin from yaml (or node centroid as fallback)
### Step 3: Project lat/lon to local meters (when needed)
```matlab
% Origin from map_projector_info.yaml or centroid fallback
geoRef = [originLat, originLon];
% For each node, convert to local meters:
dLat = node.lat - originLat;
dLon = node.lon - originLon;
metersPerDegLat = 111132.92;
metersPerDegLon = 111132.92 * cosd(originLat);
x = dLon * metersPerDegLon; % East
y = dLat * metersPerDegLat; % North
z = node.ele; % Up (elevation)
```
Set `rrMap.GeoReference = [originLat, originLon]` so RoadRunner knows the map's geographic position.
**IMPORTANT:** This projection happens ONCE during node parsing. All downstream geometry (boundaries, center lines, barriers, signs) uses the projected local coordinates. The "boundary geometry is immutable" rule (below) refers to the projected coordinates — do not re-project or modify them after initial parsing.
## Geometry Invariants (MUST enforce — violations produce broken RRHD)
These rules are NON-NEGOTIABLE. Every conversion MUST follow them:
1. **Boundary>
Import recorded driving sensor data (GPS, camera, lidar, actor tracks, lanes) into scenariobuilder.* objects (GPSData, CameraData, LidarData, ActorTrackData, Trajectory, laneData) and run preprocessing — synchronize, offset correction, crop, normalizeTimestamps, convertTimestamps. Also: compute actor tracks from lidar when no annotations exist, attach camera/lidar mounting + intrinsics, export to MAT/workspace/timetable/script. Use for raw driving dataset files (KITTI, nuScenes, Waymo, Pandaset, ROS/ROS2 bags, .mat, .csv, .mp4) or driving/vehicle/sensor logs that need wrapping. drivingLogAnalyzer (DLA) is OPT-IN ONLY — invoke only on explicit user request ('DLA', 'open in DLA', 'inspect/explore/analyze the recording') or reported sensor problem (sync drift, timestamp mismatch, overlay misalignment). NEVER auto-launch DLA after wrapping (Rule 0). For 'build scenario / export to RoadRunner / drivingScenario / OpenSCENARIO / Unreal / simulate', hand off to matlab-scenario-builder.
Generate driving scenes, scenarios, road surfaces, and 3D content from already-wrapped scenariobuilder.* sensor data (GPS, camera, lidar, actor tracks) using Scenario Builder for Automated Driving Toolbox. Use to BUILD, EXPORT, or AUGMENT a virtual scenario/scene/map: ego or actor trajectories, trajectory smoothing, OpenCRG road-surface extraction, 3D asset generation, static-object placement, point-cloud georeferencing + elevation, lane-based ego localization, sensor-fusion tracking, scenario-event extraction (cut-ins, hard brakes, near-misses, ADAS disengagements), or export to RoadRunner, drivingScenario, OpenDRIVE, OpenCRG, OpenSCENARIO, or Unreal Engine. Also: log-to-scenario, scenario harvesting, accident/near-miss reconstruction, SOTIF (ISO 21448) and ISO 26262 scenario coverage, USGS-aerial-lidar scene augmentation, traffic-sign placement from camera+lidar logs. NOT for raw-data import or multi-sensor sync/crop/offset/timestamp normalization — route those to matlab-driving-data-importer.
>
>
>
Build, modify, and diagram SimBiology models — API reference, helper functions, and layout patterns. Use when constructing or editing models programmatically or visually.
Fit SimBiology model parameters to data — fitproblem, population NLME, virtual patients, and NCA. Use when asked to fit, estimate, calibrate, or compute PK metrics.