Mapping applications

The GIS behind the button

For much of GIS history, using GIS meant seeing GIS. A specialist sat at a workstation surrounded by layers, toolbars, coordinate systems and query functions. When GIS moved into browsers around the turn of the century, much of that structure remained visible. The user still knew they were using a map system. They switched layers, zoomed to a place, queried a feature or chose from a set of tools that had been moved from the desktop into a browser. The map application looked like GIS because, in many cases, it was still asking a non-specialist to think rather like a GIS operator.

By the 2010s, an increasing number of users encountered something different. They might open a public crime-reporting site, complete a safety checklist, search a land-resource portal or work through a community-response application without seeing anything that looked like traditional GIS. Geographic data, map services and spatial relationships were still doing work underneath. The difference was that the interface started with the task rather than the software. Instead of asking the user to learn a GIS, the application tried to present only the part of the spatial system needed for the job.

In April 2002 the Māori Land Court completed a major stage in its move from paper records to digital land information. Courts Minister Matt Robson described the Māori Land Information System (MLIS) as a complete computerised index of Māori land title and ownership information, accessible across the Court network. Historic records had also been digitised, Māori Land Online was under development, and a Geographic Information System was being built to link with MLIS and show the location and characteristics of Māori land in map form. The 2002 system therefore belongs before the later public GIS portal: it established the Court’s digital land-information base and explicitly prepared a geographic interface for it.

On 4 March 2011 Courts Minister Georgina te Heuheu officially launched the Māori Land Court GIS Project. The internet portal supplied geospatial information for Māori land blocks to land owners, judges, researchers, local government and the public. It used Google technology with LINZ information, supported searching and downloading, could be viewed in te reo Māori, and was designed so further information layers could be added. The public service built on the land-information modernisation already under way inside the Court.

Kōrero Takutai provides a later government example of a subject-specific spatial portal. The Office for Māori Crown Relations – Te Arawhiti publicly launched the coastline information hub on 11 December 2019 after it had been developed for Crown use from 2014. The portal overlaid applications under the Marine and Coastal Area (Takutai Moana) Act, coastal permits, Walking Access information, marae locations and other public records. Applicant groups, the Crown, local authorities and other decision-makers could work from one geographic view of the coast rather than tracing each information source separately.

Mobile field work increasingly used task-specific forms rather than miniature desktop GIS interfaces. The Department of Conservation's Helicopter Boarding Pass used a location-enabled form for a defined safety task. It was a pre-flight safety checklist, not a mapping system. Survey123 supplied the form, location and supporting metadata, but the person completing it did not need to think about layers, spatial databases or web services.

This was a broader shift than a change in screen design. A simpler interface could depend on more deliberate work behind it. Someone had to decide which data were authoritative, what a user was allowed to see, which fields were mandatory, how locations were captured, how records were stored, what happened when categories changed and how the application would continue working after the original project team moved on. GIS became easier for many users partly because more of the complexity had been moved out of sight.

From viewer to task

The first generation of New Zealand web GIS had already reduced the need for installed specialist software. PHEW!, Census WebMap, council viewers, DOCgis and other early web systems let people reach maps through browsers. That was a substantial change, but many of those applications still behaved like GIS viewers. They were designed around the map and the layers available through it. The user generally began by deciding what to display, where to navigate and what to inspect.

A task-specific application reverses that emphasis. It begins with a defined task such as reviewing crime reported in an area, finding land-resource information for a place, recording completion of a safety check or documenting a support need at a location. The interface can then hide functions that do not contribute to that task. A user may never need to know which feature service supplies the map, which fields are stored in the database or which spatial operation is being performed. The application narrows the experience deliberately.

That narrowing can widen the audience. A general GIS is powerful because it can do many things, but that also makes it demanding. A person using it has to understand enough about both the software and the data to choose sensible operations. A purpose-built application can remove choices that are irrelevant to a particular user. The result may be less flexible, but it can also be faster to learn and much harder to misuse accidentally.

This changed the work of GIS practitioners. Requirements had to be understood before the interface was built. Designers had to establish what the user actually needed to decide, which terms belonged to the user’s ordinary work, which locations or categories were visible and which edits were allowed. A GIS analyst could no longer assume that exposing more layers or tools was automatically helpful. Application design required choosing what not to show.

A portal for a subject

The Land Resource Information Systems Portal launched publicly in August 2010. The LRIS Portal gave users access to nationally significant land-resource and environmental data held by Manaaki Whenua. It organised that information so that users could find, inspect and obtain data relevant to soils, land-use capability and related land-resource questions.

An older web map might invite a user to switch layers on and off and explore what was available. A subject portal has to explain what the information is, how it is organised and how to get to the useful part without already knowing the internal catalogue. Search, metadata, preview and download become part of the spatial experience. The map remains important, but it is one step in a larger information journey.

LRIS also shows a different development beyond widening access to reusable government and research data. Once datasets could be distributed online, organisations had to think about how non-specialists would find and understand them. A folder full of downloadable files would satisfy the narrow technical meaning of online access while still leaving most users stranded. Portals therefore became part of the infrastructure of use, translating a collection of datasets into an interface organised around a subject.

Contemporary material recorded more than 1,700 downloads soon after the LRIS launch. People were obtaining data for work outside the portal. The application was becoming a doorway into a larger spatial-data ecosystem.

S-map and Our Environment

Landcare Research followed the LRIS Portal with services that let people use environmental information directly in a browser. S-map Online launched on 29 August 2011, and Our Environment followed in December. David Medyckyj-Scott, then Informatics Team Manager, described the need to serve people who wanted useful maps and information without downloading data into GIS software. These applications extended online access beyond the professional data users served by LRIS.

S-map Online allowed users to search for a location, inspect mapped soil properties and obtain soil factsheets. A farmer or adviser could examine drainage or available-water information for mapped soils without operating the specialist systems used to compile it. The service made a developing national soil-information resource queryable online. Its launch did not mean the underlying soil survey was complete: information was available where S-map mapping existed, and further coverage depended on continued survey work and funding.

Our Environment presented a wider land atlas, covering subjects such as land-use capability, vegetation, erosion and ecosystems. Users could query maps, read explanations and produce reports or printable maps. Links to LRIS allowed GIS users to obtain the underlying datasets. The Informatics team designed the application for people without specialist GIS knowledge, including planners, policy staff, farmers, researchers and the public. Explanatory information helped users interpret the scientific classifications behind the colours on the map.

The two services also required national basemaps suited to their science data. Landcare Research built scale-dependent web maps from LINZ’s 1:50,000 topographic vector data, with additional information from other custodians. This meant rendering the vector features as web maps; it does not imply that the applications used the later vector-tile delivery format. Medyckyj-Scott recalls LINZ identifying these as possibly the first national web basemaps derived from its 1:50,000 vector data. The published technical account confirms the local basemap development, while the priority claim remains his recollection.

Maps beside numbers

A second change was the growing importance of dashboards and interactive reporting. Traditional GIS tended to give the map visual priority. Other information appeared in an attribute table, popup or separate report. Dashboards redistributed that attention. The map could sit beside totals, charts, lists, indicators, date filters and categories, allowing the user to move between geography and summary statistics without constructing an analysis from scratch.

New Zealand Police's policedata.nz, launched on 30 November 2016, provides a strong public example. The service was designed to let people explore crime and victimisation information by dimensions including place, time and demographics. The public interface offered selected crime information and searches. The application constrained the questions to those that could be answered safely and consistently from published data. Users interacted with reports, filters and visual summaries in which location was one of several organising dimensions.

That design also reflects a wider tension in public spatial applications. Location can make statistics easier to understand, but it can also make sensitive information easier to identify. Police therefore had to treat anonymisation and privacy as part of the application rather than as a separate policy document sitting beside it. The public interface required a filtered and anonymised view of the operational records used inside policing. The application had to decide what geographic detail, categories and combinations were safe to present.

The 2016 system also illustrates the maintenance burden hidden behind a public interface. Police records show that policedata.nz moved from Flash to HTML on 31 October 2017. A Tableau Public object for Victimisations Time and Place survives from that period. The underlying public purpose persisted while part of the delivery environment had to be replaced. Applications are living systems that depend on browsers, platforms and components continuing to change after launch.

A dashboard does something else as well. It tells the user, through its layout, which questions the designers think are useful. A general GIS might allow almost unlimited combinations of layers and queries. A dashboard presents selected measures and relationships. This can make evidence easier to use, but it also makes the design choices more consequential. The categories on screen, the default time period, the geographic unit and the filters provided all shape what the user sees.

The form becomes the interface

Forms followed the same trajectory. Mobile forms reduced transcription and helped field workers attach structured observations directly to places and features. Once the approach became familiar, there was no reason it had to remain limited to field inspection. A form could become the front end of a spatial system for users who never needed to see a full map.

The DOC Helicopter Boarding Pass shows this in a particularly clean form. By 2020 the department described it as a compulsory paperless pre-flight checklist and the final check of critical safety controls before take-off. The application's geographic capability sat in the background. It could capture location and other metadata, but the user experience was organised around completing a safety procedure. GIS had become part of operational software rather than a separate mapping activity.

Spatial design remained part of application development. If a form captured a location automatically, someone still had to decide how accurate that location needed to be and what happened when it was wrong. If users selected a place from a list or map, the identifiers had to align with the database. If the form was later used in reporting, the categories needed to remain stable enough to compare records. Hiding GIS from the user increases the importance of getting those underlying decisions right because the user has fewer opportunities to see or correct the machinery directly.

Forms also made permissions more visible as a design problem. A user might be allowed to create a record but not see other people's records. A manager might need a summary but not detailed personal information. An administrator might need to correct data without changing the historical record of who submitted it. These are information-governance questions expressed through an application. They are not solved simply by making the form attractive or easy to complete.

The same pattern appeared outside conservation. Quenten Higgan worked with AsureQuality’s AgriBase and later biosecurity response, while Bronwyn Rodgers used Survey123 in Pāmu farm operations. These applications presented a task, form or decision workflow to the user while spatial databases and services worked underneath.

One system, several interfaces

The 2020 Manaaki system combined several applications. A contemporary technical document described a Survey123 data-entry form with map and dashboard, a separate registration form, a shared feature layer, multiple mapping applications, a tabbed StoryMap used as the main launch interface, embedded forms and viewers, dashboards, website pages, permissions, access groups, backups and reshared public data. Different users encountered different parts of the system according to what they needed to do.

The health and community-response purpose of Manaaki belongs principally in Chapter 27. What belongs here is the architecture of the user experience. A person registering for access did not need the same interface as someone entering place-based information. A manager looking for patterns did not need the same interface as a contributor completing a form. A public user could be given selected maps and information without receiving access to restricted records. The system therefore used several applications over the same broader information environment rather than expecting one interface to serve everybody.

The data-entry form was deliberately designed to make geography simple. The technical record described place-based capture through a small number of mapping steps rather than relying only on typed addresses. Each user's visibility was restricted so that users did not automatically see one another's records. A single feature layer sat underneath, but the application rules controlled which parts of that layer appeared to different people. GIS supplied location and data services behind the application workflow.

Manaaki’s workflow used configurable components from Survey123, ArcGIS Online, dashboards and StoryMaps. Configuration still required substantial design work around the data model, permissions, user groups, backup process, embedded applications and transition options. It reduced some programming effort while increasing the value of understanding how the pieces fitted together.

The system also demonstrates why the phrase "the application" can be misleading. Modern spatial systems often present a family of interfaces over shared data. A user sees the form, dashboard or launch page relevant to them, while administrators see layers, groups and services underneath. The map becomes one component among many. By this stage, asking which single map represents the system is almost the wrong question.

StoryMaps

The use of a StoryMap-style launch interface in Manaaki points to another change in spatial communication. Earlier web GIS invited the user to explore. Narrative mapping can instead guide the user through a sequence. Maps sit beside text, images, videos, charts or embedded applications, allowing the designer to explain a subject rather than merely provide access to layers.

Atlases, reports and web pages had long combined maps with text and images. Modern platforms made it much easier to assemble interactive maps, media and live applications into a single browser experience. A GIS team could publish something that behaved more like an illustrated explanation or service portal than a mapping application.

This changed the balance of expertise again. Cartographic judgement still applied, but the designer also had to think about sequence, narrative, screen size and what the reader needed to understand before reaching the next map or application. The audience was no longer expected to discover the story by turning layers on and off.

That approach became common enough that by the 2020s a StoryMap could be used for professional communication, public explanation, project documentation or operational synthesis. Spatial communication had expanded into structured online publications. GIS could now sit inside a structured explanation with no expectation that the reader would operate GIS controls.

Public applications

Purpose-built public applications also changed the relationship between GIS teams and routine information requests. Before web delivery, a member of the public or another organisation might need to ask for a map, contact a council, purchase a product or rely on someone with specialist software. Early web maps removed part of that mediation. Task-specific applications went further by anticipating particular questions and building the answer path into the interface.

Policedata.nz guides users through selected searches and views. The application already knows the subject, the available measures and the permitted geographic detail. A user chooses among supported questions rather than constructing a GIS analysis. The design makes the service more accessible while also protecting the integrity and privacy boundaries of the published data.

The same principle applies across planning, property, environmental and service applications even where the underlying systems differ. A resident may enter an address and see the planning information relevant to that property. A researcher may search a portal for a dataset. A community organisation may view a dashboard summarising a defined issue. In each case the application acts as an interpreter between the user and a larger spatial information environment.

Applications reduced some one-off mapping requests while creating work in development, maintenance and support. Instead of producing the same map repeatedly for different requesters, specialists may spend more time maintaining the application, correcting data, improving search, testing permissions and explaining edge cases. Automation shifts the workload rather than making it vanish.

In 2018, Orbica helped a regional council present its proposed 2018/19 budget through an interactive rates website. Ratepayers could inspect the proposed spending and the projects funded by rates, turning a council budget into a browsable public information service.

Kā Huru Manu provides a distinct example of public mapping built around iwi knowledge and authority. Takerei Norton managed the Ngāi Tahu Cultural Mapping Project through the Ngāi Tahu Archives Team. Its early paepae included Trevor Howse, Kelly Davis, Matapura Ellison, Jimmy Russell and David Higgins, while Muriel Johnstone contributed knowledge of the Ōraka Aparima takiwā. Iain Gover helped develop a place-name database linked to the mapping system, allowing information to be entered and corrected directly during mapping sessions on marae. The public atlas, launched in November 2017, presented selected information approved by Papatipu Rūnaka from a larger body of collected material.

Applications for staff

The internal version of the same change can be even less visible. A planner, call-centre worker, field coordinator or manager may use spatial information as part of a business process without thinking of themselves as a GIS user. Their application might show one map, one search box and a set of records. It may allow a person to select a property, confirm a location or review a dashboard while keeping the underlying geodatabase and services entirely out of sight.

This widened the organisational reach of GIS. Earlier corporate GIS programmes often focused on increasing the number of people who could access mapping software or browser viewers. Application-based delivery focused instead on embedding spatial capability into jobs that already existed. The emphasis shifted from identifying who needed GIS to identifying where location improved an existing process. That was a different way of thinking about deployment.

The change also altered user support. Training someone to use a general GIS can require explaining layers, selections, queries, scale and other concepts. A well-designed task application can reduce that burden by embedding defaults and controls. However, if the application is too rigid, users may have no way to handle unusual cases. Designing for ordinary work without preventing necessary exceptions becomes part of the product decision.

Good user requirements became part of spatial design. The builder needs to understand the available data, the user’s task, their decision authority, the language they use and what happens when the data do not fit the expected pattern. GIS practitioners increasingly had to work as translators between operational teams and spatial systems.

The hidden spatial infrastructure

The apparent simplicity of these applications can obscure how much GIS remains underneath. A public reporting application may depend on geocoding, authoritative boundaries, regularly updated source data, spatial aggregation, privacy rules and hosted services. A form may write to a feature layer with controlled identifiers and permissions. A dashboard may depend on scheduled updates and carefully defined categories. A portal may link metadata, previews, downloads and maps maintained by different teams.

None of this requires the user to see the architecture. In fact the point of the application is often to prevent them from having to see it. But the infrastructure still determines whether the application is trustworthy. If the address data are stale, the search fails. If boundaries change without the reporting logic being updated, statistics become inconsistent. If a source layer moves, an embedded map can break even though nothing obvious has changed in the interface.

Application behaviour depended on data, services and configuration as well as the visible interface. The visible interface may be the easiest object to archive, but the durable historical work often sits in technical documents, configuration records and source notes explaining what data and services were underneath. The application is the public face of a larger system.

Enterprise architecture, cloud services and APIs would make these environments more durable and more interconnected. Users worked through task-specific applications supported by GIS services.

Maintaining applications

Applications also created maintenance obligations that were easy to underestimate at launch. A map printed in a report remains fixed. A live application depends on software, data, authentication, browsers, networks and organisations that continue changing. The user expects the application to behave as though none of that complexity exists.

Policedata.nz moved from Flash to HTML as browser support and delivery technology changed. The purpose of the application remained stable while the interface technology changed. Similar maintenance pressures affect hosted maps, StoryMaps, embedded forms and dashboards. An application can look lightweight while creating a continuing obligation to test, update and sometimes rebuild it.

Personnel changes affect resilience too. A configurable application may have been assembled rapidly by a small team that understood every dependency. Years later, another team may inherit the system with no knowledge of why a field, filter or permission was designed that way. Good documentation becomes part of application resilience. This was already true of GIS databases, while application proliferation increased the number of components and user-facing dependencies that had to be understood.

A simple interface can also hide analytical choices. A dashboard that provides only selected categories may prevent invalid combinations and make interpretation easier. It can also make the limits of the data less obvious. A user sees a polished answer rather than the messy decisions that produced it. The historical movement towards applications therefore improved accessibility while placing more responsibility on the people designing the defaults.

Live applications are also unusually fragile historical objects. A printed map can survive unchanged in an archive for decades, while an online application may disappear when a service is retired, a browser technology is no longer supported or an organisation rebuilds its website. Even when the service survives, the interface may change enough to erase how users originally encountered it. That makes period screenshots, tutorial videos, technical notes and platform metadata disproportionately valuable for reconstructing this stage of GIS history. The application age produced more public-facing spatial tools, but it also produced records that can be harder to preserve than the paper maps they partly replaced.

The specialist moves behind the interface

By the 2020s, the GIS specialist was often doing substantial work that a user would never recognise as GIS. Someone had to design the data model, prepare spatial services, configure forms, set permissions, build dashboards, test devices, manage updates and decide how applications should respond to incomplete or ambiguous information. The user might see only a button marked Submit or a chart beside a map.

Desktop GIS remained the specialist environment for analysis, editing, data preparation and investigation. The newer assumption was that downstream users could receive a smaller application suited to their job. A planner, manager, volunteer, field worker or member of the public could work through that purpose-built interface while the specialist retained the broader toolset behind it.

GIS staff took on application design, support and information-management work, requiring conversations about users, business processes, language, privacy and maintenance as well as spatial data. Some practitioners became developers. Others became configurators, product owners, data engineers, service administrators or analysts working inside multidisciplinary teams. The common thread was that more of the GIS expertise was being applied to designing what somebody else would experience.

Applications changed how users accessed geographic expertise. Earlier GIS put the specialist and the software in the foreground. Later applications can put the user's task in the foreground and push the geographic machinery behind it. The technology remains spatial, but the experience no longer needs to announce itself as GIS.

The map becomes an application

Browser GIS and task-specific applications continued alongside other tools. Browser GIS made maps reachable without installed specialist software. Consumer mapping changed what ordinary users expected from digital maps. Open-source tools broadened the professional toolkit. Open data widened access to the information underneath. Mobile GIS carried spatial systems into the field. Task-specific applications then reorganised those capabilities around particular jobs and audiences.

LRIS showed a subject portal organising complex spatial information for people who came looking for land-resource data. policedata.nz combined geography with reporting, filters and statistics for a public audience. The DOC Boarding Pass showed location disappearing behind a safety workflow. Manaaki used forms, dashboards, maps, permissions and a launch interface as different faces of one underlying spatial environment. None of these examples required the user to become a GIS specialist.

Maps remained a central way to present geographic information. They became easier to place inside other things. They could sit beside a chart, inside a form, behind an address search, within a story or as one panel of an operational dashboard. The application decided when the map needed to be visible and when location could work quietly in the background.

Once organisations had applications capable of delivering spatial information to large audiences, attention increasingly turned to how frequently that information could be refreshed and how much of the world could be observed directly rather than mapped from occasional surveys. Repeated satellite imagery, multispectral data and other remotely sensed information were moving from specialist projects into regular operational use.

Huia Pacey’s 2005 Lincoln University thesis, The Benefits and Barriers to GIS for Māori, examined adoption through a Kaupapa Māori research framework. It considered the circumstances in which the technology could support Māori development and the difficulties communities encountered in gaining that capability. The thesis provides a contemporary account alongside later cultural mapping projects.

Hauiti Hākopa’s research connects GIS with ancestral landscapes, cultural sites, oral narratives and whakapapa. Ngā Pae o te Māramatanga’s account describes the use of mapping technology to support collecting and working with that information. This places the technology within a research practice shaped by the knowledge and relationships associated with the places.

Practical Māori web mapping

Ngā Poutama Matawhenua provides a sustained example of web mapping being taught as a practical community capability. Early recordings showed how to build an online map of Māori Land Blocks, find property information and create StoryMaps for cultural narratives. Later sessions moved into freshwater data, climate resilience, historical imagery, Kōrero Takutai, QGIS, 3D flythroughs and StoryMaps, council GIS and hapū-led systems such as He Kete Mātauranga. Holden Hohaia demonstrated QGIS projects using census and environmental data, while Keith Holswich described the Ngāti Rāhiri experience of building a grassroots GIS for whenua information. The series is useful historically because it records the point where web GIS, open data and community-controlled mapping were being taught together as routine practice.

LINZ’s linked Ngā Poutama Matawhenua material names Duane Wilkins, Roland Pomana, Matt Grose, Holden Hohaia, Keith Holswich, Karl Majorhazi, Jonathan Hanson as presenters, participants or programme contributors in the verified material reviewed for this history.