What happens when you take cloud native geospatial out of the satellite-and-petabyte world and drop it into a small city with no budget and the world’s slowest internet connection?

In this episode, Daniel talks with Nissim Lebovits, a city planner turned geospatial data scientist, about his nine months in Argentina building climate risk tools for under-resourced municipalities. Nissim breaks down what “cloud native” actually means in practice (hint: it’s really about ease of access), why range requests let a small city grab 100MB instead of downloading a 20GB file, and how a single spatial join — run in about three seconds — revealed that 3 million people are missing from Argentina’s own census data.

We also get into open building footprints, why QGIS (not Python) is where the real adoption is happening, the adoption gap holding cloud native geo back from small cities in the Global South, vibe-coding a QGIS plugin to finally make Argentina’s census data usable, and where cloud native geo is headed over the next five years.

This episode is brought to you by the Cloud Native Geospatial Forum. CNG Forum 2026 runs October 6-9 at Snowbird, Utah — three days of real-world cloud native geospatial (STAC, COGs, GeoParquet, Zarr, and more) plus a hands-on workshop day on the 6th. Register at 2026.cloudnativegeo.org.

In Conversation

From City Planning to Cloud Native Geospatial

Daniel: Let’s start with your background, since it’s a bit unusual for this space. Who are you, what do you do, and how did you end up working on cloud native geospatial?

Nissim: My background is in city planning. I came to geospatial through an AmeriCorps year with the City of Philadelphia, a year of national service. That was during COVID, so I had a lot of free time, started learning to program in R, and got really interested in open geospatial data through Philadelphia’s open geo portal. I carried that interest into a master’s degree in city planning at the University of Pennsylvania, focused on climate risk and spatial data science. In 2025 I got a Fulbright research grant to go to Argentina, where I spent nine months looking at how smaller, under-resourced cities, especially in the Global South, can use new open geospatial datasets to make better decisions about climate risk. I had a hunch that cloud native geo was involved in that somehow, even though I couldn’t have articulated exactly how at the time. That hunch turned out to be accurate, and it’s basically what my career has turned into since.

Nissim: Now I do contract work for Radiant Earth, continuing some of that Argentina work and trying to scale it up. Part of that is GeoParquet work with Chris Holmes, plus a project with Chris and some folks at CARTO called Porton, where we’re trying to build a low-cost cloud native spatial data infrastructure. It’s early stage, but the goal is to make cloud native more accessible to more people, and to figure out how to scale what I did in Argentina to more cities.

What “Cloud Native” Actually Means

Daniel: We’ve said “cloud native” a few times already. Are we just talking about a file format? Is Parquet cloud native infrastructure?

Nissim: There are a lot of ways to look at cloud native, and I try to stay away from strict definitions. I find it more useful to think in examples. It emerged to handle really large volumes of data, mostly satellite imagery coming out of NASA and the European Space Agency, who were moving petabytes of it into cloud buckets on Google or AWS and needed to make it easier for people to access. For me, the number one thing about cloud native infrastructure is ease of access, especially for small cities working with climate risk data, which tends to be huge. A city doesn’t need the entire world’s elevation or land cover data, just the chunk that applies to it. The old-school approach means downloading a tile that might be 15 or 20 gigabytes, and climate risk analysis usually stacks several layers, so that becomes intractable fast. Cloud native uses range requests instead: you download the 100 megabytes you actually need rather than the 20 gigabyte file. You only download what you need, and that unlocks access to global climate datasets for local use.

Daniel: That’s a really good explanation, it pulls it down to the ground. It’s also worth mentioning that range requests lessen the burden on the host of the data too. They don’t need a GeoServer instance or a massive Postgres setup running in the background, just a file sitting somewhere that people can query against.

Finding 140,000 Missing People in La Plata’s Informal Settlements

Daniel: Let’s talk about the work you did in Argentina and tie it back to cloud native. How does it connect?

Nissim: The number one connection is just being able to reach the data. A dataset I come back to constantly is open building footprints, and it’s really a cluster of related products: Google, Microsoft, OSM, Overture. It’s enormously valuable because the value is so obvious once people see it. Historically the obstacle has been access: people don’t know the data exists, and if they do, they don’t know how to get it. In La Plata, where I was based, I worked with the municipal GIS team on the city’s first ever comprehensive plan in its 120-plus-year history. We used building footprints to analyze population in informal settlements and better understand the spatial distribution of flood risk there. We showed there are probably 140,000-plus people missing from La Plata’s own assessment of its informal settlements, more than an eighth of the city’s total population. You can load those footprints straight into QGIS now thanks to the GeoParquet downloader Chris Holmes built, and the actual analysis, a spatial join, runs in seconds.

Nissim: There are really two obstacles: people don’t know the data is there, and they don’t know how to access it efficiently. When I first started pulling this data with DuckDB, I was learning GeoParquet and cloud native patterns as I went, realizing things like a bounding-box covering or presorting on a Hilbert index can be the difference between a query that runs in two minutes versus thirty minutes versus not at all. So a big part of what I worked on was building the documentation and examples to show people this is highly replicable: what you do in La Plata works the same way in Bariloche or Buenos Aires or anywhere else.

The Adoption Gap: Why Education Is the Missing Piece

Daniel: Chris Holmes and others have put a lot of work into building this into tools like GDAL and QGIS. If the technical infrastructure exists, what’s the missing piece? Where have we dropped the ball?

Nissim: I’d be careful saying we’ve dropped the ball, because that undersells how much has already been done. This is a field with very limited capacity; you spend enough time here and realize it’s a handful of people holding up the whole field. If I had to pick the next frontier for closing the adoption gap, it’s education. We’ve done a great job building scientific education materials, things like Project Pythia or the EOPF toolkit, and that’s a model for what we can do for other communities. We haven’t historically looked at small cities in the Global South because, frankly, they have no money to pay for this work, so the field has been oriented toward paying customers like ESA and NASA. But we now have a real opportunity to scale our impact by expanding who we think of as our audience. Most people in this field aren’t here to make money, we’d be working somewhere else if that were the goal, we care about social impact. The thing holding that back isn’t incomplete infrastructure or a lack of knowledge, it’s literally just broadening who we’re building for and communicating with.

Daniel: That tracks with how technology usually moves faster than the cultural change needed to actually take advantage of it. Can you say more about those two toolkits, Project Pythia and the EOPF toolkit?

Nissim: I teach a remote sensing course at Penn that I actually started out taking myself, and that’s where I learned a lot of what I know about Dask, Xarray, and pulling data through the pystac-client. Project Pythia and the EOPF toolkit, put together by ESA, DevSeed, and others, were incredible educational resources for me, and I now use them to teach my own students, including a recent lab pulling Sentinel data in Zarr format for wildfire analysis over Portugal. It’s a great example of pairing high-quality technical expertise with concrete domain applications, which is exactly the kind of resource I think we need more of.

Performance, Cost, or Just Having Data at All?

Daniel: What’s the biggest benefit of a cloud native approach? Is it performance, cost, simplicity, something else?

Nissim: It depends on your user, thinking about the user is a hill I’ll die on, but there are two parts to my answer. First, everything we say about cloud native at large scale is true at small scale too. I worked with municipal governments in the middle of Argentina on the world’s slowest internet connection, and they care about latency and low cost just as much as a company processing Earth observation data at scale, maybe more. Second, and this is the piece I almost forgot: feasibility. These are municipalities that often can’t collect their own data. Without cloud native access to global building footprints, there’s no way they’re ever getting that data at all. That’s the difference between having data to support good decisions and not having any data at all, and that matters enormously for something like climate risk.

Daniel: It’s wild that a three-second DuckDB query can mean three million people’s lives suddenly get represented in an analysis that didn’t account for them before. If you’re pitching a GIS analyst on this, do you show them how, point them to an article, walk them through it?

Nissim: There’s real institutional resistance to new tools in city government, a sense of not wanting to rock the boat, and I’ve seen it everywhere from Philadelphia to tiny towns in Argentina. When I’m pitching non-technical people, I work from concrete examples rather than jargon, because talking about cloud native and range requests just sounds too technical and puts people off. I got into cloud native partly because I’m a little lazy, it was way easier than spinning up a PostGIS database, I could just serve PMTiles. In a town called Tres Arroyos we were doing flood risk work, and almost as an aside I showed their GIS analyst how to pull the building footprints data in Python, maybe two minutes for a town of about 45,000 people. She’d been given high-resolution satellite imagery from the state government and was working on the same problem with an intern, a job that was going to take months. Those demonstration moments, showing people this isn’t scary and makes their life easier, are what I come back to.

Meeting Users Where They Are: Why QGIS Wins Over Python

Daniel: Does the choice of platform matter here? We’ve mentioned Python and QGIS.

Nissim: It matters depending on the audience. I love Python, it’s what I work in, but when I got to Argentina I found almost nobody was in Python, everybody was in QGIS. That’s just the reality on the ground, and honestly it’s a big win: I’d much rather people be in QGIS than in Esri products. It shaped how I built things. As much as I want to hand someone a Jupyter notebook, my users are in QGIS, and we’ve already invested a huge amount of time and money getting people onto that tooling, so we should build for it. A couple of months ago I vibe-coded a QGIS plugin, the first ever tool to access Argentina’s national census data directly in QGIS. It had been a 15-year problem: the data ships in an awkward format that requires downloading a database tool, exporting to Excel, and joining it into a shapefile by hand. I extracted the data instead, put it in a Parquet file on Source Cooperative, and in about an afternoon built a DuckDB wrapper in QGIS that pulls it all in in a couple of seconds.

Nissim: If I’d stopped at putting Parquet files on Source Cooperative, nobody would have used it. Now there are hundreds of downloads, more than the membership of the largest geospatial Telegram channel in Argentina, and people are sharing it with professors at their universities. If it weren’t in QGIS, it would have been a dead end. Meeting people where they are is crucial, and it’s worth celebrating that they’re in QGIS rather than ArcGIS.

Daniel: The takeaway for me is: if you build it, they won’t necessarily come. You put it on a platform that already had attention and distribution, and you also told people about it. There are probably a billion great projects on GitHub that never got that second part. Do you know much about how Esri is adopting cloud native?

Nissim: I’m not an expert on it, but I see plenty on LinkedIn about Esri building tooling for DuckDB and Parquet, which I think is great, a sign we’re on the path to real adoption. Maybe I’m biased by the company I keep, but I think we’re two to three years out from this being industry standard. Once Esri fully supports it, that’s when it becomes viable to see mass adoption.

AI, Vibe Coding, and the Risk of Fragmenting the Field

Daniel: You mentioned vibe-coding that QGIS plugin. Is AI going to change how we think about cloud native, maybe even the discoverability problem, since search has always been about finding the best information among a lot of noise?

Nissim: It can, if we use it well. The optimistic take is that with really good metadata and an agent-first mindset, we can make these tools and datasets much more discoverable. There’s a paper from about a year ago on exactly this: writing metadata in anticipation of LLM discovery, so someone doing climate risk analysis can quickly find which temperature metric to use and where the data lives. It’s exciting to watch people figure this out with MCP servers and similar tooling.

Nissim: But there are two pitfalls. First, most people in the Global South don’t have access to the tooling we do. I’m chewing through Claude Code tokens at a pretty irresponsible rate, and I think about colleagues back in Argentina copy-pasting into the free version of ChatGPT. We’re operating in different universes, and if we forget those users exist, we just create new moats of inaccessibility. Second is siloing. I put a huge amount of deliberate work into the Argentina census Parquet files, working with Jed on where to host them and how to structure the metadata. A few weeks after I published it, someone else built a similar Python package, moved the data to Hugging Face, and dropped the geospatial piece entirely, without knowing any of the context I’d built in. That kind of fragmentation, everyone in their own GIS silo not talking to each other, is exactly what AI coding risks amplifying if we’re not careful. We should be collaborating, not splintering.

Where Cloud Native Geospatial Is Headed in Five Years

Daniel: Where do you think we’ll be in five years? Will cloud native be more or less important?

Nissim: It’s going to be the water we swim in, the air we breathe. For geospatial, the more interesting question is almost when it stops being a distinct thing you’d even mention. It feels inevitable at this point: it’s simpler, easier to use, more scalable, integrates with everything, and we’ve solved most of the technical problems. The real question is dissemination. Within five years I think people still using shapefiles will get funny looks. I’m more curious what we build once storing vector in GeoParquet and raster in Cloud Optimized GeoTIFF or Zarr is just assumed, what’s next after that.

Daniel: It’ll probably go the way AI is going: eventually we stop saying ‘I used AI to do this’ the same way we stopped saying ‘I used a computer to make this map.’ It becomes just the stack. Though I wonder about one thing: unless cloud native formats become genuinely writeable, not just readable, there might still be use cases where we need a different approach. Can you write to Parquet?

Nissim: Yeah, assuming you have write access to the bucket. CARTO is working on geospatial support in Iceberg for multi-user access, admin privileges, and concurrency, that more sophisticated power-user stuff is still being worked out, but we’re pretty close.

Daniel: I mean specifically: I download a chunk of data you stored, enrich it, and send that update back into the same file.

Nissim: That would depend on the format. Iceberg is append-only, my understanding is a bit loose, but you basically append to a Parquet file and a manifest references the current version. There’s probably a way to do something similar with plain Parquet, but Iceberg is likely the answer to what you’re describing.

Daniel: Good to know, I’ll have to dig into that. Nissim, thank you so much for your time, I really enjoyed this. I wish you all the best with the work, it’s making a real difference.

Nissim: Thanks, really good to be here, Daniel.