GIS

Lessons from Maps and Old Code

by

Taking over someone else’s code is hard. There is probably no better look at how a person thinks than looking at their code. It can be tempting to trash their code and start from scratch. This temptation often runs into conflict with a sunk-cost fallacy that says “The previous person spent so much time on this that they had to understand the problem far better than me and maybe my time would be best spent learning from their code.” The really tough part about this is that it’s not always a fallacy.

My own encounter with this dilemma came early in my career – early enough that the code in question was written in AML. The company I worked for at the time had just transferred me to the offices of a large water utility to take over the development of their cartographic production system from a developer who had recently moved on. I had never met this developer and he was already gone, so I only had his code to work from.

Read more

Services, Solutions, and Products

by

Prior to my current role, I spent 25 years working in the federal contracting space. Almost all technology built in that world is one-off and designed for the specific needs of a customer. Often, those needs are complex and meeting them involves creating new technology. “Productizing” a solution is common trope around the Beltway among integrators of all sizes. Most of the time, attempts to do this never get past the whiteboard stage and those that do invariably fail to become anything the wider technology market would recognize as a product.

In my current role, I happen to work for a company that actually succeeded in turning a solution it built to support its original services-based business into a thriving software-as-a-service (SaaS) product. While this represents an anecdotal and statistically-insignificant sample of one, it has helped me understand the differences between successful products and those solutions that never quite get there. I also happen to manage the portfolio of SaaS platforms my company uses for its own operations, so I’ve had a good chance to observe commonalities among many products and contrast them with the solutions in the previous phase of my career.

Read more

Give Me a Standard, Any Standard

by

I’ve spent the last year or so doing very little with geospatial technology, but I find myself missing it tremendously. Of course “in my blood” and “how I’m wired” and similar aphorisms apply to how I’m feeling, but that’s not what really has me missing geospatial. In a shocking (for me) turn of events, I find myself missing the influence of OGC on the geospatial technology community.

I’ve spent the last year working on integrating several SaaS systems, including Stripe, Salesforce, NetSuite, and others. I’ve touched upon this in previous posts. All of them implement some form of REST API, but fostering interoperability doesn’t seem to be a primary purpose of those APIs as much as is the enablement of a proprietary partner/strategic-alliance ecosystem. As a result, these APIs, while generally well-documented, are essentially arbitrary. They implement the HTTPS+JSON pattern in the same way that many written languages implement the Roman alphabet. I can sound out the words, but I don’t really have any idea what I’m saying.

Read more

Simple Isochrone Analysis in QGIS

by

With my MBA program behind me, one of my goals has been to shake the rust off my coding and GIS skills. For this post, I thought I would start simply, just to make sure I remembered how to find my way around QGIS.

We recently purchased a plug-in hybrid. It has a 17-mile range when running fully electric, so I used this as the basis for a quick analysis with QGIS. Of course, any such experimentation isn’t much fun without a few unrealistic assumptions, so here they are:

  1. The car was parked with an empty tank.
  2. It was brought up to a full charge overnight.
  3. Rather than immediately going to a gas station, we’ll go to a charging to top off the battery again.

These assumptions are, of course, ridiculous, but they allow me to have some fun.

I decided to build out drive-distance isochrones representing ten miles and sixteen miles. Ten miles represented the safe range, and sixteen represented the edge of insanity, at which I should use the last mile to find a gas station.

Read more

SaaS, IPaaS, and Interoperability

by

I started this blog back in 2006 during a time when I wasn’t doing much geospatial work at all. I was working on building a human resources system for a federal government customer who was falling under the then-new and now-defunct National Security Personnel System. Because it was new and sufficiently different from the GS system, there were no off-the-shelf products to acquire. So I found myself deep in the development of logic to model workflows for personnel reviews, tracking accomplishments, and other minutiae of managing different types of personnel. There was no room for anything geospatial and I felt it, probably incorrectly, slipping away so I started doing personal projects at home. This blog started out as the means for documenting those diversions, which included my first dabblings with PostGIS among many other things.

I find myself in a similar period now. I’ve been mostly occupied the past few months with migrating to a new billing system. It’s not sexy and it’s certainly not geospatial, but billing is a necessary engine of any business. When people talk about “growing pains” as businesses scale up, billing is one of the biggest.

Read more

Geography, Geospatial, and GIS

by

I was participating in a Clubhouse discussion today when someone asked the about the distinction between GIS and geospatial. Since Clubhouse is audio-only, I am paraphrasing by contribution to that particular discussion here.

I think the boundaries and definitions of these concepts are pretty blurry and I am reticent to create hard distinctions between them. In my daily life, I use the three terms “geography,” “geospatial,” and “GIS,” but I don’t use them interchangeably. I see all three as related in a layered fashions with geography being the bottom base layer and GIS being the top layer. I’ll briefly discuss each from bottom to top.

GrammarFascist, CC BY-SA 4.0 https://creativecommons.org/licenses/by-sa/4.0, via Wikimedia Commons

First is geography. The way I think about it, geography is the science that underpins the entire “geo” technology industry, as well as others. It is the theoretical, mathematical, and scientific construct that defines the boundaries of the sandbox in which we play. Because it’s a science, those boundaries are always changing and expanding, but that’s simply understood. Without the science of geography, the rest isn’t possible.

Read more

Reconsidering the Spreadsheet

by

I’m a CIO. That means a typical day can involve a range of activities: responding to data calls for security audits, reviewing SOC2 reports of prospective platform vendors, managing subscriptions of existing vendors, handling GDPR requests, ensuring data from corporate systems is meaningful and relevant for our internal stakeholders, attending meetings of various sorts. Somewhere … Read more

Return on Non-Investment

by

Yesterday evening, I had the pleasure of participating in a panel discussion on Clubhouse, hosted by Todd Barr and Jordan Cullen, and including Will Cadell of SparkGeo. Clubhouse seems to be a really convenient venue for setting up such a forum with low barriers to entry, so that was enjoyable. The topic of the discussion was “Geospatial ROI” and we talked about various ways to articulate the value of geospatial (the data and the concept) and GIS (the toolset to exploit geospatial).

One topic that we didn’t have time to get to, but has been at the front of my mind for a while is the “return on non-investment” with regard to open-source tools, geospatial or otherwise. Open-source has been mainstream for quite some time and platforms like Github make it easier to publish, manage, and maintain open-source tools. As a result, it’s easier than it’s ever been to find and use open-source tools to solve your problem.

Read more

Routing with BigQuery and ArcGIS Platform APIs

by

This post is a continuation of last month’s post about analyzing location change with BigQuery. At the end of that post, I was already thinking of ways to extend the analysis and visualization. I decided to take the opportunity to explore Esri’s recently-announced ArcGIS Platform APIs. These APIs are the same that have been available via an AGOL subscription or an ELA, but they are now presented in a consumption-based model, similar to Google or Mapbox APIs, that allow you to make use of them without having to make a larger up-front commitment to the rest of the ArcGIS stack. Esri’s basemaps and their location services have always been high-quality, so it’s nice to see them available under a more accessible model.

Decided to use the Esri routing API to visualize possible routes between the various locations of the “Sample Asset” from my last post. I chose to build a very simple Node API to access the BigQuery data and use that API from a simple page that calls the Esri API and displays the output on a Leaflet map. The first thing I needed to do was add a little extra SQL in BigQuery to return coordinates in a format consumable by the Esri API. The raw API expects coordinates delimited as such:

-76.519989228,38.303696474000006;-76.695443826137989,38.376038894414251;-76.635015354340467,38.29745667728772;-76.519989228,38.303696474000006;-76.695443826137989,38.376038894414251;-76.635015354340467,38.29745667728772;-76.519989228,38.303696474000006;-76.495959193,38.236694621

Read more

Analyzing Location Change Over Time in PostGIS

by

Following up on my previous post, I decided to attempt the same analysis in PostgreSQL. The analysis doesn’t make use of any spatial logic itself (yet), but I consider this a PostGIS post because it is using PostGIS geometries.

A simple FME workspace to move my data to PostGIS.

In the past, I have noticed that BigQuery SQL is very reminiscent of that of PostgreSQL, which has helped me ramp my productivity with BigQuery. In the case of the LAG function as used here, that reminiscence is an exact copy. So, again, PostGIS comes through.

Read more