If data has a location element, it’s best visualised on a map, right?
Well, that depends.
In geospatial teams, or with people who are GIS-orientated, we’re conditioned to think in terms of maps. The first thing we look for is, “is the data spatial? Is the data in a format that can be represented on a map?
But sometimes we ask the wrong questions or we forget the first rule of map making. What we should be asking is, “what is the purpose, who is the end user and how should the information be communicated?” Sometimes it’s a map, sometimes it’s not, and sometimes it’s a combination.
Those are the questions that the Orbica team confronted when engaging with Environment Canterbury about a customer-facing rates visualisation tool. The tool’s purpose was to show how the regional council proposed to collect and spend regional rates.
The council’s goal was to inform the public about its proposed rates spend as well as encourage engagement through consultation.
Exercising creative license
Orbica’s solution was not map-centric. The desktop rates tool, which was launched in February 2018 to coincide with Environment Canterbury’s consultation period for its draft Long-Term Plan, was designed so that the data could be visualised from different perspectives. It does utilise maps, but as another view of the data, rather than as the primary focus.
Subsequently, the visualisation tool also presents each individual Environment Canterbury project as a bubble. Each bubble’s colour identifies the portfolio the project sits within (e.g. freshwater management, transport and urban development etc) and the size represents the relative expenditure.
It was hard because we love maps, but we had to put that drive aside for a moment because although the spatial distribution of rates was an important component, it was not the application’s sole purpose. The purpose of the application was to communicate rates. What’s the best way to communicate rates? Well, it’s not necessarily a map.
Orbica developed the solution using open-source rather than proprietary software. Here are a few reasons why:
Customer centric – not map centric
The choice to use open-source software was easy once it was decided that the solution would not be map-centric.
Most of the proprietary GIS applications and platforms are mainly map-centric, because that is what they are designed for. So, any solution created in these platforms must be map-based. Ours was not: you can view the data on a map, but it’s focused on data that is beyond spatial. For example, it is very hard to show all projects by revenue, type, and programme on one map without overwhelming the audience. However, by using open source technologies, we could compartmentalise and integrate several libraries - including proprietary systems - to produce the desired visualisation. For example, the application uses Environment Canterbury’s ArcGIS Geocoder that they maintain as part of the search function. Also, by compartmentalising the application, the initial bubbles view can exist completely on its own, without a map if need be.
Orbica utilised HTML/CSS/JS, PHP, D3, GeoServer and PostGres/PostGIS to develop the solution, including a fully functioning CMS.
To create the same solution using equivalent proprietary software would have required separate software licenses for development and production. It would have also required additional development for integrating various structures and formats and the scope of the project did not require a full enterprise system of any one commercial software.
We could have made the whole thing in proprietary software, but it would have meant procuring licenses from various vendors. We didn’t want an ongoing licensing cost. Given that it’s rate payer-funded, and in the spirit of open data initiatives, we wanted to keep the cost as low as possible.
Also, while many potential clients already used different software packages, they did not necessarily want to implement and manage another third-party software. That’s why the application had to be stand alone and capable of integrating with any existing system.
Freedom to create
Another consideration with adopting open source technology was the ability to customise the design.
For doing analysis and your day-to-day work, your off-the-shelf, commercial software is amazing. But when you are trying to communicate something to a large audience, you are constrained by the templates and the functions that it provides. You can only customise it so much.
In open source, you are coding it, so you have the freedom to design and develop the way that you want to communicate. You create it all from scratch.
Developing your skills
Exploring open-source is great for GIS developers, because it teaches you to think about the problem from beginning to end rather than utilising pre-existing tools and algorithms that could be menu-driven and uninformative.
When you are a proprietary software customer, you know all the functions and how they operate. For example, you can use a buffer tool or a clip tool easily without having to think about how they actually work. This is great if you fully understand the restrictions and nuances in the tool, but for the most part, you don’t have much control of how those tools work, or the ability to tweak the tool as required.
When you develop through open source, you actually think about the geographic problem because you have to develop the tool. It’s a lot harder, but it’s a good experience and you may come up with quite a different way of solving the problem than you would otherwise because of it.