Thank you for your reply and sorry for my late response.
You are right that we should not design message without defining use cases first. I have started writin use cases of map information with Cockburn’s template(with some modifications).
I wrote them based on functions of current Autoware and functions that are likely implemented in the future, although it is not finished yet. We are planning to discuss about use cases and requirements in detail in the Map WG so hopefully we can provide more sophisticated use cases in next few weeks. Then, we can continue our discussion on requirements and designs.
Having said that, I would like to start Lanelet2 integration with unstructured(binary) message approach for v1.13, as it seems to be most supported message type so far. I believe fundamental purpose of replacing Aisan vector map implementation is to make Autoware’s HD Map format public (both physical storage format and internal data), and having best message design is not crucial to the purpose as long as it transfers sufficient information. Current closed format is likely to discourage developers to create new features or even enter into discussions like this, and dropping Lanelet2 features from v1.13 could be a huge loss to the community. Therefore, I suggest to start implementation with binary message in order to hedge the risk. I am aware that the deadlines for next release is longer than last release, but I would like to submit merge requests in advance because there are many nodes that uses vector_map_info/* topics that needs to be replaced.
I understand the importance of following engineering process, and we should continue designing best map message for Autoware in this thread as well as in Map WG. We will do our best to keep implementation of Lanelet2 nodes for v.1.13 to be independent from message structure so that we can replace it easily once we have the new message design.
How does this sound to you?