Thank you for your feedback.
Would an AWF implemented library still use the lanelet2 conceptual format (lanelets/areas/regulatory elements etc.)? I would prefer that over switching to an alternative without a very good reason.
Would forking the Lanelet2 repo be sufficient for making the kinds of changes which might be needed?
I think the overall concept behind the library could be kept (like separating road objects layers and routing modules). Major change that I would like to have is slimming out implementation of core primitives. About forking, since the part I am concerned is core primitives of the library, we wouldn’t get much merits from forking.
The AWF probably represents the single largest user community which would want to work with Lanelet2. Can we use that to get the lanelet2 developers directly involved?
If we are going to use Lanelet2 for Autoware.auto, I think asking lanelet2 developers to join the WG would be nice.
Regardless of the backend library, it would be nice if the interface used by downstream components could be largely preserved to ease porting of Autoware.ai components to Autoware.Auto. What is the practicality of doing that?
I agree that ideally the interface of the library used by downstream should be independent of backend library. (That’s one of the reasons why we wanted to list up all the functional requirements we need.)
About porting the Autoware.ai components to Autoware.Auto, I don’t think we want to do that in first place. Many of the components(lane_rule, velocity_set, decision_maker) that use HD Maps have very bad implementation, and they need refactoring anyways.
Are there any functional requirements missing from lanelet2 which cannot be added without reworking the library? Pretty much all of the “cons” listed are surface level issues which represent a challenge in learning the lanelet2 API but do not represent bugs or blockers on usage of the library.
I believe all of the functional requirements we have seen so far is achievable using lanelet2. My major concern is the challenge to learn the core implementation behind the API. Maybe it’s only me, but I had hard time looking deep into them. (e.g. How they implement attributeMap? What’s the logic behind registration of new Regulatory Elements?)
It might be good to come up with non functional requirements first.