This post originated from an RSS feed registered with Ruby Buzz by . Original Post: A Bit of GIS History - the Smallworld Technical Papers Feed Title: cfis Feed URL: http://cfis.savagexi.com/articles.rss Feed Description: Charlie's Blog Latest Ruby Buzz Posts Latest Ruby Buzz Posts by Latest Posts From cfis

For those interested in the history of GIS, in the last 1980's and early 1990's, the founders of Smallworld laid out their vision for the future of GIS in a series of technical papers. I recently noticed the papers are no longer online, so I fished them out of the Internet Archive WayBack Machine and have posted them on my site.

Fifteen years late, its interesting to reread the papers, and see how these ideas changed the industry. The best known of the articles is Ten Difficult Problems in Building a GIS, by Richard Newell. The keypoints are:

• Spatial data should be stored in seamless databases, not tiled systems
• Spatial databases should support huge amounts of data
• Spatial databases should be versioned to enable long transactions
• Topology should be supported
• Vector and raster data should be supported
• Interaction with spatial data should be done via a dynamic, object-oriented language (in the same way Ruby and ActiveRecord work in Ruby on Rails)

These ideas were so far ahead of their time that they propelled Smallworld into a hundred million dollar a year company and an IPO on Nadaq a mere six years after its founding in 1990. They also created an extraordinarily loyal user base. Once you used it, you never wanted to go back. Just like Mac users knew their machines were vastly superior to Wintel boxes, Smallworld users knew their software was light years ahead of anything ESRI, or anyone else, offered.

When I started at Smallworld in 1997 no other GIS system had these features. ESRI was struggling to overcome its ancient, ArcInfo/ArcGIS tiled-based technology that used AML and Avenue for customization. Technically, we beat them hand-downs in every technical benchmark. When we lost a deal, it was always for political reasons.

It was only recently have these ideas have entered the mainstream:

• Spatial data is stored in relational database such as Oracle or PostGIS
• Terabyte size GIS databases are common
• Smallworld, Oracle and ESRI support versioned databases
• Google maps has trained user to think something is wrong if you can't see vector data overlaid on top of raster data
• Perl, Python and Ruby show the productivity gains provided by object-oriented, dynamic languages

But even today, there are very few environments that combine all these elements together. And Smallworld still has some unique features. For example, it has the concept of worlds. In most GIS systems there is one world - the outside world where you see map data. But let's say your map shows a building. Often times it is useful to click on the building and go inside of it - you've entered the building's world which has its own coordinate system and bounds. Once inside the building, you may want to open a switch box and see how fibers connect to each other. And then you might want to know where does a particular fiber lead, what customers will be impacted if it gets turned off.

Another thing Smallworld excels at is speed - it was built when network connections were painfully slow. Thus the system does some very clever caching at the client, resulting in near instantaneous response times, even when working against a terabyte sized database. All this happens under the hood, the user doesn't have to know anything about it. And it even works across dial up lines, which of course were the norm back in the early 90's.

So if you have a few minutes, its definitely worth you time to look through these papers.