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.
This week we’ll put together what we’ve covered so far in this series by implementing a simple but usable service: looking up the Zip Code Tabulation Area (ZCTA) for a location. This is an actual task I had to do for my job at Pirq, and while I will pare it down for this article, we’ll go through some of the actual trade-offs and optimization decisions I made in our implementation.
In this article, we will cover:
- The goals for the service, and what is a ZCTA anyway
- Obtaining ZCTA data from the U.S. Census
- Developing our own ZCTA database
- Querying the database
- Improving performance using polygon segmentation
This is part 8 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.
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.
Scaling, scaling, scaling. Can Rails really scale? It’s been a source of FUD and the butt of running jokes. But scaling is a serious matter when it comes to large data sets, and it’s something we need to pay attention to in the geospatial realm where big data is commonplace.
In this week’s article, I’ll go over the basic issues every geospatial programmer should know about scaling, and provide tips for writing your geospatial Rails application so it doesn’t fall over when you go national. We will cover:
- The bottom line regarding scaling
- Building spatial indexes for your database
- Writing queries to take advantage of indexes
- Simplification and segmentation of large objects
This is part 6 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.
I’ve released RGeo 0.3.3. This is a bug fix release with several important fixes, and upgrading is highly recommended.
- The WKRep WKT parser recognizes MultiPoint WKTs in which individual points are not contained in parens. This syntax is technically incorrect, but we are now supporting it because there was some ambiguity due to an error in early versions of the spec, and apparently there are now examples in the wild. (Reported by J Smith.)
- The Geos CAPI implementation sometimes returned the wrong result from
- Fixed a hang when validating certain projected linestrings. (Patch contributed by Toby Rahilly.)
- Several rdoc updates (including a contribution by Andy Allan).
- Separated declarations and code in the C extensions to avert warnings on some compilers.
RGeo is a spatial data library for Ruby, providing full implementations of the standard spatial data types. It is the basis for a suite of useful gems for writing geospatial applications in Ruby and Rails. For more information, see the documentation at http://virtuoso.rubyforge.org/rgeo/README_rdoc.html.
The location revolution is a revolution of data. Ubiquitous data, from mobile GPS and user input as well as from census and other datasets, is what makes location-aware applications possible. And so the first task of many geospatial projects is to determine how to find and utilize (and, in some cases, produce) external data.
In this article, we will survey some of the important spatial data formats, including serialization, file formats, and api-oriented formats. Specifically, we will look at:
- Basic serialization using WKT and WKB
- Variants on WKT and WKB
- Reading public datasets from shapefiles
- Web service oriented formats such as GeoJSON
- XML-based formats commonly used in web services
We will also go over a few quick examples using Ruby and RGeo. This will be a fairly high-level overview and we won’t go into a lot of detail. We’ll take deeper looks at some of these formats in future articles.
This is part 5 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.
RGeo is a library and framework for handling spatial data in a Ruby application. It’s currently designed more for completeness than ease of use, so there’s a bit of an initial learning curve. This article is an attempt to smooth that learning curve a bit. It contains a tutorial introduction to RGeo, covering the basics that every RGeo user needs to know, and a bit of discussion of where the library came from. Included is:
- An introduction to the industry standard spatial data types
- Working with spatial data objects in RGeo
- Factories: why RGeo uses them and what they’re for
- A comparison with GeoRuby
- A guide to the RDocs
RGeo includes a number of advanced features which I’ll cover in future articles. But for now, I think these are the important topics that will get you started.
This is part 3 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.
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.