Sizing the Total Data Footprint of Google Maps

Estimate how much storage space Google Maps needs. Decide which parts of the product your estimate covers, break the calculation into pieces you can reason about, label your assumptions, and finish with a figure and a range. ```hint Count what is stored, layer by layer Split Google Maps into the kinds of data it keeps, and for each one pick something you can count, such as area, road length, places or photos, along with a size per unit. ``` ### Clarifying Questions - Which parts of Google Maps are in scope: the road map with its labels, satellite and aerial imagery, Street View, place listings with reviews and photos, or all of them? - Is the estimate for one copy of the current data, or does it include replicas, backups and older versions of imagery? - Should the road map be treated as pre-drawn image tiles or as vector data that the app draws itself? - Does it cover the whole world or one region? ### What a Strong Answer Covers - A scope decision on which layers and which copies count, settled before any arithmetic - A breakdown into data layers, each with a countable driver and a size per unit - Labeled assumptions with rationale, especially for resolution, coverage and compression - Correct arithmetic with consistent units across bytes, area and counts - A sanity check, a final range, and which layer dominates the total and why ### Follow-up Questions - How much new storage does Maps add each year, and what drives that growth? - If storage costs had to be cut in half, which layer would you shrink first, and what would users lose? - How would the answer change if every historical Street View and satellite capture were kept? - Suppose the question asked only for the storage behind every image Maps shows: satellite and aerial photos, Street View panoramas, the photos people upload for places (360-degree ones included), and the drawn map tiles and icons. How would your breakdown and final figure change?