On April 29, I gave a talk entitled “Humanity on Rails” at RailsConf 2013 in Portland, OR. The talk was a brief introduction to the philosophy of technology, targeted toward the Ruby and Rails developer community.
This is a quick bibliography and a set of useful links related to my talk. The philosophy of technology is already a fairly large topic; so this is not an exhaustive list, but more of a selection of resources that I myself happen to be familiar with. Feel free to leave any additions that you think are worthwhile in the comments!
In this post is a collection of useful material related to my RailsConf 2012 talk, entitled Getting Down To Earth: Geospatial Analysis With Rails. You can download the slides for the talk, and I’ve provided links to all the software mentioned (as well as some that wasn’t mentioned but that I think is useful or at least interesting). Finally, I’ve curated links to a bunch of articles, reference material, and other information for those interested in digging deeper into geospatial features.
This is by no means a complete list, and I’ll be adding more links over the next few days so check back often. And please leave me a note if you have any suggestions!
Update: thanks to Confreaks, the video is now up as well.
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.
When you create a spatial database using PostGIS, you may notice that PostGIS automatically installs a table called “spatial_ref_sys”. This is a standard table for spatial databases, as required by the Open Geospatial Consortium’s specification. It defines which SRIDs are allowed in your geometries, and provides information about the corresponding coordinate systems.
In this article, we’ll take a brief look at the
spatial_ref_sys table and how you can use it in your application. We’ll cover:
- What’s useful about the
- Where the
spatial_ref_sys data comes from, and how you can populate your own custom data.
spatial_ref_sys data from Ruby using RGeo’s
This is part 9 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.
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.
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.