OpenLABEL Format

OpenLABEL is a standardized annotation format developed by ASAM. It comes with in-depth documentation of the format as well as a json schema, which can be used to ensure that the format is valid.

Even though OpenLABEL is a strict format there is still some room for interpretation. In this section we try to clarify some of these parts and explain the choices that we have made within the standard.

The rotation is such that the y-axis is facing forwards, with a rotation order of XYZ. This means that a cuboid with a heading (yaw) equal to 0 is aligned with the y-axis in the positive direction along the axis. This is somewhat different compared to the ISO 8855 standard, where the forward direction is along the x-axis. Conversion to ISO 8855 can then be done by applying a rotation around the z-axis and changing sx and sy in the following way

Due to reasons of simplicity we have made the choice to treat non-sequences in the same way as sequences. This means that non-sequences are represented as a sequence with only one frame. Only data such as name and type are defined in the top level element keys. All other information is stored under frames, see example below

The stream property is used to indicate which stream/sensor/source that the geometry och property was annotated in. For example here is an object with a point that has been annotated in a stream with the name Camera. Note that all corresponding attributes for the geometry have also been annotated in the same stream.

We consider two types of relations; unidirectional relations between two objects and group relations. In addition to these, there is a need to represent false relations, i.e. relation properties that are not actually pointers to other objects but rather take values such as Inconclusive, Nothing or Unclear.

Relations are unidirectional, meaning that if an object, object1, has a relation to another object, object2, it does not mean that object2 has a relation to object1. Below follows an example where car-0 is following car-1 and it is unclear whether car-2 is following another car or not.

In the Kognic Platform, there is support for assigning values to relations that are not actually references to other objects. Examples are Inconclusive and Nothing. Actions are used to represent these in the following way, where the name of the action determines the value and the type determines the property name.

Group relations are relations where objects can be seen as belonging to a group. There is then a need for an abstract concept that describes the group. OpenLABEL suggests the use of actions for this in such a way that each object in the group has a relation of type isSubjectOfAction to this action. Below follows an example where two lane-0 and lane-1 belong to the same road, while it is unclear whether lane-2 belongs to a road.

If a relation is stream specific, there will be a property stream_relations denoting which stream the list of relations belong to.

Polygons are described by a list of Poly2d objects in OpenLABEL. One of these represents the exterior while the others represent potential holes and this is determined by the boolean property is_hole. Below follows an example of a polygon with one hole.

The value MODE_POLY2D_ABSOLUTE is the only supported value for mode. Absolute mode means that the values in val are interpreted as pixel coordinates (not as values relative to the first coordinate pair).

Multi-polygons are simply lists of polygons, so we describe these in a similar way with lists of Poly2d objects with the property is_hole. However, we also add one additional property polygon_id that determines which polygon a Poly2d object belongs to in the multi-polygon. Below follows an example of a multi-polygon with two polygons with one hole each.

The value MODE_POLY2D_ABSOLUTE is the only supported value for mode. Absolute mode means that the values in val are interpreted as pixel coordinates (not as values relative to the first coordinate pair).

Curves are represented using the poly2d geometry and the interpolation method is specified as a text property in the following way.

The value MODE_POLY2D_ABSOLUTE is the only supported value for mode. Absolute mode means that the values in val are interpreted as pixel coordinates (not as values relative to the first coordinate pair). The property interpolation_method is mandatory and determines how the nodes should be associated to each other. The following values are supported:

A 3D lane is represented as two lines in 3D (poly3d), one to the right and the other to the left. The text property lane_edge determines whether the line is to the right or to the left. The lines will always have closed set to false.

A 2D point is represented as a single point2d. Each point2d has an optional point_class attribute. For single points this may be ommited, but if set it must be equal to the type of the object. This attribute is reserved for future use on other point-based geometries.

A group of points is used when multiple points refere to the same object. The attribute point_class is required for each of the points in the point group, and the point_class has to be different from the object type. The point_class value "line_reference_point" is reserved for future use cases.

Related documenation for the task view Class groups.

A collection of geometries as described in the link above will be represented as having a reserved relation as type geometry_collection.