All posts by Stefan Geens

Earth unplugged

The following story has nothing to do with Google Earth other than the slant it’s been given by the Times of India: “India’s answer to Google: Image Atlas

Image Atlas will show the globe at a resolution of 2.5 meters per pixel with pictures taken from Indian satellites. It will be published next month by India’s National Remote Sensing Agency (NRSA). Adds Times of India:

Mindful of the concerns about Google Earth maps raised by President Abdul Kalam last month, NRSA’s bouquet of high-resolution images will not carry features of defence installations and, therefore, be of no use to the enemy.

Cute. And did I mention that Image Atlas is a 212-page book?

Dave Bouwman lectures

Dave Bouwman is giving two talks this coming monday at Colorado State University in Fort Collins: “Enterprise GIS: The Future is Embedded” and my favorite, “The Google Effect: How web-mapping became the killer app of 2005”. Open to anyone. A bit late notice for me:-)

How should we encode location in RSS?

Not, says Geo-Web’s Ron Lake.

I agree with him to a point. I think location references should surround the referring text, not an entire item/post, as that would turn the post into too blunt a geographic instrument. There is no reason to assume that only one location will ever be referenced by an item — a listing of the top five restaurants in Stockholm, for example, would be given little extra value if the accompanying geo-reference was for the location of Stockholm’s town hall.

I don’t particularly like the idea of forcing location information to reside elsewhere, however. While that is obviously a good idea if the geographic reference you are making is a no-fly zone, a hiking route, or a particular vineyard’s boundaries (all containing a lot of structured data), it becomes a real burden to first create a separate object off-site if all you want to do is the equivalent of sticking a pin on a map. In such instances, it has to be easy and instant.

So I propose (and if this has already been done elsewhere, forgive me) the following when it comes to simple geographic referencing:

<a href=”https://www.ogleearth.com” gref=”17.995,59.3019″>Ogle Earth HQ</a>

<a href=”http://124.12.91.02″ gref=”75 backvagen, 12647, Stockholm, Sweden”>Ogle Earth HQ</a>

<a gref=”17.045,59.201″>A nice meadow for a picnic</a>

( and of course <a href=”http://mail.google.com”>Gmail</a>)

<a /> tags, then, should be able to contain href and/or gref attributes. The reason this is a good idea is that both a link to a web/IP address and a link to a coordinate/postal address are, well, links, although to completely separate magisteria. There is never any overlap between the set of internet coordinates and the set of Earth coordinates, although there are many cases in which an object will benefit from having links to both.

How would Ron be able to incorporate complex geographic objects into such a setup? Well, the gref attribute could also take http://-style internet addresses, in which case the browser would expect a file containing KML, GML or somesuch:

<a gref=”https://www.ogleearth.com/somefile.kml”>A nice meadow for a picnic</a>

Why use gref instead of href in that case? Because with href we’d be downloading a file, any file. With gref, we are specifically referencing a geographic description of the anchored text. Here’s how I’d use href with that address:

<a href=”https://www.ogleearth.com/somefile.kml”>somefile.kml</a>

Finally (and thanks for making it this far) if geographic browsers are going to be the navigation tool of choice for online surfing, shopping and socializing within five years (as I believe they will), then these next-generation browsers need to have their own separate way of depicting where you’ve navigated. This proposed setup would work wonderfully for split-screen browsers, where a 3D Earth and HTML renderer appear side by side. Clicking on a link containing both gref and href attributes would result in both the 3D Earth and HTML browser navigating to a new spot — on Earth and on the internet. (Clicking on a link with just a gref or a href would leave the other browser’s window untouched.)

Flat Earths

Via The Map Room: Yahoo releases its competitor to Google Maps and MS Virtual Earth, but Microsoft’s Robert Scoble calls both Microsoft’s and Yahoo’s efforts doomed. Why? He says it’s because Google is disrupting everything with their advertising business model — the more people use Google Maps, the better it is for Google’s bottom line (whereas Yahoo has limits on use, showing that they see their maps as a cost burden, not a revenue opportunity.)

The Map Room highlights Scoble’s reasons for why the masher-uppers have gravitated to Google — advertising opportunities and licencing restrictions of competitors. Reading Scoble’s entire post (do so), I kept on thinking he was missing an obvious point, but perhaps it’s only obvious from over here. His second commenter nails it, though. Virtual Earth and especially the new Yahoo maps are useless anywhere outside the US. And a large minority, if it isn’t a majority, of mash-up artistes are non-American, and hence so are their mashups. Other mashups are truly global in scope, and there is only one offering that can help you there: Google’s. Google is the only one getting a boost from the network effect here. It’s had this advantage now for over 6 months. In Virtual Earth Europe still looks like a JMW Turner painting seen from across the room. Try making Maplandia out of that.

Google Maps doesn’t have maps either for areas outside the US, Canada, Great Britain and Japan, but it has glorious high-resolution satellite imagery plucked straight from Google Earth. Google Earth, of course, is even better — it already has a pan-European road atlas built in. Above all, though, it is a globe, and that globe drives home with every twirl that the dataset is global. If you were to paint Yahoo’s current offering onto a globe, it’d cover less than a quarter of it.

When Yahoo, Microsoft, ESRI et. al. produce worthy competitors to Google’s free 2D and 3D offerings in terms of content, then we can start talking hackability, revenue and licencing. But until then, for the rest of the world, this riddle isn’t really that hard.

AmberCore improves Google Earth support

Previously mentioned as an example of pro authoring tools maneuvering to make sure they can produce KML output, AmberCore continues to add KML features to their fancy Amber IQ software, now at version 2.6. From the press release:

Amber iQ 2.6 enhances its already strong support of the widely popular Google Earth application by allowing users to export both vector and raster data generated in Amber iQ to the Keyhole Markup Language (KML) format. Interactive support continues to accelerate allowing users to specify KML database fields accessible in Google Earth.

“Our work with Google compatibility continues to be driven by customers demanding to integrate Google Earth into their daily work flow,” said Martin Sendyk, President and CEO of AmberCore. “For example, we have developed the ability to automate the creation of maps in KML format. This really highlights our competitive advantage – the ability to quickly develop tools for customers on a robust and reliable platform.”