[Discussion] Map Architecture

[kfunaoka]

A map architecture which welcomes multiple map formats/companies/organization/researchers.

A.I.

• Dig down map abstraction layer

[kfunaoka]

@gbiggs suggested that Internal Preresentation is more suitable for ROS convention.

[hadiTab]

@kfunaoka has the internal representation been decided yet?

[kfunaoka]

Not yet and A.I.

[msmcconnell]

A map abstraction layer is a great idea! Are you looking to define the API in this issue as well, or just propose the creation of such an API?

I think there may be some overlap with #408 as the definition of unique lane id's will be determined by the vector map specification standard (Autoware format, lanelet2, etc.) It might be best to pick one representation to use in ros messages, but allow the underlying internal structures to be swapped out as you suggest.

[gbiggs]

A map abstraction layer is a great idea! Are you looking to define the API in this issue as well, or just propose the creation of such an API?

I think the idea is to define that API here as well.

The information model that the API represents will need to be a superset of all supported map formats. Although the diagram above lists "other format", there is no guarantee that any information model we define will be able to support all information contained in some unknown, possibly as-yet-undefined map format. I propose we define which map formats will be supported now so that we know what information must be representable. We can extend the information model in the future when and if necessary.

I think a good selection that covers maps commonly used and those in use by Tier IV is Aisan, Autoware, Lanelet2 and OpenDRIVE.

[TonysCousin]

Generally agree, but the API doesn't necessarily need to be a strict superset of all supported formats. It may be worth choosing to ignore a particular feature of a particular format that is seen as low value because it would be seldom used. Eliminating difficult "special interest" cases, if any exist, could allow much faster progress. Then those cases could be considered for inclusion in a later enhancement.

[gbiggs]

That's true. We should start with the major use cases and hard-to-add-later parts of the information model, and do the remainder incrementally.

[mitsudome-r]

The format proposed in #408 should contain most of commonly used information in Autoware and should contain less "unwanted" information (since that how it was made). Maybe internal representation can start with something similar to the format and extend it to add any valuable features from other formats.

[mitsudome-r]

Another possible solution that I can think of is to use Lanelet2 as base.
It already has some useful API, and seems to contain most of required information.
My concern is that Lanelet is white line based implementation, while current Autoware is mainly centerline based(waypoint based) so it might require some workload to replace current implementation with Lanelet2-based implementation.

[msmcconnell]

@mitsudome-r
LaneLet2 does provide center line calculations per documentation https://github.com/fzi-forschungszentrum-informatik/Lanelet2/blob/master/lanelet2_core/doc/LaneletPrimitives.md

lanelets may have an additional centerline to guide the vehicle. This centerline must be within the area formed by the left and right bound and must not touch the boundaries. If no centerline is given, the library will calculate it for you.

However, the key for an interface like that proposed above is how we represent the lane geometry and connections in ROS messages. I believe that the description should match one of the standards presented in #408. This ensures that all users have a clearly defined way of interpreting the data. Regardless of which file format or processing component is actually used for map data, a single interface representation should be selected to describe the road in the abstract.

[mitsudome-r]

@msmcconnell
Yes, I am aware of the center line calculation.
However, there is no connection information between the center lines of each lanelet. You have to reference back to lanelet connection in order to connect the center line, which I thought is bothersome if we mainly use center line for calculation. Also, points of the centerline doesn't have unique ID, and we have to assign them by our hands.

I have a feeling that we at least need to re-organize or modify Lanelet information to some extent in order to use it in Autoware without stress. Once we do that modification, we have to convert them back to Lanelet format to use Lanelet2 functions, which kind of weakens the merit of using Lanelet2 in calculation efficiency or we would have to modify the library itself.

However, the key for an interface like that proposed above is how we represent the lane geometry and connections in ROS messages.

I also think this is very important. I've asked in Lanlet2 if they have such interface, but they said that it will be available later this year.
fzi-forschungszentrum-informatik/Lanelet2#7

[msmcconnell]

@mitsudome-r
Those are valid concerns with regards to LaneLet2 and probably worth sharing in the other issue page as well.

Why don't we start moving this issue forward by identifying the high level data we need even if some details like (lane id) may not yet be determined.

For this purpose, I have created the following document. Please leave comments. After we agree upon a data set and access method, we can start outlining ROS messages.
https://docs.google.com/document/d/1bRKtcFLnzv0C-zgzOpggp7TU2MW1y8Q0NgVNhGVSMT4/edit?usp=sharing