Geography · Economics · Visualization

Timoney Group’s “Hot” List for 2016

We here at Timoney Group headquarters in Denver aren’t above a SEO-pandering listicle–we’ve done it before–and you clicked, so we’re all good.  If you follow tech closely, much of what follows won’t be “new” per se, but the context here is things/trends that could deliver real value to our clients in ways they may not have considered.

Jupyter Notebooks

Code, data, and visualizations–all in one place.


Stop right there.  If you’re like me, keeping stuff organized is a PITA difficult and time consuming.  If you’re working with clients iteratively, or passing stuff back and forth with a collaborator, the Dropbox tango becomes bloated and fraught.  Everything in one place, runs in a browser, supports multiple programming languages–that’s the beginning of what the Jupyter project brings to the table.

The bigger picture is that while our roots are in Geospatial, much of what we do can comfortably fit under the ever-growing umbrella of Data Science.  And the notebook is the format of exchange, whether the underlying code be in Python, R, whatever.  While its roots are in academia (originally as the IPython project), it has heavyweight support from IBM, Microsoft, Google, GitHub, et al: that’s good enough for us and our customers.

AWS Lambda

For most of us, using the Cloud has meant just having a server or cheap disk space Somewhere Else, with performance monitoring and management limited to determining whether the monthly bill from Amazon “looks right”.


The Lambda offering is what we really want from the Cloud: purely on-demand, with provisioning and scaling being Not My Problem. And dirt-cheap.  Since a lot of the value we deliver is essentially along the lines of “Where is x?” or “What’s close to here?”, it lends itself well to building out small, manageable location services that don’t need a server being “on” 24-7.  For those of us who didn’t get into tech to be Systems Administrators, dispatches from the land of the Server-less Startup make for giddy reading.

Matt Perry has a nice write-up of using Lambda to create a simple raster-to-vector geospatial conversion: it should get your gears turning.

APIs of APIs

If eleven years of consulting has taught me anything, it’s that small- and medium-sized businesses vastly underestimate the amount of Technical Debt they are accruing with their internal, custom-coded applications.  If you’re a Project Manager, the question of “how we can build this?” should really be “how can we build this with the absolute minimal amount of custom code?”  With the mainstreaming of SaaS (e.g. Salesforce), we’re preaching the gospel of linking these services’ APIs together using platforms such as Zapier.  For many, being able to send text alerts to workers in the field based on changes in a Google Spreadsheet made back at the main office is indistinguishable from magic.


We have white-boarded for 2016 a very lightweight asset tracking system that will link together a phone’s location, its camera as a QR code reader, a Google spreadsheet as the “back-end” database, a live map hooked to the Google Sheets, and SMS messaging based on geographic triggering with the goal of less than 100 lines of custom code.  Wish us luck!

Dead Simple Mobile Apps

Have you heard about the importance of Mobile?  Me too.  More than once.  But I’m not talking about the iPhone, or Android, or even PhoneGap.  I’m talking a text.

Like, works on a flip phone.


Given my background, when someone asks me a data question I naturally want to answer with a map.  And in recent years that meant an online, interactive map.  Yes, we love Bootleaf because it’s the easiest way to get our interactive maps to work on a variety of devices. But to often they’re messing with something that’s too interactive as they pinch their screen in vain searching for that ONE data point that actually matters to them.

Well, let’s use the power of computers to figure out what that ONE data point is and serve it up to them in the most user-friendly format of all: a simple SMS text.

 *  *  *  *  *  *  *

One could summarize the marching orders for 2016 as being “instead of trying to impress other techies, let’s simplify, and then simplify some more until a paying client looks us in the eye and says we’ve gone too far.”


Brian Timoney is an information consultant in Denver, Colorado.

notebooks photo courtesy of Jose Camões Silva’s Flickr stream
birds photo courtesy of Sigfrid Lundberg’s Flickr stream
plumbing photo courtesy of Russ Morris’ Flickr stream
cell phone photo courtesy of Ken Banks’ Flickr stream

5 Mapping Industry Trends I Saw At JS.Geo


Wait long enough to blog a conference, and you’ll find others have beat you to it.  Bill, Derek, and the folks at Cesium have done a great job with both talk-by-talk reviews as well as a few big picture reflections here, here, and here.  In addition, we posted most of the talk decks/links here.  As co-organizer of the event (along with Chris Helm), the weight of logistical concerns tends to crowd that mind.  But all that being said, there were five themes I saw throughout the day that are worth sharing.

Mapping Platforms Are Ready For Big(ger) Data

Whether through GL libraries (CesiumJS, Mapzen Tangram), advanced techniques for handling heavy time-stamped data (CartoDB Torque), or the newest take on vector tiles (Mapbox, ESRI), the industry has the capabilities in place to display larger volumes of data in more interesting ways. We all like novel maps, but a truly useful future is probably a combination of Platform + Data + Visual Grammar that isn’t quite in place yet.

Turf.js, Everywhere

A benefit of putting on the 3rd iteration of JS.Geo is that you get to see the new “cool” stuff of past conferences become mainstream.  Turf.js–think spatial analysis in the browser–popped up repeatedly in a wide range of demos.  As a developer, there’s much to be said if you don’t need a server to calculate a buffer. But put your point-in-polygon logic in your phone browser that works disconnected from the Internet? Now we’re talking muddy-boots geography out in the field!


Node.js As Back-End Workhorse

Node–server-side Javascript–always gave off the whiff of an edgy t-shirt, not-freshly-laundered. But it’s not just for the hip startups anymore.  We saw old school enterprise-y shops using Node for everyday data processing tasks (data never comes into this world clean, shiny, and usable).  As a consultant sensitive to how daisy-chaining tools together can spawn nasty Technical Debt through a mishmash of programming languages, being able to use Javascript for back-end grunt work as well as the usual front-end browser stuff has interesting efficiencies.

Mappers Are Coming From Everywhere

We can debate all day the pros and cons of making maps without a traditional background in GIS and Cartography (that’s what Twitter is for, right?).  But the fact is the field has never been more diverse with new mappers often going to school in the halls of Github and StackOverflow. I, for one, welcome the new state of affairs if only for the pleasure of regularly pointing out to these new carto-apprentices that ‘choropleth’ has only one “l”.  

But would I have thought of wiring my map navigation to an arduino controller?

No, no I wouldn’t.


Everyone Is Hiring

Even the one guy who said he wasn’t hiring is now hiring.  So yeah, everyone is hiring–coding + geo talent is at a premium.

We’ve been saying this for years, but it bears repeating:  if your daily routine has you doing geospatial work strictly through GUI-driven desktop software, the impact on your future earnings is clear and unmistakable.

 *  *  *  *  *  *  *  *  *

Chris and I want to thank the 26 speakers who presented.  

We especially want to thank our sponsors for making it financially viable.  



If nothing else it enabled us to offer darn good sandwiches.

Oh, and thanks to the guy who picked up the tab at the after-gathering!

Brian Timoney is an information consultant in Denver, Colorado.


Philly skyline photo Bill Morris
muddy boots photo courtesy of Leszek Leszczynski’s Flickr stream


PostGIS Is So Successful That It Needs To Change Its Name

Like all important debates of our time, this one started with a tweet:

I’m no branding expert (I don’t spend nearly enough money on my haircuts), but it seems to me that if your name includes a specific acronym–“GIS”–perhaps you should pronounce it the way the acronym itself is pronounced.  And while we’re on the topic, how obvious is it to the newcomer that the “Post” relates to the PostgreSQL database?

Don’t get me wrong: I love PostGIS, even to the extent of co-organizing an upcoming “PostGIS Day” here in Denver.  But even at the risk of losing an amusing pun on “GIS Day”, one thing is now crystal clear to me–

PostGIS is so successful it needs a new name.

First, the name recognition of PostgreSQL has increased enormously in recent years:  from only Geek Cred to now widespread Street Cred.  So we need to make that association more explicit.

Then we have the acronym “GIS”.

It needs to go.

The assumption that those who would find a spatially-enabled database useful in 2015 would be familiar with “GIS”–either by education or professional practice–is much too narrow.  And while those of us who have earned our chops via GIS courses and years of desktop software may cringe inwardly, the obvious reality is that increasing numbers of bright and talented people who want to do mappy things and geo-analysis things don’t naturally connect such desires with “GIS”.

So I beseech the caretakers of this extremely valuable piece of open-source geospatial software to choose a new readily- identifiable moniker that captures its dynamic centrality in the ever-evolving mapping industry.

Brian Timoney is an information consultant in Denver, Colorado.