As I mentioned earlier this year, I spend a lot of time working in Python these days. More and more, my work seems to be about performing geospatial tasks with the minimal amount of geospatial dependencies possible.
My most recent work has been generating contours from a set of sampled elevation points. I’ve done this countless times in various GIS environments. I last wrote about such a task over a decade ago but I’ve had to revisit it inside Esri and open-source environments several times. This is a meat-and-potatoes geospatial task.
Most recently, I’ve been looking at rehosting some logic into a cloud environment that would have minimal access to traditional geospatial tools, with the contour generation logic being a key piece to migrate. The core process is fairly straightforward – create a triangulated irregular network (TIN) using a Delaunay triangulation of an array of three-dimensional coordinates read from a delimited text file. Using the TIN, interpolated elevation points are created, with contour lines created from the interpolated points at a desired interval.
The process described above is all math, no geography and is accomplished in Python using the numpy, scipy, and matplotlib libraries. The input data is captured in a known planar coordinate system and the code currently outputs to GeoJSON, so shapely is introduced at the end of the process to perform necessary transformations and write out the data. Here is a display of the TIN and contours along with the original points.
I am certain that I am guilty of having over-relied on geospatial libraries that simply encapsulated math for the sake of expediency rather than fully decomposing implementations of tasks to use only the computational components necessary for a needed purpose. GIS tends to be heavy. Unnecessary GIS is an impediment to performance and scale.
The quest to do more with less is one of the things that originally led me to open-source geospatial tools. The idea that I could use well-segmented libraries in my applications and access advanced capabilities without artificial bundling for licensing purposes was attractive to me then.
That quest has evolved into one in which I seek to use just enough geospatial to get the job done and no more. (It’s worth noting that requirements vary and that “just enough” could be quite a lot in some cases.) This most recent task was a good fit with that ongoing goal.
I’ll probably tidy up the code in the near future and share it in a gist as an addendum to this post but, in truth, it doesn’t really break any new ground. The methods are fairly standard and readily searchable. But that’s the point – looking behind the button or under the hood of the DLL can reveal that the geospatial parts of a problem are less than the cumbersome whole with which we are often presented.
