Mapping applications

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.

Mobile field work increasingly used task-specific forms rather than miniature desktop GIS interfaces. The Department of Conservation's Helicopter Boarding Pass is a useful bridge because its purpose was completely clear. 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. The map had not disappeared from the system. It had disappeared from the user's mental model of the task.

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.

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.

The Land Resource Information Systems Portal, launched publicly in August 2010, is useful because it sat between the older map viewer and the later task-specific application. The LRIS Portal gave users access to nationally significant land-resource and environmental data held by Manaaki Whenua. The application provided tools for a particular task. It organised a particular body of information so that users could find, inspect and obtain data relevant to soils, land-use capability and related land-resource questions.

The distinction is subtle. 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. Users downloaded information through the interface. People were trying to obtain information for work outside the portal. The application was becoming a doorway into a larger spatial-data ecosystem.

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.

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 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. That is a good example of GIS capability becoming a service behind a workflow.

Manaaki also shows how configurable platforms changed development practice. The system used 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.

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. The story could be designed around them.

That approach became common enough that by the 2020s a StoryMap could be used for professional communication, public explanation, project documentation or operational synthesis. The major disaster sequence belongs elsewhere because its operational history is substantial in its own right. Here the relevant point is simply that spatial communication had moved beyond the map viewer. GIS could now sit inside a structured explanation with no expectation that the reader would operate GIS controls.

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 guided 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.

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.

Source P8-S04 · Alice Dimond Kā Huru Manu 2018 Te Karaka

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 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.

This is why application history cannot be reduced to screenshots. 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.

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.

The Flash-to-HTML transition in policedata.nz is a useful example because it shows a public service adapting when a delivery technology ceased to be a sensible foundation. 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.

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. Application work required 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.

That is why the map becoming an application is more than a software story. It is a change in where geographic expertise sits. 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.

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.

Source WEB-PACEY-HAKOPA-2026 · Huia Pacey, Lincoln University thesis, 2005

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.

Source WEB-HAKOPA-LANDSCAPES-2026 · Ngā Pae o te Māramatanga research profile