GIS in the field

For most of the history of GIS, the computer stayed inside. The field worker went outside. That division shaped how information moved. Someone might leave the office with a paper map, printed aerial photograph, notebook, inspection form and, by the 1990s, a separate GPS receiver. Observations made at a stream, pole, track, culvert or property then had to be matched back to the right feature and entered into the organisation’s database later. Good field teams developed disciplined ways to do this, but the separation between observation and database maintenance was built into the workflow.

Portable computing began to narrow that separation. The change combined portable computing with positioning, structured data capture and synchronisation. A useful mobile GIS had to take enough of the organisation’s map and data into the field, let a worker find or update the right feature, preserve the result, and return it to the central system without creating a second uncontrolled version of reality. The technology was only one part of that. Data had to be simplified, forms had to be designed, identifiers had to remain stable, positions had to be interpreted correctly, and field staff had to know which edits they were authorised to make.

New Zealand was a particularly good test of the idea because the places where GIS was useful were often the places where communications were least convenient. Utility corridors, conservation land, farms, mountains, rivers, coastlines and rural roads did not offer reliable network coverage simply because a project had bought handheld computers. Early mobile systems therefore developed with an assumption that disconnection was normal. Maps and data might be loaded before leaving the office, edits stored locally, and changes reconciled later. Even after mobile networks improved, that basic requirement did not disappear.

In April 2002 Vector described a mobile GIS system that makes the early workflow unusually concrete. Development had begun the previous August. The electricity network company was introducing 40 Compaq iPAQ handheld computers and six Panasonic Toughbook notebooks for field crews. The Toughbooks ran the same Smallworld GIS used in the office, while the smaller iPAQs ran Esri ArcPad with additional software developed to translate data between ArcPad and Smallworld. Each iPAQ also carried a Navman GPS unit so the worker could establish an approximate position in the field.

Staff worked offline between synchronisations. Data moved back to the corporate environment when the handheld was placed in a cradle at the office. Vector had considered wireless access but concluded that the available bandwidth was not adequate for the volume of graphical map data that would have to be sent. The limitation is historically useful because it shows what mobile GIS meant at the time. The system made mapped information available in the field through synchronisation. It was the ability to take a controlled part of the corporate GIS outside, use it where the assets were, capture faults or inspection information, and return the result without retyping everything from paper.

Vector expected the NZ$200,000 project to save about NZ$500,000 a year, mainly by reducing duplicate entry and unnecessary trips back to the office. That figure was an expectation reported at deployment rather than an audited later saving. The workflow logic is clear. A technician looking at a cable, transformer or pole could work against the organisation’s own mapped asset record rather than a detached field sheet. The mapped feature and the field observation were becoming part of the same process. That sounds ordinary now because field applications routinely work this way. In 2002 it was a material reorganisation of how the GIS met the physical network.

A later 2003 account showed the system moving again. HP iPAQs were being used with ArcPad, Bluetooth and GPRS, and field staff could reach the corporate asset register more directly. The shift from cradle synchronisation towards connected field work happened quickly, but it did not abolish the earlier design problem. Mobile systems still needed to decide what data travelled, what could be edited, how identifiers were preserved and what happened if the network was unavailable. Connection changed the transfer mechanism. It did not remove the need for information management.

The first handheld systems also forced organisations to decide what information was genuinely useful in the field. Vector’s iPAQs had 64 MB of memory and a 256 MB storage card. The numbers now look almost comically small, but the design problem has not gone away: a field worker needs the right information, not every byte the organisation owns. Map layers had to be selected, simplified and translated. Symbology that worked on a desktop monitor had to remain legible on a small screen in sunlight. The technical work of reducing the GIS to a field-sized package was part of the application design, not an afterthought.

Rugged notebooks solved some problems by providing a larger screen and more capable software, but they carried different costs in weight, battery demand and price. A utility technician could justify a Toughbook where detailed editing was necessary, while a smaller PDA could handle inspections and simpler updates. The two devices in Vector’s 2002 deployment therefore represented different field jobs rather than a single mobile-computing standard. That pattern continued. Mobile GIS developed as a family of devices matched to tasks, with trade-offs between durability, accuracy, screen size, processing power, battery life and ease of use.

Power and weather were as significant as processor specifications. A field application had to survive a full working day, and a device that was awkward in rain, bright sun or cold conditions could fail regardless of the quality of the map. Ruggedisation remained important in utilities, conservation, emergency work and surveying long after consumer phones became capable GIS devices. The later smartphone did not make these requirements disappear. It changed the threshold at which a specialist device was necessary and made simpler spatial tasks economical for many more users.

The Department of Conservation was confronting the same set of issues from a different direction. Its 2003 enterprise-GIS work documented a national ArcSDE, ArcGIS and ArcIMS environment and described integration with GPS, Windows CE and ArcPad. The technical material discussed downloading and uploading field information, hardware connectivity, datum transformation, standardisation and field verification. The project addressed the practical requirements of connecting handheld GIS with a larger information system. A portable map was easy compared with the harder question of how a field edit became a reliable organisational record.

DOC’s regional staff and project teams adapted GIS tools to field conditions. A central system provided databases, services and standards, while the teams using devices had to make them work on tracks, in wetlands, beside huts and during helicopter operations.

That distinction between architecture and use runs throughout the history of GIS. Institutions often describe systems from the centre because central projects leave the best documentation. The work that makes those systems useful is more distributed. A regional team may adapt a form, simplify a dataset, work out a practical synchronisation routine or discover that a theoretically elegant workflow is useless without offline maps. Mobile GIS made that gap especially visible because the software left the controlled environment of the office and met weather, distance, gloves, batteries, weak signals and people whose main job was not GIS.

North Shore City Council used handheld equipment in 2005 and 2006 to check modelled overland flow paths on site. The council had used LiDAR and GIS to model where stormwater would move across the urban landscape during heavy rain. That analysis could identify likely overland flow paths, but a model was not the same as the street itself. In the summer of 2005–06 a pilot field assessment used a PDA running ArcPad to take the mapped flow paths and supporting council data into the field.

The field engineer could access cadastral boundaries, roads, aerial photographs, stormwater and wastewater networks, parks and reserves, and the modelled overland flow paths. Standard forms and pick lists were used to capture observations in a database-ready structure. Staff used the PDA to compare the model with conditions on the ground. It placed the council’s spatial evidence beside the physical kerb, property, channel and obstruction being assessed. Field inspection could confirm the model, qualify it or reveal details that were not visible in the source data.

This closed a loop that desktop GIS often left open. Office analysis generated a hypothesis about the real world, the field worker carried that hypothesis back to the place, and the observation returned to improve the information base. The project authors explicitly contrasted the method with older paper field sheets that had to be manually transferred into spreadsheets or other systems. Structured mobile capture reduced that re-entry. It also made the design of the form part of the GIS itself because the categories chosen in the field determined what could later be queried and analysed.

North Shore staff used both connected and offline tools. Most supporting layers could be served to the PDA through ArcIMS rather than stored locally, which saved scarce memory and reduced setup effort. That arrangement demonstrates the other direction mobile GIS was taking as networks improved. Some projects tried to make the field device a thin client of the central environment. Others carried more data locally. New Zealand organisations ended up needing methods suited to very different urban and back-country connectivity conditions.

Offline operation remained one of the defining practical requirements of New Zealand mobile GIS. A conservation worker in remote country, a utility crew beyond urban coverage or an environmental team in a catchment cannot treat connectivity as guaranteed. The field application therefore needs a useful state when the network disappears. That can mean cached basemaps, downloaded feature layers, local forms, stored attachments and a queue of edits waiting to synchronise. The details changed across software generations, but the problem did not.

Mobile GIS differed from simply opening a web map on a portable screen. A browser viewer could assume a connection because it had no independent copy of the data. A field system had to survive disconnection without losing context or creating untraceable edits. It also had to reconnect cleanly. Once several people could edit features away from the central database, the organisation needed rules for conflicts, permissions, validation and failed synchronisation. The technology became easier to use while the governance underneath it became more important.

Offline design remained essential as mobile broadband expanded. Coverage improved dramatically through the 2000s and 2010s, while New Zealand’s geography ensured that field teams continued to work in gaps. Disaster work could create new gaps precisely when information was most urgent. Conservation and environmental work often occurred beyond ordinary networks by design. A good field application therefore became less dependent on a permanent connection even as its connected functions improved.

The map attracts attention, but structured forms were often the more consequential change. A paper notebook is flexible because a person can write almost anything in it. That flexibility creates work later when an organisation wants to compare hundreds or thousands of observations. Mobile forms could restrict values, require essential fields, present pick lists, calculate derived values and keep the observation attached to the correct mapped feature. The field worker was no longer collecting notes for someone else to interpret. They were contributing directly to the database structure.

Data quality still depended on the form design. A badly designed digital form can collect bad information with impressive efficiency. Ambiguous categories, poorly chosen mandatory fields, confusing asset types or selection of the wrong feature can send mistakes into the corporate system already formatted and apparently tidy. Mobile GIS therefore increased the value of careful schema design. Specialists increasingly designed the forms and rules used by other staff to capture information.

The DOC 2003 technical material is useful again here because it treated GPS standardisation, datum handling, upload procedures and verification as organisational problems rather than as accessories to the handheld. A national database could not absorb arbitrary coordinates and field files without rules. The same principle became more visible as mobile applications spread to larger numbers of staff. The easier it became to collect data, the more important it became to control what the fields meant.

Smartphones and tablets added another element that earlier field systems often kept separate. A worker could now record a coordinate, complete a form and take a photograph on the same device. The photograph could remain attached to the inspection or observation rather than being copied from a separate camera and matched later through filenames or notes. This was useful for asset condition, compliance, environmental observations, damage assessment and field verification. The visual record became another attribute of the mapped feature.

The convenience needs qualification. A phone photograph is not automatically survey evidence, and a stored location does not guarantee survey-grade accuracy. Consumer GNSS may be perfectly adequate for locating a damaged sign, checking a stream site or documenting a culvert, while being completely unsuitable for defining a cadastral boundary or engineering set-out. Organisations therefore had to match positioning methods to the decision being made. Mobile GIS expanded the range of tasks that could include location, but it did not erase the distinction between approximate operational position and precise measurement.

Where greater accuracy was needed, later phones and tablets could act as the interface for external GNSS receivers. That arrangement is a useful reminder that the smartphone did not replace professional positioning equipment so much as change the front end of the workflow. A familiar device could handle the form, map, camera and communications while a specialist receiver supplied the position. The field system became modular in much the same way that wider enterprise GIS was becoming modular.

The history of mobile GIS can also be read as a history of the return journey. Vector’s 2002 iPAQs returned their edits through an office cradle. Other early projects copied files, imported tables or reconciled field datasets manually. Later systems synchronised over mobile networks or Wi-Fi whenever a connection became available. The physical trip back to the office stopped being the necessary boundary between observation and database update.

Faster return created its own risks. An organisation could no longer rely on an experienced GIS operator to inspect every field sheet during manual entry. Validation increasingly had to be designed into the workflow. Some edits could be accepted directly. Others needed review. User permissions, edit history and stable identifiers became part of routine mobile configuration. The shorter the path from field observation to corporate database, the more deliberate the controls around that path needed to be.

This changed what counted as GIS work. GIS specialists built domains, designed forms, set permissions, prepared offline map areas and managed synchronisation. The map was still there, but much of the expertise had moved behind the interface. Mobile GIS widened the user base partly by hiding complexity from the person doing the field job.

Once field staff could update mapped records directly, authority over changes to the organisation’s version of the truth had to be made explicit. In a paper workflow the delay between field note and database entry often created an informal review point. Someone in the office interpreted the note, checked the identifier and decided how it should alter the corporate record. Mobile GIS could shorten that path to minutes. That was efficient, but it meant authority had to be designed deliberately rather than inherited from the old process.

Different organisations solved the problem in different ways. Some field edits could be accepted immediately because the worker was the person responsible for maintaining that asset or observation. Other changes needed approval, especially where geometry affected legal, engineering, regulatory or public-facing information. Mobile systems therefore developed alongside user roles, edit permissions, validation rules and review queues. The field device might make changing a feature easy, but the organisation still had to decide whether ease of editing and authority to edit were the same thing.

This was particularly important where local knowledge and central databases disagreed. The person standing beside a track, pole, culvert or monitoring site could see something that the office record had missed, but the database might also contain information from surveys, legal records or other systems that was not visible in the field. Good mobile workflows had to preserve both the immediacy of local correction and the discipline of organisational records. Field observations and central data management became more closely connected. It was that the conversation between field knowledge and the central system became faster and more explicit.

The same issue helped move GIS work towards application design. A field application could decide which fields were editable, which values were allowed, when a photograph was required, whether a geometry change was permitted and what happened after submission. Those choices encoded organisational policy into the interface. By the late 2010s, much of the sophistication of mobile GIS was no longer visible as a map function at all. It sat in the permissions, forms and workflow rules that determined what happened to the information after the user pressed submit.

By the late 2010s a field application no longer needed to look much like conventional GIS. DOC’s Helicopter Boarding Pass provides a sharp example. Following serious concern about helicopter risk, the department needed a pre-flight checklist that could be changed quickly and used where helicopter operations actually occurred. A 2019 New Zealand Esri User Conference presentation described the decision to use Survey123 because a checklist could be created and amended rapidly, while also capturing basic metadata such as location, user and date.

By the 2020 annual report the Boarding Pass was described as a compulsory paperless pre-flight checklist and the final check of critical safety controls before take-off. The report reproduced smartphone screens from the application. The mapping component was no longer the visible centre of the workflow. The geographic capability sat behind a task-specific form. That is a different stage of GIS adoption from giving a field worker a portable version of a desktop map.

The example also shows why the DOC story is better understood through operational use than through a simple chain of central GIS management. The 2003 enterprise architecture supplied one layer of capability, but it does not explain every useful field application that appeared later. Practical progress came when project and operational teams could take available platforms and configure them for a real problem. In such cases, the workflow and the people solving it are the historical actors, not the organisational chart above the technology.

The smartphone and tablet changed the economics of mobile GIS because the organisation no longer had to begin every deployment by buying a specialist data collector for each user. Rugged devices continued where conditions justified them, but capable touchscreens, cameras, GNSS, storage and communications were becoming normal workplace equipment. That widened the group who could participate in spatial data capture. A ranger, technician, inspector, scientist or contractor could use a structured field application without learning a general-purpose desktop GIS package.

The change also moved GIS closer to ordinary operational software. A user might think they were completing an inspection, safety check or monitoring form rather than “doing GIS”. Location could be captured automatically or selected from a map. The database could sit behind the application. The spatial machinery could disappear from the user's view even as it remained essential to the task. Earlier generations spread GIS by giving more people access to GIS software. Mobile applications spread geographic capability by giving people a tool for their job and allowing the spatial component to sit underneath it.

The same logic extended beyond formal organisational work. In April 2023 NIWA described electronic Survey123 forms developed for community-based freshwater monitoring groups. The forms could run on mobile phones, tablets or computers and were part of a national quality-assurance framework covering more than 25 variables relating to water quality, aquatic life, habitat and hydrology. The aim was to make community monitoring digital while retaining the governance and context around the observations. It was to make observations more consistent, capture the supporting information needed to interpret them and produce data whose quality could be understood.

That example is a useful endpoint because it combines wider participation with stronger structure. Opening data collection to more people does not require abandoning standards. In fact it can increase the need for them. A form used by many community groups must make clear what is being measured, how, where and under what conditions. The mobile device makes collection easier. The framework around it makes the result useful.

Across these examples the most persistent contribution of mobile GIS is the closing of a loop. The office system tells the worker what the organisation thinks is at a place. The worker goes there and sees what is actually present. The field observation then changes the system that guided the visit. This sounds simple, but it shifts the database from being a product maintained mainly by GIS staff to being an operational record maintained through the work itself.

The North Shore flow-path pilot showed this clearly by taking a modelled result back to the street. Utility work did it by taking asset records back to poles, cables and transformers. Conservation and environmental work did it whenever field observations were compared with existing mapped features. The more immediate that return path became, the less sense it made to treat “the GIS database” as something created only in an office mapping unit.

The loop also exposed disagreements between mapped data and local knowledge more quickly. A field worker could see that an asset was missing, a track had shifted, an access point was wrong or a feature’s condition had changed. Mobile GIS did not solve the institutional question of who was allowed to declare the new information authoritative. It did make the disagreement visible at the point where it could be checked.

By the 2020s the old phrase “mobile GIS” covered several different things. It could still mean a specialist rugged device with high-accuracy GNSS and offline spatial layers. It could mean a tablet used to edit an asset database. It could mean a phone running a structured safety form with location captured quietly in the background. It could mean a community monitoring application designed so people with no GIS training could collect information that still fitted a controlled data model.

The common thread was no longer the device. It was the movement of spatial information into the task. Maps, coordinates, attributes, forms and photographs had become available where the work occurred, and the return path to the organisational system had shortened. The GIS specialist did not disappear; specialist effort moved behind the interface. Data models, permissions, validation, offline behaviour, basemaps and integration increasingly had to be designed so someone else could use geographic capability without operating a full GIS.

Once the field worker could be given a purpose-built interface for one job, there was no reason every office user needed to see a traditional GIS interface either. The same principle could be applied to dashboards, portals, inspection systems, public tools and specialised analytical applications. The map was becoming one component inside software built around a task, with the user’s job increasingly shaping the application around it.