Geo-Rails Part 1: A Call to Revolution

It was about a year ago that I released the first public version of RGeo, a geospatial framework for Rails and Ruby applications, along with a bunch of add-on libraries and ActiveRecord adapters designed to work with it.

RGeo has enjoyed some success so far. But over the past year, I've fielded a number of questions from folks struggling with it, and I've come to realize that it is not very easy to learn or use. A lot of that is my fault. The core RGeo framework is fairly complex, and neither RGeo itself nor its add-on libraries are particularly well documented. Furthermore, geospatial technology is not an easy topic in general. A number of concepts and a fair amount of math has to be understood before you can really get off the ground with a location-aware application beyond the most simple display of a few pushpins on a Google map.

My hope is to start changing that.

For the past few months, I've been heads-down on the product releases for Pirq, where I'm the chief architect. But as those projects ease up a bit, I'm going to try to spend more time giving RGeo some love. And as part of that, I'm starting up a series of articles on doing geospatial programming in Ruby and Rails apps, using RGeo.

Why location?

It is pretty much beyond dispute that location has become ubiquitous. We've seen mobile GPS, Google Maps, and the explosion of available data; and all the big players and many of the hottest startups have been scrambling to lead in this space. The location revolution is already well underway. And for good reason. We humans are location-oriented beings. No matter how much we dabble in the "online" world, when it comes to our day-to-day lives, we are inextricably embedded in our particular locations.

At RailsConf this past year, Pete Jackson gave a great talk on "Geospacing Your Rails Apps." What I loved about it was Pete's passion for unleashing our creativity, for telling a rich story. And generally, I think Rails developers should be good at this. We're creatives. We're innovators. It's in our DNA, embedded in our language and in our key projects such as Rails itself.

Still, most of us probably haven't gone much further than putting a few pushpins on a Google map. And I think the reason is clear: it's just too hard. As soon as you have to query and manipulate polygons, integrate with raster data in some weird coordinate projection, design a spatial index, get OpenLayers working... blam, it's like hitting a brick wall. The learning curve can be steep, and there isn't a scaffold we can just run or a convention we all follow.

Certainly, there are a few tools out there to help us. But they're kind of scattered, fragmented. Some aren't really being maintained anymore. And we're still forced to do some things manually that we really shouldn't. In fact I'll go right out and say it: we, the Rails community, are behind the curve. Our Python-based competitor has an excellent framework addition called GeoDjango. Where's our "GeoRails"? There's a great open-source full-stack framework called OpenGeo, developed by some of the top people in the GIS field. Most of it is based on Java, Django, and C. Where's Ruby?

Certainly, there's some information out there to help us. But it's hard to find, and usually not written for us as Ruby developers. Most of the resources out there were developed for geospatial technology when it was a niche technology used by maybe a small percentage of government or research-related projects. That is no longer the case. Location is no longer niche. The revolution has already taken place.

That revolution calls for corresponding revolutions, in our toolset and in our mindset.

The Geo-Rails Article Series

I'm planning on writing a series of articles on geospatial programming in Ruby and Rails. My goal is to release a new article about once every week or two. I don't know how long this series will last. As long as I still have material to cover, which will probably be a while since some of these topics can get fairly deep and technical.

Several entries have already been planned out. I intend to cover various Ruby tools that are available. I'll cover the common data types and operations available to geospatial applications. I'll definitely include several entries on coordinate systems, probably the most important "difficult" topic in the discipline. And I'll be sure to include some coding examples writing geospatial features in Rails. I might even dive deep into some computational geometry or spatial database design topics.

However, I'll also be looking for feedback. If there's a topic you'd like to see covered or a question you'd like answered, please leave me a comment and I'll see what I can do.

Furthermore, I don't claim to be the expert in the field. I've been doing location in Rails for a few years, but there are others have done far more interesting things than I have. If you've put together some helpful material on doing geospatial Rails apps, whether it's a blog, a book, a tool, or what have you, send me a link. Let's start building a knowledge base for our community. Location is here, and as Rails developers I don't see any reason we shouldn't be the ones leading.

Together let's bring Rails down to earth!

This is part 1 of my series of articles on geospatial programming in Ruby and Rails. For a list of the other installments, please visit http://daniel-azuma.com/articles/georails.