Earth is a banana
Fake images, fake data, are a problem for the geospatial community. Instead of yelling at the tide, lets build some real geospatial benchmarks and provenance.
EDIT: While writing this piece, Google Earth switched off the Nano Bannana 2 functionality. That was quick.
In a previous post, I talked about the need for geospatial professionals to think more carefully about provenance. Provenance is an important subject; we need to know a pixel’s history before we can really determine its fitness for purpose.
But this week, things got crazy.
Google have pushed their Nano Banana 2 technology into Google Earth. In the blog post announcing the technology, we can see some amazing examples of bringing history to life and imagining new buildings. This is exceptional AI technology that, for a number of workflows, is exciting and disruptive, and great fun!
I made a map of a place called Barkerville, a historic gold rush town in Central British Columbia, in a “wild west cowboy style.” And it did create a nice-looking product. I then asked for it to be wintry, because it snows in BC…
And again, I was delivered a nice product. But the sharp-eyed in the audience may say that the main features are in the wrong places, and you’d be right, they are. When I asked for more accurate locations, it refused. Freelance cartographers take note: don’t refuse to make things more accurate, it’s a bad look!
This raises two important ideas.
Geography has to matter to the AI community
Provenance has to matter to the geospatial community
90% accurate is a losing grade.
Apple Maps was roasted when it first launched. If you remember, there were several errors in the mapping fabric. Within a few short years, though, Apple was as good as Google, and now they are both excellent products. At the time, I remember thinking that, in navigation, 90% good is 100% bad. If the user doesn’t reach their destination, it doesn’t matter if 90% of the route was good. In terms of geography, we are beset with very high user expectations set against a backdrop of typically dubious data. Quite simply, it’s hard and annoyingly non-linear.
In the context of AI, however, I regularly find that geographic knowledge is annoyingly implicit. What I mean is that location is learned through text and images. I do not think most AI’s have a sense of space. This leaves us in the position that AI doesn’t get upset, or even know when it places locations in the wrong place. If that is the case, then we have a bit of a problem.
I built a geospatial agent last week. I wanted to use it to find the latest satellite images of places within a chat interface. I was using it to find images of wildfires in rural BC. This was cool, but the gazetteer of places was poor and frequently wrong. If I didn’t know it was wrong, then I would have been mapping the wrong places.
In the same way, the map above is also wrong; the places are just wrong. But bad AI geography seems to have become expected. James Banting, one of Sparkgeo’s AI leaders, recently reminded me of the concept of AI benchmarking, and we have been bouncing ideas around since. Today, this idea seems more prescient than ever. Having a benchmark of places that an AI should know about would easily solve this problem, or at least let the public know which AI is better at geography. I realize that sometimes the location of a place is deterministic → a Point of Interest, and sometimes it’s not → the boundaries of a neighbourhood. But having a measurable concept of these ideas would be hugely valuable.
I wonder if the Overture Maps Foundation (OMF) could play a role here. While the Open Geospatial Consortium deals more with standards, OMF is a place for data. OpenStreetMap would also be an option, albeit with a more limited feature set and less governance, but an extremely open alternative. OMF has been building “living POIs” that change based on input from social data signals. This is an interesting model because it’s based on the concept of a place’s likelihood of existing and being what we think it is. Does that remind you of anything? It’s exactly how we’re thinking about the outcome of an AI query. Another benefit of OMF is its independence from, yet connectivity to, many large technology companies that use geographic data.
Ultimately, a geographic benchmark would provide some indication of a model’s understanding of our Planet. Better than that, we would also be more nuanced with questions like “how many football fields are there in Georgia?” Knowing that football means two different sports depending on which Georgia you are in. And if the AI had access to Earth observation imagery, it could actually count them and provide different results based on the dimensions and linework of the football in question. Indeed, what can we imply from the world field, rather than the pitch?
Geographic benchmarks start to untangle this deeply human mess.
You can’t handle the truth.
Not mentally, I’m sure you have the mind of a steel trap, but physically. Our EO data doesn’t have an agreed-upon standard for provenance. It literally can’t handle the truth. In cases where there are provisions for provenance, then we’re not using it. So, while some images may have a checksum from orbit, after that point, it’s a free-for-all of reprojects, stretches, tweaks, touchups, super-resolution, recoloured-SAR, cloud removal, area replacement, mosaicing, you name it. But the problem is, you can’t because we never wrote it down, or better, never wrote it into the image.
My problem with Nano Banana 2 colliding with Google Earth isn’t that Google did this. That would be like yelling at the tide; it was going to happen. My problem is that the geospatial community sleepwalked into this problem, knowing it would happen. Any number of good or bad actors could have done this; at least Google can manage some of the process and likely add the appropriate health warnings. Others will not, and open-source models can certainly provide a similar capability.
So today, I can place a nuclear plant in Iran, or add an angry crowd outside an embassy, neither of which happened. Even if the event is disputed, that image can still be distributed, and shared… and shared. If one were a bad actor, this is a tremendous opportunity to flood the zone with crazy images.
In terms of a reasoned response, there are enough sensors in the sky that the ultimate truth of a place or feature can be determined from the volume of imagery over a given area. That Iranian nuclear facility will clearly not appear in other images at the same location. However, events are harder to dispute. Events are a combination of time and place, and fewer corroborative sensors may be available at a given time. This is where provenance would be appropriate.
Provenance should be stamped into the image and additionally held alongside in STAC metadata. To some extent, our dominant design of moving large amounts of data around to do things to it holds some responsibility for the splatter gun of data storage, management, and documentation processes. If data is managed more systematically and, indeed, in a cloud-native manner, then provenance becomes much easier to track (see Prescient for Sparkgeo’s solution).
The combination of geographic benchmarks and data provenance goes a long way toward ensuring defensibility in our practice. In my opinion, it's time for the geospatial community to build the tools to help us return to being arbiters of truth, rather than the source of conspiracy.
I think our community can work this out. But who will step up first?