|
| 1 | +## Recordings and Map Data |
| 2 | + |
| 3 | +The omega-prime library has two major components, the `Recording` and the `Map`. |
| 4 | +The `Recording` stores the dynamic object information and the map object. |
| 5 | +A recording is a continuous traffic observation and usually corresponds to an OSI trace or an MCAP recording. |
| 6 | +The dynamic object information is stored in the attribute `df` (for DataFrame) as a single polars DataFrame, where each row corresponds to the observation of a single moving object at a specific point in time. |
| 7 | +A convenience function to access this data in an object oriented manner are the `MovingObject` stored in `moving_objects` attribute of the `Recording`. |
| 8 | +For most operations, it is recommended to use the DataFrame stored in `df` directly, as polars provides a fast and flexible API for data manipulation. |
| 9 | +See the [Polars user guide](https://docs.pola.rs/) for more information on how to use polars DataFrames. |
| 10 | +The object polygons for each timestamp are accessible as shapely objects in the `polygon` column or as [`polars_st`](https://github.com/Oreilles/polars-st) geometries in the `geometry` column. |
| 11 | +It is recommended to make use of `polars_st` as much as possible instead of `shapely` since `polars_st` can utilize the benefits of using a DataFrame more effectively. |
| 12 | + |
| 13 | + |
| 14 | +```mermaid |
| 15 | +flowchart TB |
| 16 | + |
| 17 | + subgraph recording [Recording] |
| 18 | + rec_map[map]@{ shape: doc } |
| 19 | + df@{ shape: win-pane } |
| 20 | + moving_objects@{ shape: docs } |
| 21 | + end |
| 22 | + df -.- moving_objects |
| 23 | +
|
| 24 | + rec_map --> map |
| 25 | + subgraph map [Map] |
| 26 | + lane_boundaries@{ shape: docs } |
| 27 | + lanes@{ shape: docs } |
| 28 | + end |
| 29 | +
|
| 30 | + subgraph lane [Lane] |
| 31 | + centerline |
| 32 | + lane_polygon[polygon] |
| 33 | + right_boundary_id@{ shape: doc } |
| 34 | + left_boundary_id@{ shape: doc } |
| 35 | + end |
| 36 | +
|
| 37 | + subgraph lane_boundary [LaneBoudary] |
| 38 | + polyline |
| 39 | + end |
| 40 | + lanes --> lane |
| 41 | + lane_boundaries --> lane_boundary |
| 42 | + right_boundary_id --> lane_boundary |
| 43 | + left_boundary_id --> lane_boundary |
| 44 | + polyline -.- lane_polygon |
| 45 | +
|
| 46 | + subgraph moving_object [MovingObject] |
| 47 | + |
| 48 | + end |
| 49 | + moving_objects --> moving_object |
| 50 | +``` |
| 51 | + |
| 52 | +The `Map` stores the static map information, i.e., lanes and lane boundaries. |
| 53 | +Lanes and lane boundaries are derived form the ASAM OSI definition and are also corresponding to the concept of lanelets in Lanelet2. |
| 54 | +When working with the map data in python, the geometries of the map are represented through polygons or polylines (for boundaries and centerlines) using [shapely](https://shapely.readthedocs.io/en/stable/). |
| 55 | + |
| 56 | +`MovingObject`, `Lane` and `LaneBoundary` each have types and additional information corresponding to ASAM OSI definitions. |
| 57 | +The library uses [betterosi](https://github.com/ika-rwth-aachen/betterosi) as a python implementation of ASAM OSI. |
| 58 | + |
| 59 | +The omega-prime specification suggests the usage of ASAM OpenDRIVE maps as map data. |
| 60 | +This is supported through the `MapOdr` subclass of `Map`. |
| 61 | +Additionally, this library provides subclasses for ASAM OSI maps through `MapOsi` and `MapOsiCenterline`, where the latter does not provide lane polygons and lane boundaries (which is needed for some datasets). |
| 62 | +In the future, `MapLanelet` will provide support for Lanelet2 maps. |
| 63 | +Thus, a key benefit of using this library is the unified interface to work with different map formats. |
| 64 | + |
| 65 | +See [Tutorials / Introduction](notebooks/tutorial) for examples of how to use omega-prime. |
| 66 | + |
| 67 | +## Converters |
| 68 | + |
| 69 | +The class `omega_prime.converters.DatasetConverter` aids in defining converters that transform existing data sources into the omega-prime format. |
| 70 | +For guidance on how to implement your own converter you can have a look at the `LxdConverter`, which translates the [LevelXData](https://levelxdata.com/) datasets into omega-prime. |
| 71 | +Additionally, you can have a look at [omega-prime-trajdata](https://github.com/ika-rwth-aachen/omega-prime-trajdata) to convert many motion prediction datasets into the omega-prime format. |
| 72 | +Examples of datasets that can be converted with `omega-prime-trajdata` into omega-prime are [NuPlan](https://www.nuscenes.org/nuplan), [NuScene](https://www.nuscenes.org/), [Argoverse2](https://www.argoverse.org/av2.html) and [Waymo Open Dataset - Motion](https://waymo.com/open/). |
| 73 | +Here, the class `TrajdataConverter` implements the `DatasetConverter`. |
| 74 | + |
| 75 | +Data that is available as ASAM OpenDRIVE and ASAM OSI traces does not need a conversion an can be directly used with `omega-prime`. |
| 76 | +Many simulation tools such as [esmini](https://github.com/esmini/esmini) or [CARLA](https://carla.org/) through [Carla-OSI-Service](https://github.com/DLR-TS/Carla-OSI-Service) support the logging of simulation data as OSI traces. |
| 77 | +These can be directly read in and analyzed with the omega-prime library. |
| 78 | + |
| 79 | +## Locator |
| 80 | + |
| 81 | +The `Locator` uses the `Map` object to locate `MovingObject`s or any polygon or coordinate onto the `Lane`s of the map. |
| 82 | +The `Locator` can assign lane occupancy to objects and derive s-t-coordinate (Frenet coordinates). |
| 83 | + |
| 84 | +See [Tutorials / Locator](notebooks/tutorial_locator) for examples of how to use the `Locator`. |
| 85 | + |
| 86 | +## Metrics |
| 87 | + |
| 88 | +The `MetricsManager` makes use of [Polars feature of lazy evaulation](https://docs.pola.rs/user-guide/concepts/lazy-api/#previewing-the-query-plan) to enable efficient computation of many, possible, dependent metrics. |
| 89 | +The metrics computation can be defined by subclassing `Metric` or, more easily by using the decorator `@omega_prime.metrics.metric` a function that computes your metric based on the `Recording.df`. |
| 90 | +Moreover, the `Metric` lets you define dependencies between metrics, e.g., `distance_traveled` needs to be computed to compute `timegaps`. |
| 91 | +The `MetricsManager` then handles the dependencies automatically, and makes sure only the things you actually need are computed. |
| 92 | + |
| 93 | +See [Tutorials / Metrics](notebooks/tutorial_metrics) for examples of how to define and use the metric utilities. |
0 commit comments