Google Earth: Beirut, Haret Hreik quarter, before / after

Of all possible sources, News.com has posted a short blog entry called "Why isn't Beirut burning in Google Earth?". The answer of course is that Google Earth doesn’t update their image sources all that often. But as many responses have pointed out there are ways around this, using user-added image overlays and extra data from external sources.

Some examples: Ogle Earth offers a KMZ file overlaying an image from Digital Globe showing the Haret Hreik quarter of Beirut after the recent bombardments (link). This area is considered to be a Hezbollah stronghold, and has suffered heavy damage. One Google Earth community post provides a schematic overlay showing bomb targets (link), while another post provides geolocated information about bomb and missile strikes (link).

I’m not posting this to take a political position on the conflict, though I have concerns about humanitarian law and the Israeli use of disproportionate force). But it should remind readers that GIS applications are inherently political. Maps have always been weapons, although the innocuous geotagging of Flickr pictures makes it easy to forget this fact. When Art+Com developed Terravision in the mid-90s (predating Google Earth by 10 years), they were soon approached by the US Military with a view to use it for military applications. Art+Com turned them down.

So while this should serve as a sobering reminder of the traditional uses of geolocation, it simultaneously highlights a new possibility for user-generated geoinformation resources balancing out the mass media. One of the applications proposed by Art+Com in 1995 was the distributed sharing of environmental research data. A utopian view would be that Google Earth, MSN Virtual Earth etc. could make the power of geopolitical applications available to grassroots movements.

Satellite image of Sao Paulo from Google Earth

I recently returned from a week in Sao Paulo for the opening of the excellent Art.ficial Emotion 3.0 exhibition at Itau Cultural. Following my recent Flickr addiction I documented the show in a Flickr set, a lot of which is geotagged. It’s worth noting that Aemkei has released a new version of his excellent Flickr geotagging bookmarklet, which caches the previous location found and automatically adds a “see where this picture was taken” link to the photo description.

Another fun tool I’ve been experimenting with is Roblog’s Flickrfly. It is a script which will allow you to “fly” to the location of a geotagged image in Google Earth. Just add a simple link to your image description and Flickrfly takes care of the KML file, including overlaying a thumbnail of your photo on the Google Earth map. The image above was taken in Google Earth, and if you look at the original size on Flickr you will see 4 small thumbnails indicating different images and their actual location.

Do have a look at what Sao Paulo looks like from space, it’s a bit like watching cancer grow. And I liked it there.

Bonus geo links (see Toxi / TomC)

• Geotracing
• Google Earth KML specs (now in version 2.1)
• Battleship: Google Earth

Just came back from the Art.ficial Emotion 3.0 exhibition in Sao Paulo, which featured some excellent interactive works. See my Art.ficial Emotion Flickr set for documentation.

I’ve pretty much been on blogging holiday lately, but here’s a few Processing links at least…

• Christian Riekoff has released an early version of a new PGraphics renderer called proGL, aimed at optimizing OpenGL performance by calling OpenGL directly instead of performing world transformations in Processing. See his post on the Processing forums for details.

  This should improve OpenGL performance for many applications. This project started during the EXTEND workshop in Barcelona, so I am personally especially happy to see this realized.

• Michael Chang has released a new version of his SVG importer library, called “Candy”. It’s a beta, again see the post on Processing forums.
• Ben has posted a new Processing status report, detailing what’s going on with the project. Some API changes are in the works on the way towards 1.0 status, and they are focusing on libraries as a way of extending Processing. Ben mentions changes to the library structure, but no details. Should be interesting.

Websites as graphs: Code & Form HTML structure

A while back I blogged Websites as Graphs on Generator.x. It’s a nice visualization of the structure of HTML documents. Since a well-formed HTML document has a logical hierarchy of tag containers, it is possible to visualize it as a strict graph. The results are both informative and beautiful, revealing the strategies used for structuring the document’s content. It will also reveal whether the document holds up to that most essential of post-CSS web principles: A tableless design.

The original post by Sala shows some examples, and also provides a live applet that you can try out on your own site. Be sure to have a look at all the pictures tagged 'websitesasgraphs' on Flickr.

Sala has generously provided the Processing source code for the application. It requires the HTMLParser, Traer.Animation and Traer Physics libraries to run. HTMLParser is a standard Java library and hence does not come with instructions for Processing. According to the project home page, all you should need to do is download the latest version of the library, and then copy the file htmlparser.jar from the /lib folder to your sketch’s “code” folder. I haven’t tested this, so if you find otherwise let me know.