Lanelet map convention for static obstacles

[maxime-clem]

I would like to discuss the convention for representing static obstacles in a Lanelet map.

Current Convention

The recommended way to represent such information is by tagging linestrings with the tag type. For example, type=curbstone or type=guard_rail would correspond to a static obstacle.
See https://github.com/fzi-forschungszentrum-informatik/Lanelet2/blob/master/lanelet2_core/doc/LinestringTagging.md for more details.

Current Use

Currently, the lane_following module of the behavior_path_planner uses the type road_border in its logic to extend the drivable area (
https://github.com/autowarefoundation/autoware.universe/blob/89bc5d26c6483172e4041f95266a8c5b91669b33/planning/behavior_path_planner/src/scene_module/lane_following/lane_following_module.cpp#L146-L149).

Issue

Currently, a single type value (road_border) is used as static obstacle. If a map contains other static obstacles (e.g., guard_rail), they will not be considered by that algorithm.

Dicussion Point

How should static obstacles be represented in the Lanelet map ?

I can think of 2 options:

• "Real" tags: associate the most accurate tag with the object in the Lanelet map. E.g., a guard rail should be tagged type=guard_rail. Planning algorithms should consider a list of tags (e.g., guard_rail, wall, fence, ...) relevant to their algorithm.
  • Pros: general solution; information in the map stays close to the real world.
  • Cons: ?
• Planning tags: associate tags specific to the planning algorithms. E.g., an algorithm use the tag type=obstacle and all its relevant obstacles need to be tagged accordingly in the Lanelet map.
  • Pros: control which object is used by which algorithm.
  • Cons: tag has a meaning only for some Autoware modules.

Please share other potential use cases or suggestions.

[angry-crab]

Please correct me if I was wrong. I think most static objects are either considered as obstacles or some symbols to identify road borders. In such cases, the specific type does not matter that much since most logic is same. I guess planning tags sounds better at least for now.