1. You put up a KML (or KMZ) file on your web site. You make sure to put some relevant text inside.
2. Wait for the Googlebots to find it.
3. Someone fires up Google Earth, zooms to an area that includes the area your KML is about (or at least gets close).
4. Said person enters a query that happens to match your relevant text.
5. Your KML file is found, and lo!, Google Earth puts it up on the person's screen.
   

So, what's not to love about that? Well, nothing, really. But consider this.

• Google is a private company.
• Google has a search API but limits the use you can put it to.
• To use the geographic area search, you have to use Google Earth.
• To use the geographic search at work, you have to use a paid for copy of Google Earth
• There is (currently) no other way to do a geographic search for KML files

That's ok though. Google paid for the development of KML. Google pays for the crawlers. Google pays for the servers that hold the data and respond to your search.

It's also open. Anyone else can crawl for KML files. Anyone else can parse them, and anyone else can offer a search service for them.

But, until they do, the only way to geographically query KML is via Google Earth.

To me that's not an SDI.

But, hey! It's a start. The buzz is there. It's easy to post KML files. How hard would it be to post the entire metadata holdings of a large geospatial data provider like NASA or NOAA in KML? I bet a service like GCMD could post theirs in a week. At Where 2.0, we could be watching demos of Google Earth finding, and displaying, realtime remote sensing data.

That's a powerful combination. Easy to publish. Open format. Instantly demo-ready. It won't be long before someone catches on and realizes you could build, say, the Geospatial One-Stop by  crawling the web for KML files, doing some decent filtering of the results, and offering a decent, unrestricted search API.

Maybe, just maybe, then we're on our way to an SDI.

[Update: a good definition of "SDI" (Spatial Data Infrastructure)]