NEW ZEALANDGIS History
Book contents / Chapter 32

Open source GIS

New Zealand organisations adopted open-source GIS software gradually. Early operational uses included spatial databases, web servers and custom applications. By the middle of the 2000s, organisations were assembling systems from c

This chapter in time

Full timeline →
1900192019401960198020002020
5 of 5 events
Chapter

Open source and open data

Open source underneath the map

New Zealand organisations adopted open-source GIS software gradually. Early operational uses included spatial databases, web servers and custom applications. By the middle of the 2000s, organisations were assembling systems from components such as PostgreSQL/PostGIS, MapServer, Apache, GeoServer and OpenLayers while continuing to use commercial GIS elsewhere.

NIWA used open-source software in its work. On 30 October 2006, described using PostGIS to manage spatial datasets containing up to hundreds of millions of features across about half a dozen systems. He also noted that he had recently used PostGIS during two weeks at sea. The message discussed an ordinary technical problem: NIWA was using an open-source spatial database in its operational work.

By 2006 an open spatial database could sit inside serious operational and scientific work. Removing a licence fee expanded the range of components available, while database design, server management, coordinate-system knowledge, data maintenance and user support remained part of the job.

The database arrives quietly

The database layer was one reason open source could spread without attracting much attention outside technical teams. A user might work through a browser, a desktop GIS or a purpose-built application while PostGIS handled geometry and attributes behind the scenes. The organisation did not have to present the system as an open-source GIS. It only had to decide that an open component was suitable for a particular part of the architecture. This made adoption incremental and often invisible. Open source could therefore enter through the basement while the people upstairs kept using the same map application.

By December 2008 Wood was publicly discussing PostGIS, Apache and UMN MapServer as a complete standards-based web mapping environment. In July 2009 he referred to PostGIS tables containing hundreds of millions of point features and discussed MapServer, GeoServer and OpenLayers as practical ways to publish and view spatial information. These records place the New Zealand open-source story firmly in database and server work before QGIS became the most visible open desktop application. Organisations combined software components to meet their production requirements.

A government-commissioned study published in 2009 provides a commercial example. had selected MapServer, PostgreSQL and Apache for an Auckland courier-dispatch website. The system displayed live courier and job locations received from mobile GPS units and supported tracking and replay. Couriers could use the operational service while the software library and spatial database remained behind the interface. Open-source components supported the service’s daily work.

GBS itself makes the open-source-versus-proprietary divide less tidy than later labels imply. and founded the consultancy in 2002 after earlier work through GTU and Geographic Technologies and a period of independent consulting. The company later became a prominent Esri partner, yet this 2009 system used open components because they suited the service being built. Consultancies changed components as customer requirements, staff skills and platforms changed.

NIWA’s 2010 Ocean Survey 20/20 Bay of Islands portal gives a fuller picture of the same approach. Later technical documentation records GeoNetwork handling metadata and discovery, PostGIS storing spatial data, MapServer publishing WMS and WFS services, OpenLayers providing browser mapping and SilverStripe supporting the web environment. Several packages together formed the working GIS, each performing a different job and communicating through agreed interfaces. That component model became familiar across geospatial systems, whether the components themselves were open or proprietary.

Web maps without a single vendor

This period therefore sits naturally after the first generation of browser GIS. New Zealand organisations had already moved maps into browsers through systems such as ArcIMS and other institutional platforms. Open-source server software widened the technical choices available for building the same broad kind of service, adding another route alongside established commercial platforms.

Christchurch had an earlier open-source GIS implementation. Later NIWA technical material records DASmap as an early or mid-2000s application developed by using MapServer and Python Mapscript. was building web applications from open components while browser GIS was still relatively new.

These systems also demonstrate why free software is an incomplete description. Someone still had to install the software, understand it, connect it to data, secure the server, build the interface, test upgrades and respond when something broke. Open source changed the licensing and development model, not the need for professional capability. Organisations could avoid some licence costs or gain more freedom to customise, but the trade shifted towards skills, integration and support.

Many New Zealand organisations combined open-source and proprietary tools. Commercial desktop GIS might be used for specialist editing and analysis while PostGIS stored data, GeoServer or MapServer published services and a web application delivered the result. Later, QGIS could be added to that environment as another desktop option. The software ecology became more mixed precisely because systems were becoming more connected.

QGIS comes into view

QGIS eventually made open-source GIS much more visible to ordinary GIS users because it put a complete desktop mapping environment directly in front of them. Different people and organisations experimented with it, used it alongside other software, funded improvements and gradually placed it into production. QGIS use became more visible in New Zealand’s professional discussions during the early 2010s.

Wairarapa. Imagery CC4.0 LINZ 2021. Imagery CC4.0 LINZ 2021

NIWA provides the best institutional bridge. Its Quantum Map application used QGIS to make environmental information easier to reach through local files and web services. A NIWA publication shows Quantum Map combining WMS, WFS and local data, including aerial imagery, bathymetry, freshwater observations and LINZ-based context. The application was simpler than the full QGIS environment and gave users a route into freely available environmental information.

NIWA later recorded that Quantum Map functionality was merged into the main QGIS application with QGIS 2.6, released on 31 October 2014. Additional NIWA work continued through QGIS plugins and funded enhancements. A New Zealand research organisation was paying for and developing functionality that then entered the wider QGIS project.

That reciprocal relationship is one of the distinctive features of open-source development. An organisation can use a shared code base, commission work for its own requirements and, where that work is contributed upstream, make the resulting capability available to other users. Developer costs remain; the difference lies in what happens to the result. NIWA described funded enhancements becoming part of the core application rather than remaining a private feature locked inside one organisation.

Code goes both ways

The wider project record contains other examples of New Zealand practitioners contributing to open geospatial software and related technical communities. GRASS GIS records, QGIS development and plugin work, mailing lists and later OSGeo activity show local participation extending well beyond downloading packages. Some practitioners wrote modules or code, others tested software, maintained documentation, developed plugins or helped other users solve problems. These activities were less visible than buying a major enterprise system, but they were part of how capability spread.

The community around the software also changed support arrangements. A conventional vendor relationship offered a recognisable path for licences, account management, training and technical support. Open-source users could draw on project documentation, developer communities, mailing lists, local consultancies and specialist staff. In practice, many organisations combined these models. They bought commercial support for open software or relied on consultants even though the program itself could be downloaded freely.

Cost therefore needs to be read as a whole-system question. Open-source software could remove a purchase price or per-seat licence from part of a system, which mattered for small teams, education, research and organisations needing many users. It also gave developers direct access to code and more freedom to automate deployment. Servers, staff, training, migration, security, testing and maintenance still carried real costs. The licence line could shrink while the capability and support lines grew.

The more enduring change was technical choice. A GIS team could select desktop, database, server and web-interface components separately, connect them through standards and replace them at different times. That made some architectures more flexible while increasing dependence on local technical knowledge. A system assembled from several excellent parts still needed somebody who understood the whole thing.

The real cost of free

During the 2010s, the binding constraint for some public-sector teams was specialist capability rather than the software purchase. A production PostGIS, GeoServer, MapServer or QGIS environment still needed people who could design, secure, integrate, test, monitor and support it. Spatial developers were a substantial staffing commitment, and a tight FTE ceiling could make that commitment harder to carry than a subscription or enterprise licence. The apparent saving therefore depended heavily on which skills already existed inside the organisation and which had to be recruited or contracted.

Simple return-on-investment comparisons were awkward. Commercial licensing produced a visible recurring invoice. Open-source costs were distributed across developer time, infrastructure, integration, training and maintenance, while benefits appeared as avoided licence fees, flexibility and control. A bespoke application delivered the functions a team had actually built and tested; every additional dashboard, field workflow, public viewer or automation added another component that someone had to maintain through browser changes, security patches, library upgrades and staff turnover.

Integrated commercial suites changed the calculation because they supplied many application types within one supported environment. By the later 2010s the ArcGIS family could combine desktop editing, enterprise services, hosted feature layers, field capture, configurable web applications, dashboards, identity, sharing and automation. Open components could reproduce many of those functions, sometimes very effectively, but an organisation had to assemble the combination itself or pay a specialist supplier to do so. Few alternatives offered the same breadth as one supported product family, which made the comparison very different from choosing between two desktop GIS programs.

The proprietary route concentrated a different risk. Enterprise and hosted licensing could spread platform access across many users and application types, making additional use cheaper at the margin for organisations already committed to the environment. Renewal also concentrated leverage with the supplier. Once databases, applications, identities, field workflows, automation and staff skills depended on one platform, an enterprise agreement became difficult to unwind quickly. Licence cost therefore sat beside a much larger switching cost, and renewal negotiations could expose how dependent the organisation had become on the vendor.

A mixed toolkit

By the later 2010s, QGIS was sufficiently established that government could build direct connections to public data around it. By 2018, the LINZ Data Importer plugin provided a route for bringing LINZ Data Service and other public geospatial information into QGIS. The larger history of open data and licensing sits alongside this one. An open desktop GIS could connect directly to authoritative government spatial services, reducing manual downloads and assembly.

QGIS also appeared beside commercial software in training, research, conservation and community work. That coexistence is important. A practitioner might use QGIS at home or for a particular project while using ArcGIS at work. A research organisation might run PostGIS and GeoServer while maintaining commercial software for particular analytical or enterprise tasks. A council or consultancy might choose software differently for desktop editing, databases, field work and web delivery.

Several GIS products coexisted and competed rather than one platform replacing all others. Instead, the assumption weakened that an organisation needed one product family to supply every layer of its spatial environment. Databases, desktop tools, web libraries, services and version-control systems could come from different communities. Commercial vendors were adapting at the same time, expanding their own platforms into web, mobile, cloud and enterprise environments. New Zealand organisations used a wider mix of GIS tools.

This also changed the work expected of some GIS specialists. Database skills, SQL, scripting, web services, plugins, repositories and software configuration became more common around traditional mapping and analysis. Most analysts remained analysts, while the boundary between GIS administration and software development became less tidy. Open-source systems were one contributor among several.

The national map adopts open tools

LINZ used open-source tools in national topographic mapping. LINZ began its Future Topographic Maps programme in November 2024 to replace ageing production technology and modernise the way topographic data and map products were maintained. Later programme documentation records QGIS and Kart as intended key tools in that future production environment, with QGIS supporting cartographic editing and layout and Kart providing spatial version control. Because those descriptions were published after the historical cutoff, they are used here only to document the direction of the programme that had already begun by 31 December 2025, not to claim that the later production state had already been achieved.

Kart represented a different kind of practice in the programme design. Later LINZ documentation described it as spatial version control, tracking changes to geographic data in a way comparable with software teams managing code. Earlier national mapping systems had also controlled revisions and production stages, but the technical model here came directly from modern software development. The spatial dataset became a version-controlled asset whose changes could be tracked, compared and managed through a dedicated workflow.

Future Topographic Maps was still an active transition at 31 December 2025. LINZ planned to use open-source software for national topographic map production. Landonline, data services and geodetic systems used other software environments.

That would have been an unusual proposition in the desktop GIS market of the early 1990s. By the 2020s it barely required explanation. Open-source databases and servers had already spent years behind working systems, QGIS had matured as a desktop and cartographic tool, and organisations had become accustomed to combining products from different sources. National mapping moved through several generations of systems; other organisations followed different implementation paths.

A community large enough to host the world

The professional community followed a similar trajectory. New Zealand practitioners had participated in mailing lists, open software development, local workshops and regional FOSS4G activity well before the mid-2020s. The first QGIS User Conference was held in Nødebo, Denmark.

From 17 to 23 November 2025, Tāmaki Makaurau Auckland hosted the global FOSS4G conference. Workshops, conference sessions and community events brought open geospatial users, developers, researchers and decision-makers from New Zealand and overseas into one event. The local community organised and hosted an international gathering for open-source geospatial practitioners.

The timing is revealing. NIWA’s PostGIS use had been documented in 2006, nearly two decades earlier. During that period open-source geospatial technology had moved through databases, web services, custom applications, desktop GIS, plugins, training, data services and official production environments. Much of that work had been quiet. The 2025 conference simply made the accumulated community more visible.

Many tools, one practice

Open source widened the set of tools available, made it easier to assemble systems from separate components and created more routes for local developers and organisations to contribute directly to software they used. It also brought new responsibilities. A flexible stack still required people who could maintain it, and technical dependency shifted from a single vendor towards code bases, specialist skills, integration choices and the people able to support them.

Organisations used open-source and proprietary software together. NIWA used open databases, servers and desktop software while operating inside a wider mixed technology environment. Commercial firms built production services from open components. Government made authoritative data easier to consume from QGIS. LINZ later placed QGIS and Kart inside the future national topographic production workflow while retaining many other systems for other purposes.

The mixed environment had become normal by the end of 2025. Asking whether an organisation was an open-source GIS shop or a proprietary GIS shop could miss how modern geospatial work was actually assembled. A map might be edited in one desktop application, stored in a different database, published through another service, checked by automated code and consumed in an application built with yet another set of libraries. Organisations combined products within their working processes.

Open-source GIS changed the choices available to New Zealand practitioners and their relationship with software developers. Alongside commercial enterprise systems, web mapping, open data, mobile GIS and cloud services, it helped make geospatial work more connected and easier to assemble from separate components.

Chapter source notes

1. NIWA / Earth Sciences New Zealand institutional history is the principal source for the Quantum Map case. Master Research Register P9C-S16 documents Quantum Map being built on QGIS, its functionality being merged into QGIS 2.6 in October 2014 and continued NIWA plugin development. It is evidence of institutional production use, not of open source replacing commercial GIS nationally.

2. The project research corpus documents NIWA/PostGIS open-source practice publicly by 2008–09. These examples demonstrate a production stack in which database, desktop and web components could be assembled from open-source software. They should not be generalised into a national market-share claim.

3. The Future Topographic Maps programme began in November 2024. Later LINZ documentation that mentions QGIS and Kart may be used only retrospectively to establish the direction of the pre-cutoff programme. A 2026 implementation state must not be narrated as though it existed by 31 December 2025.

4. FOSS4G 2025 Auckland, held 17–23 November 2025, is a legitimate endpoint for the visibility and maturity of open geospatial software communities in New Zealand. The conference does not by itself prove organisation-wide adoption of any specific product.

5. The evidence supports durable open-source production options alongside commercial GIS, not a separate story in which one software model defeated the other.