Such a big topic, so little time…

Science journalist Declan Butler has a post up announcing a special issue of Nature, with free access to articles focusing on the future of computing. It’s a long and absorbing read, and a quick blog post like this one won’t do it justice. Declan gets to write about the “sensor web” in 2020 computing: Everything, everywhere:

These new computers would take the form of networks of sensors with data-processing and transmission facilities built in. Millions or billions of tiny computers — called ‘motes’, ‘nodes’ or ‘pods’ — would be embedded into the fabric of the real world. They would act in concert, sharing the data that each of them gathers so as to process them into meaningful digital representations of the world.

How best to represent this data meaningfully? Why, on a virtual Earth, of course. Here’s an actual working example (via Declan’s post), a project in the James Reserve, California. The KMZ file available on the site gives you access to live data from a hundred odd sensors scattered around a valley. This is a groundbreaking use of Google Earth (first I’ve seen, in any case), but it is also a taste of things to come. Not much I can add other than point to it, so go play and imagine this applied to urban environments, in industrial spaces, for search and rescue, for livestock management, for border control…

How might all this information be distributed? Check out this page outlining the idea of the “Information Commons” (Declan, again). The Information Commons posits a peer-to-peer approach for these myriad datapoints — interconnected stores of data that do not attempt to impose hierarchies on one another. While the idea would face challenges similar to those of P2P networks today (scaling costs, data irregularities, sourcing questions), such problems are being solved on today’s P2P networks.

Still, this would just mean that an inordinate amount of georeferenced data becomes available to the user. How to forge some kind of order from of this complexity? Well, that sounds like just the job for Google, Microsoft, Yahoo!…

• One more Australian billboard turned into hovering car written about by mainstream media.
• A skeptical view of the SketchUp purchase. I disagree, but at least architect Matt Stachoni doesn’t pull his punches.

Astute reader Ron Schott writes in about Yahoo!’s foray into gotagging: Zonetag Photos, “a research prototype release from Yahoo! Research Berkeley”.

Is this what Dan Catt has been up to recently? Ron does some digging and finds Dan in the Zonetag Flickr group, so we’ll assume yes. (Before Dan went to work at Yahoo!, he was responsible for Geobloggers, which mapped geotagged Flickr photos onto Google Earth.)

What is Zonetag? It’s not a mapping solution per se, but a mobile publishing tool for cell phone cameras that incorporates an automatic geotagger. In English: It will let you upload your cell phone photos to your Flickr account via your phone and automatically tag the photos with the ID of the cell phone tower you’re using.

As soon as somebody in the Flickr photo community associates that cell phone tower ID tag with a ZIP code or city location tag, all photos with that tower ID will then be linked to the area in which you took them.

The service is experimental and works in the US only, with Nokia Series 60 phones. Here is an example of a “celltagged” Flickr Photo, with a ZIP code tag attached. Here are all 1968 zonetagged photos to date.

Implications for mapping & Google Earth? These photos aren’t nearly as precisely positioned as longitude/latitude tags generated by GPS-based devices, and will likely be scrunched up at one location for multiple cell towers if many are displayed on a map. We’ll see if that proves to be “good enough” for mainstream use, given the ease of publishing to Flickr. I suspect people will expect more precise positioning when zooming in close with Google Earth.

• ShockFire of Shock’s News Network posts a new version of his (her?) KMLImporter for NASA World Wind, which now works for periodically updating network links (he says — and I need a PC to check such things).

  While we’re on the topic, Geography 2.0 points to World Wind’s development road map: By next month, we should see some cool new features that will keep Google Earth on its toes. And by October, multiplatform support through in-browser viewing! In other words, NASA World Wind should be running on my Mac using Java before the year is out.

• Le Blogue du CFM de Guadalajara finds another GPX-to-KML converter, GoogleEarthTweaker. Drag and drop geocaching.com “pocket queries” into it, and get nice KML back.

Blender is a free open-source multi-platform 3D modeling application. Ynniv of A life of Coding has now written a python script that exports Blender’s content as KML. The learning curve for Blender might be steeper than for SketchUp’s, but the price certainly isn’t.

(The following is pure speculation, so feel free to ignore it if you’re here for news)

It’s 2008, and Google Earth has evolved. It now comes with simple SketchUp tools in the free version, and many people are building virtual structures on Google’s Earth. How might this work, practically? Specifically, what happens when several different people want to build on the same spot?

Sources will be plentiful: Already today, Google provides a default layer for its buildings. You can also import structures via static KMZ files, such as those provided by ZNO and Digitally Distributed Environments. These files usually involve a single structure or collection of related structures, because file sizes for KML structures can grow large very quickly.

But there is no reason why 3D structures can’t be returned as part of a dynamic network link that polls your location, so that only the nearest structures are rendered from a much larger library, much as how Google’s building layer manages it now. And so I imagine that a third breed of content provider will emerge, serving up dynamic 3D content across the globe from a large library of available structures.

Who might these content providers be? There’d be an open source movement, of course, with user-contributed content systematically filling in gaps in its library. There’d be free content offered by commercial businesses, funded by virtual billboards and rooftop ads. There’d be pay services, offering premium works for those who want the highest fidelity models. There’d be content offered free by architecture firms as a way to ply their wares. Real Estate companies would release their beachfront condos onto Google Earth before building them, to generate buzz and sales. Other sources: City councils, hotels, artists making fantasy constructions, roadside franchises, architecture magazines…

Who decides which layer gets precedence in case of an overlap? Google? I don’t think so; I think it will be you, but it will require a control panel interface that lets you rank your 3D content. At the bottom might be Google Earth’s default layer, followed by the free layers, followed by the one or two premium ones you might subscribe to; at the top would be your own creations. But you order them as you wish, and you add only those you like.

Google might of course sell access to its base layer, or offer other layers as default options (for a fee, akin to browsers coming with pre-made bookmarks or Windows coming with pre-made desktop icons). In the end, however, each user’s Earth will be unique.

One further consideration: With OGLE able to copy 3D structures wholesale, it won’t be long before intellectual property battles come to Google Earth. Will there be pirated versions of paid content? Is re-using Washington’s virtual head from somebody’s version of Mount Rushmore fair use? Who owns a virtual 3D model of a famous living architect’s work? The maker of the model, the architect, the architect’s firm, or whoever paid for it to have it in their Google Earth?

Just noticed that photo geocoding app RoboGeo is up to version 3.4 — it can now export your GPS tracklog as AutoCAD 2000 DXF files (in addition to doing ESRI shapefiles, blogged previously).

What’s so special about DXF files? SketchUp supports them. This leads to some interesting possibilities. Thinking aloud, you could, for example, take geocoded pictures of existing buildings, and then try to recreate those buildings inside SketchUp using your tracklogged image locations as vantage points, for comparison. (Caveat: I haven’t tried this.)