Support for lanelet map store type

[zwkcoding]

Hi, @berndgassmann When I looked into the code, I noticed:

/**
 * @class AdMapAccess
 * @brief handle loading and removal of map data to/from a map store
 *
 * The type of map store depends on the implementation that is linked to the application.
 * There exists two variants of AdMapAcces, one for AD Map Store and one for Lanelet.
 *
 * The variants (adg::ad::map::Store, Lanelet) themselves are a singleton and therefore any consumer/user of the
 * Store can use it directly.
 */

Based on what I know so far, the current store is loaded from OpenDriveData by AdMapFactory or adm binary file by Serializer. I didn't found any support for lanelet map from the view of implementation. Do I understand correctly?

So, any support plan for it or could you talk about design methodology for supporting OpenDRIVE and Lanelet format at the same time in an elegant method ?

[zwkcoding]

Oh, when I looked into map_maker, I found this line

 admap_generator::AdMapGenerator generator(factory, converter.dataStore, converter.logFactory);

Yes, the store is loaded from osm datastore, SO, the osm datastore is the lanelet format converted from openstreetmap? Then it makes sense. Am I right ?

[berndgassmann]

Yes and no.

In general ad-map has its own HD map data format, which can loaded/stored via the serializer functions.

In the beginning, we worked mainly with the map_maker taking data from OpenStreetMap and convert those offline into the ad-map-access binary "ADM" format. The map_maker is designed to support different reader frontends that translate the input data into some intermediate format before being actually written. Like this we planned to support also other formats like Lanelet there, but that one didn't make it to the end. The conversion steps OSM -> ADM are still available through map_maker.

Then we decided to go rather for support of the standardized OpenDRIVE map format. On OpenDRIVE we decided to perform the conversion on-the-fly while reading the xml as you always want to make use of the current map which e.g. get reported from CARLA. You still are able to store the converted OpenDRIVE map into ADM format, if it is required.

So you can quickly get a rough map of the surrounding using map_maker on an OSM map and create a ADM-variant of it (see e.g. https://github.com/carla-simulator/map/blob/master/ad_map_access/impl/tests/test_files/TPK.adm or https://github.com/carla-simulator/map/blob/master/ad_map_access/impl/tests/test_files/PFZ_Traffic_Lights.adm examples from Karlsruhe). Or you can make use of OpenDRIVE maps directly without explicit conversion.

[zwkcoding]

Like this we planned to support also other formats like Lanelet there, but that one didn't make it to the end.

Why didn't make it ? What trouble or reason that made it fail ? Do you think the method (support different reader frontends that translate the input data into some intermediate format before being actually written) is possible ? BTW, The "intermediate format" is the common format or minmium set format for different HDMap format (osm variants, apollo odr, so on ) ?

I would be grateful if you could share the experience.

[zwkcoding]

Upload a rough flowchart based on what I know about this module

[berndgassmann]

Hmm, not exactly.

The map_maker is independent from ad_map_access and so independent from the ad::map::access::Store. osm_to_adm uses the flow OSM-> dataStore -> ADM That was the initial tool we used to create a map for our testing. But now we are mainly using OpenDRIVE files... but if you don't have an OpenDRIVE file at hand, it's still a useful tool, so we've also put it to the open source.

The upper flow is in general possible and I believe done in one of the unit tests, but not actively used. Actually the flow steps are
OpenDrive -> initializeFormOpenDrive -> Store Keeping the store in memory and running functions on the map.

If you have an ADM file (e.g. by the osm_to_adm calls above) and use it, the flow is: ADM -> (de-)seriaizer -> Store Also keeping store in memory and execute.

And yes, the method "support different reader frontends that translate the input data into some intermediate format before being actually written" is possible. It's quite some time ago, but I believe we had these Lanelet flow as follows in the early stages: OSM -> dataStore-> Lanelet

And we had another flow implemented: Lanelet -> Store but that import was only limited in terms of traffic regulations. Mainly handling of the geometry border points...

At one point we decided to go rather for the OpenDRIVE standard instead of either go to Lanelet2 or to write our own extensions to Lanelet when we were extending the functionality towards e.g. traffic lights, right of way rules, etc. And as we didn't want to develop on multiple fronts with not much benefit => we removed all the lanelet parts after the transition was done.

The "intermediate format" in map maker was grown to the way we needed it to create the ADM format. Don't know if it would match to other formats, too. But we didn't work nor use the map_maker for many years now... I'd see the map_maker as a tool to quickly create an AD map from the streets around the corner ... not sure if I would extend that one.

When thinking of adding other imports, then the best choice, I believe is still the one, we did for OpenDRIVE. Read input data and try to calculate the required data to put it into the Store.

Then you are free to write the Store to a binary file (which would make loading in the end much faster for large maps), or just always read from the original format.

[zwkcoding]

Really Really thanks for your patient ,sincerely and informative reply.

It's really a long history, isn't it ？Really learnt a lot from your process about HD map.

One more thing, as you said "ad-map has its own HD map data format", I know the data format introduction can ref to Map Model So, my question is why design such an HD map data format for internal map format, Is there some consideration?

In the end, The suggestion "When thinking of adding other imports, then the best choice, I believe is still the one, we did for OpenDRIVE. Read input data and try to calculate the required data to put it into the Store." is really attractive, I'll do something similar for my project.

[berndgassmann]

In the end the internal model was designed to store the exact shapes of the road (not center-line + parameters + shape), which in the end is required to perform all the calculations on map data for AD, like map matching, path planning but also: detecting if objects are in the route or if objects at intersection entries have priority (->maneuver planning). Or creating a concrete driving corridor used for trajectory planning. And for these you need concrete topological information, but also exact geometric information + for sure additional information on speed limits, right-of-way, etc. At least to some extend ad-map format considers all of that (maybe not into each and every detail to cover all around the world ;-)

In case you succeed and the input map format is something others might also find beneficial (if nothing super special from your side), feel free to create a pull request and contribute.

[zwkcoding]

OK, I learnt a lot from your reply. The design about the exact shapes of the road sounds lilke Lanelet format. I agree that a good design of map model needs some consideration about providing topological/geometric/physics information and supporting some ADS applications, like matching, routing, planning.

I will go on my research, If I have some progress, I am willing to create a PR. But I need some time to go deeper to this code, If I have some question, I will create a issue :)

Thanks, Nice man！