namely software, geo stuff, and people. If any of that speaks to you, I'd love to hear from you, so please do get in touch. My goal today is to give you a gentle introduction to cloud-native geospatial. What is it exactly, and why does it matter? So let's start by getting on the same page by answering the what. The simple answer is what you might expect from the name.

Cloud-native geospatial is geospatial that assumes you're running on the cloud. At a broad level, cloud-native geospatial, or CNG, refers to an ecosystem of standards and software that's built from the ground up, or natively, for the cloud. This whole ecosystem starts with a question. What if geospatial tools and software

were built from the ground up for the cloud? What if you never had to download data to do GIS or to do remote sensing? So if any of you are like me and you have a background working in GIS more than a decade ago, you'll remember when downloading data was the brave new world. Like, downloading was the new shiny

that not everybody was doing. For a lot of us, we were still stuck ordering our data by mail. Like, I remember physical disks that were shipped to you. It took days, at best. Downloading was fast compared to that. Now, we're asking the question, what if you never had download data? What if it was just immediately available? So at the center of the cloud-native geospatial ecosystem

there's two standards. The first is cloud-optimized geotiff, or COG, which is emerged as the core format to store geospatial raster data in. Second standard is the Spatial-Temporal Asset Catalog, more commonly known as STAC, which complements COGs with additional JSON metadata.

STAC also works with a variety of other emerging cloud-native geo formats, like formats for vector data, as well as legacy geo data formats, like non-cloud-optimized geotiffs. I'm gonna dive a little bit more into each of these standards as we go. So first up is cloud-optimized geotiffs. A COG is a special form

of one of the most classic file formats of remote sensing, the geotiff. If you've ever worked with geospatial raster data, you're familiar with geotiffs, and you've worked with those. But a COG is a geotiff that's specially formatted to work better on the cloud, which lets web clients request exactly the piece of the image they want. Instead of having to access the entire image before you can do anything with it, you can just replace the piece of the image

that you're interested in. Okay, so to explain this better, let's actually look at a COG in action. Here's one that's stored on Google Cloud. You'll see in the screenshot that it's 3.7 gigabytes, which is pretty large. It'll take 10 minutes to download if you're lucky enough to have a fast connection, which I do not have this week, so it takes even longer.

So that means before you can even begin to view the image for the first time, you have to wait and wait and wait and wait and wait. If it were a COG, then you can view it right away. You don't have to wait on the whole 3.7 gigabyte image to download before you can do anything. So this GIF shows a site that lets you load in any COG via its URL.

And then it turns it basically instantly into web tiles so you can share it, zoom around, look at it. So here I've taken that public URL for the file that was in my Google Cloud Storage. And then I put that URL in the URL field on this map and ta-da, I can instantly see it, I can zoom around, I can scroll about,

just like a regular slippy map with map tiles. Okay, so you don't have to believe me, you can actually try this for yourself. The first link here, it points at that same 3.7 gig giant raster file that I just showed you. That doves in space URL is just a short link to the longer Google Cloud link to save you some typing, but they're the same thing.

And then the second link is the web map interface itself. So try it for yourself. You can actually verify the COG at that URL is not a tiled data set. It is indeed over 3.7 gigabytes in size. If you try to download it, it'll take you 10 minutes, maybe more. But if you put it to URL in the COG tiler map, you can just instantly surf around, zoom in and out,

just like it were as if it were tiled, which is pretty cool. The other core standard in the cloud native geospatial ecosystem is stack, or the spatial temporal asset catalog. The stack originally came about when a bunch of folks got together and were trying to solve a really annoying problem in earth imagery.

So say you're interested in searching for all the available imagery in a given area. So you have to go to lots of different sites that catalog data from lots of different providers, just to be sure that you're searching everything. There's gonna be data from PlanSat or Sentinel or Planet or Digital Globe. All of these different providers have different ways of accessing their catalogs.

And even if they've got APIs, the situation's just as bad. Every API is gonna serve it slightly differently. So on this slide, every one of these visualizations is powered by a slightly different API, just to show you the vast differences. So each catalog and each imagery API is gonna have a different way

of organizing their slice of the global data. So one API might have a min and max cloud cover or where another API might just have a cloud percent value. Or one API might count cloud percentage in an imagery from zero to one, normalized between zero and one, where another one has zero to 100.

So because every image provider, every image catalog has a slightly different way of representing their data and making it accessible and searchable, you're gonna have to search each one individually, which is kind of a pain. So what STACK does is it aims for a common language for searching imagery. Instead of having a different way of searching imagery or a different way of categorizing imagery,

STACK wants to make a common way of doing this, a common catalog approach. STACK focused on the smallest, easiest building blocks so that other people could innovate on top of it. So the core of STACK is just a JSON file. JSON file can be shared statically, you can email it to somebody, or you could also serve it dynamically through an API.

So with this core JSON file, every single record of imagery that's online can be represented as a webpage. So this lets people refer to a single location online for any geospatial asset. So any imagery, any image data that exists, you have a single canonical record that you can point to.

So in this example, there's a JavaScript tool that can take a stack of JSON files into a series of interactive viewable pages in your browser. And here we've got actually a cloud-optimized geotiff in this catalog. So the image is even browsable and you can preview it, you can slide around on the map on it, just like that web tile example previously.

And it's not downloading the image or copying it to another catalog, it's just referencing it from its canonical location, but here in this unified catalog. So really stack and cog work together the complimentary pieces of one ecosystem. This page, for example, gives you what you need. Everything that you used to use your desktop GIS for,

you can see here. So like you can go full screen, you can share what you're looking at with other people. You can start doing analysis work on the cog in your browser. You no longer have to move anything to your big clunky desktop GIS. So this is radically simplifying the idea of GIS,

making data much more accessible, much more available by doing just one small thing, which is creating a common standard of accessing and categorizing data. All right, so I've told you the what. What is Cloud Native Geospatial? It's an ecosystem built on two standards that are evolving and working together to make data more accessible.

But cool, what's so great about this? Let's talk about the why. The Cloud Native Geospatial ecosystem shares a lot of the same goals and a lot of the same vision that drives the Open Data Cube project. Cloud Native Geospatial concept, the whole purpose is really unlock geospatial data so it can have a wider global impact.

We wanna make global analysis of data easier, unlock data that's stuck in silos in different systems, in different APIs, which in turn is gonna make it easier for us to handle the explosion of data. If you're involved in the EO universe at all, you know that data has exponentially grown. The availability of data, the amount of data that's being produced on a daily basis

is just exploding compared to even a year ago, much less five or 10 years ago. So we wanna make it easier to avoid data duplication because when you've got this exponential explosion of data, you really don't wanna be duplicating it to get anything done. So we wanna enable streaming of the data, that's where the cog comes in, which lets us do a lot more real-time analysis.

It reduces the time to analysis for any of the data, which is great when you're talking about high temporal cadence EO data as we are in 2021 with a lot of our data. And finally, the real purpose, the real driving goal behind all of this is just to make geospatial data more accessible. When you make the ecosystem more accessible,

then spatial is no longer special. It is just one more piece of the data science that everyone around the globe is doing. So that said, if any of this is interesting to you, if you'd like to learn more or get involved, there's a couple of websites here, one for each of the standards, the stackspec.org and cog or cogo.org.

And each of these communities has a chat room. One is on Gitter, one is on Slack. These are short links to join. My name is Sarah, like I said, would love to hear from you. My email address is Sarah at planet.com. Please do get in touch anytime. And thank you so much for your time.