The Wave

Just spent a remarkable amount of time (more than an hour) watching the video describing Google’s new idea-soon-to-be-released,  Google Wave.  It’s fascinating to watch – well worth the investment of your time.  If Google really pays off on this concept (and there’s no real reason to believe that they won’t), it’s going to seriously change the online landscape.   Par for the course for Google, I suppose.

Anyway, watch the video, if you have the time:

The Shape of Files to Come

Part 1:  How Our Thinking Shapes The File (or Why Still Use A Relational Database?)

Every now and again, the GIS conversation turns to the subject of shapefiles  (more quickly after a few drinks – see here, here, here, here, here, here and especially here),  and it always arrives at the same question:  What next?

Make no mistake – the shapefile is a goner.  The reasons for this are many and various.  And valid.  The shapefile no longer suits the needs of the GIS community (this was not always the case.  The shapefile – much like the horse and buggy and the Apple IIe – once got the job done with some aplomb).

The burning question, though, is:  Where to from here?  Put another way, the shapefile cannot simply be erased – it needs to be replaced.  And the question is:  Replaced with what?

Let me begin by making it perfectly clear – beyond doubt – that I cannot answer this question.  As a matter of fact, I am so far away from the answer to this question that I won’t even make up an answer (although it is tempting).   I have heard compelling arguments for a number of ideas, and I have to admit that I’m leaning toward databases as the next logical evolutionary step.  I would explain my feelings on this matter to you, but I have not yet reached the point where I have carved my opinion in stone, so I feel compelled to remain uncommitted.  I will, however, elucidate the two strongest of my personal pet peeves in regard to shapefiles (the first today.  The next in Part 2).  I think you’ll see why I’m leaning toward databases.

Let’s face it, folks – as a species, we’re pretty two-dimensional thinkers.  When we attempt to wrap our brains around an idea, our initial step is usually an attempt to flatten it as much as we can.  Those of us in the mapping world are especially prone to this, both because maps are traditionally two-dimensional, but also because we like our ideas in a form we can fold up and stick in our pocket.   So when it came time to attach a database to a map, it stood to reason that the database so attached would be relational.  Relational databases are about as 2D as you can get – hell, they’re practically nothing more than spreadsheets.  Nothing but columns and rows.  X and Y.  Picture it something like this:

Nice and simple.  Label the rows and the columns, and we can then populate a grid like this with pertinent data.  If we wanted to represent a surface, we could populate the grid with z-values, or elevation, resulting in something like this:

Again – nice and simple.  And – apparently – three-dimensional.  But only apparently.  A surface like this (alternately, a terrain) is, actually, what we often refer as 2.5D.  A cute way of saying faux-3D.

Now – don’t get me wrong.  There’s a time and a place for faux-3D.  A drawing of a cube is a good example.  A 2-dimensional representation of a 3-dimensional object.  Easy to produce, easy to understand, and you can fold it up and stick it in your pocket.  As an added bonus, we map dorks really get the concept of representing 3D in 2D – it’s what mapping’s all about.  Or – more accurately – it’s what mapping was all about up until fairly recently.

But now we have computers that are perfectly capable of representing three dimensions in three dimensions (or more).  So why are we still using a two-dimensional file system?  Instead of simply draping a terrain on a surface, why not represent the entirety of the area in question, in three dimensions:

Or, to put it with prettier pictures, why use our data to produce something like this:

When we could instead produce something like this:

The same 2D space, now fully represented in a 3^rd dimension.  I hope I don’t have to enumerate the reasons why this would be a good thing to do.

Now, I know that relational databases can simulate a three-dimensional dataset (joins and relates, anyone?).  But on their best day they can only simulate three dimensions, they can’t accurately represent them.  And since we live in a world in which multi-dimensional databases are not only possible but accessible, I ask again:  Why Still Use A Relational Database?

Next:  Part 2:  How The File Shapes Our Thinking.

Pixel City

While wading through the interwebs on my Google machine earlier this evening, I stumbled across a multi-part (15, I think) blog post by a guy named Shamus Young.  The posts describe his creation of a cityscape built of code.  The end result is a Windows screensaver that builds a city from scratch every time it runs, then tours you around the city.

I have to admit that I was riveted to the posts (here’s the first entry).  The process is fascinating, and Shamus’ writing is rather entertaining.  I give him 50 bonus points for using the phrase “cutting-edge Luddite”.  Well worth the read.

And, of course, I have already installed the screensaver in my Vista machine.  It’s the first time in years that I’ve actually used a screensaver.

Here’s a YouTube video Shamus put together: