[jacoblambert]

Summary

Two related changes to the 1.0 schema: consistent name / index fields, and a compact sensor ID that lets a merged LiDAR file say which LiDAR each point came from.

Consistent name / index fields

• instance.instance_name / instance_index are renamed name / index, as in category.
• Every table that has them starts with token, name (channel for sensor), then index: category, instance, sensor, vehicle, map (scene and attribute already did).
• sample_data.frame_index keeps its name: it is a position inside a file, not an ID.

sensor.index and LiDAR source columns

• sensor.index (required, 0–255): a compact ID for each sensor, set on every sensor row, cameras included.
• source_index (uint8) and source_timestamp (int64, µs) columns in a merged LiDAR file, when sensor.lidar.source_channels is not empty:
  • source_index is the sensor.index of the LiDAR the point came from. This follows the same pattern as the point-wise labels: label → category.index, instance → instance.index.
  • source_timestamp is that LiDAR's scan time.
  • They are listed in sensor.lidar.fields like any other column.
• They replace the 0.x per-frame .info files (point ranges and per-source stamps per frame). Points are grouped by source, so both columns are runs of equal values: about 1 KB per frame compressed, measured on real data.
• No reader change: load_pointcloud returns whatever columns the file has.

Docs: docs/schema/v1/data.md has a new "Merged Sources" section, and table.md is updated for the renames and sensor.index.

Sample dataset

Regenerated with the new field order and sensor.index. Its only LiDAR has no sources, so the source columns are exercised later, by the sanity checks and the 0.x conversion.

Tests

• The sample tables still load and serialize back to the same JSON (existing tests, with the renamed fields).
• tests/schema/v1/test_sensor.py: sensor.index of -1, 256 or null is rejected.

[ktro2828]

LGTM