Represent traffic islands as static objects

[tbleher]

Describe the feature

To properly simulate autonomous pedestrians using OSI (e.g. the OsiPedestrian model as developed as part of SETLevel), pedestrians need to know where traffic islands are. These can be represented in OpenDRIVE (see https://publications.pages.asam.net/standards/ASAM_OpenDRIVE/ASAM_OpenDRIVE_Specification/latest/specification/13_objects/13_14_object_examples.html#_trafficisland ) but there seems to be no way to represent them in OSI currently.

Describe the solution you would like

Traffic islands should be represented in OSI as stationary objects.

Suggestion: Add TYPE_TRAFFICISLAND to osi3::StationaryObject::Classification::Type

Describe alternatives you have considered

None

Describe the backwards compatibility

I believe there are no backward compatibility issues. As OpenDRIVE describes that vehicles should not drive over traffic islands, the concern regarding parking spots expressed in #798 should not apply here.

[thomassedlmayer]

As far as I know, OpenDRIVE is able to define polyline outlines to describe traffic islands' borders quite precisely. The other option in OpenDRIVE are either cuboid or cylindrical bounding boxes. To represent this level of detail in OSI for a stationary object the base polygon in BaseStationary would have to be used. Otherwise OSI only supports cuboid bounding boxes.

I could imagine that it can be problematic that sensor models that don't use this base polygon feature of OSI may be confused by cuboid stationary objects representing traffic islands (imagine a traffic island on the inside of a roundabout). They are very likely to protrude into a lane because of the stationary objects' cuboid nature.

What is the issue with representing a traffic island by using OSI's lanes and lane boundaries with lane type TYPE_NONDRIVING and combinations of sub types like SUBTYPE_BORDER and SUBTYPE_SIDEWALK?

[tbleher]

What is the issue with representing a traffic island by using OSI's lanes and lane boundaries with lane type TYPE_NONDRIVING and combinations of sub types like SUBTYPE_BORDER and SUBTYPE_SIDEWALK?

I think doing so would make it much harder to generate OSI from OpenDRIVE (which I assume OSI cares about, since both standards are both part of ASAM, and many people use OpenDRIVE and OSI together). For one, traffic islands are represented as objects in OpenDRIVE, so it is natural to also represent them as objects in OSI (the underlying space may, at the same time, be represented as a nondriving lane in OpenDRIVE (in addition to the traffic island object), in which case I would expect OSI to model this the same way, as a lane + object). Also, traffic agents typically use logical lanes for the lane description, and logical lanes place specific limits on the boundary points (see description of LogicalLaneBoundary). Logical lanes also have specific conditions on how the neighbours are represented.

From quickly looking into it (and based on my experience with implementing and supporting both OpenDRIVE and OSI in driving simulation), it seems like a lot of effort to translate OpenDRIVE objects to OSI logical lanes and model traffic islands that way - certainly much more than representing them as objects.

Since the request was specifically about supporting pedestrians (which already have to consider objects with various shapes, e.g. street lights and trees, and already use logical lanes), I would appreciate if traffic islands could be modeled as objects, as they are in OpenDRIVE.

Regarding base_polygon: I looked at when this was added, and it seems like base_polygon was added in February 2017 and was first released with OSI v2.1.0. So I would hope that sensor models already have support for base_polygon, since it has been in the standard for more than 8 years.

[thomassedlmayer]

From quickly looking into it (and based on my experience with implementing and supporting both OpenDRIVE and OSI in driving simulation), it seems like a lot of effort to translate OpenDRIVE objects to OSI logical lanes and model traffic islands that way - certainly much more than representing them as objects.

Well, I rather thought about mapping an OpenDRIVE traffic island outline to an OSI free lane boundary and a physical lane. I see that the mapping to logical lanes seems kind of difficult.

I was just trying to figure out how the mapping would work in practice and how it would be applied for sensors that might intentionally (or based on technology limitations) not use something like base_polygon. Just saying that this needs to be considered instead of just adding a new type that nobody knows how to use.

Adding a traffic island object to OSI would mean that people can use it as a relevant detectable obstacle for vehicle ADAS functions. But as far as I understood this is not the actual intention of this request. I am not saying that it does not make sense at all to have this type but it should be clear what it means if we introduce it. What does the bounding box represent? A curbed elevation? What if a cuboid bounding box can not represent it within certain limits (roundabout islands)? Is it possible to enforce setting the base polygon or not allow the type for environments/models that don't support that? Does it include non-elevated painted traffic islands and how would these be represented properly? Those are basically virtual objects that can not be detected by a sensor just like other physical objects (similar to the parking space issue). In my mind these questions make it quite difficult to specify.
Also, I think the current descriptions of OSI's stationary object types aren't really descriptive and we should definitely stop continuing to introduce even more type descriptions like "Object is a traffic island".