• iPhoto export plugin iPhotoToGoogleEarth is up to version 1.02, adding altitude data (in case you’re flying) and, yes, timestamps. If the time was in the EXIF data, it’ll now be in Google Earth — couldn’t be easier.
• The Earth is Square lists what’s new in the soon-to-be-released NASA World Wind 1.4 beta. Impressively quickly, it sounds like KML Importer will gain timestamp support, while WMS support gets an upgrade. NWW also seems to be working on making itself prettier, with animated 3D clouds, 3D lighting and atmospheric scattering effects promised.
• Roo Reynolds over at Eightbar makes progress on a SketchUp => Second Life converter.
• GeoServer is up to version 1.3.4, which includes “more robust” KML output.
• iLoveMountains.org is a US website dedicated to ending a form of mining that strips the tops off mountains. They’ve now made a virtual “National Memorial for the Mountains” pinpointing all missing mountains that exists only in Google Maps and Earth:-) (Via this Flickr post)

You might remember how earlier this year Norway’s Bergen decided to make itself more visible to potential tourists by donating aerial imagery of the city to Google Earth. Now Danish blog Squareboy.dk points us in the direction of the city of Aalborg, which has taken a different tack in a quest for visibility: They’ve published a 3D model of the center of town as a 5.7MB KMZ file. (It’s also available as a DWG file for AutoCAD and other pro apps.)

Aalborg also carries a nice set of aerial images. Here is a comparison view of the 3D model and the bird-eye imagery:

While the 3D model isn’t textured, it carries more detail than Google Earth’s default building layer. In fact, Aalborg seems to make most of their GIS resources freely available online. Obviously there is somebody enlightened working in Aalborg’s GIS department. Imagine if all cities did this.

Not long ago, a friend asked me what percentage of the world’s population I thought lived North of Stockholm. Off the top of my head, I guessed 1%. Obviously, he already knew the answer, having figured it out earlier (he’s like that) and it turns out only around 20 million people live at a higher latitude north than Stockholm, or one third of one percent of the world’s population.

Just yesterday, I sat wondering about what spot would have the most ocean surrounding it on its hemisphere, and also what spot would have the most land surrounding it. I fired up Google Earth and had a guess. Most ocean: Somewhere in the South Pacific, not surprisingly. Most land: Could it really be Stockholm?

But surely GIS pros have datasets on which they could run analysis that would confirm such spots? Also, has anyone run analysis on the Gridded Population of the World database to determine what would be the best spot for a cataclysmic meteor to hit Earth, in terms of minimizing mass death? (I’m assuming perhaps naively that not being in the same hemisphere as ground zero makes you safe.) My guess is that the “best” site would be somewhere on Antarctica. As luck would have it, that is exactly where the world’s largest known meteorite crater lies buried.

Indeed, this is important enough to mod up from the comments:

On September 26, the component object model (COM) application programming interface (API) for Google Earth 4 Beta for PC was given public documentation by its developers. Here it is. And here is the announcement on Google Earth Community. Much is made by the developers of the fact that this is a Beta release of the API, that there is no official support, that it could change at any moment, etc… Still, great news.

First impression: The vocabulary is much more extensive than the equivalent in AppleScript: Here’s hoping these can be made sufficiently functionally equivalent so that future helper applications can be ported with relative ease between operating systems. And I’m curious — is there an API waiting in the wings for the Linux version of Google Earth?

An enterprising japanese programmer, Nitoyon, has added an extra navigation mode to the three Google Earth comes with. To do this, he accessed Google Earth’s 4.0 beta’s undocumented COM API (for PC) with a JavaScript app, allowing you to steer Google Earth’s view and location in a way that exactly replicates many of those beloved car driving games.

Ever the web 2.0 netizen, Nitoyon’s put a video on YouTube showing you how it works:

Download the application from his home page. It worked well for me, though it helped to first go to a place I wanted to drive and then fire up Nitoyon’s JavaScript. The fact that the height above the car is maintained in mountainous locations is a very nice touch.

I don’t know much about patent law, but I do know Dutch, so I thought I’d make myself useful by airing some questions about a Dutch article in Emerce from last weekend that profiles Erwin Nikkels of Globe Assistant, the company behind Earthbooker.net.

The article explains that the company has developed EarthConnector, described as a technology that allows companies and organizations to plot their databases on Google Earth, Maps and comparable apps. Earthbooker.net is based on it. Erwin is then quoted as saying, “In the Netherlands we have a patent on our technology and there are now patent applications in 120 countries.”

I’ve blogged Globe Assistant’s patent before, albeit in a snippy fashion, but this time I asked Erwin for a link to it. (Dutch patent sites are impervious to my searching skills). He was happy to forward it to me.

Here is the link. (Click on “Save full document” to get the entire PDF.)

The title of the registered patent is “Altitude Ranking: het waarderen van data afhankelijk van de ‘hoogte’.” In English it is described thus: “Internet search result display method, uses altitude ranking system to link relevance of objects to viewpoint above virtual globe or world map.” It was applied for on August 12, 2005 and granted on December 1, 2005.

Here’s a translation of the excerpt, in full:

Altitude ranking is a method for the efficient sorting, storing, ordering and presentation of digital data objects, where the relevance of the objects is coupled to the height of the user above a virtual globe (like Google Earth) or digital map.

Increasingly, data on the internet is presented with the help of this kind of graphical environment. With the altitude ranking mechanism it becomes possible to present the most relevant information in a manageable way to the user.

Depending on the ‘height’ of the user, a selection is made of the available data. When the user’s height is altered, automatically a new selection is made and presented.

The patent goes on to explain in detail how this works: Objects are ranked by relevance to the user and then sorted in layers, with the most relevant objects becoming visible in the highest layers above the globe or map. As you zoom in, more and more (less relevant) objects become visible.

The patent differentiates between two ranking methods: External ranking and self ranking. With external ranking, an object’s relevance is determined by an external calculation. An example of external ranking is an RSS feed of news items being ranked according to their recency. With self ranking, the rank of an object depends on its popularity in a community, as determined by clicks or zooming behavior. More popular objects first become visible at a greater height.

One mentioned use of this method is for business promotions: Hotel chains engaged in a promotion could have their hotels begin to be shown at a higher altitude, for example.

Another example is for search results returned by the Yellow Pages: The most relevant results would start to be shown at the highest layers. For public agencies, risk maps could show the most dangerous objects from the highest layers.

The patent also covers the ability to use relevance to determine an object’s shape or color: For example, if you were previously on a web page about a specific real estate property, then this property could be highlighted when you subsequently view it on a globe or map surrounded by other objects.

I’m pretty sure I’ve excerpted the patent document fairly, but I would certainly welcome corrections or amendments.

What I’m curious about, as a patent neophyte, is whether this is the kind of patent GIS and search programmers recognize as being substantive — would you consider this method to be patentable? Would you licence it? Is this method something you could see yourself develop as a matter of course in response to a client’s needs, or does it represent a non-obvious yet elegant solution to the problem of visualizing geospatial data inside the confined space of a monitor screen?

3D Nature, whose Visual Nature Studio lets you build 3D landscape visualizations, has just updated their exporter, Scene Express, so that it takes advantage of some of Google Earth 4’s new KML features. 3D Nature’s Chris Hanson wrote in to explain what’s new:

I think we’re the first offering textured, georeferenced terrain translation to KML, using the COLLADA 3D object format. We also can do textured georeferenced buildings, and now proper fixed-size foliage.

KML support in the previous version of Scene Express was criticized on this blog because KML icons were used to represent foliage, which broke Google Earth’s user interface. How does the new version fare?

I haven’t seen a sample yet of the new improved foliage, so I will reserve judgement on that, but I have just seen the textured terrain feature, and this is indeed new and impressive.

Before, if you exported LIDAR-based terrain to KML, you just got a (detailed) blob built from a collection of geometries using KML:

Now, Scene Express lets you drape texture data over the same LIDAR landscape and then export it as a COLLADA .dae file wrapped inside KML. If you use Google Earth’s underlying imagery as your texture, you get a very nifty result indeed:

Visible:

Invisible:

In effect, you can now improve on Google Earth’s default height mesh, simply by adding your own local data if you feel you need more detail. Does anybody have LIDAR for the Matterhorn? That mountain still needs some help:-)