Monthly Archives: May 2019

Chris Whong to GeoHipster: “How we build is as important as what we build.”

Chris Whong is an NYC-based civic hacker, urbanist, mapmaker, and data junkie. He most recently worked as the founder and director of NYC Planning Labs, promoting the use of agile methods, human-centered design, and open technology to build impactful tools at the NYC Department of City Planning. He’s perpetually tinkering with open source geospatial technology, open data, and web projects, sharing his work via tweets, blog posts and speaking events. He teaches graduate level technology courses for Urban Planners at NYU’s Wagner School of Public Service, promoting the use of open source tools for mapping, data analysis, and visualization.

Chris was interviewed for GeoHipster by Mike Dolbow.

Q: Whong’s law states that “Every government agency, everywhere is working on a ‘new system’; It will solve all of their data problems and will be ready to use in 18-24 months.” My 20+ years in government have taught me that you’re 100% right on this, and I can’t believe I didn’t think of it myself. Please tell me this will be the subject of your first TED talk.

A: I actually came up with this a few years ago when I was in sales, and was speaking to different state and local governments several times a week. There was always a huge amount of faith everyone had that the “new system” would solve all of their data woes in the near future, but it never seemed to actually arrive. I’d love to do more research on this front, as every government technologist I’ve encountered has some version of this story for “new systems” large and small.

Q: Even after all the gigantic government IT failures, I still can’t believe how many ginormous contracts I see being awarded. (Despite their past success, I’m still looking at this $26 million award with side eye.) But they can’t all be failures, right? Maybe just the billion dollar ones?

A: I think the ones you hear about are the BIG ones… there are probably hundreds of little ones that are just as bad but not big enough to show up on anyone’s radar. There has been some reporting recently in NYC about ballooning construction costs for what should be simple projects like park restrooms. I think you’ll find a lot of the same incentives and poor practices at play in both construction and IT projects. My hunch is that it’s the bigness of NYC that allows for these kinds of things to slip through the cracks. A $14M bathroom is peanuts in a $11B capital budget… and you can’t really inspect that budget unless you’re willing to slog through hundreds of pages of screen printouts published as a PDF.

Q: You recently left your post at NYC Planning Labs. What was your favorite project to work on in that job?

A: That would be ZAP Search. It’s a frontend search tool for looking up information on land use applications in NYC. Basically, anyone who wants to change zoning (including the city) has to go through a governmental process, and there’s an information system that tracks each action. I love this project because we were able to seamlessly integrate spatial data into a non-spatial database. You and I know it’s just a simple join to add geometries to a row in a table, but this has eluded everyone and been a huge excuse for years. In government, spatial is still the realm of “GIS people”, who tend to not be the same thing as app developers.

When you’re dealing with a city that’s the size of New York, the map becomes a critical part of the search UI for making individual projects discoverable. Adding geometries and displaying them on a map goes a long way towards making the data instantly relatable to people. Nobody knows obscure project names or even addresses of things being built near them, but everyone knows where they live and can relate to things happening nearby.

I should add that the GeoSearch API comes in at a close second. (GeoSearch is the autocomplete geocoder API that powers address search in all of our apps) We didn’t even build it, the heavy lift for us was transforming the city’s official address database into a format that would work with the Open Source Pelias geocoder built at Mapzen. It’s a wonderful open source story, and I like to think a contract to build a highly-available autocomplete geocoder in government would have taken years and millions of dollars. We did it in a few weeks, basically for free, by leveraging open source.  We also made it publicly available and wrote a nice little documentation site to help people get started using it.

Q: Can you tell us what’s coming next for you? And whether or not you’ll need to add a corollary to Whong’s law?

A: I’m planning to write a book about my 3-year stint in local government (but I know I’ll just get consumed with side projects during my time off!) I want it to be a relatable easy read full of anecdotes and things I’ve learned being a solo open source developer and building a small (but highly effective) digital team. I’ve accepted a position at Qri (, an open source startup building technology for distributed data collaboration, discovery, and version control. It touches on a lot of the pain points I’ve experienced working with, publishing, and sharing data over the years. I’ll be exploring use cases, building tooling around the core platform, and trying to grow the Qri user community.

Q: Do you think every government organization needs “an 18F” to show the way towards better IT, better user experiences, better designs in government apps?

A: Yes, and it’s important to remember that the culture change is the most important thing these teams bring. The tech tooling is just a fraction of the overall environment. Openness, collaboration, good design practices, continuous learning, introspection/retrospection, sharing, focusing on the user, iterating and shipping code continuously, etc. are what lead to better products. These things require culture change way beyond just saying “use open source software”.

I’ve also described all of the above characteristics as values that are at odds with the way government is usually structured when it comes to tech delivery.

It’s important to think about the long-term sustainability of these progressive values. How do you get them out of the 18F-style team and into the regular standing operating procedure of an agency? How to you make the myriad controls and requirements codified into tech policy support this new way of working? These are things I didn’t stick around NYC Planning Labs long enough to tackle, but they remain issues that my former colleagues are faced with every day.

Q: Have you always been a New Yorker? What do you like – or dislike – about the city?

A: I came here in 2011 to study Urban Planning at NYU. Someone once told me that it takes 7 years to finally call yourself a New Yorker, so I guess I’ve passed that milestone. I always say that once I started getting involved in civic tech, I began bumping into the same people at meetups and events all over the city, and found “my scene”. After that, the big, busy, hectic city got a lot smaller and really felt more like home.

I love that there is so much opportunity here. Whatever you’re interested in, the best and brightest people on the planet who do that thing are either already here or will be passing through regularly. There’s always a meetup or conference, there’s always someone who wants to grab a coffee or a drink, and there’s always someone who knows someone who wants to chat about their bold idea or passion project.

Q: I’m an old school jQuery guy. But I know you’re more impressed with the modern frameworks. What’s your preference and why?

A: My lead developer and I had a healthy React vs Ember debate when I first stood up Planning Labs, and he won because he had better arguments for why Ember was a better fit for a small scrappy team. It’s opinionated, but it brings everything you need for building single-page apps so you can prototype quickly and not have to worry about the myriad parts of the app architecture you would if you were assembling things from scratch. I am still a fan of React, if only because I don’t have to have 3 files open to manage the same component, and I actually like JSX (don’t hate, congratulate!). I was able to squeeze a little React into our portfolio via gatsby.js, the static site generator that powers Everything else is made with Ember, which we’ve built some powerful mapping integrations with and has served us well.

Q: As a former Carto employee, your GeoHipster cred is already well established, as far as I’m concerned. Now’s your chance to embrace the label, or provide evidence to the contrary.

A: I’m proud of the progressive spatial stack we put together at Planning Labs. We were pulling vector tiles out of the carto maps API before they were officially released (you know, “before it was cool”), and figured out how to consume them with MapboxGL. We even got to play with the new PostGIS ST_AsMVT() function to produce vector tile protobufs right from the database. We pioneered print-friendly web map layouts using paper.css, and even got to automate print map creation for New York Land Use Applications, effectively building GIS on the web with automated data and a custom UI. So yeah, I’m a geohipster and proud! I’m bummed to miss JSGeo this year 🙁

Q: As a geographer, does it bug you that so many “New York” teams actually play in New Jersey?

A: I care so little about professional sports that I didn’t even know New York teams play in New Jersey. I didn’t care before and I still don’t care.

Q: What are the merits of a saltwater reef aquarium, and do you provide treasure maps to the inhabitants?

A: A reef tank was something I really wanted to do back in 2010, but I was about to move to NYC and it wasn’t a good time to start the hobby. My wife finally gave permission last year and I’ve been obsessive over starting up the tank. We’ve got a nice 34-gallon reef set up in our apartment with a few fish, some corals, a shrimp, and a crab. It’s high-maintenance, and requires a lot of water production, saltwater mixing, water chemistry testing, cleaning, etc. The payout is worth it, my kid loves to help with feeding and water changes, and the critters all have their own little habits and personalities. The tank is a big stress-reliever, and it’s just fun to nurture a little ecosystem and look to the community for advice and support. I have not integrated mapping or open source technology or into my fish tank yet.

Q: I’m sure our readers in between jobs, or considering a change, would appreciate any final words of wisdom.

A: We were successful at Planning Labs because I refused to compromise on the really important things. I always said “how we build is as important as what we build”, and that meant not doing things the way government IT is comfortable doing them. We still had lots of government cruft in our way over the years, but the basics of modern technology-building were not up for debate, and that made all the difference. By the way, sharing is a BIG part of what I consider to be part of the basics, and is probably our most progressive trait. Half the fun of working on something is sharing the achievements and lessons learned (and the finished product) with others in your community. In my experience, talking openly about what you are working on in government is either discouraged or flat out forbidden.

In summary, figure out what your values are, and apply them to every decision, every project, etc. If your personal values don’t align with your organization’s you will need to fight, defend, and evangelize them at every turn (or go find another organization whose values match yours). The former is preferable if you’re in public service.

Maps and Mappers of the 2019 GeoHipster calendar — Gretchen Peterson, May

Peterson is a geo expert working in the realm of GIS analysis and cartography. Peterson is the author of several cartography how-to books and the co-author of the recently-published QGIS Map Design, 2nd Edition along with Anita Graser of the Austrian Institute of Technology. Peterson’s consulting work has included the creation of numerous map styles for world-wide OpenStreetMap and Natural Earth based vector tiles using Mapbox GL JS including nautical, topographic, humanitarian, and specialty styles for clients such as Digital Globe and Microsoft. Peterson’s work also includes all manner of GIS data management, analyses, cartography, and tools for salmon and shellfish management in the Pacific Northwest.

The Lewis and Clark Expedition map was created for potential inclusion in a future book, which Peterson would like to produce but has not found the time to create as of yet.

The expedition route line was obtained from the Esri Schools and Libraries Program. Basemap data is from Natural Earth. US Historic Territories and States is from the Newberry Library and processed for the date of the expedition (yes, the current states of Maine and Massachusetts both fell under the name “Massachusetts” in 1804) with different colors for states, territories, and unorganized territory. The Missouri river was offset from the route line even though they physically overlap on much of the route. This was done for visualization purposes. A texture was obtained for the background. The Gabriola font is employed throughout. The elevation graph, which shows the extreme elevation changes encountered by the expedition group, was computed with the QGIS profile tool plugin and then exported and re-styled. QGIS and Inkscape were used to further process and finish the map.