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’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.