It’s late. You need to get some information on your user’s positions. You query the database and are flooded with millions and millions of datapoints, containing latitudes and longitudes. And then you start searching the web on methods of finding distance between those points. Sounds familiar?
Making operations with straight up latitude and longitude points is hard. The numbers have some very interesting properties, but at the same time, make it extremely hard to operate on mathematically. Finding nearby points, calculating distances, defining routes, zones and areas are all things that are extremely common in data-driven organizations, but rarely easy to do. And since we were not the only ones facing this problem, we started looking for alternatives.
Enter S2Geometry, a library developed by Google and open sourced in 2012, now being used by many different companies, including but not limited to Google, MongoDB, Foursquare and (more recently) 99. This library aims to solve problems of spatial indexing, searching, navigating and all sort of operations one would find useful in the 3 dimensional world that we live in.
I could go into details on how the library works (because frankly, aside from an old presentation, information on it is hard to come by) but I don’t think that is the main reason I’m writing this. Maybe if this gets enough traction, I can make a second one explaining the intricacies of it.
But no, my point here is to show what we can do with it and all the doors it has opened for us in 99. Hopefully, it will entice more people to start using it and grow an even bigger community around it.
Our initial goal with s2-geometry was building a platform to better understand our supply-demand chain. We have lots of data points on users requesting a ride. And we also have lots of data points of drivers, be them providing rides, waiting for rides or just moving around. By merging all of this information, we can have some visualizations like this:
This is a simple visualization of our estimated time of getting single driver to a single user in a predetermined location. It uses historical data, real time data and some prediction models to give a full representation of the current panorama of a determined spot. And with this data in hand, the possibilities are endless. We can manipulate both ends of the chain in this situation to allow for a better, more natural flow. And this is just the beginning.
Another use we had for the s2-geometry was creating our own coarse geocoder/reverse geocoder. One might ask: Why would you do this? and this question is better answered with another question: Why not?. Joking aside, this geocoder is useful for some really quick searches in some already mapped areas. Not having to rely on a second service, updating shapefiles and a separate structure, we can create some really useful visualizations of a city and it’s neighborhoods and frontiers.
Recently we haven’t expanded much on the use of the library, but I, for one, would love to create even more on top of it. Expanding on our way of understanding our data is the only way we can move forward with it.