Crowd-funding core open source development

Summary

CARTO joined the #gdalbarn crowd-funding effort to improve GDAL coordinate system handling.

This post may describe functionality for an old version of CARTO. Find out about the latest and cloud-native version here.
Crowd-funding core open source development

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!