Personal Geospatial Workflows

I’ve had a couple of people ask me recently about the geospatial tools I use. Year-over-year, that answer changes but here’s how I answer that right now:

As a Federal contractor, I spend a lot of time working with the Esri stack during my work day. A few years ago, I added a few open-source geospatial tools into my tool set and, since then, have also done a respectable amount to consulting work them as well. The balance between the two varies over time, depending on the requirements of individual customers and projects. Lately, commercial customers have seemed much more interested in open-source tools while my government customers are sticking with Esri. Since those observations are based on the the extremely heavy filter of my own recent experience, I’d be hesitant to draw any larger conclusions from them.

I’ve always believed that proficiency with a wide range of tools makes me a better consultant and integrator, so I am always exploring and trying new things. With those commercial customers, and in my own personal side projects, my recent workflows have gelled around a core set of tools, both commercial and open-source:

PostGIS – I am very comfortable with SQL and tend to use PostgreSQL and PostGIS for a lot of my vector data processing. Lately, this has mainly involved joining up geometries with attributes and doing aggregations and similar things. For example, the vector data in this map of the county-level Maryland Question 6 results was processed in PostGIS. Very simply, I have a baseline table of the counties of Maryland which I will use to create new data sets. In this case, I imported a CSV of the election results, created a view that joined up the data and then selected the view into a new table. This is workflow is much easier with PostGIS 2.x thanks to the use of typmod.

QGIS – In the case of the map mentioned above, the data set is ultimately going to be static so it makes sense to serve it as static content, rather than bringing a heavyweight geospatial server such as ArcGIS or GeoServer into the mix. In these cases, I lean toward GeoJSON. QGIS makes it very easy to export any vector layer out to GeoJSON so it’s become my go-to tool for that. QGIS also has great analytical tools and I consider it a complete functional match for ArcMap but, having said that, I’m actually very comfortable with the spatial SQL functions in PostGIS so I end up doing most of my analytical work there.

Leaflet/OpenLayers – Most of the web maps I’m doing are single-use and pretty straightforward. When that’s the case, I prefer to use Leaflet as it’s a pretty lightweight library. That said, I keep OpenLayers in the mix if the GIS-like requirements get a little more complex. OpenLayers does more “out of the box” than Leaflet but Leaflet is trimmer so it really depends on the use case.

Arc2Earth/TileMill – Arc2Earth is a commercial extension to ArcGIS and I lean on it to make tiles, although it does a lot more than that. I also use TileMill for this purpose but it really depends on where my cartography resides. There’s a lot of good cartography locked up in MXDs and Arc2Earth is just a great way to capitalize on that. It’s also nice that Arc2Earth works in ArcMap, eliminating the need for a license of Server. If I’m building my cartography from scratch, which is not really my strong suit, I’ll lean toward TileMill because it more easily connects directly to PostGIS, which is where my data tends to reside if I have my druthers. Again, it depends on the use case.

Python/Javascript – I’m doing a lot more work in Python these days. It’s become the lingua franca of GIS development in my book. Additionally, the capabilities of Javascript for web maps is evolving at a stunning pace. I can’t see being productive in the long term in the geospatial field without proficiency in these two languages.

So these are the tools that I’m using most often these days as part of my personal workflows. The stable of tools that I use evolves over time, as should be evident if you peruse this blog. In general, I’m finding it very easy to be productive with these tools right now.

This entry was posted in esri, gis, open source and tagged , , , , , . Bookmark the permalink.

4 Responses to Personal Geospatial Workflows

  1. Lakshmanan says:

    Excellent sum up… we are still an ESRI shop

    • Bill Dollins says:

      Thanks. We still do most of our work with ESRI tools as well but I like to keep other tools in the mix as well. I find that I’ve been able to apply techniques learned elsewhere to my ESRI-centric work, so I think it makes me a better consultant for all of my customers.

  2. Don Barker says:

    Thanks for taking time to publish your list with excellent commentary. I’ve been watching the open-source/not debate for quite awhile. Specifically for how to apply it in the federal GIS environment you work in. This helps a lot.

    • Bill Dollins says:

      Thanks, Don. The majority of my federal users are very much Esri users. There are some DoD/IC organizations that are looking at open-source tools, such as SpatiaLite and the OpenGeo suite and I think there’s additional traction for them in the civilian federal world. But, in my little corner of the world (Navy), it’s predominantly Esri.

      The alternative tool of which I make the heaviest use is probably Arc2Earth Desktop. The fact that it runs in Desktop is nice from a licensing standpoint, but it actually helps more from an information security perspective. The network folks don’t like to have too many servers on the network so the fact that Arc2Earth allows users to use Desktop for some tasks that would normally require Server helps a lot.

      Where open-source is coming into play for some of my customers is to augment workflows outside of the Esri stack. A common use case is using GDAL/OGR scripts to automate data ingest processes away from analyst workstations. I’m also seeing more interest in PostgreSQL from customers that would like to jettison Oracle licenses.

      Open-source or not, I am also trying to educate my customers on making better use of spatial SQL in their RDBMS platforms to move some of their spatial logic outside the core GIS stack where object libraries such as ArcObjects and bizarre quasi-database constructs such as geodatabase relationship classes get in the way. By using spatial SQL where possible, you get better integration with standard application development practices and, in my opinion, better performance.

      It’s a process. For those customers that are committed to the Esri platform, there are strategies for fine-tuning at the margins, which is why I like to keep my toolbox diverse.

Comments are closed.