In the first Map Working Group Meeting, attendees(including myself) have agreed that Lanelet2 was only realistic solution for map library.
Discussion was very short and the consensus was that Lanelet2 is the only real contender .
As a result, Autoware.ai would start supporting Lanelet2 library from v1.13. However, now that we have more understanding about the library, I would like to discuss once more if we should also Lanelet2 library for Autoware.Auto.
Here are my positive and negative feedback about the library.
- map data structure is flexible. (Adding new tags is very simple)
- The library is organized into modules(packages) for different objectives (core, routing, io, etc.)
- Documents and sample code exists explain how to customize the library. (e.g. adding new parser, adding regulatory element, etc)
- It seems to cover minimal uses cases so far as we were able to replace Autoware.ai functionaity.(see also map functional requirements thread)
- Expression of road objects are geometry driven. i.e.) geometry is not attribute of road objects, but object type is attribute of geometry. You cannot tell the object class unless you look into tags.
- Since all attributes are defined as optional tags, developers must be aware of what tags are present.
- Some objects have alternative ways of expression its geometry. (e.g. trafficlights can be polygon or linestring) This makes code to be relatively complex.
- IMO there are excess abstraction done for the primitive objects. Linestrings3d has 5 inheritance for example. This makes harder to track down the underlying data when debugging.
Overall, I thought the library was easy to use once I get used to it if we want to just use their API. However, underlying implementation is quite complex, and it would be hard to track down the issue if we find a bug. Also, Lanelet2 library is owned by third-party organization(not AWF member) so we cannot make changes to upstream if we cannot persuade them. For example, we have a report that Lanelet2 cannot be built on arm architecture due to mrt-cmake-modules package which Lanelet2 depends on, but the author have no intention of removing the dependency.
Therefore, I think that we should create our own simpler library and maintain in the AWF gitlab repository, and I think we should be starting soon for Hackathon in April.