Readability
Something I’ve always struggled with, going back to when I was getting my Bachelors in Computer Science, was balancing elegance and readability when writing code. There’s something deeply satisfying, to me at least, in condensing 30 lines down to 3. Or eliminating it altogether! During my first coop term, in a story for another day, I painfully learned that readability must always take precedence. After all, we write our code for fellow programmers as much as we do for the compiler.
Which brings me to Map Algebra. Available with a Spatial Analyst license, Map Algebra allows a spatial analyst to streamline their workflow by manipulating rasters using lines of python code. This allows complex, nested expressions to be created, condensing multiple tools down to a few lines.
RegionGroup(Con(ZonalStatistics("hex", "Value", "suit", "MEAN", "DATA"), 1, "", "Value <= 9"))
The sample Python code above is a nested map algebra expression that 1) creates average value hexagons from a suitability raster, 2) extracts only those with a value less than or equal to 9 and 3) groups neighbouring hexagons, assigning each cluster a unique ID. Like I said, powerful; but not particularly readable. Certainly not to someone unfamiliar with spatial analyst tools and Map Algebra. Here’s the same expression, with different input values, laid out step by step in Model Builder with labels explaining each step.
Definitely more readable. The take away here is that, much like when creating maps, we as GIS analysts must take into account our audience when working with our tools. Are we creating a one-off workflow seen only by ourselves? Or will it be used over and over again by others in our organization? As much as my natural inclination tends towards condensed and economical code, I’ve learned over the years that when it comes to code, being too concise can be every bit as wasteful as being too verbose. With documentation often being the first sacrifice in the face of a deadline, readability should be foremost in any analyst’s mind.