In which, as a result of a post by Atanas Entchev, I postulate on why I continue to do this blog thing. This is a departure from my typical subject matter and you can be forgiven for not reading any further.
With the release of ArcGIS 10.2, Esri quietly added support for SQLite as a geodatabase container. This is big news as the community has been looking for such support for some time. An open-source RDBMS originally designed for embedded systems, SQLite has a very small footprint and is arguably the most widely deployed RDBMS in the world. (Thanks, in part, to the fact that it is embedded into Adobe Reader and other commonly used software.) Over the years numerous strategies for storing spatial data in SQLite have been developed, ranging from simply storing WKT or WKB geometries in a column up to full extensions like SpatiaLite, which adds OGC-compliant data types and methods. SQLite is also the engine that drives the popular MBTiles implementation used by TileMill and MapBox.
There has been a bit of buzz the past couple of weeks over the ability of GitHub to render GeoJSON and TopoJSON files automatically using and embedded Leaflet map and MapBoxtechnology. This buzz is quite justified as it presents an easy way to simply publish and visualize vector data sets. In the weeks since the initial announcement, the community has begun exploring the limits of GitHub’s capability. Probably the two biggest limiting factors are individual file size limits and API rate limits. Some, including myself, are exploring strategies for maximizing the ability to store, disseminate, and visualize data within these confines. For the near term, GitHub will probably not be the place to store terabytes of data or act as the CDN for a high-volume mapping application. That is perfectly fine and there is still a great deal of value to be found within GitHub’s current generous constraints.
While the majority of the geospatial world was at the Esri International User Conference in San Diego last week, I was at a different conference in Orlando, Florida. This was my third time attending the Children with Diabetes (CWD) Friends for Life (FFL) conference and I’ll be there as often as I can for the foreseeable future. It’s beneficial in many obvious ways; enabling us to keep up with the latest developments in diabetes research and technologies as well as keeping us refreshed in terms of diabetes management best practices.
The unexpected thing for me over the years has been how the lessons I’ve learned at FFL have begun to translate into other aspects of life outside of diabetes. (I do not have diabetes myself but I am a parent of a person who does.) This year, perhaps because the ongoing Esri UC was somewhere in the back of my mind, it provided a different lens through which to view my approach to my professional activities.
So GitHub announced that you can now automatically view any GeoJSON files that may be in a repository inside an interactive map driven by MapBox technology. This simple enhancement to GitHub is probably one of the most significant developments in the geospatial industry in years. I’ll explain a little later in this post. It’s also important to view this new capability as a great, but limited, first step. I’ll discuss that a little later as well.
While it’s cool to click on a link and just see a map, it doesn’t take long to wonder about how you can use this capability beyond viewing data in GitHub. What follows are three ways to capitalize on GeoJSON in GitHub. Not all are directly related to the new mapping capability, and two have been possible for a long time. That said, the GitHub announcement may draw interest from users who have not previously considered either GitHub or GeoJSON, so I hope these approaches will be useful.
Continue reading “GeoJSON on GitHub: Now What?”