I just released several updates to RGeo and related libraries, focusing on bug fixes and Rails 3.2 compatibility issues.
- rgeo 0.3.4 fixes a segfault under Ruby 1.8.7, and supports prepared geometries in the FFI-Geos factory.
- activerecord-postgis-adapter 0.4.1 fixes some Rails 3.2 compatibility issues.
- activerecord-mysql2spatial-adapter 0.4.2 also fixes some Rails 3.2 compatibility issues.
Just update your gems to get these fixes. Many thanks to those who reported issues and submitted patches on Github. They were very helpful.
I’m still investigating a couple of issues in the spatialite adapter. I hope to get those resolved in a few days.
One other note. I’m not using Rails 3.2 on my own projects yet. (In fact, for the most part I’m still on 3.0.x.) So there may still be regressions and compatibility issues on Rails 3.2 that I haven’t found yet. Please comment here or email me if you find anything.
TL;DR: ActiveRecord is more than just an ORM. It also provides a convenient common interface for writing direct SQL queries, for those times when you need to access your database’s advanced features. This article provides an introduction to the low-level ActiveRecord Connection API, which you can use to bypass ActiveRecord “models” and work directly with your database.
This week we’re going to look at how to choose a coordinate system for your database. In PostGIS, this includes the choice of geometry vs geography columns, as well as which projection (if any) to use, and how to interact with it from Rails.
In this article, we’ll:
- Review geographic and projected coordinate systems
- Discuss the pros and cons of using the PostGIS geographic type
- See why I typically store data in a projection
- Look at some specific projections I recommend using (or avoiding)
- Learn how to handle projected data in Rails
My original series plan for this week called for a worked example of a location-based web service, bringing together much of the material that we’ve covered so far. But as I was writing it, I realized there was one more topic we probably ought to cover first. So I’ll publish the example next week.
This is part 7 of my continuing series of articles on geospatial programming in Ruby and Rails. For a list of the other installments, please visit http://www.daniel-azuma.com/blog/archives/category/tech/georails.
Before going in depth into any particular topic, I thought it would be useful to write a getting-started tutorial, walking through setting up and working with a simple example Rails app using RGeo. In this tutorial, we will:
- Install the main software components we need for a geospatial application, including a spatial database and the needed Ruby libraries.
- Set up a new Rails application configured to use the spatial database.
- Create an ActiveRecord model with a spatial attribute.
- Experiment with location data in the model.
- Perform simple spatial queries.
This should help you get started writing basic location features in Rails, giving you a feel for what the tools are and how they fit together.
This is part 2 of my series of articles on geospatial programming in Ruby and Rails. For a list of the other installments, please visit http://www.daniel-azuma.com/blog/archives/category/tech/georails.
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.