# RGeo: OGC Simple Features in Ruby, with GEOS doing the arithmetic > RGeo is the geospatial library for Ruby, built around an implementation of the OGC Simple Features Specification with points, lines, polygons and spatial analysis operations, backed by GEOS for Cartesian calculation and Proj4 for projections. Its design centre is the factory, which decides which backend your objects actually use, and the extension gems cover formats and databases. **rgeo/rgeo** — Geospatial data library for Ruby - Repository: https://github.com/rgeo/rgeo - Website: https://rgeo.info - Stars: 1,062 · Forks: 160 - Language: Ruby - License: NOASSERTION - Published: 2026-10-19 · Updated: 2026-10-19 · Language: en - Canonical page: https://hysenlabs.com/projects/rgeo-rgeo ## Simple Features, and a C library underneath RGeo is described as a geospatial data library for Ruby, and as a key component for writing location-aware applications in the Ruby programming language. The core is an implementation of the industry standard OGC Simple Features Specification, which provides data representations of geometric objects such as points, lines and polygons, along with a set of geometric analysis operations. The README says this makes it ideal for modeling geolocation data, and that the core gem should be used to represent spatial and geolocation data objects, to perform standard spatial analysis operations such as finding intersections, creating buffers, and computing lengths and areas, to correctly handle spherical geometry and compute geographic projections for map display and data analysis, and to read and write location data in the WKT and WKB representations used by spatial databases. That last item is the one that makes the library a real component rather than a convenience. WKT and WKB are the wire formats of spatial databases, so an object that round-trips through RGeo can go into PostGIS or be read out of a shapefile without a translation layer. The implementation detail that matters is that RGeo does not implement the geometry algorithms itself. It calls the GEOS library to handle most Cartesian geometric calculations, and the Proj4 library to handle projections and coordinate transformations. Both are maintained by the Open Source Geospatial Foundation. RGeo is the Ruby-shaped layer over two C libraries that have been doing this for decades, and the README is upfront about it. ## The factory decides which backend your objects run on The documentation list in the README contains a document called Which factory should I use?, and there is another on Factory Compatibility. Those two names say more about this library than any feature list would. A factory in RGeo is the object that constructs geometry. There are several of them, and they differ in what they can do. One built on GEOS can do the full range of spatial analysis. Others are pure Ruby, or partially implemented, and they exist so that a project without the GEOS C library installed still has geometry objects that work for the simpler operations. That design has a real cost, and the README is honest about it: GEOS 3.2 or later is highly recommended, with 3.3.3 or later preferred, and some functions will not be available without it. A pure Ruby factory will silently give you a smaller set of operations, and the failure mode is not an error at install time, it is a method that is missing or a result that is less accurate when you call the spatial analysis you needed. So the practical advice for anyone picking this up is to read the factory documentation before writing code, and to decide deliberately whether your project can depend on GEOS being present. On a hosted platform where you cannot install system packages, that is a design constraint rather than a detail, and the README even has a document about enabling GEOS and Proj4 on Heroku, which tells you the question comes up in practice. The extension list follows the same pattern of optional capability. The core library is deliberately small and the extras are separate gems, so you only take the weight of the features you use. ## Spherical geometry is where a home-grown implementation goes wrong One bullet in the summary is worth separating from the rest, because it is the reason a lot of teams end up with a spatial library rather than a few lines of arithmetic. The core gem is for correctly handling spherical geometry, and computing geographic projections for map display and data analysis. On a flat plane, a degree of longitude is a fixed distance, and distance calculations are arithmetic. On a sphere, it is not, and a rectangle drawn between two points in longitude and latitude is not the shape a user thinks it is. The machinery for that is the same pair of libraries. Proj4 handles the projections and coordinate transformations, so a point in WGS 84 can be moved into the projection a tile server expects, and GEOS handles the Cartesian calculation on the projected result. RGeo's job is to expose that as objects and operations. The WKT and WKB support ties it back to the database. A spatial database stores geometry in one of these representations and does its own spatial work with PostGIS, MySQL Spatial Extensions or SpatiaLite, and the extension gems in the RGeo organisation give you ActiveRecord adapters for each of those three, so the Ruby model and the database column can hold the same shape. The alternative approach is to do all of this in the database and treat Ruby as a transport. That is a legitimate design, and it is the one to consider first, because it moves the geometry, the index and the spatial query planning into one place. The case for RGeo is the opposite one: the geometry has to exist in the application, for validation, for formatting, and for the logic that depends on distance or containment, and a Ruby object that speaks the database's own format means the two sides cannot disagree about what a polygon is. ## Installing means a gem and a C library The installation is two parts, and the second one is where people get stuck. The gem itself is a one-liner: ```sh gem install rgeo ``` or, in a Gemfile: ```ruby gem "rgeo" ``` If you are using the proj.4 extensions, you include the separate gem: ```ruby gem "rgeo-proj4" ``` Then there is GEOS, the C and C++ library that does the actual geometric work. The README says GEOS 3.2 or later is highly recommended, with 3.3.3 or later preferred, and that some functions will not be available without it. It may be available through your operating system's package manager, and the README gives the exact commands for the two families of distribution: ```sh sudo aptitude install libgeos-dev yum install geos geos-devel ``` The first is for Debian based Linux distributions and the second for Red Hat based ones, and the README also points at the OSGeo download page for building it yourself. There is a third piece, the ffi-geos gem, version 1.2.0 or later recommended, which is needed on some platforms. JRuby requires it to link properly with Geos, and the README says Windows builds probably do as well. The runtime requirements are stated in the same section. MRI Ruby 3.1.4 or later is supported, and there is partial support for JRuby 9.0 or later, where the FFI implementation of GEOS is available but CAPI is not. The README also says to see earlier versions for support for older Ruby versions, which is the polite way of saying that older versions of RGeo covered older Rubies and this one does not. ## Extension gems for formats and databases, one of them abandoned The RGeo organisation publishes a set of gems that extend the core, and the list is a useful map of the Ruby geospatial ecosystem. rgeo-proj4 provides the Proj4 extensions, and it is the one to add if you need projections. rgeo-geojson reads and writes GeoJSON, and rgeo-shapefile reads ESRI shapefiles, which together cover the two file formats that most data arrives in. Then there are three ActiveRecord connection adapters. activerecord-postgis-adapter is based on the postgresql gem, activerecord-mysql2spatial-adapter is based on mysql2, and activerecord-spatialite-adapter is based on sqlite3. Two of them map directly onto the spatial database extensions in the previous section, and the third is the embedded option. One of those entries carries a note that deserves attention: the SpatiaLite adapter is marked not maintained. A maintained core with an unmaintained adapter next to it is a normal state for a volunteer project, and the practical effect is that a team choosing SQLite plus SpatiaLite for its embedded spatial storage is choosing a path the maintainers are no longer covering. The maintenance and support section points at the rgeo-users Google group and Stack Overflow for questions, and at the CONTRIBUTING.md for code. The documentation itself is unusually thorough for a library of this age, with in-depth documents in the doc folder, an introduction to spatial programming with RGeo, a guide to which factory to use, a document on geometry validity handling, and an exhaustive list at rubydoc.info. ## Two current maintainers, a history file, and a licence file to read The acknowledgments section names the people, and it is worth reading because it says how the project is currently staffed. Daniel Azuma created RGeo, Tee Parham is a former maintainer, and Keith Doggett and Ulysse Buonomo are the current maintainers. Development is supported by Klaxit and Goldfish Ads, which is a useful signal for a library that a lot of companies depend on without contributing back. The project also has a clear upgrade path documented for the 3.0 release, with doc/Upgrading-to-v3.md as a checklist of changes to make before upgrading, NEWS.md for a brief overview, and History.md for a comprehensive list of all changes. That trio is the mark of a library that has broken its API before and learned to write the migration down. The licence is stated as copyright Daniel Azuma and Tee Parham, with the terms in the LICENSE.txt file. GitHub's own classification for the repository could not map it to a standard identifier, so the file is the text that governs rather than a badge. For the maintenance status, the last push to the repository was on 2026-04-28, and there are no GitHub releases, so the version history lives in the gem index and in History.md. The repository itself is a conventional Ruby gem layout, with lib, ext for the native extensions, test, doc, bin, a Rakefile, a gemspec, a .rubocop.yml with a .rubocop_todo.yml beside it, and a .clang-format file for the C sources. ## Conclusion RGeo fits a Ruby application that has to model geometry properly, with points, polygons, projections and spatial predicates, and that wants the same objects in the model layer and in the database layer. It does not fit a project whose spatial work is a handful of bounding box queries, where a database extension would carry the same weight for far less setup, and it does not fit a JRuby team that needs the CAPI path, which the README says is not available. Before you install, read the factory documentation, because the object type you use determines which backend runs underneath and whether GEOS is present. ## FAQ ### What is RGeo used for in a Ruby application? RGeo implements the OGC Simple Features Specification, so you can represent points, lines and polygons, perform spatial analysis such as intersections, buffers, lengths and areas, handle spherical geometry and projections, and read and write WKT and WKB, the representations used by spatial databases. ### Do I need GEOS installed to use RGeo? GEOS 3.2 or later is highly recommended, with 3.3.3 or later preferred, and some functions will not be available without it. On some platforms, including JRuby and probably Windows, you also need the ffi-geos gem, version 1.2.0 or later. ### Which Ruby versions does RGeo support? MRI Ruby 3.1.4 or later, with partial support for JRuby 9.0 or later, where the FFI implementation of GEOS is available but CAPI is not. The README says to see earlier versions of RGeo for support for older Ruby versions. ### Which databases can RGeo work with? There are ActiveRecord connection adapters for PostGIS based on the postgresql gem, for MySQL Spatial Extensions based on mysql2, and for SpatiaLite based on sqlite3, the last of which is marked not maintained. The core also reads and writes WKT and WKB directly. ### How do I add RGeo to a Rails project? Put gem "rgeo" in your Gemfile, and add gem "rgeo-proj4" as well if you need the Proj4 extensions. For the database layer, add the matching ActiveRecord spatial adapter, such as activerecord-postgis-adapter for PostGIS. ## Sources - [Issues](https://github.com/rgeo/rgeo/issues) - [Project website](https://rgeo.info) - [README](https://github.com/rgeo/rgeo/blob/main/README.md) - [rgeo/rgeo on GitHub](https://github.com/rgeo/rgeo) --- Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/rgeo-rgeo