User Tools

Site Tools


tutorials:learning_gis

This is an old revision of the document!


Learning a New Field (Maps, Cartography and GIS)

Author: Taylor Robbins Date: September 9th 2025

I recently made the decision to leave my job in the game industry and work on my side project full time. The side project I ended up settling on is a tool in a field of expertise (Geographic Information Systems or GIS) that I have not personally had a lot of experience with, and although the goal of the project is to make something that I might use and therefore I have some intuition about what kinds of tools might not exist that I want to make, I don't actually know much about the existing endeavors in the space, or the breadth of the target audience I am designing for. I suspect that one of the following may be true:

  1. My goals have been considered before and either the software already exists but is not well known, or it has been implemented in a sub-optimal way negating the value proposition of the workflow. For example maybe the tool is only available in a web browser, or only available for dekstop, or only works on a small set of data before slowing down, etc.
  2. The tool I want is particularly hard to implement, meaning that even though the value of the tool would be high, it's not possible to create and previous attempts have never reached a state of release that I would be able to find.
  3. The tool I want is indeed “novel” in the sense that no one in the space has tried to make this type of tool. This is uncommon in the sense that a person that has a lot of experience in a field has likely come across a lot of the “low hanging fruit” kind of ideas, so my ignorant view on the space is less likely to actually prove novel. However, if we talk about the specific form that I imagine the tool existing, the “cross pollination” between two areas of work does often result innovative ideas. For example, my experience making games leads me to think a lot about “fun” interactions and good user experience (UX) patterns as a primary concern and I don't often consider absolute robustness of the tool to be the primary concern (which might not be true for someone coming from an academic background).

With those possibilities in mind it can often feel a little daunting to enter a new space and try to make progress. I am very likely to make incorrect assumptions or follow threads that end up being dead ends. Or I may do a bunch of work on a tool that I think is cool only to realize too late that some tool already exists and is much more capable than my tool.

For this reason I am approaching this project with a much different style than I normally would a video game. I don't have a fully formed idea of what the end product should be. I know I am ignorant of many facets of the problem and most of the history in the space. But I won't make progress on either problem unless I push forward and start trying to make things in the space. While I go I will do research into the space (reading books, finding existing software and testing it's functionality, finding and talking with people in the field, etc.) and then I will take that knowledge I am obtaining and try to apply it to the software. I suspect I will ping-pong back and forth between software development and research quite a lot. This sort of hybrid approach should allow me to make progress rather quickly.

This page should serve a little bit like a blog of my experience, but it will be centered around this core idea that should be applicable to more than just my experience. Each section will cover a particular concrete example of my experience moving from Video Game Development to Geospatial Software, but hopefully the examples help highlight the kind of thing you might experience if you decide to do a similar major transition into a new space. In particular, if you are considering moving into a new field and have been scared of the process, I hope that this page helps encourage you to take the plunge.

Notes

  • First proper use of double
  • Remembering my focus (end user, produce and consume, game-y)
  • Offline rendering of tiles. Downloading subsets of data from API. Map display expectations from users that are hard to implement in real-time.
  • The size of OpenStreetMaps data. Space partititioning. Back of the envelope math for computational capability for an average laptop/desktop. How much distributed computing do we need to solve the problem?
tutorials/learning_gis.1757529448.txt.gz · Last modified: by Taylor Robbins