Mapping at Aurora (opens in new tab)

I think you've hit upon one of the most challenging aspects of mapping, which is that the real world is incredibly dynamic. And it's not just the things that we think of as dynamic (bicyclists, pedestrians, other vehicles), it's also the geometry itself (lane lines, vegetation, building construction). So this requires some form of updating (either semantic, geometric, or both). And as you pointed out this is not uniform: dense city maps can change from week-to-week, whereas rural maps require less frequent updates. So first you need to build an on-board/offline system that can first detect these changes, then configure the pipeline so that the proper data is collected and updates can be compact and fast. As mentioned in the article, we have a git-like structure for Atlas updates which allows us to track small changes. And the fact that the Atlas is only locally consistent means that any update is contained just to the detected area.

I think that there is grey-area between data that is sufficiently static to represent in a map (buildings, lane lines) and data that is dynamic and must be handled by on-board perception systems (pedestrians, road debris). A good way to think of this is that the map is encoding priors about the environment for use by the perception system. It may be possible in the future to do all of this on-board (like humans do!) but the computational constraints would be quite high.