When you use CARTO to visualize a data set, or to run an analysis, it looks fairly lovely and seamless: just one piece of software doing your bidding. But, in fact, CARTO is built from a multitude of open source pieces.
Some of the pieces we wrote ourselves:
Other pieces were fully formed when we started using them, and we have been contributors:
- the PostGIS database
- the Mapnik rendering engine
Other pieces are infrastructural, so widely used that developers treat them like the oxygen we breath:
- the Redis data store
- the Linux operating system
- the Ruby language
- the Node.js web engine
When your company is built on foundations that other people wrote and maintain, it’s important to recognize that fact, and to provide support when possible to initiatives that make a difference in your domain.
Our domain at CARTO is the world of geospatial; you can’t have “location intelligence” without “location”. So when we heard about the “GDAL barn raising,” we knew it was important to play a part.
The “barn raising” was a crowd-funding effort to address some core improvements to the GDAL/Proj ecosystem to handle modern coordinate transformations. GDAL and Proj are both used by PostGIS and Mapnik, which are core components of CARTO – it makes sense to support foundational improvements to those projects. For us, with these improvements in place, we’ll address a couple use cases that will be important in the future:
- Maintaining coordinate accuracy down below the 2 meter level during coordinate transformations. As location analysis and data get more and more fine-grained, this will become important to us.
- Interoperating with data that expresses coordinate systems using the new “WKT2” standard for encoding SRS information. The standard is not yet widely deployed, but we will be seeing more and more of it as time goes by.
By joining with other companies in the barn raising now, we can avoid carrying out an unexpected, unplanned, and expensive development effort at some future date. The trouble with putting off foundational work is that, when the urgency changes from “nice to have” to “have to have”, the price and the risk go up at the same time. It’s rare to have an opportunity to share the cost of foundational work with others, so we were very pleased when we heard about the “GDAL barn”. Now that the GDAL work is funded, we’re wondering: what other open source geospatial foundations need work? There will always be funders for the next feature and the next format, but what pieces of core code need some modernization, or improvements?
- Could GEOS/JTS get a 100% robust overlay (intersection, union, difference) implementation, if there was enough funding and time?
- Could PostGIS get an explicit tolerance model (every function respecting a tolerance setting, for boolean tests, measurements and constructive geometry), if there was enough funding and time?
A good barn-raising project should probably address existing core functionality, the kinds of things the maintainers moan about, saying “if we’d know about this at the start, we would have done things differently”. It should also be large enough that it’s unlikely any one funder would ever individually fund it. And, it should be important enough that people want it, but possible to hack around, so that people never feel the full weight of how bad it is.
We look forward to working with the community in raising future barns!