Stop Downloading the Whole Map: Rethinking How GIS Systems Are Built

Cloud-native GIS means no longer moving data to work. Store it once in a shared place and let tools read only the part they need. 

Cloud-native GIS in one picture: stop carrying the whole box of data and pick only the piece you need.

Imagine you need land-use data for one taluka

Say you need land-use information for one taluka (a sub-district). Someone shares a link to a state-level file that runs into gigabytes. You wait for the download, unzip it, load it, clip out your taluka, and throw away almost everything you fetched. A month later, a colleague does the same and saves her own copy. Now two "latest versions" sit on two laptops.

Nothing went wrong here. This is how GIS has worked for decades. What is changing is the assumption behind it: that to use data, you must first bring it to you. The alternative is called cloud native. Data sits in one shared place, and software fetches only the piece it needs, such as your taluka, straight from there.

How GIS systems were traditionally built

In the classic setup, data lives inside the system: files on a shared drive, or tables in a database on one server, with software installed on desktops and on that server. To use the data, you either go to the machine or take a copy away.

This works well, and it is worth saying why. Editing is straightforward; access control is simple, and the team knows the tools. For a small team with modest data, it is hard to beat.

The cracks appear as things grow:

• Copies multiply, and nobody is sure which one is current.
• In a single-server design, more users usually mean a bigger server, not smaller ones.
• Data is shared as whole files, even when you only need a sliver.
• Tools are tied to specific formats and connectors.

In the traditional setup, everything depends on one central store. As more apps, people and processes reach for it, it becomes the bottleneck.

Why this is coming up now

Cloud-native ideas have existed for years. Three changes have made them urgent:

• Data arrives faster than anyone can copy it. More satellites, cheaper drones and denser sensors mean archives grow every day. Downloading and re-storing data for each project stops scaling.
• Big archives already live in clouds. Major satellite collections such as Landsat and Sentinel-2 are hosted on public cloud platforms. The question shifts from "how do we download this?" to "how do we work with it where it already is?"
• More kinds of users want the same data. Notebooks, machine-learning pipelines, mobile apps and partner systems all want in. A training pipeline reads in bulk, while a phone on a patchy network needs a small slice, fast. One delivery path cannot suit both.

Across an organization you pay three times: time waiting on transfers, money on duplicate storage and data movement, and effort working out which copy is the real one.

A simple, illustrative example: a 10 GB land-use dataset, and five analysts who each keep their own copy. That is 50 GB stored, 50 GB downloaded, and five versions to reconcile. One shared copy would be 10 GB, with nothing to reconcile. Now multiply that with every dataset and every project.

"On the cloud" is not the same as "cloud-native"

Moving your old server onto a cloud virtual machine is like renting a desk in a new building and carrying all your old furniture there. The address has changed, but the design has not. This is often called "lift and shift", and it relocates the bottleneck instead of removing it.

Cloud-native means designing around what the cloud is good at: cheap, durable storage, computing power you switch on only when needed, and everything reachable through a web address.

Four shifts that define it

1. Data moves out of the server and into object storage. Object storage is a service that holds files in a "bucket", and each file gets its own web address (URL). Nothing needs to run a GIS server just to hold the files.
2. Storage and compute are separated. The data waits quietly. Computing power appears when someone asks a question and disappears afterwards, so you scale by adding workers, not by buying a bigger machine.
3. Software reads only the part it needs. Newer file formats are organized, so a tool can ask the server for just the bytes it wants (an HTTP range request) instead of the whole file. For example, a tool can fetch a 5 MB window of a 2 GB raster rather than all 2 GB. This only works with formats built for it, not with just any file placed in a bucket.
4. Services are small, replaceable and speak open standards. A tile service, a feature service and a catalogue can each be swapped without rebuilding the rest. Each kind of user gets the access that suits it, all from one authoritative source.

Before: every user goes through one application to reach one data store. After: apps, notebooks, dashboards and partners read files directly from a shared bucket, with no server in between.

Trade-offs to weigh

Cloud-native is not free of cost or risk. Go in with these in mind:

• Data egress charges. Many providers charge when data leaves their network. Reading small pieces in place helps, but heavy downloads can still cost money.
• Lock-in. Open formats and standards reduce it, but your storage provider and its features still matter. Check how easily you could move.
• Security and access control. A file with a URL needs deliberate rules about who can read it. Decide what is public, what is private, and how access is granted.
• Skills. Your team will need some comfort with buckets, permissions and new formats. Plan for a short learning curve.

What this does not mean

• Desktop GIS is not going away. Digitizing, editing, quality checks and cartography still happen in tools like QGIS, because that is where good data is made. Someone has to draw those village boundaries first. What changes is where the finished data goes afterwards: published once to a shared place instead of emailed around.
• Not every project needs this. For a small, single-user job, a folder of files is perfectly fine.
• There is no big-bang migration. Most teams start with one dataset and leave everything else running as before.

Where to start: one dataset

Pick the dataset that causes the most pain, usually the largest archive or the one people copy most. Then:

1. Convert it to a cloud-friendly format (for example, a Cloud Optimized GeoTIFF for imagery, or GeoParquet for vector data).
2. Upload it to a bucket and set who can read it.
3. Share its URL, or list it in a catalogue, so people open it in place.
4. Retire the scattered copies once everyone has switched.

The details of each step come in the next posts.

Start here if…

So instead of asking "are we modern enough?", ask a better question: where does our data keep getting copied, moved or waited on? That is where to look first.

The takeaway

Cloud-native GIS is not a product to buy, and it is not a verdict on the system you have today. It is a response to a simple change: there is more data, more users and more kinds of use than the original design ever assumed.

Stop moving data to work. Let the work reach the data, reading only what it needs. Start with one dataset, and the rest can follow at your own pace.

What to read next

The next post covers the file formats that make "read only what you need" possible:

After that, we follow the data journey: where it is stored, how it is found, processed and served, and how it finally reaches a map on your screen.

The six jobs behind every map, and the technologies this series will cover. The tool names are explained in the upcoming posts.

Join the series

• Want a tool-by-tool view of the open-source side? Read The Modern Open-Source Geo Stack, Explained Visually
• Curious why we care about cloud-native-first design? Read Making (yet another) Spatial Data Infrastructure Solution