This doesnt really answer your question but hopefully gives some insight into our process.
The main bottlenecks were breaking the fisheye-style panoramas into different perspectives (so text was more readable), passing it to OCR and acquiring the panoramas as there isn't an official API.
Because of the above, we constrained ourselves from the outset. For example, the spacings between panoramas was 50m, we didnt traverse residential roads that were less likely to have signage, we only used the most recent panorama for a location etc
If I interpret global as without those constraints (5m spacings, every road, all historic panoramas) then I think the first problem you'll run into is being rate limited by Google. Compute may be able to solve the other problems but it would be very expensive.
It’s perhaps a bit better now, but back when trip-sharing features were first added to third-party mapping and delivery platforms, there was a real tendency to overshare. Many early implementations generated public URLs with sequential or low-entropy IDs that could be guessed or brute-forced. Anyone who knew the pattern could enumerate live or historical “shared trips,” exposing routes, addresses, and other metadata that were never meant to be public.
I documented a few examples of this a while ago, which demonstrate how easily these systems could leak journey data.
It feels like there could potentially be some town planning applications like finding the distribution of rubbish bins vs litter on the floor